Option to include textures in .babylon files

[sebavan]

I am guessing this would be the main reason.

[Drigax]

Yup, that seems to be the problem. I now convert to linear on my branch (this is the raw vertex color for both):

Only thing is the PBRMaterial still looks a bit off from the intended color… Here’s the scene with lights disabled, and the PBRMaterial set to unlit, and the Standard material Emissive as full white:

This seems similar to what @aWeirdo noticed with their texture rendering between the different material models as well via https://playground.babylonjs.com/#GDGCSP#2:

I’ll move forward checking in the color spacing fix so its easier to look at, but I can’t shake the feeling we’re missing…something…

[sebavan]

sounds weird without light

[PatrickRyan]

@aWeirdo and @drigax, I did a little digging to confirm, this is the playground from before (I don’t have the local changes to the color space) but I added a couple of node materials to demonstrate what is going on:

https://playground.babylonjs.com/#GDGCSP#29

If you change the variable on line 30, you can see the standard material node material (0) or the PBR node material (1). I did a sRGB to linear conversion in the PBR node material for vertex color and it comes as close as we can expect due to the difference in the lighting calculations between the standard material (pretty linear) and the PBR material (with options: Master Physically Based Rendering (PBR) - Babylon.js Documentation).

However, if you are only using vertex color and aren’t making use of the extra control in PBR materials, you can still use .glTF and just change out the material on load. This one is using a simple node material passing the vertex color into the standard material lighting model. This will render exactly like the one coming from the .babylon file:

I agree with @Drigax that we should be doing a conversion of vertex color when saving out to the .glTF file’s PBR standard, but there will always be a slight difference when looking at the models using both material types side by side due to the extra configuration options available in the lighting of PBR materials.

[Evgeni_Popov]

The albedo color is (0.5, 0.5, 0.5) in the PBR case.

If you correct the vertex colors to be in linear space and set the albedo color to be (1, 1, 1) you get the same rendering in the standard and PBR cases (in unlit mode):

https://playground.babylonjs.com/#GDGCSP#30

[Drigax]

That was the key @Evgeni_Popov, I need to work on my reading skills , thanks for pointing that out again! I’ll see where we’re adjusting the output albedo as well at export, seems suspicious as well

[Drigax]

BabylonJS/Babylon.js/blob/fc73d0b8196096f3fd59ea0d7877ee34d7cec6e7/serializers/src/glTF/2.0/glTFMaterialExporter.ts#L229

Problem is where we do our specGloss -> metal rough conversion for our Standard material here:
we should’nt be halving this base color factor. since this isn’t really a good workflow anyways Since we should probably support preserving base color, I’m going to remove this scaling

removing it gives us a pretty acceptable round trip:

Which is similar to what we were doing in our Autodesk Export plugins: Fix #533 : Base Color Texture is half darker than the original · BabylonJS/Exporters@7df0e69 · GitHub

@PatrickRyan, i can see you’re doing some offset and scaling of the color values in your converting shader, was this an “eyeball” conversion?

[aWeirdo]

Holy… a lot of things happend here
The latest examples are looking awesome!
Thank you all!

[PatrickRyan]

@Drigax, did a conversion on the vertex color, but it was not an eyeball conversion. I knew that the conversion to linear using pow(2.2) is an approximation so I dug up the root formula for the conversion and used that (or at least what I found was the root conversion in a formula I could understand):

sRGB color space in OpenGL

Using that formula rather than the pow(2.2) conversion yields much the same output so it really didn’t matter what conversion I used, but left the original in there for argument’s sake.