I think you missed my point - applying normal maps as diffuse textures will show the "seams" even if they are perfectly hidden when the texture is correctly as a normal-map.
Showing the normal-map as a diffuse texture doesn't prove anything. The seams are clear enough in the other images. I could show a screenshot of a normal-mapped asset with perfectly hidden seams and then display the normal-map as diffuse and you'd see the UV seams clearly.
I appreciate that this doesn't help solve your problem, I was just trying to point out that you seem to have misunderstood how normal-maps work.
I think you missed my point here, the normal applied as texture has nothing to do with this, just forget that I ever showed that picture.
When i apply my TANGENT NORMALMAP it got this nasty seams straight along my UV seam with up too 30% color difference on the both sides(wich is far from acceptable in my eyes):
PLZ, how do i get rid of this?
I wanted to say I use xNormal and I think it's great. I have come across a problem.
I downloaded the recent version on my Windows 7 64 bit OS. I have a high poly mesh from Zbrush, looking to be around 7milion polys. When it goes to reading the high poly mesh in xNormal, the green bar moves up to about 1/4 of the way, then the green bar goes away and its clear again and xNormal just sits there. The red abort light is still on but I've let it sit for over an hour and nothing ever happened.
Could I have been missing something. I'm doing everything the same way...all I can think of is windows 7 maybe? Thanks for any advice.
Are you 100% sure the UVs are well welded there and the smoothing groups correct? Well, if you are, then pass to the next point:
Each application has its own way to compute and use the tangent space. If you generate the maps in a XXXX application but you preview it in a YYYYY application you need a way to match the tangent basis. How can you perform that? Some advices:
1. Use object-space normal maps for non-deformable meshes.
2. Use the xNormal's 3D viewer "show tangent basis" option to see where the vertices/normals/UVs are duplicated/broken.
3. Use the xNormal SBM mesh exporter if you can. That will save into the file the Maya's tangent basis... so it will be used by xNormal.
The problem with TS-normal maps is that the normal mapper and the 3D viewer must use THE SAME tangent basis/methods or a seam will appear. For perfect results, you'll need a programmer to take a look to the xNormal and Maya SDKs ( and, probably also, to write a custom HLSL/GLSL maya shader ).
I downloaded the recent version on my Windows 7 64 bit OS.
xNormal 3 has been not yet adapted to W7, sorry. I'm delaying the 3.16.12 final intentionally until W7 is oficially released.
Btw... a question that is making me crazy... I received several emails telling me there is a problem with the Dx10 graphics driver of xNormal. It seems french versions of Vista cannot display the texts on the screen... Can anybody confirm me this, pls? thx
Hey a quick note here, in the regular AO options you can set the BG color, which is really nice, but when using the simple AO tool you can't set the BG color. If this is an easy thing to do it would be cool!
Also thanks again for the backface ao thing, this saves soooo much time.
Hey a quick note here, in the regular AO options you can set the BG color, which is really nice, but when using the simple AO tool you can't set the BG color. If this is an easy thing to do it would be cool!
Ooooopz! Ok, I'll add it for the final 3.16.12 then.
Are you 100% sure the UVs are well welded there and the smoothing groups correct? Well, if you are, then pass to the next point:
Each application has its own way to compute and use the tangent space. If you generate the maps in a XXXX application but you preview it in a YYYYY application you need a way to match the tangent basis. How can you perform that? Some advices:
1. Use object-space normal maps for non-deformable meshes.
2. Use the xNormal's 3D viewer "show tangent basis" option to see where the vertices/normals/UVs are duplicated/broken.
3. Use the xNormal SBM mesh exporter if you can. That will save into the file the Maya's tangent basis... so it will be used by xNormal.
The problem with TS-normal maps is that the normal mapper and the 3D viewer must use THE SAME tangent basis/methods or a seam will appear. For perfect results, you'll need a programmer to take a look to the xNormal and Maya SDKs ( and, probably also, to write a custom HLSL/GLSL maya shader ).
This has nothing to do with me using different programs, here's a screen of both maya and the xnormal viewer having the exact same problem(view in full res):
tip 1: Never make the seams easily visible, put it on the back of the shoe or something next time
The shoe is pretty much a cylinder and to put it on the back just makes it so the seam will be as visable on the back as on the front... and if its a 3rd person game thats just stupid...
This has nothing to do with me using different programs, here's a screen of both maya and the xnormal viewer having the exact same problem(view in full res):
I think it might be something to do with the orientation of the UVs, try making them straight horizontally (so the seam edges line up along the U axis) and try to make sure that the edges are aligned.
I think this sort of thing affects the tangent basis calculations so the more uniform you have the UVs, the more regular the traces will be.
Plus it'll make it easier to texture than having it rotated at an odd angle
OK, so I think I'm wrong there. I just did a test in Maya to check this.
I downloaded your (unnecessarily huge, 37mb) file from the (oddly slow - 14k/s) file host.
First thing I did was run the highpoly mesh through MeshLab, because there's absolutely no reason to spend two million triangles on a single sculpted shoe... I set the optimiser to aim for 250,000 triangles and it ended up looking identical. The main difference was the OBJ file was 18mb instead of 195mb... might be something you want to do before you upload a gigantic file next time
First I unlocked normals on the lowpoly mesh because they were all messed up, probably OBJ format's fault - what format are you using to export to XNormal? If you're using OBJ then that could be the problem, since Maya and OBJ seem to have fun messing around with perfectly fine vertex normals.
Then once I did a "soften edge" on the whole mesh, I made 3 versions of the lowpoly. One with your original UV layout, one with a rotated version so the seam was horizontally aligned, and one with a different UV layout where I think the UV seam is in the optimal position (and also it should make more efficient use of UV space).
Here's an image of the results, using Maya 2008's Transfer Maps...
So it seems like the problem is either XNormal (which seems unlikely since I and several other people I've seen have managed to generate perfect seamless normal-maps using XNormal), or your export format.
Also check to make sure you've unlocked normals and softened edges before exporting, maybe Maya is storing some dodgy normal data but not displaying it in the viewport (it does this fairly often if you're not careful).
But yeah, 2+ million polys for a shoe? Try to be a bit more efficient, I don't think you even need quarter of that polygon count to sculpt this nicely...
Hmm, the normal problem was just weird, the unrared file didn't have that but the rar'ed had.
But without doing anything at all to the models I tried to bake the map in maya like you instead and got the same results you got, no seams.
So this only occurs when i do it it xnormal.
And yes, modells like this doesn't need to be that large and i can bake these in maya.
edit: ohh, and i did test different formats and that made no difference.
I wanted to say I use xNormal and I think it's great. I have come across a problem.
I downloaded the recent version on my Windows 7 64 bit OS. I have a high poly mesh from Zbrush, looking to be around 7milion polys. When it goes to reading the high poly mesh in xNormal, the green bar moves up to about 1/4 of the way, then the green bar goes away and its clear again and xNormal just sits there. The red abort light is still on but I've let it sit for over an hour and nothing ever happened.
Could I have been missing something. I'm doing everything the same way...all I can think of is windows 7 maybe? Thanks for any advice.
I encountered this problem too, on windows xp x64. When exporting high-res meshs from zbrush 3.5 r2 the application proceeds to load obj then progress bar changes to all white and calculation is not completed. I solved this by exporting from 3.5, importing into 3.0, then exporting to an obj again. After this xnormal will load the obj correctly and continue to bake.
So apparently there is something different about how zbrush exports obj files in the latest release.
As a note, during the export process in zbrush 3.5, zbrush notifies you that it is exporting the obj via polypaint. I don't know if this process is any different or how but it may be useful in solving this problem.
As a note, during the export process in zbrush 3.5, zbrush notifies you that it is exporting the obj via polypaint. I don't know if this process is any different or how but it may be useful in solving this problem.
No, no! My computer not so weak. Intel Core Duo, 8800 GT, 4Gb RAM, win XP x64 sp2. I can specify more detailed configuration if you need it. I use Xnormal for 2 years (thanks for this great program), and everything was fine until now. In monday's morning I've just opened it and seen weird interface. Yesterday I left it opened to burn ambient occlusion (it works anyway, but i need at least checkboxes:( ). Today interface have appeared again, after 8 hours of work. But when i restarted Xnormal situation repeated. Reinstallation didn't help.
velesius i think its a problem with your PC not xNormal. when was the last time you reformatted your PC? i do it every 6 months
My windows was installed 1 year ago. I understand that it quickly fall down to senile marasmus, but for now only Xnormal has so strange glitches. I thought it uses some particular system resources to display UI. So I told about this problem to classify what exactly wrong with my system. Anyway I totally agree that full windows reinstallation will solve this issue.
Re: the ZB 3.5 export and Xnormal stalling issue, I think I know what that is. You need to disable the texture button in the Export options of your obj.
@velesius : That sounds like a graphics driver problem, the n-th bug of WinXP 64 ( perhaps caused by a Windows Update's patch ) or a problem with some theme. Btw... are you sure your graphics mode is set to 24 or 32 bits and not 16?
EarthQuake : The preview does not show the background color, because the .NET bitmaps pre-multiply the alpha... but, if you look into the output .BMP/.TGA file it should be the one you specified.
About thethe ZB 3.5 export and Xnormal stalling issue... could anybody send me a problematic .OBJ so I could debug it, pls? ZB3.5 does not install on my computer...
thx
@velesius : That sounds like a graphics driver problem, the n-th bug of WinXP 64 ( perhaps caused by a Windows Update's patch ) or a problem with some theme. Btw... are you sure your graphics mode is set to 24 or 32 bits and not 16?
Graphics mode is set to 32 bits. It seems I solved this issue, and yes, it was a graphic driver problem. I tried reinstall driver that already was installed on my comp (GeForce Forceware 186.18 WHQL XP (64-bit), but nothing helped. With latest driver GeForce ForceWare 190.56 Windows XP (64-bit) problem disapeear.
Thanks for advice! :-)
And besides, there is an idea of functional extension of Xnormal. Hope you'll like it and it could be realized in the following versions. It`s all about fully functional Batch mode. I know that something like this is already present in XNoraml but sometimes it doesn't help. You can load several low-polys(LP) and maps will be burnt onto them one after another, but from the SAME COLLECTION OF HIGH POLYS(HP), what isn't always acceptable.(or I do something wrong?). Would like to have the system like in the VirtualDub.
For instance, I load LP and corresponding HP. Then I set the maps I want to burn and give them certain properies. Save all this to a file. Load another LP and different collection of Hps and setup the maps, save it and so on. After the list is made I press the START THE BATCH button and leave the computer for a week or so . I think this function could be really useful.
About thethe ZB 3.5 export and Xnormal stalling issue... could anybody send me a problematic .OBJ so I could debug it, pls? ZB3.5 does not install on my computer...
thx
I can. The problem is file size. I haven't checked at what level the problem begins. For a low-poly base object, xnormal has no problem importing the model, e.g. 4,000 polys. It has trouble importing the high poly model. I have checked this on a high poly model of 3 and 12 million polys. I will check the subdivision levels in between later tonight.
@ Scooby Doofus
I tried turning texture off in the export options and unfortunately it did not solve the problem. What ws the poly count of the models for which this worked?
And besides, there is an idea of functional extension of Xnormal. Hope you'll like it and it could be realized in the following versions. It`s all about fully functional Batch mode. I know that something like this is already present in XNoraml but sometimes it doesn't help. You can load several low-polys(LP) and maps will be burnt onto them one after another, but from the SAME COLLECTION OF HIGH POLYS(HP), what isn't always acceptable.(or I do something wrong?).
You can make that currently saving several .XML files and passing them to the xNormal's command line.... something like:
c: \>xNormal.exe scene1.xml scene2.xml scene3.xml
The scenes can contain a different set of LP/HP meshes, textures and output files.
For xn4 you could also write your own scripts ( for example, you could fire the HM2NM programatically or to assign a button/menu to a script ). I'm also changing the scene model ( using a "import meshes"->load/save scene file method. The scene file will contain the optimized meshes itself so it will load much faster ).
Thanks, Jogshy! Everything works perfectly! It will save heaps of time for me. Command-line rendering well documented, I just didn't find right page before. Waiting for XN4
I have been trying to get a more in-depth knowledge of what xnormal can do and I found something in the help that interested me. In section 2.6.6.
"The bent normals can be used to perform more accurate environment mapping. This is the aspect of the bent normals's map:
As you can see it looks like a normal map... but it really represents the unoccluded rays's escape direction."
Can someone elaborate on how/why this could be used to improve environment mapping?
"The bent normals can be used to perform more accurate environment mapping. This is the aspect of the bent normals's map:
As you can see it looks like a normal map... but it really represents the unoccluded rays's escape direction."
Can someone elaborate on how/why this could be used to improve environment mapping?
It's like AO, but applied to the normals.
AO is an scalar... Bent Normals have 3 components ( XYZ ).
The bent normals represent an unoccluded direction
Visually speaking:
or
The bent normal will be the average of the unoccluded directions, as simple as that.
However, there are some problems with this technique... See this image:
There are two main escape directions ( marked in blue ) but their average gives the Nb vector which is really occluded... So you'll get a bad direction in this case...
It's useful to perform a more-accurate environment mapping because it will include occlusion information to the skylight's contribution.... The immediate effect over an specific object is that the enviroment mapping will be less intense in the shadowed parts. See these images:
jogshy, the ao has never looked better, but it's painfully slow to render. Maybe if antialiasing is disabled it will speed up?
2x= 4x slower. 4x is 16x slower.
A trick that can help: disable the tile notification. you'll get some seconds if the tiles aren't written to the preview window.
Also, play a bit with the tile size. Usually 32x32 or 64x64 are ok... but perhaps de 16x16 or the 128x128 can give you better results ( it depends on the CPU's cache ).
Another trick if you don't need very precise AO:
1. Render the per-vertex AO using the Simple AO tool into a separate highpoly .SBM
2. Assign that SBM and remove the old highpoly. UNcheck the "Ignore per-vertex AO" in the corresponding highpoly slot.
In that way the per-pixel AO will be computed interpolating the per-vertex AO computed by the Simple AO tool. It will be much faster... but it's not completely accurate.
This tool looks great, but I can't get smoothgroups properly baking in it.
They didn't import properly, and I had to export using vertex normals, but then I lose proper cage bake and I get bad seams.
Here is an example comparing xnormal and 3dsmax bake, mesh has smoothgroups.
Whats your UV layout? Did you export the sbm with "export normals" checked for the low poly?
You can test this by throwing on the xnormal bake in max viewport (showing that seam). Switch the mesh into one smoothing group. IF your seam disappears, you baked the low poly in xnormal without exporting the normals.
Yes this is with exported normals, I gather xNormal can't read smoothgroups information but requires vertex normals.
The seams is because it splits the cage by normals, I was able to get a clean bake by importing a cage.
I'll just need to figure out how it fits in my workflow, as modo currently doesn't export vertex normals and I also can't get a cage push as good as what xNormal does out of the box.
Xnormal can read smoothing groups. But I think I see where my confusion is. I thought this was in max and you exported from max in the xnormal sbm format.
Chai, the problem here is that in max your cage is averaged, but your lowpoly mesh normals are not. Xnormal will use the mesh normals for the cage by default. You can go into the 3d view and manually weld the verts and save the cage, but this is a lot more work to do compared to max or maya(in both apps its a simple option or checkbox).
I've been meaning to write up a little explanation for Santiago on how i think it could be improved, but i've been using maya recently for rendering normals so i've been lazy!
Basically it would be great if there was simply an option in the lowpoly window to use a welded/averaged mesh for projection, that has nothing to do with using a cage, as to me its a slow process to set the cage up, and you have to redo it if you change your mesh at all =(
In max its just a matter of clicking "use offset" to do the XN standard method, and the averaged cage is the default method.
In maya you can select between "Geometry normals"(averaged) and "Surface normals".
So just a click in these apps, but a long process to do the same in XN.
On a side note you can tell the max render has slightly less accurate projection(more skewing) because the entire cage is averaged. Using the mesh normals you'll get "straighter" projections, at the cost of bad seams. I've done some stuff in max where i render with both methods and combine the maps, which has worked well. The most universal solution of course is to just add some more supporting geometry so that your mesh normals are more accurate(you can also manually adjust the cage in max to fix, maya's cage doesnt work the same however and will only adjust distance, not direction).
Replies
When i apply my TANGENT NORMALMAP it got this nasty seams straight along my UV seam with up too 30% color difference on the both sides(wich is far from acceptable in my eyes):
PLZ, how do i get rid of this?
I downloaded the recent version on my Windows 7 64 bit OS. I have a high poly mesh from Zbrush, looking to be around 7milion polys. When it goes to reading the high poly mesh in xNormal, the green bar moves up to about 1/4 of the way, then the green bar goes away and its clear again and xNormal just sits there. The red abort light is still on but I've let it sit for over an hour and nothing ever happened.
Could I have been missing something. I'm doing everything the same way...all I can think of is windows 7 maybe? Thanks for any advice.
Each application has its own way to compute and use the tangent space. If you generate the maps in a XXXX application but you preview it in a YYYYY application you need a way to match the tangent basis. How can you perform that? Some advices:
1. Use object-space normal maps for non-deformable meshes.
2. Use the xNormal's 3D viewer "show tangent basis" option to see where the vertices/normals/UVs are duplicated/broken.
3. Use the xNormal SBM mesh exporter if you can. That will save into the file the Maya's tangent basis... so it will be used by xNormal.
The problem with TS-normal maps is that the normal mapper and the 3D viewer must use THE SAME tangent basis/methods or a seam will appear. For perfect results, you'll need a programmer to take a look to the xNormal and Maya SDKs ( and, probably also, to write a custom HLSL/GLSL maya shader ).
xNormal 3 has been not yet adapted to W7, sorry. I'm delaying the 3.16.12 final intentionally until W7 is oficially released.
Btw... a question that is making me crazy... I received several emails telling me there is a problem with the Dx10 graphics driver of xNormal. It seems french versions of Vista cannot display the texts on the screen... Can anybody confirm me this, pls? thx
Also thanks again for the backface ao thing, this saves soooo much time.
This has nothing to do with me using different programs, here's a screen of both maya and the xnormal viewer having the exact same problem(view in full res):
Here's a rar of the high and low poly modell so you guys can check it out for yourselves: http://data.fuskbugg.se/skalman01/shoe.rar
The shoe is pretty much a cylinder and to put it on the back just makes it so the seam will be as visable on the back as on the front... and if its a 3rd person game thats just stupid...
Soo i cant hide the seam, i want a FIX for this.
it looks like one of the channel is flipped the wrong way, try flipping either the red or the green channel
I think this sort of thing affects the tangent basis calculations so the more uniform you have the UVs, the more regular the traces will be.
Plus it'll make it easier to texture than having it rotated at an odd angle
I downloaded your (unnecessarily huge, 37mb) file from the (oddly slow - 14k/s) file host.
First thing I did was run the highpoly mesh through MeshLab, because there's absolutely no reason to spend two million triangles on a single sculpted shoe... I set the optimiser to aim for 250,000 triangles and it ended up looking identical. The main difference was the OBJ file was 18mb instead of 195mb... might be something you want to do before you upload a gigantic file next time
First I unlocked normals on the lowpoly mesh because they were all messed up, probably OBJ format's fault - what format are you using to export to XNormal? If you're using OBJ then that could be the problem, since Maya and OBJ seem to have fun messing around with perfectly fine vertex normals.
Then once I did a "soften edge" on the whole mesh, I made 3 versions of the lowpoly. One with your original UV layout, one with a rotated version so the seam was horizontally aligned, and one with a different UV layout where I think the UV seam is in the optimal position (and also it should make more efficient use of UV space).
Here's an image of the results, using Maya 2008's Transfer Maps...
So it seems like the problem is either XNormal (which seems unlikely since I and several other people I've seen have managed to generate perfect seamless normal-maps using XNormal), or your export format.
Also check to make sure you've unlocked normals and softened edges before exporting, maybe Maya is storing some dodgy normal data but not displaying it in the viewport (it does this fairly often if you're not careful).
But yeah, 2+ million polys for a shoe? Try to be a bit more efficient, I don't think you even need quarter of that polygon count to sculpt this nicely...
But without doing anything at all to the models I tried to bake the map in maya like you instead and got the same results you got, no seams.
So this only occurs when i do it it xnormal.
And yes, modells like this doesn't need to be that large and i can bake these in maya.
edit: ohh, and i did test different formats and that made no difference.
Thx
I encountered this problem too, on windows xp x64. When exporting high-res meshs from zbrush 3.5 r2 the application proceeds to load obj then progress bar changes to all white and calculation is not completed. I solved this by exporting from 3.5, importing into 3.0, then exporting to an obj again. After this xnormal will load the obj correctly and continue to bake.
So apparently there is something different about how zbrush exports obj files in the latest release.
As a note, during the export process in zbrush 3.5, zbrush notifies you that it is exporting the obj via polypaint. I don't know if this process is any different or how but it may be useful in solving this problem.
sweet, thanks!
If you have any comment please go better into the xNormal 4.0's thread
http://boards.polycount.net/showthread.php?t=50374&page=5
so we keep this one for the xn3.
thx!
http://i268.photobucket.com/albums/jj10/velesius/xnormal_gl_1.jpg
http://i268.photobucket.com/albums/jj10/velesius/xnormal_gl_2.jpg
http://i268.photobucket.com/albums/jj10/velesius/xnormal_gl_3.jpg
Thanks for any help!
Laptop?
Sorry for bad english...
My windows was installed 1 year ago. I understand that it quickly fall down to senile marasmus, but for now only Xnormal has so strange glitches. I thought it uses some particular system resources to display UI. So I told about this problem to classify what exactly wrong with my system. Anyway I totally agree that full windows reinstallation will solve this issue.
EarthQuake : The preview does not show the background color, because the .NET bitmaps pre-multiply the alpha... but, if you look into the output .BMP/.TGA file it should be the one you specified.
About thethe ZB 3.5 export and Xnormal stalling issue... could anybody send me a problematic .OBJ so I could debug it, pls? ZB3.5 does not install on my computer...
thx
Thanks for advice! :-)
And besides, there is an idea of functional extension of Xnormal. Hope you'll like it and it could be realized in the following versions. It`s all about fully functional Batch mode. I know that something like this is already present in XNoraml but sometimes it doesn't help. You can load several low-polys(LP) and maps will be burnt onto them one after another, but from the SAME COLLECTION OF HIGH POLYS(HP), what isn't always acceptable.(or I do something wrong?). Would like to have the system like in the VirtualDub.
For instance, I load LP and corresponding HP. Then I set the maps I want to burn and give them certain properies. Save all this to a file. Load another LP and different collection of Hps and setup the maps, save it and so on. After the list is made I press the START THE BATCH button and leave the computer for a week or so . I think this function could be really useful.
I can. The problem is file size. I haven't checked at what level the problem begins. For a low-poly base object, xnormal has no problem importing the model, e.g. 4,000 polys. It has trouble importing the high poly model. I have checked this on a high poly model of 3 and 12 million polys. I will check the subdivision levels in between later tonight.
@ Scooby Doofus
I tried turning texture off in the export options and unfortunately it did not solve the problem. What ws the poly count of the models for which this worked?
c: \>xNormal.exe scene1.xml scene2.xml scene3.xml
The scenes can contain a different set of LP/HP meshes, textures and output files.
For xn4 you could also write your own scripts ( for example, you could fire the HM2NM programatically or to assign a button/menu to a script ). I'm also changing the scene model ( using a "import meshes"->load/save scene file method. The scene file will contain the optimized meshes itself so it will load much faster ).
@greg: Thanks.
thanks man!
"The bent normals can be used to perform more accurate environment mapping. This is the aspect of the bent normals's map:
As you can see it looks like a normal map... but it really represents the unoccluded rays's escape direction."
Can someone elaborate on how/why this could be used to improve environment mapping?
AO is an scalar... Bent Normals have 3 components ( XYZ ).
The bent normals represent an unoccluded direction
Visually speaking:
or
The bent normal will be the average of the unoccluded directions, as simple as that.
However, there are some problems with this technique... See this image:
There are two main escape directions ( marked in blue ) but their average gives the Nb vector which is really occluded... So you'll get a bad direction in this case...
It's useful to perform a more-accurate environment mapping because it will include occlusion information to the skylight's contribution.... The immediate effect over an specific object is that the enviroment mapping will be less intense in the shadowed parts. See these images:
Environment mapping using the vertex's normals:
now using bent normals:
(extracted from http://www.cs.wisc.edu/graphics/Courses/779-s2003/final_projects/ltokheim/index.html )
So... it's basically a way to modulate the environment mapping with occlusion.
A trick that can help: disable the tile notification. you'll get some seconds if the tiles aren't written to the preview window.
Also, play a bit with the tile size. Usually 32x32 or 64x64 are ok... but perhaps de 16x16 or the 128x128 can give you better results ( it depends on the CPU's cache ).
Another trick if you don't need very precise AO:
1. Render the per-vertex AO using the Simple AO tool into a separate highpoly .SBM
2. Assign that SBM and remove the old highpoly. UNcheck the "Ignore per-vertex AO" in the corresponding highpoly slot.
In that way the per-pixel AO will be computed interpolating the per-vertex AO computed by the Simple AO tool. It will be much faster... but it's not completely accurate.
They didn't import properly, and I had to export using vertex normals, but then I lose proper cage bake and I get bad seams.
Here is an example comparing xnormal and 3dsmax bake, mesh has smoothgroups.
Anyone knows how to get this working ?
You can test this by throwing on the xnormal bake in max viewport (showing that seam). Switch the mesh into one smoothing group. IF your seam disappears, you baked the low poly in xnormal without exporting the normals.
The seams is because it splits the cage by normals, I was able to get a clean bake by importing a cage.
I'll just need to figure out how it fits in my workflow, as modo currently doesn't export vertex normals and I also can't get a cage push as good as what xNormal does out of the box.
I've been meaning to write up a little explanation for Santiago on how i think it could be improved, but i've been using maya recently for rendering normals so i've been lazy!
Basically it would be great if there was simply an option in the lowpoly window to use a welded/averaged mesh for projection, that has nothing to do with using a cage, as to me its a slow process to set the cage up, and you have to redo it if you change your mesh at all =(
In max its just a matter of clicking "use offset" to do the XN standard method, and the averaged cage is the default method.
In maya you can select between "Geometry normals"(averaged) and "Surface normals".
So just a click in these apps, but a long process to do the same in XN.
On a side note you can tell the max render has slightly less accurate projection(more skewing) because the entire cage is averaged. Using the mesh normals you'll get "straighter" projections, at the cost of bad seams. I've done some stuff in max where i render with both methods and combine the maps, which has worked well. The most universal solution of course is to just add some more supporting geometry so that your mesh normals are more accurate(you can also manually adjust the cage in max to fix, maya's cage doesnt work the same however and will only adjust distance, not direction).