i tested both and produces exact same result as before( may be because i already have a smooth normal of the low poly mesh)
I figured. It must be something related to the tangent basis calculation. I gonna investigate a few and to try to approximate better the results to Maya's ones.
"Average normals"(or "exported normals" if you already averaged it on the modelling app) + no cage = Maya's geometry normals.
This however is not the same.
One thing I should have noted on my ray casting diagram before was that in both cases the normals are hard on the lowpoly.
Hopefully this can help demonstrate the difference.
Notice the xnormal map would make sense on the low poly if the edge was smoothed but not if it remains hard.
3.15.3 RC 1 seems to be giving buggy normal maps with hard edge showing in the normal.
Maya2008 seems to be giving better normal map altogether. i tested xnormal 3.14.x and 3.15.x and they both seem to normalize the results a bit (like flattens the depth of the normal and distort in some places. 3.15.3 RC1 actually is giving hard edges on the normal map.
here is a gif anim to show the difference:
comparison:
the error in the third one is obvious, but look closely between the maya2008 and 3.15.2
What you're seeing between maya and 3.15.2 is likely just the difference in how maya/xnormal calculate tangents/bi-tangents. Neither is really better or worse, just more specific to the app. The limitation here is that OBJ doesnt store the tangents/bitangents of your mesh when you export if from maya, so xnormal has to build them on the fly. If you need the exact tangents/bitangents its best to write an importer using the format that will actually be used in your game. Thats what we did at our studio and it help immensly with smoothing errors.
3.15.3 looks like it has some unwelded uvs, or just some weird bug.
now it makes sense. so one solution could be to develop a plugin for maya that exports all that data properly to xNormal. may be xNormal should come with that plugin because i dont see my studio spending the time to develop their own normal mapping tools unfortunately
I've just uploaded the 3.16.0 beta 1.
Killed the adaptive antialiasing ( was hard to setup and the quality suffered too ). Now it uses the old supersampling method. Btw, Johnny, that should fix your AA pixelation problems.
now it makes sense. so one solution could be to develop a plugin for maya that exports all that data properly to xNormal. may be xNormal should come with that plugin because i dont see my studio spending the time to develop their own normal mapping tools unfortunately
What we did was write a importer for xnormal so that it will support our game's format. And jogshy has been kind enough to support it with his builds so that we dont have to rebuild with every new version. I think it took one of our programmers about a half day to write it, chances are if you already have an in-house exporter, your tools guy can write you up a file loader in a very short amount of time. Really, probably less time than you've spent debugging your results in xnormal so far
Its important to get your game's format, because there may even be some differences in how maya calculates the tangents/bi-tangents, and how your exporter saves them. Tho this may not be the case, depending on if the exporter just grabs maya's data or if it calculates its own. In which case a standard maya exporter should be good enough, IIRC xnormal comes with a max plugin.
sorry if Im out of date, but im getting issues with AO maps not rendering quite the same as the norm maps when using a cage.
cant post images cos its at work, but basically lots of 90 degree angled geometry using a cage so i can capture the corners correctly from the hard edges in the low.
basically the AO is rendering correctly but seams to be raycasting differently to the norms, all im changing between renders is the type of map to render and file name, so theoretically they should be the same.
using 3.15.3.38034, again sorry if this is a duplicate post or known issue, but if you could point me in the direction of a fix :-)
sorry if Im out of date, but im getting issues with AO maps not rendering quite the same as the norm maps when using a cage.
Check the "limit ray distance" option in the AO dialog and try again. If not, cages are ignored ( which is good for outdoor objects, but very bad if you need to avoid some parts to cast occlusion over other objects ). .. and use almost 128 rays and no weighting.
I assume you use the AO software rendering and not the Simple AO GPU tool's one.
cant post images cos its at work
Send me some to my mail if you want. I'll treat all confidentially.
using 3.15.3.38034
I recommend you the 3.16.0b1. The 3.15.X had the AA and AO sightly bugged.
I have just been using xnormal to bake maps, I imported the high and low res models, used the AO tool to create SBM models of the high res. Baked normal and AO maps and it was fine. Then wanted to bake the colours of the different models to the low so got rid of the SBM models and re-imported my high res. But they were misaligned from the low poly. I deleted them and re-imported the SBM and again, the same misalignment. I haven't re-exported any of the models and they were in the right place before. Any idea what's going on? I can't send them as they are models from work.
Nope, scales are fine, it's just that the meshes are now misaligned. The high res models are back, left and up, partially outside the low res now. Baffled as to the cause of this.
But they were misaligned from the low poly. I deleted them and re-imported the SBM and again, the same misalignment. I haven't re-exported any of the models and they were in the right place before.
The versions prior to the 3.15.3 apply a re-centering mechanism to get a more accurate radius when the objects are not (0,0,0) aligned. That was a problem because if you do a "save meshes" and you then assign only one mesh instead of ALL the save saved meshes, they will be misaligned. That's why the 3.15.3 and above versions don't re-center the objects anymore. So, the solution is to use the 3.15.3/ 3.16.0b1 versions or just reassign ALL the saved meshes to the mesh slots(answer "yes" when the program ask you to re-assign the meshes automatically).
Also, remeber you need to perform a "Freeze transformations" in Maya or "ResetXForm" in 3dsmax before exporting... or the vertices won't be correctly updated/exported.
I suspect that result change is because I'm no longer welding the UVs/normal automatically. Since the 3.15.3 I respect 100% the mesh input. I had to change the bevavior due to a problem with external cages(with vertex welding the geometry topology can change).
Does the "average normals"(instead of the "use exported normals") have any effect on the output map?
Are you sure your UV's and vertex normals are welded in your model? Can you render a "wireframe and ray fails" map to detect UV seams and post it here, pls?
Does the "average normals"(instead of the "use exported normals") have any effect on the output map?
Are you sure your UV's and vertex normals are welded in your model? Can you render a "wireframe and ray fails" map to detect UV seams and post it here, pls?
average normals has no effect and my UV's and vertex normals are welded.
here is the wire render:
everything is ok with my mesh. i am only getting this error on the 3.16.0 of xNormal, previous vertions and other tools (maya/max) gives proper result.
average normals has no effect and my UV's and vertex normals are welded.
here is the wire render:
everything is ok with my mesh. i am only getting this error on the 3.16.0 of xNormal, previous vertions and other tools (maya/max) gives proper result.
Yep, all seems to be ok in your model. I'll revise the code then.
You said it's a propietary model but... can you send it to me, pls? I¡ll treat it confidentially as always. It will be very good to debug the problem.. without it it's hard to figure what's happening.
Btw, what kind of mesh format are you using? .OBJ, .LWO/LXO? And what program do you used to export the model, pls? Modo by casuality? What happens if you export the model using other format or program?
I revised all the code and cannot see what's happening with the strange normal map tangent basis seams. If anybody can send me a model exposing those artifcats it will be very appreciated. thx.
sry for the delay, just a little busy at the moment.
i have other personal models that also gives the same error, i will send you the models soon.
i am using obj format, and exporting from maya ( with smoothing and normals option on)
Hey guys. This is the first time, I have been using xnormal for baking normal maps. Usually, I do it in Maya.
Anyway, I have found a problem and I don't know what is wrong. Every time I try to bake normal map, I get this strange error. I tried lots of different settings, including mesh scale. I get this strange artifacts for every mesh on my model. When I bake normals in maya the normal map is fine. I am using OBJ format for low and high polygon model. Also settings I used are default.
Some help would be much appreciated.
I wanna also thank you jogshy for let us using this wonderful program for free.
Thanks a lot MM! Yep, there is a bug that's causing some hard edges to appear in the TS-normal maps. It's a problem with the rasterizer. I'm gonna fix it asap.
I've just uploaded the 3.16.0 final.
Tons of bugs solved.
@Johnny. The pixelization bug should be gone now. @MM. The TS-normal map "hard edges" bug should be solved now. @Hu. Solved some bugs in the cone map tool.
Might just be me but when I load up 3ds max 2k9 I get this error -
Class <xNormalSBMImp> from ... the import plugin ... has duplicate class ID: not loading.
...
Same error on the exporter.
That can be because you installed 3dsmax for x86 and then the x64 ( or you updated the OS from x86 to x64 without resintalling max or xnormal).
Just delete the xNormal_3dsmax2k9_sbm_mesh_exporter_x86.dle/dli from the max's stdplugs folder if you're using x64 or the xNormal_3dsmax2k9_sbm_mesh_exporter_x64.dle/dli if you use x86.
Tried out 3.16 on my new machine. Quad core 6600, geforce 8800 512, 8 gigs of ram. Quality of ao seems quite a bit better now that it was in older versions, but it also seems a lot slower too? Cuda renderer seems to be pretty slow as well. Was expecting a pretty big increase with my new system but didnt really see it. Also, what happened to the render preview? It not longer updates as it gets blocks done like it did before. Is there a way to enable this features?
[edit] obj loading was MUCH MUCH faster, can load a 1.6 million tris model in just a couple of seconds, GREAT JOB THERE.
Quality of ao seems quite a bit better now that it was in older versions, but it also seems a lot slower too?
Yep, it's slower but gives more quality. I killed the adaptive sampling method. It was faster but introduced a lot or errors and quality degradation... and it was hard to setup well. Also incremented the default #of samples from 16 to 128.
Cuda renderer seems to be pretty slow as well.
Yep, it's not yet well optimized(in fact, it's not optimized at all). Expect some improvements in the future. I'm talking to NVIDIA to get some support.
Also, what happened to the render preview? It not longer updates as it gets blocks done like it did before. Is there a way to enable this features?
Change the combo box on the top-left corner. Set it to "Notify tile updates" to see the preview as before... but without notification it can render faster(really, much faster).
obj loading was MUCH MUCH faster, can load a 1.6 million tris model in just a couple of seconds, GREAT JOB THERE.
Yep, specially if the model comes from ZBrush. I read the comments to skip the #verts/faces count step.
That can be because you installed 3dsmax for x86 and then the x64 ( or you updated the OS from x86 to x64 without resintalling max or xnormal).
Just delete the xNormal_3dsmax2k9_sbm_mesh_exporter_x86.dle/dli from the max's stdplugs folder if you're using x64 or the xNormal_3dsmax2k9_sbm_mesh_exporter_x64.dle/dli if you use x86.
Odd, that's not my scenario. I've only ever used x86 - maybe I downloaded the wrong Xnormal? The weird thing is that only the _x86.dle/dli files are in their right 3dsmax folders.
Odd, that's not my scenario. I've only ever used x86 - maybe I downloaded the wrong Xnormal? The weird thing is that only the _x86.dle/dli files are in their right 3dsmax folders.
/re-installs
Do this if you have problems:
1. Delete manually all the xNormal_3dsmax2k9_sbm_mesh_****** files from the 3dsmax\stdplugs folder.
2. Copy the plugin you need from the xNormal\x86\3dsmax_plugins ( if you use x86 ) or xNormal\x64\3dsmax_plugins ( if you use x64 ) to the 3dsmax\stdplug folder.
And what happens if you use a cage? It's hard to measure a good uniform ray distance.... did you measure it using a 3dsmax tape or...? I prefer cages... because it more easy to extrude it until it covers completely the highpoly model.
Btw... what's the black wireframe I see in the texture?
And what are those black parts on the sides? Did you render an object space map and forgot to uncheck the "normal map is in tangent space" on the 3D viewer's options? Is that screenshot from Maya? I don't recognize my lighting algorithm on that screenshot
sorry im very dim, checked my settings again and i did have cage ticked on. its all fine now.
couple of Qs for you though.
1- could we have the old adaptive quality as an option as i found it much faster and very usefull for AO maps
2- is it a possibility to have multiple maps render one after another, as i spend alot of time loading in the HP meshes, much more than the rendering process, if it could just load them once that would be ace, or could you have the option to load the mesh then bake whatever after.
cheers for the great software.
EDIT- also i have been having a few issues with the way xnormal triangulates models, now the way i have got round this is to get maya to triagulate the mesh befor exporting it, then applying the map ionto a non-triangulated version, it works nicely but I would love an option in the low poly rollout to change the way it triangulates the mesh for the program/engine it is intended for. obviously this may well be more work than its worth
1- could we have the old adaptive quality as an option as i found it much faster and very usefull for AO maps
I need to develop a better adaptive method. The old one had a lot of bugs and the quality was not good(specially with the AO, that had a lot of banding artifacts ). I'm working to render all the maps faster.
is it a possibility to have multiple maps render one after another, as i spend alot of time loading in the HP meshes, much more than the rendering process
xn4 will solve that: you'll import a highres mesh... then the internal structures I use for ray tracing will be computed.... then you can import the lowpoly model and setup cage or whatever... then you save an scene file.
also i have been having a few issues with the way xnormal triangulates models
im not using ngons, the quads triangulate differently to maya and the engine im using. it results in some minor shading issues, triangulating it befor exporting the low mesh results in a much cleaner normal i wil post somit if i remember
cant wait for xn4 :-)
ok top shows the normals baked from the quad and tri mesh (2nd one down), third image shows the same mesh but the norms were baked with a mesh triangulated in maya first.
Shep: Is it possible to get one of your coders to write up a reader for the format that you use? Santiago has an plugins sdk for this. We did this and it helps with those sort of issues exactly, and also provides better normals overall, because you get the exact tangents/bitangents from the mesh.
NP, i think it took one of our guys about a half days work to migrate our file format into xnormal, of course we already had code for loading it in our model viewer as well as the exporter for maya, if you've got access to those sort of things it should be relatively simple, and its way worth it.
Replies
i tested both and produces exact same result as before( may be because i already have a smooth normal of the low poly mesh)
Yes this is true you get the exact same.
This however is not the same.
One thing I should have noted on my ray casting diagram before was that in both cases the normals are hard on the lowpoly.
Hopefully this can help demonstrate the difference.
Notice the xnormal map would make sense on the low poly if the edge was smoothed but not if it remains hard.
Sorry about my bad diagrams.
Hope that's of some help.
Thanks. I'm gonna investigate a few.
Btw, i'm gonna upload the 3.16.0 soon.. because the 3.15.X are very bugged
Maya2008 seems to be giving better normal map altogether. i tested xnormal 3.14.x and 3.15.x and they both seem to normalize the results a bit (like flattens the depth of the normal and distort in some places. 3.15.3 RC1 actually is giving hard edges on the normal map.
here is a gif anim to show the difference:
comparison:
the error in the third one is obvious, but look closely between the maya2008 and 3.15.2
3.15.3 looks like it has some unwelded uvs, or just some weird bug.
now it makes sense. so one solution could be to develop a plugin for maya that exports all that data properly to xNormal. may be xNormal should come with that plugin because i dont see my studio spending the time to develop their own normal mapping tools unfortunately
I'm solving it and gonna upload tomorrow the 3.16.0 beta 1.
Killed the adaptive antialiasing ( was hard to setup and the quality suffered too ). Now it uses the old supersampling method. Btw, Johnny, that should fix your AA pixelation problems.
Feel free to test it.
thx
What we did was write a importer for xnormal so that it will support our game's format. And jogshy has been kind enough to support it with his builds so that we dont have to rebuild with every new version. I think it took one of our programmers about a half day to write it, chances are if you already have an in-house exporter, your tools guy can write you up a file loader in a very short amount of time. Really, probably less time than you've spent debugging your results in xnormal so far
Its important to get your game's format, because there may even be some differences in how maya calculates the tangents/bi-tangents, and how your exporter saves them. Tho this may not be the case, depending on if the exporter just grabs maya's data or if it calculates its own. In which case a standard maya exporter should be good enough, IIRC xnormal comes with a max plugin.
cant post images cos its at work, but basically lots of 90 degree angled geometry using a cage so i can capture the corners correctly from the hard edges in the low.
basically the AO is rendering correctly but seams to be raycasting differently to the norms, all im changing between renders is the type of map to render and file name, so theoretically they should be the same.
using 3.15.3.38034, again sorry if this is a duplicate post or known issue, but if you could point me in the direction of a fix :-)
I assume you use the AO software rendering and not the Simple AO GPU tool's one.
Send me some to my mail if you want. I'll treat all confidentially.
I recommend you the 3.16.0b1. The 3.15.X had the AA and AO sightly bugged.
same mesh compared with 3.14.3:
And I'm getting the same error as MM on the 3.16. beta
I´m getting the same
Also, remeber you need to perform a "Freeze transformations" in Maya or "ResetXForm" in 3dsmax before exporting... or the vertices won't be correctly updated/exported.
I suspect that result change is because I'm no longer welding the UVs/normal automatically. Since the 3.15.3 I respect 100% the mesh input. I had to change the bevavior due to a problem with external cages(with vertex welding the geometry topology can change).
Does the "average normals"(instead of the "use exported normals") have any effect on the output map?
Are you sure your UV's and vertex normals are welded in your model? Can you render a "wireframe and ray fails" map to detect UV seams and post it here, pls?
average normals has no effect and my UV's and vertex normals are welded.
here is the wire render:
everything is ok with my mesh. i am only getting this error on the 3.16.0 of xNormal, previous vertions and other tools (maya/max) gives proper result.
Yep, all seems to be ok in your model. I'll revise the code then.
You said it's a propietary model but... can you send it to me, pls? I¡ll treat it confidentially as always. It will be very good to debug the problem.. without it it's hard to figure what's happening.
Btw, what kind of mesh format are you using? .OBJ, .LWO/LXO? And what program do you used to export the model, pls? Modo by casuality? What happens if you export the model using other format or program?
i have other personal models that also gives the same error, i will send you the models soon.
i am using obj format, and exporting from maya ( with smoothing and normals option on)
Anyway, I have found a problem and I don't know what is wrong. Every time I try to bake normal map, I get this strange error. I tried lots of different settings, including mesh scale. I get this strange artifacts for every mesh on my model. When I bake normals in maya the normal map is fine. I am using OBJ format for low and high polygon model. Also settings I used are default.
Some help would be much appreciated.
I wanna also thank you jogshy for let us using this wonderful program for free.
Tons of bugs solved.
@Johnny. The pixelization bug should be gone now.
@MM. The TS-normal map "hard edges" bug should be solved now.
@Hu. Solved some bugs in the cone map tool.
Class <xNormalSBMImp> from ... the import plugin ... has duplicate class ID: not loading.
...
Same error on the exporter.
Just delete the xNormal_3dsmax2k9_sbm_mesh_exporter_x86.dle/dli from the max's stdplugs folder if you're using x64 or the xNormal_3dsmax2k9_sbm_mesh_exporter_x64.dle/dli if you use x86.
[edit] obj loading was MUCH MUCH faster, can load a 1.6 million tris model in just a couple of seconds, GREAT JOB THERE.
Running xp 64 btw.
Yep, it's not yet well optimized(in fact, it's not optimized at all). Expect some improvements in the future. I'm talking to NVIDIA to get some support.
Change the combo box on the top-left corner. Set it to "Notify tile updates" to see the preview as before... but without notification it can render faster(really, much faster).
Yep, specially if the model comes from ZBrush. I read the comments to skip the #verts/faces count step.
Odd, that's not my scenario. I've only ever used x86 - maybe I downloaded the wrong Xnormal? The weird thing is that only the _x86.dle/dli files are in their right 3dsmax folders.
/re-installs
1. Delete manually all the xNormal_3dsmax2k9_sbm_mesh_****** files from the 3dsmax\stdplugs folder.
2. Copy the plugin you need from the xNormal\x86\3dsmax_plugins ( if you use x86 ) or xNormal\x64\3dsmax_plugins ( if you use x64 ) to the 3dsmax\stdplug folder.
Max has been acting weird lately anyway - I'll just re-install it.
Thanks jogshy!
although it does seam to be just the forward pushed geometry that its having issues with
Btw... what's the black wireframe I see in the texture?
And what are those black parts on the sides? Did you render an object space map and forgot to uncheck the "normal map is in tangent space" on the 3D viewer's options? Is that screenshot from Maya? I don't recognize my lighting algorithm on that screenshot
couple of Qs for you though.
1- could we have the old adaptive quality as an option as i found it much faster and very usefull for AO maps
2- is it a possibility to have multiple maps render one after another, as i spend alot of time loading in the HP meshes, much more than the rendering process, if it could just load them once that would be ace, or could you have the option to load the mesh then bake whatever after.
cheers for the great software.
EDIT- also i have been having a few issues with the way xnormal triangulates models, now the way i have got round this is to get maya to triagulate the mesh befor exporting it, then applying the map ionto a non-triangulated version, it works nicely but I would love an option in the low poly rollout to change the way it triangulates the mesh for the program/engine it is intended for. obviously this may well be more work than its worth
xn4 will solve that: you'll import a highres mesh... then the internal structures I use for ray tracing will be computed.... then you can import the lowpoly model and setup cage or whatever... then you save an scene file.
Hmmmm.... why? Are you using ngons?
cant wait for xn4 :-)
cheers for the help