It appears that when vtkGLTFImporter reads texture data (at least texture data stored in a buffer as opposed to an external image file), the textures are upside down.
I’ve created and attached a small glTF file. It includes two textures (jpg and png to confirm that it’s not specifically related to a particular mimetype). I’ve also included screen captures of various different renderers importing the glTF file.
Blender glTF import
three.js
vtkGLTFImporter
I’d like to emphasize, I’m making no claims about other image types, or images whose contents are defined in the glTF by URIs to external files. However, I’ve observed this flipped behavior uniformly across all of my embedded glTF files (usually with png as that’s what I use). texture_arrows.zip (3.7 KB)
Presumably, you’re running against the newest version of VTK? What are the odds that I’m tripping over something old? I’m currently pinned against 9.1. (Apologies for not broaching that before.)
I’ll do some more probing around my end to figure out what’s going on. I’m certainly not manipulating anything particular. But off the top of my head, I can imagine that I’m exercising some extra VTK APIs over that example. I’ll come back around when I’ve done more probing.
tl;drvtkAssembly does not play nicely with the textures. So, less a bug in the importer and more a bug with vtkAssembly.
Full investigation
I’ve done some exploring. Starting with the example, I made some minimum modifications that reproduced the error I’m seeing. I then dug a bit further and found a single point of failure. It’s whether I gather the actors created by the importer under an assembly or not. I’ve attached the code below.
To run it (assuming you’ve done cmake .. and make):
./GLTFImporter <path_to_gltf>
In this invocation,
the actors are added directly to the renderer and the textures appear correct.
In this invocation, the actors are collected under an assembly and the assembly is added to the renderer; the texture are upside down. (Note: any second parameter is enough, I’m simply keying on the number of parameters.)
However, it’s worth noting that if the glTF importer actually brought in the structure of the glTF, instead of flattening it out, the bug in the vtkAssembly would’ve been resolved some time ago.
For the record, this definitely impacts this other issue. Using an assembly to handle the rotations is going to cause problems here.
So, for now, I’ll have to work around vtkAssembly, it appears.