Bug: FBX reader not respecting relative paths to textures


This came up when I was looking into @Richardus.Raymaker issues with his models. This basically causes some issues content creators and forces them to use bundled textures, when the idea should be utilize as much as common resources as possible to save bandwidth costs, especially in the future.

Here are my notes:

  1. If the textures are kept in the same folder as the model, Hifi finds them just fine: ex.
    /model.fbx /texture.jpg
  2. If the textures is in a folder relative to the model, Hifi doesnt find them: this is even if they are defined so in the FBX file:
    /model.fbx /textures/texture.jpg
  3. If manually bundled in FST file and using the fst file as the model the textures are found, as Hifi seems to respect this as an overrider. Automatically the bundler cannot find the relative texture files on entities (I swear this used to work)

As a side note: AS of this moment: if a texture fails to be found, the model wont rez: Instead there should be an error texture applied to the model (Red White checker pattern maybe?): Otherwise the content creator will get frustrated trying to find the cause why their model is not rezing, even thought the model might be correctly done.

Also it seems if the model is reloaded, the textures are reloaded as well. Are the textures read from the cache at all? (need to test this)


@Menithal Do you have examples of cases 1, 2, and 3 that I could test with, please?


Sure. I’ll add the test cases I used into the ticket within the hour (currently heading home)


Attached them to the ticket #20605

As a side note, this also seems to occurs when the texture files is embedded:

Ill make a test file after the meeting tommorrow, have to head to bed its late :slight_smile:


Thanks very much, @Menithal !


Np, you can get started with the ones I put into the ticket. ill get you an example of the embedded issue (which feels related) @Richardus.Raymaker described, as well as a control of embedded as well tommorrow.


Hi @Menithal

I’ve started to get rendering with textures missing working in the code.
What would be really helpful if you have the time would be some test cases …

  1. External textures … a cube or sphere with all texture types as external files … I can then test by deleting one or more of the texture files.

  2. Embedded textures … same as external textures except several separate fbx files with textures embedded.
    embedded-textures.fbx … all textures present
    embedded-no-diffuse.fbx … diffuse missing
    embedded-none.fbx … all missing

Thanks very much!


Heya @ctrlaltdavid

Here is the one for the first test, but the relative path bug still is an issue though
Just note that I added external-textures-no-emit.fbx because while doing it I found a bug with emissions: see on the bug at https://alphas.highfidelity.io/t/bug-emission-not-behaving-as-expected/6860

For the second one test group, not quite sure how to make the textures missing from an embedded file, as all the textures tend to be embedded by default if I use embedded method: Do you just mean just as control tests?


@Menithal Thanks very much!

Re the second test group: if it’s impossible (or at least very difficult) for someone to make an FBX with embedded textures missing, we probably don’t need to worry about this case.

I’m having a look at the relative path bug, too.


Mostly the issue comes from if one embeds the file relatively to the file (instead of absolute paths). I can make a test case for it too.


@Menithal The test fbx files don’t use the specular.png texture. (Hex editing them shows no reference to specular.png.)


Just noticed i had unchecked it so it wasnt exported, sorry
, Try again with this link


The same issue holds true for .obj files. I loaded a .obj model that has a .mtl file. In it, the path was /Maps/… and the loader did not follow the path. When I modified the .mtl file to load from the same path as the model (having moved the related files there too), it worked out OK.

So, it’s a bit of a chore when there many material files to move around.