Shopping Cart
Help Requested: Occlusion issue in xNormal after using cavity map.
November 22, 2011 - 12:00pm
- 979 reads
Hello!
I have a strange issue that always happens for me, which persists no matter what I do. When choosing maps to bake, if I set it to bake an occlusion map and also a cavity map - the map it renders for occlusion is definately not an occlusion map, and the one it renders for a cavity map much more resembles an occlusion map. Even if I un check cavity, I get the same results for the occlusion. I have also reset my settings, un-installed and re-installed (though it seems to have remembered what meshes I last used despite the re-install, so perhaps settings didn't get deleted?) and I still get the same result.
I would appreciate any help figuring this out. Thanks!
Below you can see an example of what I mean, as well as my occlusion settings - cavity map settings are default. From now on, I won't use cavity map - except that I have to right now in order to get something close to occlusion.
Thanks!
Thats the interesting thing though as i have created the cages. All the other maps bake out fine - it is just this persistent odd result, regardless of what is being baked. I will experiment a little more - but I'm resonably sure that everything is as it should be with the cage and settings.
Thank you for your response. Is there anything else you might be able to think of which could cause the issue I described above?
Please, perform a ResetXForm in 3dsmax ( or Freeze transformations in Maya ) before exporting. That may prevent flipped normals.
Try to use the SBM exporter if possible.... or OBJs. The other formats might be not as mature as those importers.
Also, try always to center your objects near the world origin (0,0,0) or the search radius won't be accurate.
Other thing you can try is to play a bit with the AO bias value: if you set it too small the rays may hit the emiting surface producing self-occlusion artifacts ( == too black image ). If you set it too high then some details could be skipped ( == too white image ). The bias is expressed as a percentage of the object's radius, that's why you should center your objects near the (0,0,0) origin.
Thank you for the replies jogshy. I always bring in OBJs and am pretty religous about freezing my transforms (I'm a maya guy). The specific objects that I am baking currently are several combined pieces which have different positions, which might have something to do with it as you mentioned. I won't be back to work until monday to test this but will check to see if I can get different results with some of the other things you mentioned.
Have a happy thanksgiving!
Oh, I forgot it.
You can see if your exported normals are flipped entering the 3D viewer and enabling the "show normals" option. Normals should be then present in blue and pointing outwards.
Hey there Jogshy. When I check show normals the object will be shaded with all the bright colors of the normal spectrum, and when I check show tangents it appears to show the normals you described. I assume that was the one you meant?
I have a case where I am baking out individual objects from a sort of extended group of objects (think about a huge semi truck). In this way many objects are not centered at the origin. I did my High poly sculpts in Zbrush and can't export an OBJ (if imported from zbrush with vertex colors) from maya and retain the vertex coloring - so I am wondering how I might be able to retain the high and low poly proximity while still getting them to the origin, especially considering the two different programs. All other maps seem to bake fine - but I seem to still have strange occlusion issues. The only thing I haven't tried is having the objects in question at the origin because of the difficulties mentioned above.
Anyway, thanks for your responses. I may post more information here in the future/near future if I discover anything.
I forgot a thing: sure you checked-in the "Ignore per-vertex occlusion" in the mesh slot. It's possible that you baked the per-vertex AO previously ( with some weird params ) so xN will use those values to interpolate the per-pixel AO. That may explain why you get the occlusion so dark.
Anyways, if you want, send me a PM with the files. I'll take a look.
I almost always have Ignore per-vertex-color checked off on the HP mesh because I bake out vertex colors from Zbrush to a diffuse map. I don't see "Ignore per vertex occlusion" - is this the same thing? If so I may have to do two bakes - one for the color, then check them on again and get the rest?
Alright, so it seems that was the culprit. Having "ignore per vertex color" on the high poly mesh checked off (so I could bake Vertex Colors) was creating that result in the AO for some reason. The workaround then is to bake out the maps I need except for AO - then separately do AO after and check that back on.
Glad to see you found the problem.
We put that "ignore per vertex color" option on the HP mesh because you actually can compute the per-vertex AO using the XNormal's Simple GPU AO tool, which writes the occlusion to the vertices. If you check it in then the AO can be computed per pixel from zero... if you UNcheck it the per-vertex AO stored on the vertex colors will be used to compute the per-pixel occlusion.
Seems your ray distances or cages are not setup. You should setup a cage that covers completely the HP mesh.
------------------------------------------------------
http://www.xnormal.net
http://santyhammer.blogspot.com
http://www.ratgpu.com