fucking awesome ! thanks a bunch man will try it out in a bit

ok i tried it out and im only disapointed with the cavity thingy heheh because even if i tweak the radius etc it always gives bad result, if i go with low radius it is plain white, if i go middle etc is full of holes , there doesnt seem to be happening anything .




there is another thing tho, everytime i exit xnormal it automatiocally clears the list of models, i think it would be cool that you could load the program and the settings be the same as the previous launch , then if we want to clear we use the Clear button , no ?

also the program reports less memory available than his predecessor ( ?? )

kickass tho , ambient oclusion is really clean now.

Originally Posted by Johny

ok i tried it out and im only disapointed with the cavity thingy heheh because even if i tweak the radius etc it always gives bad result, if i go with low radius it is plain white, if i go middle etc is full of holes , there doesnt seem to be happening anything .

Don't set the radius near zero(left)... try to keep it always a bit more to the right. If the result it's too white you can play with the constrast slider a bit. Btw, the search radius is proportional to the object's radius ( 1/50 times exactly ) so perhaps you'll need to bake the hands sepparately from the body to get better results.

Well, I tested it with the smiley example and got a reasonable image:



(radius 70%, contrast 70%, 64 samples, jitter=on, notice the fine detail's cavity wrinkles )

but I must admit it still needs some tweaks. I'm gonna try to improve it with the time! Atm is very experimental. If you can pls send me any example(with wrinkles, pores, etc) I can try to adjust it better.

there is another thing tho, everytime i exit xnormal it automatiocally clears the list of models, i think it would be cool that you could load the program and the settings be the same as the previous launch , then if we want to clear we use the Clear button , no ?

Yep, it should save the last settings automatically. If it does not then it's a bug...But I cannot reproduce that behavior, I need more info.

Hey Joghsy, would it be possible to exclude the interface and mouse-pointer from screenshots? I know I can turn the interface off, but that still leaves the mouse-pointer, which I routinely forget to place near a corner or something, heh. This is basically asking for a way to counter my own stupidity, but that's what programmers are for, right?
Also, I've ran into a problem a few times where (quite randomly, it seems) turning off the interface makes everything go a lot slower.

Originally Posted by MightyPea

Hey Joghsy, would it be possible to exclude the interface and mouse-pointer from screenshots?

Ok, gonna hide it when you do the screenshot.

And yep.. i'm gonna change a bit the cavity options to get more control over it.

Hey jogshy. Thanks a lot for making such a tool available for free. I use it daily, and the whole team I was with at Ubi have been converted into using it because we were 2 users of it and it was so fast and produced so clean results... ;)

Some notes about what I'd like to see in future versions:

check boxes to bake Diffuse / normal / AO in one go, maybe even the possibility to add custom slots where you could add you own map to render by default. Maybe there is a way to do it right now but I don't see any right now (I liked it in previous versions and kinda miss this).
Just let me put a suffix next to the checkboxes this way all my objects will have _N or _D at the end of the map.

Also I'd like to see groups baking of some sort. I like to do groups of objects for baking, like for example, separate my high res / low res model in different groups that doesn't intersect with each others (often the highs have a lot of small instanced objects), to avoid baking part by part and avoid rays penetrating in other objects, and at the end I compute the final normal/AO/Diffuse in PS. But an option to set up groups and compute the final map for me would be ace. Not sure if i m clear but I could make a quick example...
Even better, tag objects (by giving then specific names, like a prefix) to identify groups and then import each groups in xnormal and let him split each group by itself. This way it would calculate the AO on all objects at once and render it separatly but with accurate result (right now if I have an object at the very top it's not getting a lot of AO as the other objects are on another group and the AO isn't calculated on everything). Again maybe there is a way to do it but no one I know was able to do it...Would work for vertex AO as I use sorrely this tool with GREAT results. Maybe an option to subdivide the high before calculating AO and saving the SBM on top of that to have really clean Vertex AO results?

Also, a way for Xnormal to bake materials that you set up in your 3D proggy...I know it sound tricky, but as I do right now it's a long and tiring process...I set my materials in Max on my high to have a base diffuse, and then Render textures the high mesh after auto unwrap (Sometimes it's a pain, because of max always wanting to do everything multi subs, so when you have mutliple objects with multi subs...Anyway...) Then Export my highs with UVs and bake the diffuse texture on the low mesh. Why not try to export from max (or maya) maybe just converting to vertex color...this way I'd just not have to bother about having to map quicly map and then bake the diffuse of my highres...I'd just toss some materials on parts I want them and Export my Highs without any mapping coordinates but with materials that Xnormal could see when baking the low meshes...

Cheers!

There are good points on that suggestions, fr0gg1e.
Gonna make all that for xn4.

hey jogshy i tried what you told me, but i think it is still too bugyy , because i have to find the perfect value and the perfect contrast , would be cool if it could have numerical input, but still it is very accurate, ill try it with something else tonightand post images for you to see. Thanks a bunch !

Originally Posted by Johny

hey jogshy i tried what you told me, but i think it is still too bugyy , because i have to find the perfect value and the perfect contrast , would be cool if it could have numerical input,

Yep. i'm changing it for the 3.15.1 and I'm also trying to refine the algorithm.

Thanks Jogshy! Also, I like Frogg1e's suggestions, I'm glad to see you'll be implementing those. Xnormal is becoming better all the time!

there is another thing tho, everytime i exit xnormal it automatiocally clears the list of models,

I'm trying to reproduce that bug but I cannot find them... Can anybody confirm this is happening and when, pls?

ok santi , heres what i got from the cavity tool, the amboc tool seems to be improved ( that or i finnaly found the right settings eheheh ) but the cavity i see that the image has exactly what i want but the cavitys itself are way to thick making it unusable , i tried playing with the radius and contrast but still too thick it would be awesome you made this as clean as your amboc tool , i would be using this the whole time !

Originally Posted by Johny

ok santi , heres what i got from the cavity tool, the amboc tool seems to be improved ( that or i finnaly found the right settings eheheh ) but the cavity i see that the image has exactly what i want but the cavitys itself are way to thick making it unusable , i tried playing with the radius and contrast but still too thick

The right image seems to have too much contrast... but don't worry, the new options I'm preparing for the 3.15.1 will solve it.
Btw, don't use the 3.15.0.... I realized the normal compression introduced makes some small(but noticeable) errors in the tangent space normal maps. The 3.15.1 beta will be available soon.

Btw... I was trying to reproduce that mesh clean error you said but I cannot find it... do you know when happens, pls?

I just uploaded the 3.15.1 beta 1 in case anybody wanna test it a bit.

Respect to the cavity options I added numerical controls instead of the track bars... and also added an option to trace more samples. To measure a good cavity distance pls referer to the xNormal documentation... and perhaps the default contrast I put is too high(2.0... better use 1.25... i'll change it for the final version though).

thx

thank you kind sir

I'm having some problems with the few newest versions of xNormal: the normals are rendered as if the hi-poly model had been set to hard edges instead of smooth. I've imported the models as .objs as I did before and it shouldn't be because of my modeling app.



Also, the newest version caused a lot of artifacts in the normal map. This hard edge baking problem exists in 13.14.2 too (I've only tried 13.12.0, 13.14.2 and 13.15.1). I've played around with settings (such as smooth normals etc.) to no avail. Do you have any idea what's causing this?

Hi Jog!

Thanks a ton for the new wireframe baking option! it's one of these little things that help a lot.
Also It would be nice to see the return of multiple bakes at once, even with something very simple when it comes to naming conventions. Like, the user gives a generic name to the bake and the maps get named like nameofthebake_normal, nameofthebake_ambiant and so on. But I am sure you have something similar planned for the near future.

However I couldn't get the cavity maps to work - it definitely shows parts of the wireframe of the highres mesh, like this
http://img530.imageshack.us/img530/2984/handfuxjl2.jpg

I understand that most of the time the meshes to be baked are so dense (sculpted) that it gives an impression of a decent cavity map, but for mechanical objects for instance highres sources might be much lower - hence giving weird result with the current calculation technique you use.

Hope this helps!

[edit]
Also - I usually don't really use imported cages as I rather spend the time to find the right distance values. However I just discovered that there is a cage slider in the 3d viewer. I would assume that as soon as I 'expand' this cage in the 3d view, this gets used as cage reference for the next bake ; however when I launched a new bake after setting this up I still got the same baking errors due to too long a fetch distance. It felt like the bake didnt take the user-defined interactive cage into account.
Am I doing something wrong?
(I tried 'save mesh' as Ogre when messing with the cage in the 3D viewer, but when I loaded back the saved object it was the same thickness as my original lowpoly... I must be missing the 'save cage' button somewhere!)

Originally Posted by Vylaroth

I'm having some problems with the few newest versions of xNormal: the normals are rendered as if the hi-poly model had been set to hard edges instead of smooth.



Also, the newest version caused a lot of artifacts in the normal map. This hard edge baking problem exists in 13.14.2 too (I've only tried 13.12.0, 13.14.2 and 13.15.1). I've played around with settings (such as smooth normals etc.) to no avail. Do you have any idea what's causing this?

Well, assuming it's not a bug(perhaps it is), now you can specify three "smooth normals" modes:

- "harden normals". It's an experimental mode to avoid the need for beveling objects with hard edges.
- "average normals". Equivalent to the old "smooth normals" one.
- "use exported normals". Use the normals the user set.

If you use 3dsmax then remember the old 3dsmax2obj plugin which comes with 3dsmax is very buggy ( that's why they changed to g::Obj in 3dsmax 2009 ).... so better use other OBJ exporter or format ( or better the SBM mesh exporter ).

On the other hand, the 3.14.0 introduced adaptive sampling like Mental Ray does. You need to set correctly the min/max samples and the AA threshold. To get more quality, for example, use minAA=1, maxAA=4, threshold=0.05. To disable it just set the threshold to 0.0. Use the diagnostics option to see how the samples are taken.

However I just discovered that there is a cage slider in the 3d viewer. I would assume that as soon as I 'expand' this cage in the 3d view, this gets used as cage reference for the next bake ; however when I launched a new bake after setting this up I still got the same baking errors due to too long a fetch distance. It felt like the bake didnt take the user-defined interactive cage into account.
Am I doing something wrong?
(I tried 'save mesh' as Ogre when messing with the cage in the 3D viewer, but when I loaded back the saved object it was the same thickness as my original lowpoly... I must be missing the 'save cage' button somewhere!)

You need to check the "use cage" option in the corresponding lowpoly mesh slot. If not the cage is ignored ( the data won't be loaded )... that's probably why you see the cage reset. Btw, better use the SBM mesh format when saving the cage(the "save meshes" button). Currently, the Ogre mesh exporter cannot save the cage's data... only the OVB and the SBM can(but the OVB is a text format using XML DOM so will be very slow, specially when dealing with big meshes ).... so better use the SBM one ( which, btw, you can export/import in 3dsmax ).

Thanks for the quick reply Jogshy. I'll play around with the settings. ;)

I got to tell you that I just love xNormal. Keep up the good work with it.

Uploaded the final 3.15.1. Two critical bugs were solved.

Uploaded the 3.15.2:

- Added an option to paint the UV seams in the "render wireframe and ray fails" map type.

- Solved some bugs ( incorrect mesh clear, 1/1 diagnostics error, etc )

Hello i have a problem.I cant render out a normalmap,Ao map from 3ds max becuse the highpolymesh is to dense

Now i found Xnormal but i get stretchings in the final render,But in the middle of the render it looks perfect,Why do i get this error?I have been trying everything now i think

This is in the middle of the render which looks perfect!



This is the final render and you see the streched parts


*Edit*I found out that it was the Padding that was set to 16,I now use 2 and it looks okay besides i get like this guy!,Stange waves or stretches inside the mesh
http://img86.imageshack.us/img86/6374/aoproblemcy6.jpg

Originally Posted by Thewiruz

Hello i have a problem.
*Edit*I found out that it was the Padding that was set to 16,I now use 2 and it looks okay besides i get like this guy!,Stange waves or stretches inside the mesh
http://img86.imageshack.us/img86/6374/aoproblemcy6.jpg

Well, it's hard to tell you a solution if you hide the interesting options with the preview window on the screenshots :poly120:

Use padding 16 better... 2 is too low for a 1024x1024 image. With 16 you will avoid mipmapping artifacts for a 2048x2048 map... Don't worry about the pixel "flooding" unless you need a very very compact UV layout(more dilation=more wasted space... but less seam problems )

To avoid those waves do this:

1. Increase your AO # of rays to 32 or more. More=more quality, but slower.

2. Your AA threshold is too low. 0.100 is for fast tests. Usually you need 0.05. This works like MentalRay's adaptive sampling.

3. Increase the minAA to 1 or 4. The 1/4 is for fast tests and produces too much "interpolation" between pixels.

4. Sure you disable the adaptive AO. This is a thing to stop occlusion ray firing if after casting "adaptive interval" the occlusion does not vary more than "ao adaptive threshold"... This is used to speed up AO... but can introduce artifacts(specially with less than 32 rays in the adaptive interval).
To disable adaptive AO just set the "adaptive interval" to the same number than the AO "rays".

So... use the settings I put in this screenshot and the AO will be renderered well:

johny has been having some problems, and he's too big of a baby to get real internet, so i'm posting this for him.

Originally Posted by EarthQuake

johny has been having some problems, and he's too big of a baby to get real internet, so i'm posting this for him.

Haha!

Originally Posted by EarthQuake

I think that's a problem with the AO bias. Try to increase it.
And sure you aren't using adaptive AO ( set the AO interval to # of rays to disable it ).
Have you tried to scale up a bit the mesh btw? And sure the cage is not very close to the lowpoly model.

Well, I would need the model and the settings to debug it though.