Loading a Sbsar file from Substance designer in Marmoset
Hey I m trying to load a Sbsar file in Marmoset. It almost works perfectly but some things seem to go wrong
Is there a correct way to load these files.
At the moment some maps are not placed correctly in their slots
like the height, roughness and metallic for instance
It works great with the Coal material setup + changing some parameters
like:
1. Normal map - Flip Y - sRGB color on
2. Gloss Map - Gloss 1.0 - Invert True - sRGB color off
3. Reflectivity - Metalness Map - Metalness 1.0 - sRGB color off
5. Reflection - mode is GGX.
I tried to mimic the outputs from the Coal material but no luck.
Loading a Sbsar file from Substance designer in Marmoset
Hey I m trying to load a Sbsar file in Marmoset. It almost works perfectly but some things seem to go wrong
Is there a correct way to load these files.
At the moment some maps are not placed correctly in their slots
like the height, roughness and metallic for instance
It works great with the Coal material setup + changing some parameters
like:
1. Normal map - Flip Y - sRGB color on
2. Gloss Map - Gloss 1.0 - Invert True - sRGB color off
3. Reflectivity - Metalness Map - Metalness 1.0 - sRGB color off
5. Reflection - mode is GGX.
I tried to mimic the outputs from the Coal material but no luck.
Some help would be appreciated.
thanks in advance.
Hey, sorry for not getting back to you sooner, I must have missed this message.
Those map type should load in from sbsar files, but you need to make sure that your material has those shader models active in your material. For instance, if your reflectivity model is set to specular I don't think the metalness map will load. Also, make sure you're using the current version (2.06) as some substance bugs have been fixed in various updates.
Hello, have a small suggestion. Floor plane from old Marmoset was a good thing, maybe reintroduce it. Otherwise, awesome tool.
Thanks for the feedback. We don't have any plans to add the floor plane feature back in, but this is something we may look into in the future. For now you can load a plane, or any other type of mesh from your 3d modeling package, and scale it with ctrl+r to fit your scene.
It seems like a new feature has been introduced in one of the recent iterations of Toolbag, basically randomly cycling the sky preset on each startup. I am not sure if this is true of every user, but I personally find it to be distracting ; I'd personally much rather have the app remember the last settings used in the last file being worked on. Another non-distracting approach would be to always load the same default sky (which I think was the case a few versions ago.)
It seems like a new feature has been introduced in one of the recent iterations of Toolbag, basically randomly cycling the sky preset on each startup. I am not sure if this is true of every user, but I personally find it to be distracting ; I'd personally much rather have the app remember the last settings used in the last file being worked on. Another non-distracting approach would be to always load the same default sky (which I think was the case a few versions ago.)
Just thought I'd mention it !
A new feature we're dropping in 2.07 is an option to load the last saved scene on launch. Not sure if that would solve the issue for you, but maybe?
Maybe ! Not sure, but as always with that kind of stuff it is very much worth a try. I could see some arguments for and against :
+ Being able to reload the last scene on startup would be pretty great for consistency within a given project. In that context it certainly would be a time saver.
- However it could be possible to end up with a lot of tweaks which might look good for a given project but not so much for another (exposure, sky brightness) and in that case that could be an issue.
With that in mind, another interesting solution would be to have the option to load a specific default scene on startup, similarly to the way 3DSMax and Blender do it. Maybe this scene could be put in a "startup" folder somewhere, and if Toolbag doesn't see anything there, the default behavior takes over ? Of course such a user-defined startup scene should be immune to ctrl-s overwriting.
Now all these suggestions could basically end up as a case of "feature creep" and I think this should be avoided at all costs. I know that I would personally be happy with a very basic behavior (whichever ends up being implemented !) as long as there is an easy access to a few well crafted default scenes with example objects, serving as a great starting point for any project.
All that being said there certainly is something that bothers me about the current random sky cycling. I am not exactly sure why but it tends to give me a feeling of instability, if that makes any sense ? It reminds me a bit of the way Adobe enables all their new options by default in new versions of Photoshop, which in turn requires users to research how to disable them (pixel grid, I am looking at you !) I feel like simply loading the last used sky, with exposure, sky brightness and post effects settings reset to their defaults could be a good, straightforward solution.
On a unrelated note : I see that there is an option to load objects in a special .mesh Marmoset file format. But is there a way to save models out of Toolbag in that format (or any other file format for that matter) ? I often find myself in the need of passing a model from one scene to another but haven't found a way to reliably do so. I end up carefully saving all my imported OBJs in a backup folder if I ever need to load them into another scene, but that's a bit of a hassle ... Is there a way around this issue ?
Maybe ! Not sure, but as always with that kind of stuff it is very much worth a try. I could see some arguments for and against :
+ Being able to reload the last scene on startup would be pretty great for consistency within a given project. In that context it certainly would be a time saver.
Yeah its handy for that, it can also be toggled off when you don't want it in the global prefs.
- However it could be possible to end up with a lot of tweaks which might look good for a given project but not so much for another (exposure, sky brightness) and in that case that could be an issue.
With that in mind, another interesting solution would be to have the option to load a specific default scene on startup, similarly to the way 3DSMax and Blender do it. Maybe this scene could be put in a "startup" folder somewhere, and if Toolbag doesn't see anything there, the default behavior takes over ? Of course such a user-defined startup scene should be immune to ctrl-s overwriting.
Yeah, this is a great suggestion and something we've thought about as well.
Now all these suggestions could basically end up as a case of "feature creep" and I think this should be avoided at all costs. I know that I would personally be happy with a very basic behavior (whichever ends up being implemented !) as long as there is an easy access to a few well crafted default scenes with example objects, serving as a great starting point for any project.
All that being said there certainly is something that bothers me about the current random sky cycling. I am not exactly sure why but it tends to give me a feeling of instability, if that makes any sense ? It reminds me a bit of the way Adobe enables all their new options by default in new versions of Photoshop, which in turn requires users to research how to disable them (pixel grid, I am looking at you !) I feel like simply loading the last used sky, with exposure, sky brightness and post effects settings reset to their defaults could be a good, straightforward solution.
I see what you're saying, we'll think about it a bit here.
On a unrelated note : I see that there is an option to load objects in a special .mesh Marmoset file format. But is there a way to save models out of Toolbag in that format (or any other file format for that matter) ? I often find myself in the need of passing a model from one scene to another but haven't found a way to reliably do so. I end up carefully saving all my imported OBJs in a backup folder if I ever need to load them into another scene, but that's a bit of a hassle ... Is there a way around this issue ?
Right, so the .mesh support is intended for legacy TB1 files more than anything else.
We've had some thoughts about ways to help in terms of transitioning content between scenes, maybe a scene merge feature or something like that. Would that be more or less useful to you than mesh export?
As always, thanks for the detailed feedback, its good stuff!
A scene merge feature would indeed be fantastic ! It could probably work with a simple list of objects to import. I think that would be extremely useful, and would bypass the need of saving models out of the program. Very cool
A scene merge feature would indeed be fantastic ! It could probably work with a simple list of objects to import. I think that would be extremely useful, and would bypass the need of saving models out of the program. Very cool
Ok cool I thought that might solve the issue, and yeah its something I would love to see as well. More stuff on the ever growing list. :poly142:
Hey I have sent this to the support email but I'm adding it here in case anybody can help.
I am trying out some basic lighting in the engine and I am running into problems. My skylight doesnt seem to cast shadows and I cant work out why?
I tried turning off back face culling and also imported a simple box mesh and nothing seems to create shadows. Is there a way to see the size of the skylight? Maybe the light is inside my room or something?
I have tried 2.05 and 2.06 with the same results.
Edit: I have just found adding a child light does add shadows, but the shadows are very sharp, can you soften them?
To try another method of lighting I put in a spot light but the shadows are really sharp and I cannot find a way to soften them as the sharpness slider didnt affect shadows?
I tried moving the light further away and turning up the distance but that only made the shadows jaggy.
So then I tried 2.05 and there is a way to soften shadows of spot lights, although the quality isnt great, is there a way to increase the quality? I already have high res shadows on. I then saved my scene and brought it back into 2.06 and the spotlight kept the soft shadow properties from 2.05, so I am assuming this is the only way to get soft shadows on spotlights in 2.06?
Ideally I would love the skylight to work with soft shadows properly, as that will give me the best light. If the shadows are broken on the skylight is there a version of the engine that they did work in that I could save the scene and load it up in a new version (if there were any benefits) and the shadows would still work?
the size/soften slider in 2.05 and previous releases was a kind of "hack" for simulating area lights, in 2.06 we have real area lights which is what the width/length sliders are for, those sliders also affect spot lights.
Child lights of the sky are just regular lights, you can adjust any of their parameters the way you can with other lights. you can even change them from directional to omni or spot.
I can get a 1 smoothing group cube to look perfect in substance designers viewport with imported tangents and binormals, baked in xnormal using Mikktspace, but I get wavy/wobbly result in Toolbag2 2.06 even when switching through the cubes tangent basis in Toolbag. I can post pictures later tonight if needed.
As far as I am aware, there was nothing changed with Mikktspace, and it should continue to work great. Can you post some screenshots and upload an example asset?
I assume you're using the correct tangent space setting?
If your FBX file has tangents, by default it will load those up. So try re-importing the mesh but no changing the tangent space, as that will pull the tangents from the file itself (tangent space option will show as blank).
Quack! I'm getting the same thing, though, if I'm honest, I never rely on tangent basises, so I'm a bit new to the set-up (and therefore it's possible I screwed it up, but I don't think I did, having gone through it a couple of times in a row).
I tried baking with a single smoothing group (both auto-triangulated on export, and triangulated before export), and with each UV island as its own smoothing group.
I'm definitely getting some mad waviness on the single smoothing group ones.
Thanks for the test files. I think I had a brain fart here, we may have improved XN tangent space for our internal build, but any changes there won't go out until 2.07.
Nick, unfortunately your FBX files crash for me, we're doing some work under the hood with file loading so that probably has something to do with it, I'll try to come back and test this again later to see if that improves the result.
From my experience, with a test mesh like this, a 6 quad cube with no hard edges, you're always going to have some smoothing errors. Even synced with Max/Maya tangent spaces (which work perfectly in 206) you'll see some issues. So I would be curious to see how the same mesh looks in Substance with the same sort of material/lighting.
Joopson, I'm seeing the same issue with 2.06 as I am with 2.07, so maybe I'm going crazy and we put the XN tangent fixes in to 2.06. Could you also show me how it looks in your target engine with the same sort of material/lighting?
A: Your test mesh and normal map
B: Your test mesh with normal map rebaked in xnormal 3.18.8.36831
C. Your test mesh imported to Maya, resmoothed, exported as obj, baked in XN
All 3 meshes set to XN/Mikktspace. B looks very, C looks essentially perfect, why is A so bad? I have no clue, I can't for the life of me reproduce the baked result that you get in XN, when I put both maps in PS together and set one of them to difference I get:
There is a large deviation that I can't pin down. Can you try to rebake your normal map from scratch with the FBX files you sent me, and verify that you get the same normal map content that was included in the package?
Tried rebaking using a different version of xNormal, but got the same results. Tried bringing it back into maya, unlocking the normals, softening them again, then exporting again and baking, but the same results.
Edit: Interesting development. In the tangent basis settings in xNormal, enabling "Compute Binormal in the pixel shader" fixes my problems. Is there any downside to checking that box? Does it create any amount of incompatibility with Marmoset or Unreal 4?
A: Compute Binormal in the pixel shader turned off.
B: Compute Binormal in the pixel shader turned on.
By default we read the tangent/binormals from the FBX. Since you are overriding them in the settings of xNormal, I would suggest doing the same in Substance Designer. This can be done by going in the Preferences and enabling "Always recompute Tangent Frames" in the project settings (this will require a restart of Designer).
Also be sure that mikktspace.dll is loaded as the Tangent Space plugin. That should gives you the same rendering.
By default we read the tangent/binormals from the FBX. Since you are overriding them in the settings of xNormal, I would suggest doing the same in Substance Designer. This can be done by going in the Preferences and enabling "Always recompute Tangent Frames" in the project settings (this will require a restart of Designer).
Also be sure that mikktspace.dll is loaded as the Tangent Space plugin. That should gives you the same rendering.
Perfect, I was hoping that we could sync them up and this fixes that!
As far as I understood, this is a xNormal-Only Feature to "Compute Binormal in the pixel shader", isn't it?
Do I need to pay attention to this in other Software packages than xNormal?
If I try to bake a Highpoly Mesh onto a Lowpoly Mesh in Maya, for instance, where do I find this option? Do I need to check it, anyway?
By the way: Where do I find information about terms like "Mikkt", "Tangent Space" and "Binormal"?
I really have no Idea what exactly those terms mean.
Sorry if this has already been answered but is there anyway to toggle camera movement out of the undo chain? Or is this something that is possible in an update? I'm working with lighting a character right now and I've had to start adding a bunch of cameras to the scene and/or writing down light settings so that I can move around the mesh quickly without having to worry about adding a bunch of camera movements to the undo chain; Especially when trying to adjust a specific area of a mesh where you may have to move the camera to move or rotate the light itself. It's not a huge deal but it's one of those little things that would help to speed things up when working on lighting a scene.
Seconding Fabian...
What is the function of "compute binormals in pixel shader" in xNormal?
I understand that its different from just using mktt space since when baking using an obj mikkt tangent space is guaranteed but using that checkbox produces different results.
Fabian to answer your 3rd question though, "Tangent Space" is a 3d coordinate space just like "World Space" but relative to a polygon's surface normal. The axis comprising "tangent space" are the Normal, Tangent, and Bitangent/Binormal and they are perpendicular to each other. A tangent space normal map uses each polygon's own coordinate system (a.k.a. tangent space) to adjust the surface direction per each pixel given to that polygon in UV space. The normal vector is easy - it points away from the surface of the polygon. But the tangent vector and and binormal vector have to be either included with the model or derived/re-computed by both the baking and the render package. There are a couple different methods to computing these, of which one is called Mikkt and is the default "tangent basis calculator" in xNormal, Blender, and (now apparently) Unreal.
Sorry if this has already been answered but is there anyway to toggle camera movement out of the undo chain? Or is this something that is possible in an update? I'm working with lighting a character right now and I've had to start adding a bunch of cameras to the scene and/or writing down light settings so that I can move around the mesh quickly without having to worry about adding a bunch of camera movements to the undo chain; Especially when trying to adjust a specific area of a mesh where you may have to move the camera to move or rotate the light itself. It's not a huge deal but it's one of those little things that would help to speed things up when working on lighting a scene.
Sorry for the delayed response, currently there is no way to remove the camera from the undo chain. This is something we might look into if there was a lot of interest for such a feature. I have added it to our suggestion list for now, thanks!
Seconding Fabian...
What is the function of "compute binormals in pixel shader" in xNormal?
I understand that its different from just using mktt space since when baking using an obj mikkt tangent space is guaranteed but using that checkbox produces different results.
MikkTSpace is short for Mikkelsen Tangent Space. Created by Morten Mikkelsen.
This gets a little technical, not sure if you're wanting that kind of depth..
With MikkTSpace (and many other tangent bases) the tangents and binormals are computed, but are then optimised down to save on memory.
To do this, you cross-product the tangent with the normal and that gets you a third vector that becomes your new binormal. It's not the true binormal, but it doesn't matter so long as it's consistent between baker/renderer.
This is then flipped so that it roughly faces the direction that the "true" computed binormal points in - whether it should be flipped or not gets stored along with the tangent in a 4th component, it's either -1 or 1: flipped or not flipped). If you don't do this, you'll get issues with mirrored normal maps.
The point of doing this is that you can store the mesh itself with only the normal and the tangent, rather than all 3 vectors. That makes it a bit cheaper to store and transform.
You can then cheaply and easily re-do that cross product and flip directly inside the shader itself to get back an identical binormal.
Generally, it gets done per-vertex in the vertex shader, then all 3 vectors get passed through to the pixel shader.
Some engines (UE4, for example) will do the cross product per-pixel, in the pixel shader. That costs a little more, but it's a cheap operation and it means there's a little less data (or frees up room for other things) to send over to the pixel shader.
The results from doing that cross product per-vertex or per-pixel differ slightly. So to get proper syncing, you need to make sure you're doing the right one.
That check-box effectively determines whether the cross-product happens per-vertex or per-pixel, so you can match whatever the engine does.
Farfarer, yes! That's exactly the depth and the answer I was looking for.
I'm glad I asked and you explained it super well because most everyone I've talked to seemed to think that the check-box simply meant to recalculate tangent space and disregard any tangent space stored with the model or else *shrug*. Confusion ensued.
This is the art reel we put together for our 2015 Game Developers Conference booth to showcase the power of Toolbag 2. We would like to give a special thanks to each and every one of the world class artists who helped out with this video, your work is the driving force that pushes development of our products.
Sorry to bring this up again, but couldn't help read the entire page after checking the awesome GDC video and noticed the per-pixel/per-vertex discussion.
Could someone confirm for me what is the correct operation for Marmoset? I.e if Marmoset does things per-vertex in the vertex shader or per-pixel in the pixel shader when selecting the XN/Mikk tangent space?
Here is the workflow loop we put together to showcase the functionality of Toolbag 2 at our 2015 Game Developers Conference booth, featuring scene setup and presentation with area lights, camera and post effects, as well as some upcoming features like material ID support and the Marmoset Viewer. And stay tuned for the release of our new Japan and Full Sky pano packs! Thank you very much to Nicolas and Viviane for the example art content.
Sorry to bring this up again, but couldn't help read the entire page after checking the awesome GDC video and noticed the per-pixel/per-vertex discussion.
Could someone confirm for me what is the correct operation for Marmoset? I.e if Marmoset does things per-vertex in the vertex shader or per-pixel in the pixel shader when selecting the XN/Mikk tangent space?
Toolbag2 calculates the binormal in the pixel shader rather than per-vertex, so for a fully synced workflow you should check that box in xNormal. This also means that your workflow is perfectly synced between Toolbag2 and Unreal Engine as well.
Not all of our tangent space modes do this, but Mikkt does.
The man, the myth, the legend. Insomniac Games Gavin Goulden stopped by our booth to talk PBR, character setup and how Toolbag 2 has become an essential part of his workflow.
I love this so far. It's so fast and easy to get nice results. I made this beach texture from just something off CG Textures and using nDo2. I know it's not the best thing but I love how the displacement looks and all the settings you can mess around with. ~10 mins of work, ~10 mins of tinkering in Marmoset.
How this texture to tile over a large area in Toolbag? No tiling control.
I'm seeing a lot of Marmoset Viewer Assets getting uploaded to Artstation. Any details on when the export to web feature will actually be showing up? I'm in the midst of updating my portfolio, and this would be a nice feature.
Sorry, we don't have a release date in mind at this time. We're still working on some kinks and adding a couple features we think are important to have in before the public release.
Replies
Hey I m trying to load a Sbsar file in Marmoset. It almost works perfectly but some things seem to go wrong
Is there a correct way to load these files.
At the moment some maps are not placed correctly in their slots
like the height, roughness and metallic for instance
It works great with the Coal material setup + changing some parameters
like:
1. Normal map - Flip Y - sRGB color on
2. Gloss Map - Gloss 1.0 - Invert True - sRGB color off
3. Reflectivity - Metalness Map - Metalness 1.0 - sRGB color off
5. Reflection - mode is GGX.
I tried to mimic the outputs from the Coal material but no luck.
Some help would be appreciated.
thanks in advance.
Hey, sorry for not getting back to you sooner, I must have missed this message.
Those map type should load in from sbsar files, but you need to make sure that your material has those shader models active in your material. For instance, if your reflectivity model is set to specular I don't think the metalness map will load. Also, make sure you're using the current version (2.06) as some substance bugs have been fixed in various updates.
Thanks for the feedback. We don't have any plans to add the floor plane feature back in, but this is something we may look into in the future. For now you can load a plane, or any other type of mesh from your 3d modeling package, and scale it with ctrl+r to fit your scene.
It seems like a new feature has been introduced in one of the recent iterations of Toolbag, basically randomly cycling the sky preset on each startup. I am not sure if this is true of every user, but I personally find it to be distracting ; I'd personally much rather have the app remember the last settings used in the last file being worked on. Another non-distracting approach would be to always load the same default sky (which I think was the case a few versions ago.)
Just thought I'd mention it !
A new feature we're dropping in 2.07 is an option to load the last saved scene on launch. Not sure if that would solve the issue for you, but maybe?
+ Being able to reload the last scene on startup would be pretty great for consistency within a given project. In that context it certainly would be a time saver.
- However it could be possible to end up with a lot of tweaks which might look good for a given project but not so much for another (exposure, sky brightness) and in that case that could be an issue.
With that in mind, another interesting solution would be to have the option to load a specific default scene on startup, similarly to the way 3DSMax and Blender do it. Maybe this scene could be put in a "startup" folder somewhere, and if Toolbag doesn't see anything there, the default behavior takes over ? Of course such a user-defined startup scene should be immune to ctrl-s overwriting.
Now all these suggestions could basically end up as a case of "feature creep" and I think this should be avoided at all costs. I know that I would personally be happy with a very basic behavior (whichever ends up being implemented !) as long as there is an easy access to a few well crafted default scenes with example objects, serving as a great starting point for any project.
All that being said there certainly is something that bothers me about the current random sky cycling. I am not exactly sure why but it tends to give me a feeling of instability, if that makes any sense ? It reminds me a bit of the way Adobe enables all their new options by default in new versions of Photoshop, which in turn requires users to research how to disable them
On a unrelated note : I see that there is an option to load objects in a special .mesh Marmoset file format. But is there a way to save models out of Toolbag in that format (or any other file format for that matter) ? I often find myself in the need of passing a model from one scene to another but haven't found a way to reliably do so. I end up carefully saving all my imported OBJs in a backup folder if I ever need to load them into another scene, but that's a bit of a hassle ... Is there a way around this issue ?
Yeah its handy for that, it can also be toggled off when you don't want it in the global prefs.
Yeah, this is a great suggestion and something we've thought about as well.
I see what you're saying, we'll think about it a bit here.
Right, so the .mesh support is intended for legacy TB1 files more than anything else.
We've had some thoughts about ways to help in terms of transitioning content between scenes, maybe a scene merge feature or something like that. Would that be more or less useful to you than mesh export?
As always, thanks for the detailed feedback, its good stuff!
Ok cool I thought that might solve the issue, and yeah its something I would love to see as well. More stuff on the ever growing list. :poly142:
I am trying out some basic lighting in the engine and I am running into problems. My skylight doesnt seem to cast shadows and I cant work out why?
I tried turning off back face culling and also imported a simple box mesh and nothing seems to create shadows. Is there a way to see the size of the skylight? Maybe the light is inside my room or something?
I have tried 2.05 and 2.06 with the same results.
Edit: I have just found adding a child light does add shadows, but the shadows are very sharp, can you soften them?
To try another method of lighting I put in a spot light but the shadows are really sharp and I cannot find a way to soften them as the sharpness slider didnt affect shadows?
I tried moving the light further away and turning up the distance but that only made the shadows jaggy.
So then I tried 2.05 and there is a way to soften shadows of spot lights, although the quality isnt great, is there a way to increase the quality? I already have high res shadows on. I then saved my scene and brought it back into 2.06 and the spotlight kept the soft shadow properties from 2.05, so I am assuming this is the only way to get soft shadows on spotlights in 2.06?
Ideally I would love the skylight to work with soft shadows properly, as that will give me the best light. If the shadows are broken on the skylight is there a version of the engine that they did work in that I could save the scene and load it up in a new version (if there were any benefits) and the shadows would still work?
Thanks
Ben
http://www.3dscanstore.com/
I can get a 1 smoothing group cube to look perfect in substance designers viewport with imported tangents and binormals, baked in xnormal using Mikktspace, but I get wavy/wobbly result in Toolbag2 2.06 even when switching through the cubes tangent basis in Toolbag. I can post pictures later tonight if needed.
Max -> FBX w/ Tangents/Binormals -> Xnormal(Mikkt) -> Substance Designer = PERFECT!
Max -> FBX w/ Tangents/Binormals -> Xnormal(Mikkt) -> Toolbag2 = Wavy Normals!
I assume you're using the correct tangent space setting?
If your FBX file has tangents, by default it will load those up. So try re-importing the mesh but no changing the tangent space, as that will pull the tangents from the file itself (tangent space option will show as blank).
I tried baking with a single smoothing group (both auto-triangulated on export, and triangulated before export), and with each UV island as its own smoothing group.
I'm definitely getting some mad waviness on the single smoothing group ones.
I'm exporting from Maya, though.
Here are the results:
And here's a RAR containing the triangulated before export, Tangents+Binormals, cube. And the corresponding map, and all the components used to bake:
https://dl.dropboxusercontent.com/u/30185090/Boxing.rar
Max 2015(Force Triangulate) -> FBX2014 w/Tangents/Binormals -> Xnormal 3.18.8(Mikkt) -> Toolbag2 2.06 With Xnormal/Mikkt Tangent Space selected
Here are the files.
https://dl.dropboxusercontent.com/u/2344272/crit/quackToolbag2CubeTest.rar
Nick, unfortunately your FBX files crash for me, we're doing some work under the hood with file loading so that probably has something to do with it, I'll try to come back and test this again later to see if that improves the result.
From my experience, with a test mesh like this, a 6 quad cube with no hard edges, you're always going to have some smoothing errors. Even synced with Max/Maya tangent spaces (which work perfectly in 206) you'll see some issues. So I would be curious to see how the same mesh looks in Substance with the same sort of material/lighting.
Joopson, I'm seeing the same issue with 2.06 as I am with 2.07, so maybe I'm going crazy and we put the XN tangent fixes in to 2.06. Could you also show me how it looks in your target engine with the same sort of material/lighting?
Thanks.
Same workflow in but displayed in substance designer (bit depth errors represent!):
A: Your test mesh and normal map
B: Your test mesh with normal map rebaked in xnormal 3.18.8.36831
C. Your test mesh imported to Maya, resmoothed, exported as obj, baked in XN
All 3 meshes set to XN/Mikktspace. B looks very, C looks essentially perfect, why is A so bad? I have no clue, I can't for the life of me reproduce the baked result that you get in XN, when I put both maps in PS together and set one of them to difference I get:
There is a large deviation that I can't pin down. Can you try to rebake your normal map from scratch with the FBX files you sent me, and verify that you get the same normal map content that was included in the package?
This looks closer to your 'b'.
Is 3dsmax the culprit then?
Edit: Interesting development. In the tangent basis settings in xNormal, enabling "Compute Binormal in the pixel shader" fixes my problems. Is there any downside to checking that box? Does it create any amount of incompatibility with Marmoset or Unreal 4?
A: Compute Binormal in the pixel shader turned off.
B: Compute Binormal in the pixel shader turned on.
B: Compute Binormal in the pixel shader turned on, but this breaks Substances viewports.
Also be sure that mikktspace.dll is loaded as the Tangent Space plugin. That should gives you the same rendering.
Perfect, I was hoping that we could sync them up and this fixes that!
Do I need to pay attention to this in other Software packages than xNormal?
If I try to bake a Highpoly Mesh onto a Lowpoly Mesh in Maya, for instance, where do I find this option? Do I need to check it, anyway?
By the way: Where do I find information about terms like "Mikkt", "Tangent Space" and "Binormal"?
I really have no Idea what exactly those terms mean.
Best regards
What is the function of "compute binormals in pixel shader" in xNormal?
I understand that its different from just using mktt space since when baking using an obj mikkt tangent space is guaranteed but using that checkbox produces different results.
Fabian to answer your 3rd question though, "Tangent Space" is a 3d coordinate space just like "World Space" but relative to a polygon's surface normal. The axis comprising "tangent space" are the Normal, Tangent, and Bitangent/Binormal and they are perpendicular to each other. A tangent space normal map uses each polygon's own coordinate system (a.k.a. tangent space) to adjust the surface direction per each pixel given to that polygon in UV space. The normal vector is easy - it points away from the surface of the polygon. But the tangent vector and and binormal vector have to be either included with the model or derived/re-computed by both the baking and the render package. There are a couple different methods to computing these, of which one is called Mikkt and is the default "tangent basis calculator" in xNormal, Blender, and (now apparently) Unreal.
Here's the write-up on the Max calculator - http://area.autodesk.com/blogs/chris/how_the_3ds_max_scanline_renderer_computes_tangent_and_binormal_vectors_for_normal_mapping
Here's the write-up on the xNormal (Mikkt) - *shrug*
Sorry for the delayed response, currently there is no way to remove the camera from the undo chain. This is something we might look into if there was a lot of interest for such a feature. I have added it to our suggestion list for now, thanks!
This gets a little technical, not sure if you're wanting that kind of depth..
With MikkTSpace (and many other tangent bases) the tangents and binormals are computed, but are then optimised down to save on memory.
To do this, you cross-product the tangent with the normal and that gets you a third vector that becomes your new binormal. It's not the true binormal, but it doesn't matter so long as it's consistent between baker/renderer.
This is then flipped so that it roughly faces the direction that the "true" computed binormal points in - whether it should be flipped or not gets stored along with the tangent in a 4th component, it's either -1 or 1: flipped or not flipped). If you don't do this, you'll get issues with mirrored normal maps.
The point of doing this is that you can store the mesh itself with only the normal and the tangent, rather than all 3 vectors. That makes it a bit cheaper to store and transform.
You can then cheaply and easily re-do that cross product and flip directly inside the shader itself to get back an identical binormal.
Generally, it gets done per-vertex in the vertex shader, then all 3 vectors get passed through to the pixel shader.
Some engines (UE4, for example) will do the cross product per-pixel, in the pixel shader. That costs a little more, but it's a cheap operation and it means there's a little less data (or frees up room for other things) to send over to the pixel shader.
The results from doing that cross product per-vertex or per-pixel differ slightly. So to get proper syncing, you need to make sure you're doing the right one.
That check-box effectively determines whether the cross-product happens per-vertex or per-pixel, so you can match whatever the engine does.
I'm glad I asked and you explained it super well because most everyone I've talked to seemed to think that the check-box simply meant to recalculate tangent space and disregard any tangent space stored with the model or else *shrug*. Confusion ensued.
Thank you for the explanation!!:thumbup:
Toolbag 2 | GDC 2015 Artist Showcase
This is the art reel we put together for our 2015 Game Developers Conference booth to showcase the power of Toolbag 2. We would like to give a special thanks to each and every one of the world class artists who helped out with this video, your work is the driving force that pushes development of our products.
Artists:
Adam Fisher - http://afisher.com.au
Alexander Stepanchikov - http://www.stepanchikov.com/
Baj Singh - https://bajsingh.wordpress.com/
Ben Garnell
Carlo Andrea Giordano - http://www.artstation.com/artist/DergasteR
Eric Ramberg & Wiktor
Could someone confirm for me what is the correct operation for Marmoset? I.e if Marmoset does things per-vertex in the vertex shader or per-pixel in the pixel shader when selecting the XN/Mikk tangent space?
Bit confused since it seemed to be fixed here (C) but I don't think the "Compute Binormal in the pixel shader" was enabled: http://www.polycount.com/forum/showpost.php?p=2247866&postcount=1284
Toolbag 2 | GDC 2015 Workflow Showcase
Here is the workflow loop we put together to showcase the functionality of Toolbag 2 at our 2015 Game Developers Conference booth, featuring scene setup and presentation with area lights, camera and post effects, as well as some upcoming features like material ID support and the Marmoset Viewer. And stay tuned for the release of our new Japan and Full Sky pano packs! Thank you very much to Nicolas and Viviane for the example art content.
Artists:
Nicolas Garilhe - http://guedin.wix.com/guedin
Viviane Herzog - http://www.hev3d.com/
Music: The Chase by Codex Hammurabi
Toolbag2 calculates the binormal in the pixel shader rather than per-vertex, so for a fully synced workflow you should check that box in xNormal. This also means that your workflow is perfectly synced between Toolbag2 and Unreal Engine as well.
Not all of our tangent space modes do this, but Mikkt does.
Keep up the good work!
Gavin Goulden | Toolbag 2 GDC 2015 Live Demo
The man, the myth, the legend. Insomniac Games Gavin Goulden stopped by our booth to talk PBR, character setup and how Toolbag 2 has become an essential part of his workflow.
Be sure to check out Gavins portfolio as well: http://www.gavimage.com/
How this texture to tile over a large area in Toolbag? No tiling control.