SEA3D vs GLTF

6 thoughts on “SEA3D vs GLTF”

1. In that case, I still don’t consider this to be a complete or actionable bug report and I continue to vote to close this issue.

2. The users are interested in the best results with THREE. Other engines and 3D authoring environments are irrelevant here.

   Being able to author a PBR model in Substance Painter or download one from Sketchfab, and have the model appear as the artist designed it, is good for three.js users. I don’t think there’s any definition of “best result” where that sort of consistency can be dismissed.

   This topic shows GLTFLoader design flaws. We don’t reinvent the wheel here, so “renderer.gammaOutput = true” is not an option now…

   This isn’t reinventing any wheels, and it isn’t a design flaw. PBR calculations are done in linear space, with every engine I’m aware of. If you pass sRGB data into the renderer and pretend it’s linear, the lighting and blending math will come out wrong. The difference is not huge, and so this not a major concern for many three.js users, but nevertheless it is not as good as it could be. For that reason, your “good” result example is not actually correct. But as you’ve said before, backward-compatibility is important, so I’m not here to advocate for changing any three.js defaults. But because glTF is a new format, and because we’re trying to get PBR right, we’re going to mark sRGB textures as sRGB, even if other loaders are not doing so.

   See this article about Unreal —

   …textures that are used for color information should have the sRGB flag checked, and textures that are used for masks and numerical calculations in shaders and effects (like Normal maps) should have it unchecked. And if you follow this simple guideline you mostly get the best effect.

   This is precisely what we are doing.

3. You are talking about PBR materials with glTF, but I assume this is just as much a problem with a Phong material?

   Yes, the problem is the same for Phong materials or PBR materials loaded in any other format.

   …should other loaders be doing so? It seems like this inconsistency between loaders is a point of confusion for users, and it would make sense for all of them to treat sRGB textures the same way if possible.

   If we had a time machine, yes, the other loaders should also be marking sRGB textures containing color data as sRGB. But making the change now would cause confusion and break backward-compatibility, and the gammaOutput=true setting needed to fix output is not intuitive — I don’t think changing other loaders can be justified given those issues.

   Let’s keep an eye on #11337. I hope the resolution there will make color workflows more intuitive. With that and NodeMaterial, there may be opportunities to fix some existing issues without breaking anyone’s existing applications.

4. I’ve addressed each of those points in #14419 (comment) — we will not be removing the sRGB encoding assignment to sRGB textures in GLTFLoader. If you would like to override that, it is easy to change the texture encoding after loading the model.

   If there are no other actions to take here, this issue should be closed.

5. If you care to read all the guidelines, there’s a document called owners.

   Wow, I never say that before. And apparently I “own” the FBXLoader 😍 😆

6. I’ve never marked yours or anyone else’s comments as disruptive.

   I’m the one who was doing this. As collaborators we have to moderate issues and ensure correct language and behavior.

Comments are closed.