Ah, right one. Most of the openings I'm seeing are for Unreal3 experienced artists, so that's likely my target. Anything looking good in UE3 would be what I'm after
Wow, how did I manage to miss this discussion? This is something that caught my attention a while back with woes on shiny hard-surface objects in UE3. I'll be reading back over the full discussion and see if I can contribute anything that hasn't already been covered.
After reading alot of the discussion. I just use topogun to render out my normals and other maps.
I still havn't gotten too far with XNormal yet.
How is Topogun for baking? It is more efficient with the cage settings?
EDIT: Just got Topogun and the baking to me looks a bit better than Xnormal. It fixed a lot of shading errors I got from XNormal. Having trouble with the AO baker however.
Fozi: the problem i see right now about the OS to TS tool is that, in order to bake nice OS normal maps, there can't be overlapping faces on the uvs right?
So, we have to make one set of uv's for the OS bake to be correct, then, when it converts to TS.. we have to make another set of uv's to transfer them. amirite?
Won't this cause a problem, when chaing uv islands and shit?
As long as you offset your mirrored uvs, all is well. You see when you convert, all you're converting is the *rendered* OS map into tangent space, in the 0-1 range. So everything in the 0-1 range transfers correctly. However it would not display(as OS) correctly, it would transfer to TS just fine. Now there are ways to mirror OS as well, just ask CrazyButcher.
I've updated my normalmap article.
I've done a small comparison between packages, and I gotta say the results are similar - xnormal and maya being only slightly better than 3dsmax, at the end of the day you gotta work around your smoothing errors either way.
Hmm I'm confused - is the OS->TS thing be done on the fly ingame, or is it a tool that the artist uses to generate better TS maps ?
@ bitmap, I am working on a bigger package with the 3ps material/3ps tangent modifier. And you can imagine with Per being around the UI has to look nice and be ultra functional
This is very basic first version of the normal map space converter. Right now, it is able to convert any world space normal map, as long as it matches the obj space, into the Max's viewport tangent basis. The generated TS normal map should work with "Normal Bump" (tested max 2010) out of the box.
To run the application you might need to install the VC++ 2008 runtimes. Get it here.
It's far from finished, but does the job that was promised. I'll be posting more info later.
I always thought this was just because you needed more geo on the low poly to make it bake without artefacts.
I never thought of it as a max specific issue.
Does this mean that you could bake a low poly box with no bevels and only 1 smooth group and it would look ok if you baked it in maya?
I have tried this max and the render looks correct as you mentioned but in the view port you get weird shading artefatcs
ruz the plugin/shader I did will fix the viewport for max. its just a matter of someone at 3ps finding the time to make a nice sample scene with the shaders features. Which given they are all busy is hard But without a nice sample scene, it's a bit ugly to release a realtime shader.
Ruz, it happens when the tangent basis changes too fast. (e.g. 90 degree angles)
Using a higher bit per-channel output format would solve the problem. A more practical solution is to do a better job at converting the generated high resolution normal down to 8bit per-channel. The latter is one of my priorities, and while it won't solve the problem, it'll shade a lot better.
For now, either tonight (or this weekend at most), I'll update the build to support input and output of 48bit per-channel normal maps.
Ruz, I was called to attention that I might have misread your post.
- If the lighting looks good in the render but not in the viewport, it's possible that you weren't using the converted normal map. It's supposed to be the other way around.
- Another possibility is that you are using a DirectX Shader Material. These shaders need to be modified in order to match the tangent basis used in "Normal Bump". I can do this modification for you.
- Or maybe an older version of Max?
I would love to get more shaders fixed to use your modification. What exactly did you do to get good bitangency? It would be great to let shader authors make versions of their popular shaders, if they desire... CrazyButcher, Xoliul, Rollin, etc.
I wonder if you would be able to do the opposite conversion as well, from tangent to object? I can do this in a bit of a manual process, by bumping the mesh and using RTT to bake an object-space map, but it's a bit of a drag.
I wonder if you would be able to do the opposite conversion as well, from tangent to object? I can do this in a bit of a manual process, by bumping the mesh and using RTT to bake an object-space map, but it's a bit of a drag.
That's precisely the concept behind this tool. Currently it only does WS->MaxTS, but in the future I plan to support, not only MaxTS<-WS, but ANY<->ANY. That includes authoring tools and rendering engines.
ok there's on thing I don't understand. Where does the problem lie?
as far as I understand it, the problem is caused by max's normal baker.. not the viewport display ..
if this is correct, changing any viewport shader wouldn't help.. it would just be a nice gimmick but more useful would be indeed a tool to convert normalmaps from all different engines back and forth
even better would be some kind of norm.. but .. well..
I have read through this thread briefly and I am having some trouble understanding some of it, so I was wondering if anyone could dumb it down a bit for the less technical such as myself.
Now I understand that when you bake something tangent space in 3ds max that has a greater angle change than 90 degrees on one smoothing group you get errors.
But you guys are saying this is an error with the baker, and it is possible to get tangent space normal maps that CAN handle this?
Are you also saying that one way to solve this, is to use max and bake Object space then use the program that fozi wrote to convert back to tangent space as a work around for this issue of baking maps with models that have greater than 90 degree turns?
So if I am understanding this all correctly, could anyone explain how to use fozi's program. When I run nspace.exe I just get that black bios type interface, and I don't know what to do with it. I have windows 7 64 bit btw. I was thinking possibly I had to drag something onto the .exe file or type something in the box when it is run, but both seem to simply shut down the program and do nothing.
Anyways, it would be great if I could get some answers to these question. I always thought these were just limitations with tangent space maps, not how the programs are baking themselves. Awesome thread!
I was thinking possibly I had to drag something onto the .exe file or type something in the box when it is run, but both seem to simply shut down the program and do nothing.
you run it from the command. look into the readme, it is explained there
you can create a bat file to run the program with your commands and you don't have to type them in again and again.
rollin: Thanks! Yeah for some reason when I run the .exe and get the command prompt, as soon as I type anything it closes.
But I am able to open note pad paste the appropriate code (looking at the "usage.txt" file explains the code) and save as .bat. So I can in-turn click on the .bat file and convert properly.
It would be cool if there was a little interface or something, but I won't complain, this thing is really freaking cool. I have to run some tests now!
Where does the problem lie?
as far as I understand it, the problem is caused by max's normal baker.. not the viewport display
The 3ds Max tool Render To Texture generates normalmaps that render correctly in the offline renderer (scanline, using the Normal Bump map type) but do not render correctly when using the realtime DirectX viewport shaders. 3ds Max seems to be interpolating the tangent basis per-pixel in the renderer, but per-vertex in the viewport. This is readily apparent when creating non-organic hard surface normalmaps; smoothing errors appear in the viewport that do not appear when rendered.
fozi's shader fix allows the viewport shaders to act the same as Normal Bump does in the scanline renderer.
Eric, not at all. Feel free. Keep in mind though, the shader fix only works if you use normal maps converted by NSpace, which is prepared to output "Normal Bump" compatible tangent maps.
rollin, the problem is neither one or the other. They use incompatible tangent basis. You can fix either of them to solve the problem, but that's not what I did. I went for the generic solution, which is what you describe in the bottom half of your post. I decided to start with Max because the whole idea originated from this thread.
I'm also looking for a decent norm, and I'll integrate it into the tool as soon as possible. On top of that, I'm looking for a quick per-pixel solution to take full advantage of 8bit per-channel TS normal maps.
BradMyers82, might take me a while to get a UI out the door, but I'm working on it. Regarding the explanation, let me get back to you on that.
fozi - yeah that's just the standard max dx material I was using. I have n't mesed with anything else yet.
I just always assumed that the rendered version used a more advanced method to display the tangents and that the real time version for the sake of speed was slightly broken
TBH as a character artist who deals mainly with cloth and the occasional accessory it doesn't affect me as much as the tech guys. I try to avoid straight lines at all costs:)
Just out of interest is there anything wrong with rebaking an existing normal map with RTT in max. Will that break the normal map?
My intention is to rebake a map from channel 1 to channel 2 which has a different UV layout.
Would I need to renormalize that?
Just out of interest is there anything wrong with rebaking an existing normal map with RTT in max. Will that break the normal map?
My intention is to rebake a map from channel 1 to channel 2 which has a different UV layout.
Would I need to renormalize that?
I've done this with RTT, works fine. Some tips here.
Keep in mind though, the shader fix only works if you use normal maps converted by NSpace, which is prepared to output "Normal Bump" compatible tangent maps.
I thought that's what RTT bakes out by default when you choose tangent space output?
Okay, I tested out the conversion software.
-Now either I'm not doing it right
-I don't understand the limitations
-Or It's because I am attempting to use 3ds max standard "Show hardware map in viewport"
But my results are not good so far.
Here is what I did:
I created a bullet model both high and low as a test object. Mainly because on the end it has a greater than 90 degree angle.
I unwrapped the low poly and gave it one smoothing group.
I baked in 3ds max a regular tangent space map and a world space Map with default settings
I found that in order to use the conversion software I had to ***triangulate my mesh*** and do a Reset XForm and collapse. My export settings were set to .obj and Mudbox default settings. If I didn't taking these steps first the conversion software would crash.
So, once I ran the conversion software I got the results shown.
It appears like there is a large shadow on the model when I use the converted world space to Tangent space Normal map. Also, it doesn't look like any normal map I'm used to seeing with all that color in there.
If anyone can help me out I would really appreciate it!
The shading issues could be:
1) Either the obj is not being exported with Max's native axis orientations, maybe a Z/Y rotation in the exporter?
2) The world space normal map was not rendered with X and Y both positive (projection options)?
3) I screwed up somewhere and I could use that sample model to fix it.
I'm going to have a look at that crash. The tool doesn't support quads yet but it should have presented an error message instead.
fozi: Thanks for the info. I will try a couple more tests to make sure its not due to 1. or 2. that you mentioned. I'll get back to you with the results soon.
Hurray! I got it to work! This is so freaking sweet, I didn't think it was even possible with tangent space normals.
Looks like I have a new workflow now, that not only is faster, and easier, but yields better results!
This is awesome.
Thanks for the explaination of settings Undoz, and thanks so much for the software fozi.
Hurray! I got it to work! This is so freaking sweet, I didn't think it was even possible with tangent space normals.
Looks like I have a new workflow now, that not only is faster, and easier, but yields better results!
This is awesome.
Thanks for the explaination of settings Undoz, and thanks so much for the software fozi.
Results:
So your baking the normals using world space instead of Tangent space and then converting it back to tangent space after?
It doesn't seem to work quite right for me. I baked both tangent and world maps, then converted the world map. Tangent and world render correctly, Nspace doesn't. I also have unaltered viewport shaders assigned (RTTNormalmap.fx), you can just disregard those.
Eric, are you doing scanline renders? Because that sort of defeats the whole purpose doesnt it, this tool fixes your bakes so that it will display correctly realtime, not in offline rendering.
Replies
I still havn't gotten too far with XNormal yet.
How is Topogun for baking? It is more efficient with the cage settings?
EDIT: Just got Topogun and the baking to me looks a bit better than Xnormal. It fixed a lot of shading errors I got from XNormal. Having trouble with the AO baker however.
Bad news: tangents in exported FBX still don't match the Max viewport. Basis smoothing is different along UV edges.
The conversion tool is almost ready, only Max OS to TS for now. I just need to get the tangents right and do a bit of polishing.
So, we have to make one set of uv's for the OS bake to be correct, then, when it converts to TS.. we have to make another set of uv's to transfer them. amirite?
Won't this cause a problem, when chaing uv islands and shit?
so we can mirror shit with OS NMaps?
I've done a small comparison between packages, and I gotta say the results are similar - xnormal and maya being only slightly better than 3dsmax, at the end of the day you gotta work around your smoothing errors either way.
Hmm I'm confused - is the OS->TS thing be done on the fly ingame, or is it a tool that the artist uses to generate better TS maps ?
ask Renderhjs to make a nice ui:)
http://diogo.codingcorner.net/uploads/NSpacePack.zip
This is very basic first version of the normal map space converter. Right now, it is able to convert any world space normal map, as long as it matches the obj space, into the Max's viewport tangent basis. The generated TS normal map should work with "Normal Bump" (tested max 2010) out of the box.
To run the application you might need to install the VC++ 2008 runtimes. Get it here.
It's far from finished, but does the job that was promised. I'll be posting more info later.
The test model was done by engelik
I never thought of it as a max specific issue.
Does this mean that you could bake a low poly box with no bevels and only 1 smooth group and it would look ok if you baked it in maya?
I have tried this max and the render looks correct as you mentioned but in the view port you get weird shading artefatcs
Using a higher bit per-channel output format would solve the problem. A more practical solution is to do a better job at converting the generated high resolution normal down to 8bit per-channel. The latter is one of my priorities, and while it won't solve the problem, it'll shade a lot better.
For now, either tonight (or this weekend at most), I'll update the build to support input and output of 48bit per-channel normal maps.
Also it's great that I can still use the baking tools from max and convert the map at the end with one click.
- If the lighting looks good in the render but not in the viewport, it's possible that you weren't using the converted normal map. It's supposed to be the other way around.
- Another possibility is that you are using a DirectX Shader Material. These shaders need to be modified in order to match the tangent basis used in "Normal Bump". I can do this modification for you.
- Or maybe an older version of Max?
Cheers guys, glad to be of assistance.
I would love to get more shaders fixed to use your modification. What exactly did you do to get good bitangency? It would be great to let shader authors make versions of their popular shaders, if they desire... CrazyButcher, Xoliul, Rollin, etc.
I wonder if you would be able to do the opposite conversion as well, from tangent to object? I can do this in a bit of a manual process, by bumping the mesh and using RTT to bake an object-space map, but it's a bit of a drag.
http://diogo.codingcorner.net/uploads/nspace_shaderfix.txt
I'll do my best to provide patched versions of those shaders this weekend.
That's precisely the concept behind this tool. Currently it only does WS->MaxTS, but in the future I plan to support, not only MaxTS<-WS, but ANY<->ANY. That includes authoring tools and rendering engines.
Would you mind if I posted your shader fix to the Polycount wiki? It would be attributed to you, with a link to your site.
as far as I understand it, the problem is caused by max's normal baker.. not the viewport display ..
if this is correct, changing any viewport shader wouldn't help.. it would just be a nice gimmick but more useful would be indeed a tool to convert normalmaps from all different engines back and forth
even better would be some kind of norm.. but .. well..
Now I understand that when you bake something tangent space in 3ds max that has a greater angle change than 90 degrees on one smoothing group you get errors.
But you guys are saying this is an error with the baker, and it is possible to get tangent space normal maps that CAN handle this?
Are you also saying that one way to solve this, is to use max and bake Object space then use the program that fozi wrote to convert back to tangent space as a work around for this issue of baking maps with models that have greater than 90 degree turns?
So if I am understanding this all correctly, could anyone explain how to use fozi's program. When I run nspace.exe I just get that black bios type interface, and I don't know what to do with it. I have windows 7 64 bit btw. I was thinking possibly I had to drag something onto the .exe file or type something in the box when it is run, but both seem to simply shut down the program and do nothing.
Anyways, it would be great if I could get some answers to these question. I always thought these were just limitations with tangent space maps, not how the programs are baking themselves. Awesome thread!
you run it from the command. look into the readme, it is explained there
you can create a bat file to run the program with your commands and you don't have to type them in again and again.
But I am able to open note pad paste the appropriate code (looking at the "usage.txt" file explains the code) and save as .bat. So I can in-turn click on the .bat file and convert properly.
It would be cool if there was a little interface or something, but I won't complain, this thing is really freaking cool. I have to run some tests now!
The 3ds Max tool Render To Texture generates normalmaps that render correctly in the offline renderer (scanline, using the Normal Bump map type) but do not render correctly when using the realtime DirectX viewport shaders. 3ds Max seems to be interpolating the tangent basis per-pixel in the renderer, but per-vertex in the viewport. This is readily apparent when creating non-organic hard surface normalmaps; smoothing errors appear in the viewport that do not appear when rendered.
fozi's shader fix allows the viewport shaders to act the same as Normal Bump does in the scanline renderer.
Eric, not at all. Feel free. Keep in mind though, the shader fix only works if you use normal maps converted by NSpace, which is prepared to output "Normal Bump" compatible tangent maps.
rollin, the problem is neither one or the other. They use incompatible tangent basis. You can fix either of them to solve the problem, but that's not what I did. I went for the generic solution, which is what you describe in the bottom half of your post. I decided to start with Max because the whole idea originated from this thread.
I'm also looking for a decent norm, and I'll integrate it into the tool as soon as possible. On top of that, I'm looking for a quick per-pixel solution to take full advantage of 8bit per-channel TS normal maps.
BradMyers82, might take me a while to get a UI out the door, but I'm working on it. Regarding the explanation, let me get back to you on that.
I just always assumed that the rendered version used a more advanced method to display the tangents and that the real time version for the sake of speed was slightly broken
TBH as a character artist who deals mainly with cloth and the occasional accessory it doesn't affect me as much as the tech guys. I try to avoid straight lines at all costs:)
Just out of interest is there anything wrong with rebaking an existing normal map with RTT in max. Will that break the normal map?
My intention is to rebake a map from channel 1 to channel 2 which has a different UV layout.
Would I need to renormalize that?
I've done this with RTT, works fine. Some tips here.
I thought that's what RTT bakes out by default when you choose tangent space output?
-Now either I'm not doing it right
-I don't understand the limitations
-Or It's because I am attempting to use 3ds max standard "Show hardware map in viewport"
But my results are not good so far.
Here is what I did:
I created a bullet model both high and low as a test object. Mainly because on the end it has a greater than 90 degree angle.
I unwrapped the low poly and gave it one smoothing group.
I baked in 3ds max a regular tangent space map and a world space Map with default settings
I found that in order to use the conversion software I had to ***triangulate my mesh*** and do a Reset XForm and collapse. My export settings were set to .obj and Mudbox default settings. If I didn't taking these steps first the conversion software would crash.
So, once I ran the conversion software I got the results shown.
It appears like there is a large shadow on the model when I use the converted world space to Tangent space Normal map. Also, it doesn't look like any normal map I'm used to seeing with all that color in there.
If anyone can help me out I would really appreciate it!
The shading issues could be:
1) Either the obj is not being exported with Max's native axis orientations, maybe a Z/Y rotation in the exporter?
2) The world space normal map was not rendered with X and Y both positive (projection options)?
3) I screwed up somewhere and I could use that sample model to fix it.
I'm going to have a look at that crash. The tool doesn't support quads yet but it should have presented an error message instead.
Cheers Brad, CB
Try these settings. If I enable Normals at export I get strange results.
Looks like I have a new workflow now, that not only is faster, and easier, but yields better results!
This is awesome.
Thanks for the explaination of settings Undoz, and thanks so much for the software fozi.
Results:
I've tested it with the test model EQ provided here
(So I've checked the difference between the provided nmaps and a max-WS bake convertet to TS with this tool)
So your baking the normals using world space instead of Tangent space and then converting it back to tangent space after?
(gotta think of straightening those UV edges now tho hehe)
Here are the Max 2010 example files