Yea it feels really good. It’s a very bespoke implementation though. The asset list is in that json file, but they must have manually created offline somehow.
This may be dependent on how much pixels must the engine replace/stretch/whatever because my 8191x8191 and 8192x8292 textures are loading at the same speed.
I suspect its because they’re so big the rate limit becomes something else not related to the gpu loading speed. So the GPU bit is still probably slower, its just the majority of the time is spent somewhere else. Or maybe it chunks it into power of 2 blocks and only the final blocks are slow, idk. but definitely on reasonably sized textures it’s pretty significant. 8k textures are absurd lol
oh by big i mean resolution and file size, not layout size
Can you tell me please more about the whole scenario? Maybe I am looking dumb but still don’t get what’s the issue here 
Let me try it and convince myself
Maybe nowadays. But I will make them smaller and test with them. I had a colleauge (is this from French? eau lol) a 3d artist, he was hired because he did some pretty cool renders and that he did a lot of game assets as well. He was working on one of our building’s 3d model and delivered a 1.2GB blender file, 300 MB glb / floor. He used 4k textures everywhere. A table? 4k. A chair 4k, even a computer mouse had 4k textures. The funny part was that the textures had actual pixels only in the top left corner covering maybe 5% of the whole texture area. He told me later that he was thinking even about 8k. So we definitely need 8k lol
so if you look at the screenshot nick posted above, for #1 he had 300ms vs #2 160ms.
the 160ms file is LARGER in file size at 16mb , yet 2x faster to load because its a power of 2.
so without a doubt, power of 2 matters
next comparison is for #3 square vs #4 rectangle. i took the same file and lowered resolution to make the files the same file size for the data, they’re both 5mb. #3 is a rectangle with lower resolution and #4 is a square at higher resolution. the square one loaded in 105ms vs the rectangle at 130ms. the article i linked above said square textures were faster to load, and i wanted to see if that is true, and it seems to be.
But, why you’re not seeing any difference is because your textures are fucking huge, like 150mb. it has to schedule a lot of shit in the background, encrypt and decrypt too because https. lots of stuff going on that will make it slow no matter what, so you can’t really measure loading gpu loading time. So, if you had some scene where you needed to load 20 small textures or wanted to stream textures, having them as a power of 2 and square can seemingly make them load a lot faster, if they are small in mb size (like 15mb or less probably)
I think they keep the super high res textures to bake shadow maps and normal maps or whatever other tricks there are, but then you ship low res textures on the model itself, and use the high res maps to somehow make it look better. i don’t know shit about that stuff though, probably @labris does
1 Like
I get your point and I will try the smaller ones. I do believe that there must be some differences because there is extra work to align the texture to POT but I am not yet convinced that the differences are so big.
This doesn’t apply, because the timer starts after the data are already in an arraybuffer. However there is a texture init observer on the engine object. I’ll try to hook the timer start there. (writing from phone, don’t remember the exact observer name)
Pouring some Irish whisky and enjoying a cigarette. 3:26 AM lol
Would be interesting to know KTX timings
Hey @labris! Welcome buddy!
I’ve created a PG but I was not able to load the KTX texture from the array buffer so I couldn’t start the timer exactly when the texture binding starts. Any ideas to do it before I start to google?
Ah thats a good point on the https, probably not a factor. We shall resume later then 
I am good
Okay 
How does the ktx encoder decoder work? Like, how does the decoder know to decode? Same with draco? Is there like a marker at the front of the binary that says this a ktx encoded thing. Also, how does it work if its packed into a .glb? maybe the babylon gltf loader could just handle it
To make precise measurements this cache must be avoided.
And look at this, I’m already conviced without doing further tests. It it’s pot it just creates the gl texture and all of this is avoided:
1 Like
ooh. gl.texStorage2D is supposed to be the fast way to use srgb. is that a drop in replacement for texImage2D?
1 Like
Figured it out, try this guys:
EDIT: I’m calling engine.createTexture directly thus avoiding the caching stuff
EDIT2: I’m getting ~600 ms at every restart
ANOTHER EDIT: @jeremy-coleman it’s one of your beloved 8k textures 
650ms on first load and 500ms restarts here
ooh, thats an improvement and seems stable too. had to look up the other times, they were like 700-1700
750ms for a plain JPG texture. 600ms for the KTX2. So there is a small ~25% improvement for me.
texStorage2D creates an immutable texture (it’s size and format cannot be changed by further calls, unlike textures created with texImage2D ), which results in some speed gains, but I’m not sure if it would affect loading times. UnityWeb seems to only use texStorage2D and compressedTexSubImage2D , if it helps (as long as the context is WebGL2, of course - StackOverFlow. There is no trace of usage of the textStorage2D in the bjs source code.
Ah, i mentioned it back in november in the old loading post, just searched for it using the forum’s search
the three issue where i got the scoop
1 Like