just wondering - is xnormal (or any other tool out there) capable of adjusting the normal map accordingly if you change the underlying vertex normals? e. g. change the topology of an already finished asset and tweak the existing normal map based on the differences between original and new topology?
Depends. If you have the old mesh then it will be possible, yep.
If not, it won't... because you cannot reconstruct the original tangent space.
In xNormal you could make this: pass the TS-normal map into object space using the old mesh.
Then, convert the resulting object space normal map into tangent space using the new mesh.
Voil
Hmmm, what's that? Well, I need to investigate a few but the Projection modifier programming interface that provides Autodesk is a bit limited currently.
in turbosmooth and meshsmooth you have iterations and renderiterations, while iterations are for on screen previewing and could be used for rendering too, render iterations just are an overwrite so you could preview you smoothed mesh in the viewport with lets say, 2 itereations and render it with 4 to have a smoother result
in turbosmooth and meshsmooth you have iterations and renderiterations, while iterations are for on screen previewing and could be used for rendering too, render iterations just are an overwrite so you could preview you smoothed mesh in the viewport with lets say, 2 itereations and render it with 4 to have a smoother result
Hmmm... you're right.... for some reason the SBM exporter is exporting the subdivided mesh using the View Iterations instead of the Render Iterations.... I must fix it, yep.
Oddly, I reinstalled, including the examples this time, to see if they worked... and everything is functioning as it should. My textures render correctly and everything is working normally.
To further investigate, I reinstalled without the examples again, but things are still working fine. It's utterly confusing why they didn't work yesterday, but perhaps a library somewhere had gotten corrupted, or it was my shutting down the PC overnight that fixed it. If this ever happens again, I will look into what had been previously done, perhaps to discover the cause.
Thanks for the support.
Edit: it happened again after I baked an AO map. Then it happened after I scaled the model... I really have no idea. It's possible that my videocard is shot and forgets to load the texture, or something. I usually have problems like this, that don't make any sense and nobody else has. As it is, I can just load one of the sample settings and clear out the models and it all renders fine. If you still want information about my system I can post it here or send you a PM.
Depends. If you have the old mesh then it will be possible, yep.
If not, it won't... because you cannot reconstruct the original tangent space.
In xNormal you could make this: pass the TS-normal map into object space using the old mesh.
Then, convert the resulting object space normal map into tangent space using the new mesh.
Voil
pass the TS-normal map into object space using the old mesh.
Then, convert the resulting object space normal map into tangent space using the new mesh.
I’m rendering a occmap from 3milj polys as I’m posting. Iv used this program for little over a year now for all my normalmaps! Its kick ass and its getting better all the time.
I just wanted to say thx for this amazing freeware.
I am the author/developer of the Riptide, Riptide Pro (enahanced Wavefront .obj IO plugins) as well as Undertow (symmetry workflow tools and many uv-mapping helpers plugin) for Cinema 4D.
I just wanted to pop in with a few comments...
Riptide Pro (the commercial version) Imports and Exports very much 'correct' Vertex Normals, taking into account the various attributes of the Phong Tag on meshes (ie. phong angle, edge-breaks, etc). It also has code to safe-guard against some sloppy/bad Normal info from other exporters (ie. Max2Obj).
Riptide (the free version) may still Import/Export incorrect Vertex Normals (several fixes that were recently implemented in the Pro version have not (yet) been propogated to the free version).
Note to Max users using "Max2Obj": Don't. As jogshy has mentioned multiple times, it has multiple issues related to exporting Vertex Normals (but provided a good "bad data" test case to help me fix my plugin ).
...finally, a general comment:
This is my first visit to this forum (and BTW jogshy, I haven't used it yet, but xNormal looks to be an excellent app - thanks!). As a plugin developer, I love hearing about how people are using my products but rarely hear about it unless I stumble across some thread in some forum.
I try to get around to other sites to answer questions when I can, but the best/quickest way to get an answer is by using the Support Forums set up on my site for my products.
If you have any questions, bugs to report, suggestions or just comments related to my plugins - please feel free to stop by and leave a note (posting there requires a free signup).
didn´t know about this thread. don´t know exactly why it doesn´t show it when I look for xNormal which is exactly the name but anyway...
I posted this thread some days ago http://boards.polycount.net/showthread.php?t=60193
since then I found out most of the issues I had got (basically it was a problem with the size of the model and the distance of the cage.
basically I´ve still got the issues with the peak effect in my normal map. I´ll post some images tomorrow but what happens is I´ve got a horitzonal sculped line along leg which looks fine looking at it from below fut if you look at it from the top it has a extrem wavy effect. I´ve change the way the UV layout was and the line looks completely straight in the texture so I think it sould be a problem with the way the cage is set up but I don´t know exactly what can produce that. As I said I tryed what ben explains in his tutorial which works fins for ending pieces but not in this case where the line is in the middle of the shin.
thanks a lot for your help and thanks to jogshy for this awesome program!!
following my last post these are the screenshots of what I explained before.
low model in max with its cage. I used a general value for the whole model and I edited locally where the result wasn´t the best one but nothing special.
high poly model in zbrush
uv layout. the seam is located in the back part of the model which is the one you see in the screenshots.
and these are the images in xnormal (don´t pay attention to the anormalities but to the wavy effect)
bottom view in xnormal (correct)
middle view in xnormal (you begin seeing the issue)
top view in xnormal (where the problem appears the most)
here is the "wirefram and rays fail" map just in case it could tell me something but nothing seems to be wrong.
I tried different ways with more and less distance or changing the inclination and the height of the cage but I can´t get the way to get a proper normal map.
anyone can suggest anything I could do?? thanks a lot in advance!!
If that's a 3dsm bake you're displaying there on the low poly then max does that all the time. It's mostly the reason why I mix an xnormal bake with the one I get out of 3dsm. What I'd suggest if you haven't done so already is export your low and high from max as .ASE import into xnormal and bake it without a cage (make sure that the mesh has beenexploded). Looking at the UVs xNormal should give you a pretty nice bake
they way I did it was exporting the high poly model from zbrush to obj (with merge opcion on) and the low poly one from max, as a sbm, with the uv, the normals and the cage included (without smoot and tangen basis options on). once in xnormal I active use cage in the low poly model and that´s pretty much about it . the cage is the one i´ve shown but i´ve been trying other configurations and I´m not getting better results.
I used explode in my mesh and exported it and create the normal map with the default cage in xnormal but I´m getting the same.
thx anyway dude! if you can think about something else... let me know :P
idn´t know about this thread. don´t know exactly why it doesn´t show it when I look for xNormal which is exactly the name but anyway...
HYmmm... curious... you're right. Since the black-theme's change ( or the new year ) the search system seems to skip some threads.
About the baking problem:
- Are your UVs strictly in the [0.0,1.0] range?
- Did you perform a Reset X Form before exporting? Always do that before exporting.
- You're using the SBM exporter, aren't you? And NEVER use the max2obj one, it's the most bugged thing in the world!
- If your object has a radius aproximately of 1 unit... try to scale the object up ( the raytracing accuracy is bad for very small objects ).
- Are you sure ( inside the xNormal's 3D viewer, not in 3dsmax ) the cage covers completely the highpoly mesh?
- Sure the "use cage" option is enabled on the corresponding lowpolu mesh slot... notice it's disabled by default. If you don't enable it the cage will be ignored even when it's present in the SBM file!
- Finally, try render a "directions map". Do you see any strange or too big distortion in the cage's directions?
I'm just curious why the requirement of restricting uv values to the [0.0,1.0] range? It's pretty common to use values outside that range for either tiling or for visual neatness/organization purposes. Is the real restriction 'overlapping' UVs? or ... something else?
About the baking problem:
- Are your UVs strictly in the [0.0,1.0] range?
if by that u mean using the main square that´s what I´m doing. no overlaping, no tilling... all normal.
- Did you perform a Reset X Form before exporting? Always do that before exporting.
I did it. befor each projection.
- You're using the SBM exporter, aren't you? And NEVER use the max2obj one, it's the most bugged thing in the world!
i´m exporting to sbm format.
- If your object has a radius aproximately of 1 unit... try to scale the object up ( the raytracing accuracy is bad for very small objects ).
I tried that using the scale option in xnormal because when I do it using zbrush export and max export both models are exported in a different why and they don´t end up in the same position. didn´t work anyway.
- Are you sure ( inside the xNormal's 3D viewer, not in 3dsmax ) the cage covers completely the highpoly mesh?
yep. I checked it out and everything gets covered.
- Sure the "use cage" option is enabled on the corresponding lowpolu mesh slot... notice it's disabled by default. If you don't enable it the cage will be ignored even when it's present in the SBM file!
done. when I forget it I can appreciate a huge difference but because of the error I get.
- Finally, try render a "directions map". Do you see any strange or too big distortion in the cage's directions?
done. nothing terribly wrong. all pretty smooth in the "polemic" area.
don´t know what else I could do. I tried lots of different combinations with the cage being almost flat, closer, farther... thw weird thing is that line that causes the peak effect if working absolutely fine in the front part where the shape and the cage are pretty much the same than at the back...
I have no more ideas about those line artifacts 3lk0m, but if you want compress the files + xml settings with 7zip and send me the files. I'll take a look.
I have no more ideas about those line artifacts 3lk0m, but if you want compress the files + xml settings with 7zip and send me the files. I'll take a look.
hey jogshy,
sorry for not answering. didn´t realise you answered me. I found out a way. it took a little bit more but it worked so everything is fine now :P
got a quick one. transparency mode. I´ve got both the alpha within my diffuse texture and as a separate file. how can I use it? i´ve seen the transparency mode option below base texture with the dropdown menu but I can´t find out the way to use it. I assume I have to use the one bit option to use the alpha saved within the diffuse texture but it doesn´t show up once in the 3d viewer. am I supposed to use the value in any way??
transparency mode. I´ve got both the alpha within my diffuse texture and as a separate file. how can I use it?
You need to mix RGB and Alpha into the same file. Use a TGA or a TIFF ( BMP, JPG, etc have no alpha channel support ) and pass it as "base texture".
The alpha modes for the combo box are:
- 1bit/alpha test. Texels with alphas less than the ref value won't be painted. To get better results use DX10/Vista with an antialiased video mode(8X if possible)... so MSAA can be used.
- Additive. Good your hard glows, neons or psychedelic effects.
- Blended. Order dependent ( see the "render order" big arrow ). srcAlpha, 1-secAlpha.
- Screen. Good for... glasses. Order dependent too.
To get better results remeber to turn OFF the "Use texture compression" in the DX9/DX10/OpenGL graphic driver's options ( using the plug-in manager->configure button ).
Is it a known issue of a AO and normal Map not matching the surface evenly on some objects? Like I have a screw on a surface. The normal map shows it in one position, the AO shows it in another.(This is with the latest version). I checked against with Maxs render, and they do line up. Im re-rendering now with cosign square to see if any results are different.
Yes, yes, pictures. Will post later if doesn't work. I'm going to see if this render makes the difference. Hell, maybe I accidently loaded a earlier render revision before tweaking.
Oxy, that happens usually if you move some vertex in the cage. If you extrude it won't affect the map... but if you move a vertex a distorsion can appear ( remember the cage not only controls the ray distance but also the ray direction -> see poop's normal map cages tutorial, specially the cylinder example ).
To be sure: render a direction map. I bet you'll see a distorsion in the directions.
Do a fast test if you want: disable the cage(use cage=disabled) and uncheck the "limit ray distance".
Other test: erase the old cage and just extrude the vertices without moving them.
Thanks for the reply jogshy. The distortion isn't bothering me that much. The issue is more that the AO is not showing the distortion the same as the normal map. I had gone back and instead of pushing the cage, individually extruding each side, which still will distort, but not as bad. I still had the same issue with the AO.
Its distortion doesn't match the normal maps. Which in Max, using the Mental Ray AO (which Im cluess on all the options so it looks like crap), it matches perfectly.
I see your newer version was just released. I will play around with it to see if any difference.
Woooot! XYnary! Thanksssssssssssssssssssssssssssssssssss a lot!
I finally discovered the misalignment AO/normal map bug! ( and was thanks to your example! )
I'm fixing it now!
I see your newer version was just released. I will play around with it to see if any difference.
Web down :P I'm uploading the patched version now. It will be available soon.
I had thought that there was a feature put into the latest version of xnormal, that would keep the edges intact in your cage when you had a hard edge(from smoothing group) like max and maya will/can do. I've never seemed to be able to get this to work in xnormal, but i could have sworn i saw talk here of this feature being added. Am i going crazy, or is this just an obscure option somewhere?
Hey Jogshy and anyone else who might know. Any ideas on how to use the new Maya SBM exporter to get a usable cage out of Maya into Xnormal? I take it vertex order has to match up?
I'm thinking that you would set up in maya as if you were going to use transfer maps, create an envelope (cage) and export that?
BTW jogshy, any chance of a "maya style" cage option when raycasting? Max, as I understand it, always draws the ray from the lowpoly vertex to the equivalent vertex on the cage, which means you can do some tricks with cylinders etc, but has some other drawbacks.
Maya always casts the ray along the averaged vertex normal and ignores the position of the equivalent vertex on the cage. You can't do the same cylinder cap trick as with max, but you can be fairly brutal with tweaking the cage and not have to worry about it ruining your normal map.
edit: Tried what I suggested above, and it works However, Xnormal doesn't have Maya's "closest to envelope" option for raycasting, making it a bit harder to get a decent bake without a ton of cage tweaking.
so anyway, i'm trying to bake down some polypaint information from zbrush. here's what i've done:
imported basemesh into zbrush, went nuts.
exported one of the lower subdivisions into max, retopo'd and uvw mapped.
zbrush hates the uvw map and keeps crashing, so i've uvw mapped the mesh inside zbrush too. then gone colour>texture, to capture the polypaint info on the uv's zbrush made.
zbrush makes some funky uvw maps i tell you...
in xNormal i've gone "base texture to bake", and selected the colour file i just got from zbrush, assuming it would realign the colour information onto the low poly models uvw map, even though the maps are different, the colours should end up in the right place.
Hey Jogshy and anyone else who might know. Any ideas on how to use the new Maya SBM exporter to get a usable cage out of Maya into Xnormal? I take it vertex order has to match up?
the only way is to copy the object, keep its topology intact and just move the faces/vertices... then export it and use as an "external cage" file.
Maya always casts the ray along the averaged vertex normal and ignores the position of the equivalent vertex on the cage.
In theory, you can do that too in xNormal: set the average normals mode and keep the "use cage" UNchecked.
Maya's "closest to envelope" option for raycasting
To be sincere, I'm a complete Maya noob. Are you referring to a "use closest hit" when ray fails?
Hey Jog, I went back into the Xnormal groove today after some time not using it and the latest version is a pleasure to work with.
Below are some instant reactions. I suspect most of this is planned for the next big revision, but i thought it could help.
-First of all : as a long time Xnormal user I obviously got used to the interface (plus, it's been getting better with each revision). However right click menus still need to be addressed.. As the software creator I understand that a right click popup menu is handy : it's fast, and lets you bypass some layout/interface problems. However this is confusing for users, since in many cases it is impossible to visually guess what to do.
For instance, you could very well keep the righclick behaviour for the low/high polygon loading options. But I would suggest to double that with a 'Mesh Loading Options' pushbutton, on the far left, calling the same dropdown menu. That way everybody could 'figure out' Xnormal easily.
- Baking options : I really really like the smart file naming, and how it is now possible to bake multiple maps at once (tickboxes). More options I'd love to see : being able to set resolution and AA for each map independantly, and also tangentspace and objectspace normals having each a tickbox (i often bake both)
-I noticed that when baking multiple maps at once, the highpoly models are cached and remain in memeory for the coming bake. However they are dropped once the baking preview window is closed. It would be nice to keep them in 'mind' all the time, unless the highpoly visibility options are changed.
-Sometimes when I have multiple meshes in the highpoly list, I can run into a situation asking for 2 or more separated bakes.
To do so at the moment I have to make the meshes of the first bake visible, set up the map outputs, wait for the bake, then select the meshes of the second bake, rince and repeat. I would love to be able to setup 'xnormal jobs' running multiple bakes in a row - just press a button, and go for a walk :P
The ability to run multiple bakes to avoid intersections would be excellent, great idea Pior! Especially if xnormal could combine the maps at the end too.
hey bumping this up - i had a question with the latest version of the xnormal app: (3.16.4.30881)
What are the most optimal and efficient settings (in results and time) for the ambient occlusion baking in this particular version - i seem to be waiting and staring at the 'rendering' bar for ages, then still getting a crappy result (from not enough rays still i assume). There's a tutorial on the site regarding ao baking, but its done with a previous version with different (if not more ) features - the only values i have available to tweak are:
1. Rays
2. Distribution (which i keep on uniform)
3. Occluded color - Unoccluded color
4. Bias (kept at 0.000010)
5. Limit ray distance checkbox (unchecked)
6. Attenuation [ 1.00000 ] [ 0.00000 ] [ 0.00000 ]
7. Jitter checkbox (unchecked)
8. Allow 100% Occlusion (unchecked)
anyone have any suggestions (especially you jogshy ?
hey bumping this up - i had a question with the latest version of the xnormal app: (3.16.4.30881)
What are the most optimal and efficient settings (in results and time) for the ambient occlusion baking in this particular version
You should change to the 3.16.6 because the previous versions have a strange bug that misaligns the normal map and the AO map.
About the settings you mention:
1. Rays
I use 32 for a very faaaast test. 64 for fast but better test.
128 for medium quality. 256/512 for quality. 1024+ for final result.
For testing, of course, don't use AA. For quality, use 2X or 4X AA ( the AA will multiply almost linearly the rendering time so... )
2. Distribution.
Use the Uniform method to get more drastic AO or the Cosine one to get a smoother/softer one. If you're curious about how this parameter works: the cosine one places more samples aligned with the surface's normal while the uniform one places the samples evenly.
3. Occluded color - Unoccluded color
Occluded = I use pure black (RGB 0,0,0)
Unoccluded = I use pure white (RGB 255,255,255)
If you want the AO brighter you can raise a bit the occluded one from (0,0,0) to (20,20,20) for example. If you want the AO darker then lower the unoccluded to ( RGB 200,200,200).
4. Bias (kept at 0.000010)
A VERY dangerous param. It basically extrudes a bit the ray origin using the surface's normal to avoid problematic self-collisions of the ray with the triangle being rendered. It's expressed in relation with the object's total radius.
Usually keep it as low as you can. A too-low value will cause some moire or self-shadowing artifacts. A too-high value will miss a lot of the detail around near surfaces.
5. Limit ray distance checkbox (unchecked)
Checking in that option will tell xNormal to use the cage to limit the ray distance. Usually keep it UNchecked so AO rays will travel undefinitely far until they hit a surface. You can also use ray blockers if you need that the AO rays don't hit a concrete part of the model.
The AO attenuation is needed because the further distance the AO travels the lesser will be the shadow value ( shadows are attenuated over the distance ).
Following some radiance and radiometric properties, you can use constant, linear and quadratic fallofs. The 1st number(1.0) corresponds to the constant, the 2nd to the linear and the last one to the quadratic.
You need to play a bit with the values until you're happy with the result... but, usually, a value of 1/0.01/0 is fine for almost all. If you don't need the attenuation effect then just use 1/0/0.
7. Jitter checkbox (unchecked)
I usually keep it UNchecked, aye. You can check it in to reduce the AO banding artifacts due to sampling ( at the expense of some noise ).
8. Allow 100% Occlusion (unchecked)
That's a feature than Dan Walter ( vegastrike game/Cinemut shader suggested me to solve a problem with low-resultion AO maps. He sent me two very descriptive pictures:
As you can see on this image, the completely occluded texel gonna cause a big black(full occluded) point which is, perhaps, too brutal.
When you disable the "Allow pure occlusion", that completely occluded black point will be computed averaging the near texels, making the shadow smoother:
artifacts/missing rays
You probably need to measure well the uniform ray distances, place cages or place ray blockers. Try to render a "wireframe and ray fails" map to see if some ray is missing. Even if none is missing hit I recomend you to test visually the cage using the 3D viewer ( sure the highpoly is completely covered by the cage ). I don't recommend uniform ray distances unless your object is very simple ( a sphere, a box, etc ).
You can also use the MatchUV feature if your model is made 100% using subdivision surfaces so the ray distances can be simplified ( or skipped completely in some cases ).
You mention also something about the speed. Precise AO, unfortunately, is a VERY time consuming problem. For a typical 1024x1024 map, 512 rays and 4x AA need 1024x1024x512x4 = 2,15 billions of rays. That's a lot.
If you need very accurate AO maps, you can just wait, get a 24-core machine over x64 or use the hxGrid distributed renderer... but, hopefully, there's an easier solution if you don't need an accurate result AND the mesh is not very complex: use the Simple GPU tool. In that way the GPU can be used to compute a cheaper ambient occlusion... and you can also compute it per-vertex instead of per-pixel which will save you a lot of time ( see the "ignore per-vertex AO option" ).
Unfortunately, the GPU is very limited currently so I couldn't integrate that system into the "normal" software rendering path.
In the future, I want to re-write completely the renderer to make it more GPGPU-friendly, to optimize a lot more the rendering speed ( not only AO ) and to add advanced sampling methods. The problem is that my available time is reducing drastically. I'm waiting also for OpenCL and Larrabee.
In theory, you can do that too in xNormal: set the average normals mode and keep the "use cage" UNchecked.
Yeah, but I WANT to use the cage to limit the ray length, but not to control the direction of the cast rays. Maya works like this, AFAIK. It has two modes : one uses face normals for raycasting, the other uses vertex normals.
To be sincere, I'm a complete Maya noob. Are you referring to a "use closest hit" when ray fails?
Sort of, but it works differently in Maya I think. If you have the rayacasting set to sample "closest to envelope", it will sample from whichever surface is nearest the cage, including OUTSIDE the cage. This makes it much easier to set up a working cage without having to fully enclose the highpoly model which can be very fiddly in tight areas. I've used Max's render to texture as well, and generally Maya's is easier to get a clean bake from, although it has fewer options.
I'll be damned if I can get the search to function, so please excuse as I am sure this problem has been asked a number of times in this thread.
This is what I'm getting in the map I'm generating. I've tried changing the front & rear ray tracing from distances of 0.1 to 1000, as well as Cage or No Cage and I keep getting the same thing.
Replies
If not, it won't... because you cannot reconstruct the original tangent space.
In xNormal you could make this: pass the TS-normal map into object space using the old mesh.
Then, convert the resulting object space normal map into tangent space using the new mesh.
Voil
in turbosmooth and meshsmooth you have iterations and renderiterations, while iterations are for on screen previewing and could be used for rendering too, render iterations just are an overwrite so you could preview you smoothed mesh in the viewport with lets say, 2 itereations and render it with 4 to have a smoother result
Oddly, I reinstalled, including the examples this time, to see if they worked... and everything is functioning as it should. My textures render correctly and everything is working normally.
To further investigate, I reinstalled without the examples again, but things are still working fine. It's utterly confusing why they didn't work yesterday, but perhaps a library somewhere had gotten corrupted, or it was my shutting down the PC overnight that fixed it. If this ever happens again, I will look into what had been previously done, perhaps to discover the cause.
Thanks for the support.
Edit: it happened again after I baked an AO map. Then it happened after I scaled the model... I really have no idea. It's possible that my videocard is shot and forgets to load the texture, or something. I usually have problems like this, that don't make any sense and nobody else has. As it is, I can just load one of the sample settings and clear out the models and it all renders fine. If you still want information about my system I can post it here or send you a PM.
Yep this should work problem free, as long as your uvs dont change!
Feel free to test it if you want.
thx
I just wanted to say thx for this amazing freeware.
Btw... has Modo an SDK?
http://www.luxology.com/whatismodo/developers.aspx
http://www.luxology.com/whatismodo/document/modo302_developer_file_IO_SDK.pdf
I am the author/developer of the Riptide, Riptide Pro (enahanced Wavefront .obj IO plugins) as well as Undertow (symmetry workflow tools and many uv-mapping helpers plugin) for Cinema 4D.
I just wanted to pop in with a few comments...
- Riptide Pro (the commercial version) Imports and Exports very much 'correct' Vertex Normals, taking into account the various attributes of the Phong Tag on meshes (ie. phong angle, edge-breaks, etc). It also has code to safe-guard against some sloppy/bad Normal info from other exporters (ie. Max2Obj).
- Riptide (the free version) may still Import/Export incorrect Vertex Normals (several fixes that were recently implemented in the Pro version have not (yet) been propogated to the free version).
- Note to Max users using "Max2Obj": Don't.
).
...finally, a general comment:As jogshy has mentioned multiple times, it has multiple issues related to exporting Vertex Normals (but provided a good "bad data" test case to help me fix my plugin
This is my first visit to this forum (and BTW jogshy, I haven't used it yet, but xNormal looks to be an excellent app - thanks!). As a plugin developer, I love hearing about how people are using my products but rarely hear about it unless I stumble across some thread in some forum.
I try to get around to other sites to answer questions when I can, but the best/quickest way to get an answer is by using the Support Forums set up on my site for my products.
If you have any questions, bugs to report, suggestions or just comments related to my plugins - please feel free to stop by and leave a note (posting there requires a free signup).
Cheers,
Keith
I also updated my blog with an entry about 3D, James Cameron's Avatar movie and other thoughts.
thanks!
didn´t know about this thread. don´t know exactly why it doesn´t show it when I look for xNormal which is exactly the name but anyway...
I posted this thread some days ago
http://boards.polycount.net/showthread.php?t=60193
since then I found out most of the issues I had got (basically it was a problem with the size of the model and the distance of the cage.
basically I´ve still got the issues with the peak effect in my normal map. I´ll post some images tomorrow but what happens is I´ve got a horitzonal sculped line along leg which looks fine looking at it from below fut if you look at it from the top it has a extrem wavy effect. I´ve change the way the UV layout was and the line looks completely straight in the texture so I think it sould be a problem with the way the cage is set up but I don´t know exactly what can produce that. As I said I tryed what ben explains in his tutorial which works fins for ending pieces but not in this case where the line is in the middle of the shin.
thanks a lot for your help and thanks to jogshy for this awesome program!!
low model in max with its cage. I used a general value for the whole model and I edited locally where the result wasn´t the best one but nothing special.
high poly model in zbrush
uv layout. the seam is located in the back part of the model which is the one you see in the screenshots.
and these are the images in xnormal (don´t pay attention to the anormalities but to the wavy effect)
bottom view in xnormal (correct)
middle view in xnormal (you begin seeing the issue)
top view in xnormal (where the problem appears the most)
here is the "wirefram and rays fail" map just in case it could tell me something but nothing seems to be wrong.
I tried different ways with more and less distance or changing the inclination and the height of the cage but I can´t get the way to get a proper normal map.
anyone can suggest anything I could do?? thanks a lot in advance!!
I used explode in my mesh and exported it and create the normal map with the default cage in xnormal but I´m getting the same.
thx anyway dude! if you can think about something else... let me know :P
About the baking problem:
- Are your UVs strictly in the [0.0,1.0] range?
- Did you perform a Reset X Form before exporting? Always do that before exporting.
- You're using the SBM exporter, aren't you? And NEVER use the max2obj one, it's the most bugged thing in the world!
- If your object has a radius aproximately of 1 unit... try to scale the object up ( the raytracing accuracy is bad for very small objects ).
- Are you sure ( inside the xNormal's 3D viewer, not in 3dsmax ) the cage covers completely the highpoly mesh?
- Sure the "use cage" option is enabled on the corresponding lowpolu mesh slot... notice it's disabled by default. If you don't enable it the cage will be ignored even when it's present in the SBM file!
- Finally, try render a "directions map". Do you see any strange or too big distortion in the cage's directions?
I'm just curious why the requirement of restricting uv values to the [0.0,1.0] range? It's pretty common to use values outside that range for either tiling or for visual neatness/organization purposes. Is the real restriction 'overlapping' UVs? or ... something else?
Thanks.
Or is that just a silly question.
if by that u mean using the main square that´s what I´m doing. no overlaping, no tilling... all normal.
I did it. befor each projection.
i´m exporting to sbm format.
I tried that using the scale option in xnormal because when I do it using zbrush export and max export both models are exported in a different why and they don´t end up in the same position. didn´t work anyway.
yep. I checked it out and everything gets covered.
done. when I forget it I can appreciate a huge difference but because of the error I get.
done. nothing terribly wrong. all pretty smooth in the "polemic" area.
don´t know what else I could do. I tried lots of different combinations with the cage being almost flat, closer, farther... thw weird thing is that line that causes the peak effect if working absolutely fine in the front part where the shape and the cage are pretty much the same than at the back...
thanks anyway!!
hey jogshy,
sorry for not answering. didn´t realise you answered me. I found out a way. it took a little bit more but it worked so everything is fine now :P
got a quick one. transparency mode. I´ve got both the alpha within my diffuse texture and as a separate file. how can I use it? i´ve seen the transparency mode option below base texture with the dropdown menu but I can´t find out the way to use it. I assume I have to use the one bit option to use the alpha saved within the diffuse texture but it doesn´t show up once in the 3d viewer. am I supposed to use the value in any way??
thanks a lot!!
The alpha modes for the combo box are:
- 1bit/alpha test. Texels with alphas less than the ref value won't be painted. To get better results use DX10/Vista with an antialiased video mode(8X if possible)... so MSAA can be used.
- Additive. Good your hard glows, neons or psychedelic effects.
- Blended. Order dependent ( see the "render order" big arrow ). srcAlpha, 1-secAlpha.
- Screen. Good for... glasses. Order dependent too.
To get better results remeber to turn OFF the "Use texture compression" in the DX9/DX10/OpenGL graphic driver's options ( using the plug-in manager->configure button ).
Yes, yes, pictures. Will post later if doesn't work. I'm going to see if this render makes the difference. Hell, maybe I accidently loaded a earlier render revision before tweaking.
Download sbm file (low has cage)
http://www.oxynary.com/downloads/xnormAOissue.zip
To be sure: render a direction map. I bet you'll see a distorsion in the directions.
Do a fast test if you want: disable the cage(use cage=disabled) and uncheck the "limit ray distance".
Other test: erase the old cage and just extrude the vertices without moving them.
Its distortion doesn't match the normal maps. Which in Max, using the Mental Ray AO (which Im cluess on all the options so it looks like crap), it matches perfectly.
I see your newer version was just released. I will play around with it to see if any difference.
I finally discovered the misalignment AO/normal map bug! ( and was thanks to your example! )
I'm fixing it now!
Web down :P I'm uploading the patched version now. It will be available soon.
Feel free to download and test if it's solved.
Thanks!
Is this like 3.16.5a ? As per the revision I downloaded on the 5th was 3.16.5? BTW You rock Jogshy!
I'm thinking that you would set up in maya as if you were going to use transfer maps, create an envelope (cage) and export that?
BTW jogshy, any chance of a "maya style" cage option when raycasting? Max, as I understand it, always draws the ray from the lowpoly vertex to the equivalent vertex on the cage, which means you can do some tricks with cylinders etc, but has some other drawbacks.
Maya always casts the ray along the averaged vertex normal and ignores the position of the equivalent vertex on the cage. You can't do the same cylinder cap trick as with max, but you can be fairly brutal with tweaking the cage and not have to worry about it ruining your normal map.
edit: Tried what I suggested above, and it works
imported basemesh into zbrush, went nuts.
exported one of the lower subdivisions into max, retopo'd and uvw mapped.
zbrush hates the uvw map and keeps crashing, so i've uvw mapped the mesh inside zbrush too. then gone colour>texture, to capture the polypaint info on the uv's zbrush made.
zbrush makes some funky uvw maps i tell you...
in xNormal i've gone "base texture to bake", and selected the colour file i just got from zbrush, assuming it would realign the colour information onto the low poly models uvw map, even though the maps are different, the colours should end up in the right place.
but it didn't... any ideas?
In theory, you can do that too in xNormal: set the average normals mode and keep the "use cage" UNchecked.
To be sincere, I'm a complete Maya noob. Are you referring to a "use closest hit" when ray fails?
Below are some instant reactions. I suspect most of this is planned for the next big revision, but i thought it could help.
-First of all : as a long time Xnormal user I obviously got used to the interface (plus, it's been getting better with each revision). However right click menus still need to be addressed.. As the software creator I understand that a right click popup menu is handy : it's fast, and lets you bypass some layout/interface problems. However this is confusing for users, since in many cases it is impossible to visually guess what to do.
For instance, you could very well keep the righclick behaviour for the low/high polygon loading options. But I would suggest to double that with a 'Mesh Loading Options' pushbutton, on the far left, calling the same dropdown menu. That way everybody could 'figure out' Xnormal easily.
- Baking options : I really really like the smart file naming, and how it is now possible to bake multiple maps at once (tickboxes). More options I'd love to see : being able to set resolution and AA for each map independantly, and also tangentspace and objectspace normals having each a tickbox (i often bake both)
-I noticed that when baking multiple maps at once, the highpoly models are cached and remain in memeory for the coming bake. However they are dropped once the baking preview window is closed. It would be nice to keep them in 'mind' all the time, unless the highpoly visibility options are changed.
-Sometimes when I have multiple meshes in the highpoly list, I can run into a situation asking for 2 or more separated bakes.
To do so at the moment I have to make the meshes of the first bake visible, set up the map outputs, wait for the bake, then select the meshes of the second bake, rince and repeat. I would love to be able to setup 'xnormal jobs' running multiple bakes in a row - just press a button, and go for a walk :P
Thanks for the hard efforts!
What are the most optimal and efficient settings (in results and time) for the ambient occlusion baking in this particular version - i seem to be waiting and staring at the 'rendering' bar for ages, then still getting a crappy result (from not enough rays still i assume). There's a tutorial on the site regarding ao baking, but its done with a previous version with different (if not more ) features - the only values i have available to tweak are:
1. Rays
2. Distribution (which i keep on uniform)
3. Occluded color - Unoccluded color
4. Bias (kept at 0.000010)
5. Limit ray distance checkbox (unchecked)
6. Attenuation [ 1.00000 ] [ 0.00000 ] [ 0.00000 ]
7. Jitter checkbox (unchecked)
8. Allow 100% Occlusion (unchecked)
anyone have any suggestions (especially you jogshy
About the settings you mention:
I use 32 for a very faaaast test. 64 for fast but better test.
128 for medium quality. 256/512 for quality. 1024+ for final result.
For testing, of course, don't use AA. For quality, use 2X or 4X AA ( the AA will multiply almost linearly the rendering time so... )
Use the Uniform method to get more drastic AO or the Cosine one to get a smoother/softer one. If you're curious about how this parameter works: the cosine one places more samples aligned with the surface's normal while the uniform one places the samples evenly.
Occluded = I use pure black (RGB 0,0,0)
Unoccluded = I use pure white (RGB 255,255,255)
If you want the AO brighter you can raise a bit the occluded one from (0,0,0) to (20,20,20) for example. If you want the AO darker then lower the unoccluded to ( RGB 200,200,200).
A VERY dangerous param. It basically extrudes a bit the ray origin using the surface's normal to avoid problematic self-collisions of the ray with the triangle being rendered. It's expressed in relation with the object's total radius.
Usually keep it as low as you can. A too-low value will cause some moire or self-shadowing artifacts. A too-high value will miss a lot of the detail around near surfaces.
Checking in that option will tell xNormal to use the cage to limit the ray distance. Usually keep it UNchecked so AO rays will travel undefinitely far until they hit a surface. You can also use ray blockers if you need that the AO rays don't hit a concrete part of the model.
The AO attenuation is needed because the further distance the AO travels the lesser will be the shadow value ( shadows are attenuated over the distance ).
Following some radiance and radiometric properties, you can use constant, linear and quadratic fallofs. The 1st number(1.0) corresponds to the constant, the 2nd to the linear and the last one to the quadratic.
You need to play a bit with the values until you're happy with the result... but, usually, a value of 1/0.01/0 is fine for almost all. If you don't need the attenuation effect then just use 1/0/0.
I usually keep it UNchecked, aye. You can check it in to reduce the AO banding artifacts due to sampling ( at the expense of some noise ).
That's a feature than Dan Walter ( vegastrike game/Cinemut shader suggested me to solve a problem with low-resultion AO maps. He sent me two very descriptive pictures:
As you can see on this image, the completely occluded texel gonna cause a big black(full occluded) point which is, perhaps, too brutal.
When you disable the "Allow pure occlusion", that completely occluded black point will be computed averaging the near texels, making the shadow smoother:
You probably need to measure well the uniform ray distances, place cages or place ray blockers. Try to render a "wireframe and ray fails" map to see if some ray is missing. Even if none is missing hit I recomend you to test visually the cage using the 3D viewer ( sure the highpoly is completely covered by the cage ). I don't recommend uniform ray distances unless your object is very simple ( a sphere, a box, etc ).
You can also use the MatchUV feature if your model is made 100% using subdivision surfaces so the ray distances can be simplified ( or skipped completely in some cases ).
You mention also something about the speed. Precise AO, unfortunately, is a VERY time consuming problem. For a typical 1024x1024 map, 512 rays and 4x AA need 1024x1024x512x4 = 2,15 billions of rays. That's a lot.
If you need very accurate AO maps, you can just wait, get a 24-core machine over x64 or use the hxGrid distributed renderer... but, hopefully, there's an easier solution if you don't need an accurate result AND the mesh is not very complex: use the Simple GPU tool. In that way the GPU can be used to compute a cheaper ambient occlusion... and you can also compute it per-vertex instead of per-pixel which will save you a lot of time ( see the "ignore per-vertex AO option" ).
Unfortunately, the GPU is very limited currently so I couldn't integrate that system into the "normal" software rendering path.
In the future, I want to re-write completely the renderer to make it more GPGPU-friendly, to optimize a lot more the rendering speed ( not only AO ) and to add advanced sampling methods. The problem is that my available time is reducing drastically. I'm waiting also for OpenCL and Larrabee.
thanks a lot mate - these details really help, no i just have to set off my final 1024 render.... and come back in a few days heh
Yeah, but I WANT to use the cage to limit the ray length, but not to control the direction of the cast rays. Maya works like this, AFAIK. It has two modes : one uses face normals for raycasting, the other uses vertex normals.
Sort of, but it works differently in Maya I think. If you have the rayacasting set to sample "closest to envelope", it will sample from whichever surface is nearest the cage, including OUTSIDE the cage. This makes it much easier to set up a working cage without having to fully enclose the highpoly model which can be very fiddly in tight areas. I've used Max's render to texture as well, and generally Maya's is easier to get a clean bake from, although it has fewer options.
This is what I'm getting in the map I'm generating. I've tried changing the front & rear ray tracing from distances of 0.1 to 1000, as well as Cage or No Cage and I keep getting the same thing.
What am I doing wrong here?