jpeg texture converted to white pngs

[FreakTheMighty]

I exported an FBX from Maya LT with "embedded media". When I convert the FBX to gltf it appears to see the textures, unlike #54, but when it copies the textures it converts them to pure white pngs.

The FBX is here: https://storage.googleapis.com/blocker-gltf-test/GenericCameraFBX/GenericCameraEmbedded.fbx

And inside of a GenericCameraEmbedded.fbm director is this texture https://storage.googleapis.com/blocker-gltf-test/GenericCameraFBX/GenericCameraEmbedded.fbm/CameraTexture.jpg

• Running on a mac
• Latest release of FBX2glTF

[zellski]

I'll take a look at this shortly. That said -- does the texture actually work when you try to render the model? I noticed recently that I always write four-channel PNGs, which is pretty silly since it'll render them transparent in an image viewer. I'll file an issue to fix that, too, ASAP. :)

[FreakTheMighty]

It did not render correctly. It only worked after manually copying the textures. I wouldn't think that they would render transparent in image viewers unless of course the entirely alpha channel was transparent. If FBX2glTF doesn't handle image conversion such as in the tga example, why does it convert the jpgs at all? I would think a simple copy would suffice.

…

On Wed, Dec 6, 2017, 7:16 PM Pär Winzell ***@***.***> wrote: I'll take a look at this shortly. That said -- does the texture actually work when you try to render the model? I noticed recently that I always write four-channel PNGs, which is pretty silly since it'll render them transparent in an image viewer. I'll file an issue to fix that, too, ASAP. :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPFNMNTukF5STyOkj1hLIPIhB1tjjqhks5s91iAgaJpZM4Q4uPv> .

[zellski]

First of all, I should say, you're running into some very newly written code and it's not well tested. I appreciate the feedback & especially supplying me with a model to duplicate the problem.

But also you're running into a fundamental problem that's explained in the Readme in some detail.

GLTF 2.0 is a PBR format. There is no built-in support for traditional materials such as Phong, which this model uses. The converter tries to convert old textures, like a straight diffuse, to something that'll work okay in PBR. That's why it doesn't just copy. It does some pretty fancy calculations to come up with baseColor (albedo), roughness and metalness.

Clearly something in that process is going wrong, though, cause the whole point is that it should come up with something fairly close to the original. I will dig in later and try to work out what's failing, hopefully tonight, but I can't make promises -- it's mostly a hobby project. :)

[FreakTheMighty]

Ah, thanks for the info. I'm exporting from Maya LT, so given what you said about having to convert from Phong I thought I would try the Stingray PBS material. Unfortunately the FBX export does something weird with the texture maps. I'll dig into this workflow a bit more.

Anywho, thanks a ton for the tool and for looking into this.

[FreakTheMighty]

I take that last comment back, using Stingray PBS does fix the problem. That's a pretty good solution for me, though it would of course be great if it worked magic on the older materials.

[zellski]

Stingray PBS is far and beyond the best result in general -- but yes, I definitely want the conversion to work, so I'm grateful for the .fbx that shows it failing.

[zellski]

Did a bit more digging -- this isn't a coding error, it's a problem with the underlying equations, or with how I use them here. In practice, what happens is there is no specular map; specularFactor is 1, 1, 1, 0, which means a 100% metallic material, which in turn means baseColor is entirely composed of the specular contribution, is... (1, 1, 1, 0), basically. I'm not sure what can be salvaged here -- maybe the whole silly idea was not just silly, but doomed.

[zellski]

I was just taking too many liberties with the conversion. I suspect I should just throw Phong -> PBR out. But until I can dig into it more thoroughly, I've bastardised the expressions I was using, kind of randomly, with the result being fairly reasonable: