Hey Per, does that mean this is what you guys rely on whenever a studio asks for 'Max specific' maps?
Would it be correct to assume that this is your preferred solution when it comes to UnrealEd (since I believe Epic is a Max house)
Also ... If you guys have this fix, I would think you also put together a Maya style shader, displaying Maya bakes properly in Max? If so, what do you guys use to transfer lowpoly meshes accross? (since obj does not carry tangents properly as far as I know. Or maybe exporters/importers ignore them)
Anyways, that picture is kinda like magic hehe. Given how more powerful Max is at handling dense geo than Maya, it would be great to find a way to bake in max, transfer the low, and display perfectly in Maya. But I guess thats a bit of a dream hehe
We'll shortly be releasing the 3DS Max normal map display fix as part of a major free release from 3Point. You can safely continue baking normal maps in Max. Here's a teaser:
img
Hey Perna that's really cool. What are you exactly doing there? Changing the tangent basis that is fed to a shader? I thought there was no way to access that ? Or is it a shader that does some extra tangent calculations ?
here is another blog post from autodesk area. this one is called '3ds Max Normal Map Baking and Face Angle Weighting: The Plot Thickens'. good thing this thread was started because in the blog post Christopher Diggins says "I should also point out that while our engineers are working on the problem the community may have a workaround soon!" and then mentions & credits polycount forum and members! so thanks again MoP for starting the thread and all the people working towards a fix.
Hello all, my name is Christopher Diggins. I'm the SDK writer for 3ds Max. This has been a very interesting thread. I appreciate all of your hard work and patience in exploring this issue.
On another note, MOP, I'd like to make a suggestion if I may. This is a really long thread, but contains a lot of really useful information (e.g. various tools and workarounds) which is buried deep in the thread. The original post (and the first few pages) paint a really bleak picture (which was fair at the time).
I thought that it might be helpful to forum visitors to have direct links to some of the more useful posts from the first post, if you aren't against making an addendum. A few posts that caught my eye as being particularly useful for users are:
Good call Mr, Diggins (that is an epic name by the way!)
I must confess I am surprised and pleased (more and more as time goes on!) by the decent treatment and frank and open discussion and interest in this particular bugbear from the guys at autodesk.
I was afraid that the autodesk behemoth would care less and less about the customers, probably because i am a massive cynic! But this great response from the AD guys has restored my faith in massive companies still having room to care.
We're finalizing presentation and documentation. Here's a few notes for now:
-The Quality solution does not require new bakes. Any previous max bakes will work.
-Output is identical to offline scanline rendering of normal maps.
-Intergration into game engines can be done as pure code or by re-export of assets using our solution.
Awesome! You 3point guys rock, can't wait! And I'll be all over anyone who mindlessly bashes Autodesk as some souless monolithic machine. These guys are out there, listening to real customer concerns, and adressing them directly. You don't see that often, and they should be acknowledged for it.
We're finalizing presentation and documentation. Here's a few notes for now:
-The Quality solution does not require new bakes. Any previous max bakes will work.
-Output is identical to offline scanline rendering of normal maps.
-Intergration into game engines can be done as pure code or by re-export of assets using our solution.
Still curious as to what you are exactly doing. I hope it's not a sceret. By what you are mentioning here it sounds like a c++ coded plugin that actually changes the viewport tangent basis calculation?
I guess we'll know soon enough, but is your solution in the form of a shader or is it some other kind of plug-in? Is it able to be combined with other existing shaders (such as Xoliul's)?
It actually sounds more like something going on on the mesh side - maybe twisting the vertex normals and tangents so that they fit just right, and exporting in a format holding those changes ... Speculation is fun haha
I reckon modifier on the stack which appropriately wrangles the basis by averaging properly or whatever is not being done by default. This is going to be great!
We have plugins for max9 and up (32-bit and 64-bit flavors). Should there be significant interest in support for earlier versions we will take it into consideration.
Chad: If you like the control of max and the results of xnormal than you are in luck. You can export your cage to xnormal in a simple step and use the cage instead of raycast in xnormal. This way you litterally do everything in 3ds max, and simply bake in xnormal (no raycast, just cage). There are actually 2 ways to do this, check out the xnormal tutorials page: http://www.xnormal.net/Tutorials.aspx
Personally, I use method 2B. Just be certain you actually make a clone of your model and don't try to export the actual cage in 3ds max. I have had problems with the actual cage in 3ds max. (vertex mis-matching errors).
Chad: If you like the control of max and the results of xnormal than you are in luck. You can export your cage to xnormal in a simple step and use the cage instead of raycast in xnormal. This way you litterally do everything in 3ds max, and simply bake in xnormal (no raycast, just cage). There are actually 2 ways to do this, check out the xnormal tutorials page: http://www.xnormal.net/Tutorials.aspx
Personally, I use method 2B. Just be certain you actually make a clone of your model and don't try to export the actual cage in 3ds max. I have had problems with the actual cage in 3ds max. (vertex mis-matching errors).
This is exactly how I do my bakes at the moment, doing the cage in max and just handling the baking in xNormal. Works really well imo
not attempting to be negative but this is a max only solution right? for examle a similar implementation would need to be made in the unreal renderer to allow it to correctly render max normal maps
Chris just told me "it's some sort of neck thing" but I believe it's socks on the ears (see avatar). I do it sometimes as well.
Sorry, I've wandered for a while and just read your post.
I must admit these are my daughter socks, where exactly is the daughter is up for speculation :poly142:
That'd be great rollin, thanks for volunteering!
I have a partial list here, though not the actual shader code for each.
If you find some shader code, let me know. Better yet, get a wiki account and post it yourself!
there is infinite possibilities...
besides the main part of the tangent basis is done when setting up vertices and their attributes of the mesh itself. Shader authors can't do much about that, the "in shader" you lack most information you need (e.g. triangle information). I am afraid it isn't as simple as doing stuff in the shader itself.
After you have calculated the appropriate basis and may have modified the output vertex count there is 2 stages for runtime work:
for vertex-shader, there is only a few combinations around. many engines pass 2 vectors and recreate the last with a crossproduct + sign information (if I recall correctly ue3, crysis, and likely many others). Some might pass in all 3 as vertex attributes.
And for pixel-shader work, some renormalize the basis on per pixel basis before transforming the normalmap vector with it, most not.
It's important to note that most engines don't really care for quality they could achieve by syncing the entire workflow (baker + engine) and just live with the quality degradation, whether they do it knowingly or not, I am not sure. I think many programmers are not aware of the major pain it can cause for artists. And sometimes it's straight impossible to "sync", when all kinds of bakers are used... and non is recommended.
I think the most important goal is to educate both programmers and artists that if they don't have a sync'ed pipe, they will not get the optimal quality, which effectively costs money and performance.
Try enclosing your filename and directories within quotation marks.
You've got spaces in the "normal map converter" folder name, which'll be throwing off the command line interpreter. Quote marks will let it read the entire directory and filename as one input.
We've been preparing a white paper on normal mapping.
I thought it might be of interest to you guys and answer some interrogations you may have. Let me know what you think of it. I will most certainly follow this polycount thread for a bit.
It would be really awesome if there could be some agreed upon standards between content creation apps soon. Then the various engines would probably follow along and things would be perfect.
It would be really awesome if there could be some agreed upon standards between content creation apps soon. Then the various engines would probably follow along and things would be perfect.
thumbs up for this statement: game engines and general game technology itself has come incredibly far, and though techniques in general are unified and all the same everywhere, it would be nice to have ground rules when it comes to specific algorithms like normal map creation. it would make switching between engines so much easier...
Ben
We haven't reached out to other folks just yet. I may or may not, depending if I need to get more alignment on our work.
Currently, Autodesk supports 2 tangent basis calculations.
1. the one in 3ds Max, implemented ages ago.
2. the one used in Mudbox / Maya is considered as the standard. Would you guy agree to this?
Right now, in 3ds Max, only the Nitrous viewport does support the Maya/Mudbox normal maps. We're working on adding support to the viewport - stay tuned.
People would use different algorithms than those supported by the Autodesk products for different reasons. For example, another computation may be used by other DCC or game middleware. Game developers may optimize the calculations for a specific look/game.
If I can foretell the future, I would guess
1. a standard may arise and the Autodesk entertainment suites are well positioned to establish it de facto with Mudbox/Maya. This standard should be supported with game engines out of the box.
2. Yet we will need to support legacy tangent basis (3ds Max) until people stop using it completely (which is something that may (or may not) happen long term).
3. Expert users/dev will still want to support different tangent basis and adding tangent basis plugin support (to drive viewport, renderer) and game engines will be desirable even if there's a standard.
Is there any chance that Max's baker could have the option to use Maya's tb calcuation. say a drop down in the RTT dialog. This would make peoples lives alot easier
2. the one used in Mudbox / Maya is considered as the standard. Would you guy agree to this?
Humm I'm not so sure about this, but then again I mostly use Unreal/UDK which if I remember correctly falls in line with the max default. There might be some internal settings that allow for both but I think default is the same as 3dsmax. I believe Unity is the same way? To that effect, its like stuffing a sqaure peg in a round hole and Maya/Mudbox default is the odd duck. As for the rest I think it mostly falls along preferred application lines for those particular studios and some kind of study would probably need to be done...
I think for me it will be a problem if I can't use scanline to render normal maps or if the default is different than the engines I use. There is just so much broken and slowness with MentalRay that I barely use it for baking anything besides AO. If scanline had a quick AO option I would never use MR. On the flip side if MR could bake a decent normal map, not do silly things like flood the background with black and not take 4x as long it might be a more attractive option...
Also I think the 3point shader has another advantage over Nitrous? It displays normal maps even if you're using a slightly outdated video card, where Nitrous I think requires a geforce300 or better? But I could be off on my facts that's just pulled from memory...
Humm I'm not so sure about this, but then again I mostly use Unreal/UDK which if I remember correctly falls in line with the max default.
Isn't it more of a case of being closer to Max,, but still not right. I mean using a max normal map in UDK doesn't result in anywhere near the quality that you would get rendering it with 3Point, or 'Qualified' normals.
Unless its been updated since last I used it, which admittedly is about a year.
Replies
Would it be correct to assume that this is your preferred solution when it comes to UnrealEd (since I believe Epic is a Max house)
Also ... If you guys have this fix, I would think you also put together a Maya style shader, displaying Maya bakes properly in Max? If so, what do you guys use to transfer lowpoly meshes accross? (since obj does not carry tangents properly as far as I know. Or maybe exporters/importers ignore them)
Anyways, that picture is kinda like magic hehe. Given how more powerful Max is at handling dense geo than Maya, it would be great to find a way to bake in max, transfer the low, and display perfectly in Maya. But I guess thats a bit of a dream hehe
jfyelle is from autodesk and they are hoping to look at the issues in max's viewport, but this looks awesome! the future is bright!
here is another blog post from autodesk area. this one is called '3ds Max Normal Map Baking and Face Angle Weighting: The Plot Thickens'. good thing this thread was started because in the blog post Christopher Diggins says "I should also point out that while our engineers are working on the problem the community may have a workaround soon!" and then mentions & credits polycount forum and members! so thanks again MoP for starting the thread and all the people working towards a fix.
http://area.autodesk.com/blogs/chris/3ds_max_normal_map_baking_and_face_angle_weighting_the_plot_thickens
(first part here if anyone missed the links above 'How the 3ds Max Scanline Renderer Computes Tangent and Binormal Vectors for Normal Mapping' http://area.autodesk.com/blogs/chris/how_the_3ds_max_scanline_renderer_computes_tangent_and_binormal_vectors_for_normal_mapping )
I want to let you know that I have made a new blog post with additional information to share about normal mapping in 3ds Max involving angle face weighting: http://area.autodesk.com/blogs/chris/3ds_max_normal_map_baking_and_face_angle_weighting_the_plot_thickens
On another note, MOP, I'd like to make a suggestion if I may. This is a really long thread, but contains a lot of really useful information (e.g. various tools and workarounds) which is buried deep in the thread. The original post (and the first few pages) paint a really bleak picture (which was fair at the time).
I thought that it might be helpful to forum visitors to have direct links to some of the more useful posts from the first post, if you aren't against making an addendum. A few posts that caught my eye as being particularly useful for users are:
- Perna's normal map display fix preview: http://boards.polycount.net/showpost.php?p=1122347&postcount=456
- Undoz and CW's edit normals workaround:
- Fozi's normal map space converter
- Osman's GUI to Fozi's tool
Anyway, its just a suggestion. Thanks again everyone for their patience and hard work investigating the problem.http://boards.polycount.net/showpost.php?p=1046668&postcount=189 / http://boards.polycount.net/showpost.php?p=1046842&postcount=195
http://boards.polycount.net/showpost.php?p=1072599&postcount=274
http://boards.polycount.net/showpost.php?p=1074986&postcount=331
And I concur, props to MoP for starting the thread.
I must confess I am surprised and pleased (more and more as time goes on!) by the decent treatment and frank and open discussion and interest in this particular bugbear from the guys at autodesk.
I was afraid that the autodesk behemoth would care less and less about the customers, probably because i am a massive cynic! But this great response from the AD guys has restored my faith in massive companies still having room to care.
wiki updated
http://wiki.polycount.net/Normal_Map#SAS
We're finalizing presentation and documentation. Here's a few notes for now:
-The Quality solution does not require new bakes. Any previous max bakes will work.
-Output is identical to offline scanline rendering of normal maps.
-Intergration into game engines can be done as pure code or by re-export of assets using our solution.
Good idea, I will update the first post with the links and information that is most pertinent to resolving this issue.
Still curious as to what you are exactly doing. I hope it's not a sceret. By what you are mentioning here it sounds like a c++ coded plugin that actually changes the viewport tangent basis calculation?
Cant wait!!!
Some questions, if I may...
Is your solution a plugin?
If its the case, does it support past versions of 3ds Max?
I'm asking because I presume any changes we _could_ do (no promises!) risk affecting only the current or the next version of 3ds Max.
stay tuned for more
Jean-Francois Yelle, ADSK (caring) Technical Product Manager.
I've done some test bakes using Max 2011 and xNormal, and everytime the xNormal comes out darker and with more depth.
I'm not sure if this is a difference using the cage in Max vs Raytracing that xNormal uses, but I find it a bit frustrating.
I like the control of Max, but xNormal gives better results.
http://www.xnormal.net/Tutorials.aspx
1. "Ray distance measurement method 2B: External cages"
2. "Ray distance measurement method 3: 3DSMAX 9 .SBM exporter"
Personally, I use method 2B. Just be certain you actually make a clone of your model and don't try to export the actual cage in 3ds max. I have had problems with the actual cage in 3ds max. (vertex mis-matching errors).
This is exactly how I do my bakes at the moment, doing the cage in max and just handling the baking in xNormal. Works really well imo
not attempting to be negative but this is a max only solution right? for examle a similar implementation would need to be made in the unreal renderer to allow it to correctly render max normal maps
Sorry, I've wandered for a while and just read your post.
I must admit these are my daughter socks, where exactly is the daughter is up for speculation :poly142:
stuff like ben posted here
this could help shader authors to implement support for different baking tools
I have a partial list here, though not the actual shader code for each.
If you find some shader code, let me know. Better yet, get a wiki account and post it yourself!
besides the main part of the tangent basis is done when setting up vertices and their attributes of the mesh itself. Shader authors can't do much about that, the "in shader" you lack most information you need (e.g. triangle information). I am afraid it isn't as simple as doing stuff in the shader itself.
After you have calculated the appropriate basis and may have modified the output vertex count there is 2 stages for runtime work:
for vertex-shader, there is only a few combinations around. many engines pass 2 vectors and recreate the last with a crossproduct + sign information (if I recall correctly ue3, crysis, and likely many others). Some might pass in all 3 as vertex attributes.
And for pixel-shader work, some renormalize the basis on per pixel basis before transforming the normalmap vector with it, most not.
It's important to note that most engines don't really care for quality they could achieve by syncing the entire workflow (baker + engine) and just live with the quality degradation, whether they do it knowingly or not, I am not sure. I think many programmers are not aware of the major pain it can cause for artists. And sometimes it's straight impossible to "sync", when all kinds of bakers are used... and non is recommended.
I think the most important goal is to educate both programmers and artists that if they don't have a sync'ed pipe, they will not get the optimal quality, which effectively costs money and performance.
Got a problem with the nSpace program...i got the GUI part working and opening, but when i hit GO! it gives me
Your argument line:
-m
ERROR: Input mesh file type not supported.
These are the obj's that came with the program. I tried re-exporting them too
Any ideas?
You've got spaces in the "normal map converter" folder name, which'll be throwing off the command line interpreter. Quote marks will let it read the entire directory and filename as one input.
Also if there was a way to make the cube-maps blend additive that would be cool.
We've been preparing a white paper on normal mapping.
I thought it might be of interest to you guys and answer some interrogations you may have. Let me know what you think of it. I will most certainly follow this polycount thread for a bit.
http://area.autodesk.com/blogs/jean/everything_you_always_wanted_to_know_about_normal_maps_but_were_afraid_to_ask
cheers,
Jean-Francois Yelle, product manager, 3ds Max.
Thanks for the update and information.
Are you guys at Autodesk in contact with Santiago Orgaz the creator of xNormal or Morten S. Mikkelsen the guy who has made a new tangent basis calculator for xNormal and the 2.5+ series of Blender.
http://wiki.blender.org/index.php/Dev:Shading/Tangent_Space_Normal_Maps
It would be really awesome if there could be some agreed upon standards between content creation apps soon. Then the various engines would probably follow along and things would be perfect.
Thanks for all of your efforts
thumbs up for this statement: game engines and general game technology itself has come incredibly far, and though techniques in general are unified and all the same everywhere, it would be nice to have ground rules when it comes to specific algorithms like normal map creation. it would make switching between engines so much easier...
We haven't reached out to other folks just yet. I may or may not, depending if I need to get more alignment on our work.
Currently, Autodesk supports 2 tangent basis calculations.
1. the one in 3ds Max, implemented ages ago.
2. the one used in Mudbox / Maya is considered as the standard. Would you guy agree to this?
Right now, in 3ds Max, only the Nitrous viewport does support the Maya/Mudbox normal maps. We're working on adding support to the viewport - stay tuned.
People would use different algorithms than those supported by the Autodesk products for different reasons. For example, another computation may be used by other DCC or game middleware. Game developers may optimize the calculations for a specific look/game.
If I can foretell the future, I would guess
1. a standard may arise and the Autodesk entertainment suites are well positioned to establish it de facto with Mudbox/Maya. This standard should be supported with game engines out of the box.
2. Yet we will need to support legacy tangent basis (3ds Max) until people stop using it completely (which is something that may (or may not) happen long term).
3. Expert users/dev will still want to support different tangent basis and adding tangent basis plugin support (to drive viewport, renderer) and game engines will be desirable even if there's a standard.
Now, about standards,
http://xkcd.com/927/
JF
I get what you are saying about making new standards, and Autodesk only really needing/wanting to look after it's own applications.
I guess I should be bugging the "others" to adopt Maya/Mudbox's tangent basis.
To my surprise qualified normals are just not working for some people...
I think for me it will be a problem if I can't use scanline to render normal maps or if the default is different than the engines I use. There is just so much broken and slowness with MentalRay that I barely use it for baking anything besides AO. If scanline had a quick AO option I would never use MR. On the flip side if MR could bake a decent normal map, not do silly things like flood the background with black and not take 4x as long it might be a more attractive option...
Also I think the 3point shader has another advantage over Nitrous? It displays normal maps even if you're using a slightly outdated video card, where Nitrous I think requires a geforce300 or better? But I could be off on my facts that's just pulled from memory...
Isn't it more of a case of being closer to Max,, but still not right. I mean using a max normal map in UDK doesn't result in anywhere near the quality that you would get rendering it with 3Point, or 'Qualified' normals.
Unless its been updated since last I used it, which admittedly is about a year.