Baking Lowpoly to Lowpoly in 3.05
polycounter lvl 6
Hello!
The new 3.05 features are a huge improvement to toolbag. With the bug fix of baking normal maps from LP to LP, making LODs easily and allowing other workflows is now possible in Marmoset. But I still seem to have found a few small issues when baking from one lowpoly to another.
Here in this setup I have identical objects, one using a different set of UVs to the other. On top is the original object I textured in SP2 and on the bottom is the re-UV'd object that has had the textures from the top baked onto it.
The bake is near identical, with the normal map and roughness I see no issues or complaints at all. But, just barely noticeable, the baked result appears brighter due to metalness inconsistencies.
With base colour/albedo the only issue is that sRGB actually affects the results of the bake. Since the originally textured objects need to have sRGB enabled to appear correctly, baking will result in much darker textures which will produce an identical result to the original as long as sRGB stays disabled. This isn't really an issue in Marmoset but when you take it into a game engine it's an extra step you have to go through for each asset. Would be nice to have an option included in the albedo bake settings.
sRGB also seems to be just a little buggy. With the baked material, the textures even with sRGB enabled after baking will appear washed out if the original material has sRGB disabled. Toggling sRGB off and on will fix this.
The workflow I'm using right now bakes over 14 different materials into just one, so going through all of them to disable sRGB for the bake is both time consuming and will result in the original materials appearing washed out, making any comparison between original and baked impossible.
Here you can see the baked result is almost black. I did make sure to use Albedo (Metalness). When setting the original material to have sRGB disabled will of course produce a bake where the result is identical to the original.
With metalness I'm unsure what's going on. The bake just seems darker and I haven't yet found out why. Switching sRGB doesn't help and the metalness threshold bake setting doesn't seem to have any noticeable effect.
Really hope at least the metalness gets sorted out soon. Marmoset is becoming incredibly useful to any good workflow.
The new 3.05 features are a huge improvement to toolbag. With the bug fix of baking normal maps from LP to LP, making LODs easily and allowing other workflows is now possible in Marmoset. But I still seem to have found a few small issues when baking from one lowpoly to another.
Here in this setup I have identical objects, one using a different set of UVs to the other. On top is the original object I textured in SP2 and on the bottom is the re-UV'd object that has had the textures from the top baked onto it.
The bake is near identical, with the normal map and roughness I see no issues or complaints at all. But, just barely noticeable, the baked result appears brighter due to metalness inconsistencies.
With base colour/albedo the only issue is that sRGB actually affects the results of the bake. Since the originally textured objects need to have sRGB enabled to appear correctly, baking will result in much darker textures which will produce an identical result to the original as long as sRGB stays disabled. This isn't really an issue in Marmoset but when you take it into a game engine it's an extra step you have to go through for each asset. Would be nice to have an option included in the albedo bake settings.
sRGB also seems to be just a little buggy. With the baked material, the textures even with sRGB enabled after baking will appear washed out if the original material has sRGB disabled. Toggling sRGB off and on will fix this.
The workflow I'm using right now bakes over 14 different materials into just one, so going through all of them to disable sRGB for the bake is both time consuming and will result in the original materials appearing washed out, making any comparison between original and baked impossible.
Here you can see the baked result is almost black. I did make sure to use Albedo (Metalness). When setting the original material to have sRGB disabled will of course produce a bake where the result is identical to the original.
With metalness I'm unsure what's going on. The bake just seems darker and I haven't yet found out why. Switching sRGB doesn't help and the metalness threshold bake setting doesn't seem to have any noticeable effect.
Really hope at least the metalness gets sorted out soon. Marmoset is becoming incredibly useful to any good workflow.
Replies
Woops. Well I made a new file and tested sRGB and it seems to be working fine. I'll do a few tests later to see if I can find out why. The issue can still be replicated and doesn't seem to be fixable in the file I first tried it on, I'm just unsure why.
Here you can see the albedo opened up on the right. It consistently bakes sRGB into the texture whenever it's 16 or 32 bits per channel.
Metalness still has the same slightly darker issue, bits per channel doesn't do anything there.
As far as the color space goes, we're investigating what we can do here. For now, I can explain how it works:
For various texture outputs, the color space is fixed to sRGB or linear. We make assumptions based on how the content is typically authored. Most of the outputs are linear space, except for a few map types that are typically authored perceptively / in sRGB, such as Albedo and Specular.
The problem you're running into here is that the Metalness input map is set to sRGB (this is not typical), so we're converting sRGB to linear space for the output. If you don't want this conversion to happen, make sure the input map is set to linear (click the gear icon next to the texture and turn sRGB off). This will result in the Metalness map content coming through without gamma correction.
I'm curious to know whether the sRGB setting for the metalness input was intentional? If so, is this something you need for your target engine?
As far as 8 vs 16 or 32 bit depth images, when 16 or 32 bit is selected, all map types (including albedo) are saved in linear space. So if you're loading an 8 bit sRGB albedo map and exporting a 16 bit output, the texture is getting gamma corrected from sRGB to linear, which will darken the image when you open it in Photoshop (it will appear correct when loaded into Toolbag with sRGB off, but I expect that is not what you want).
If you change the color space for albedo input so that it is linear (sRGB off), it will look wrong in the viewport but it will bake out as expected.
If you use 8 bit it should work as expected for albedo maps, without the need to adjust the input color space. Since your input maps are 8-bit, there's no benefit to baking them in 16 or 32 bit.
As for albedo I guess I'll stick to 8bit for low to low bakes. 16 bit was just out of habit for when baking high to low for SP.
Thanks for the response as always!
I think I've found some kind of bug with the quickloader with the new update. It seems to be unloading files whenever I load or refresh a file in any quickloader.
I have 4 bake groups here, all completely filled with quickloader files, yet they all get unloaded whenever I'm messing with a new baker. This isn't exclusive to quickloaded meshes. I manually imported some models and placed them into new bake groups and they also disappeared from the baker when refreshing a quickloaded file in another baker.
I've also noticed some meshes popping into a baker that shouldn't be there. The baker was duplicated just so that I could have the same bake settings, but those meshes 100% should not have been there as I deleted all the quickloaded files and the baker was completely empty after duplicating it. I'm not sure if the meshes that shouldn't be there appeared because I duplicated the baker or for some other reason, had to remove and add back each quickloaded file to get rid of them.
This seems to happen with brand new files too.
RE: sRGB Metalness, thanks for the additional detail here. We're going to set this input so that it defaults to linear space rather than sRGB. I had to re-load your inputs when I was testing, and I was confused and thought you had set the input to sRGB, but it was Toolbag's default setting. Silly me.
As for the quick loader issue, we should have this sorted out in the coming hot fix. For now, try using a separate Toolbag scene for each baker object.