Progressive Texture Loading Sprites and Tiled Textures

I’m fiddling around with progressive texture loading and I have problems in some cases. As soon as the script is in the scene. Some Textures always stay at their lowest setting and do not get progressively loaded further:

  • UI Images/Sprites
  • Vector Graphics imported as Texture Sprite with unity SVG Package
  • all normal Textures on materials that are tiled > 1. Duplicating the same Material, setting tiling to 1 and putting it somewhere in the scene does nothing to the tiled texture sadly

Original Post on Discord

by user 334342083445784576

Hello @Podden thanks for the reports

  • Progressive loading for UI graphics is not yet supported. If you need that could you open a feature request on github?
  • The same might be true for Vector graphics, actually i havent used the package yet ever :sweat_smile: what are they using for rendering the image?
  • That means if a normal texture is progressively loaded and has a tiling != 1 then the texture is not replaced at all?

Last point: Yes, as soon as if use tiling != 1, the texture stays at, say, 32x32 and does not get progressivly loaded.
I’ve put a demo together. It seems the applying to the material fails, because the image_…glb is created and I see console logs of loading this glb on the tiled mateiral. This was build with 2.66, Unity 2022.2.8 and URP 14

by user 334342083445784576

Oh I just saw my texture is named “CharacterController”. So the console says it all, the uuid is generated wrong
"unknown uuid CharacterController a76fd0a9-d9e9-4180-b000-a201436f5191 "

by user 334342083445784576

I still have not figured out why the uuids of textures are not correctly exported when using them on tiled materials. I’ve made another test with the same texture on different material, same behaviour

by user 334342083445784576

What do I see there ^^?

the lower-right cube doesnt get updated? Is it a mesh? or UI ?

Two Gamobjects with Meshfilter, standard cube meshes and a urp/lit material with the same texture but the one on the right has tiling = 3. Console says something about uuid cannot be found.

by user 334342083445784576

It’s a little bit hard to debug as i cannot look into glb files and progressive mode is only active in a “real” build. What I can say is, there is always a “image_0_2800000_xxxxxxx.glb” file build and it’s referenced in the scene.glb file but with tiling != 1 on the material, it does not get loaded.

by user 334342083445784576

for local testing you can use this menu item

Looking into glb: try this: to dropp your glb

only difference I can find between two glbs is that an export with tiling = 1 gives this message while the tiling != 1 glb does not have this info:

      "message": "Cannot validate an extension as it is not supported by the validator: 'NEEDLE_persistent_assets'.",
      "severity": 2,
      "pointer": "/extensionsUsed/4"

by user 334342083445784576

The image_XXXXX_XXXXXX.glb files that gets exported are exactly the same with both settings.

by user 334342083445784576

The image glb is the one it tries to load and cant, the main scene glb (not sure how your scene is setup) has an extension in each texture with the info about where to find the progressive image

I know. And in the scene glb, they get correctly exported according to the gltf viewer

by user 334342083445784576

And loaded with needle engine, the image glb with NoTiling Texture gets correctly found and loaded

by user 334342083445784576

But as soon as it is tiled, the image glb gets loaded correctly, but the uuid of the generated asset is different to the one it referenced it to the material? At this point I have no idea what happens. How is a uuid generated? I find this nowhere in the glb files, only the guid is in there and it seems to be correct.

by user 334342083445784576

the uuid is generated by threejs internally

we have no control over that so we dont use it

Here is the issue link: Progressive/Deferred Texture Loading failed if Material has Tiling != 1 · Issue #133 · needle-tools/needle-engine-support · GitHub

It has been fixed locally and will be part of the next update