how do you export the bistro scene? i am not able to get it running
I’m just handling gltf with blender… Not sure why your computer is unable to process it.
I can make a .jar executable file later, but I don’t know where to upload it for others to download and run tests…
Heh yeah, me too, the BistroExterior chews up my 32Gb of RAM 
But on the bright side, I’ll try to make it crash faster (and harder) with GltfLoader is slow populating buffers · Issue #2125 · jMonkeyEngine/jmonkeyengine · GitHub.
you load gltf or GLB. also via SDK or as via code?
How something 1.7 GB (uncompressed) can chew up 32 GB. If you mean vram then maybe because for example each “bottle” etc use separate material/texture or something.
But ram? it should just cache 1.5 GB of textures in assetManager and thats all.
Ask LWJGL 3… It is the one eating all. It creates a lot of buffers. I use code to load GLB. And my machine just runs out of RAM. LWJGL crashes at some point, it tries to allocate a buffer but it comes a null (fails).
It seems unacceptable, and its not like only JME use LWJGL.
I see screenshot, but its not like LWJGL cause issue, its just used, so maybe GLB loader is broken, but not gltf for example?
Also worth check j3o load, if its same.
Another would be if it would create mip-maps for every texture or etc. but as i know it do not.
Well that could be the case also. They are the same though. In the code. GLB and GLTF loader. Although I think they have few differences, that GLB includes textures and GLTF not…? Well, I’ll try to enable swap file I haven’t done that in awhile…
GLTF with separate textures does work.
told u, GLB since start had too many issues as i remember, seems like still broken.
so GLTF / j3o should be fine, but GLB is not fine.
Its not like GLB is important, because j3o is there anyway to load bulked right?
But i think [if there isnt] should be github issue about GLB actions.
At least we know its something in loader code. So it is fixable.
Just as note i already seen ton of GLB fixes, so im worried about this format.
Yeah, it is the same code that handles it. And I tested GLB without the textures and it is just fine. I think it has something to do with the textures… They were also the most painful part to load as the issue I linked before. Reading everything byte by byte.
1 Like
Yes, most probably true. If you say its mostly same code, but not bulked texture part, then it seems like it clone texture as different reference in memory for each Geom or something even more scary.
Thanks for testing GLTF tho. I was scared for a moment lol.
Also at least now you can test this scene 
@zzuegg you probably got same
2 Likes
I mean it is exactly the same code. All of that. There is just this thin boy https://github.com/jMonkeyEngine/jmonkeyengine/blob/c9d10eb6ffcebbf18a7709de15be1eac67de9c1f/jme3-plugins/src/gltf/java/com/jme3/scene/plugins/gltf/GlbLoader.java for GLB. Just extracts the header. Then it is all GLTF loading. Same code. Just that there could be textures.
2 Likes
You magnificent beast (you were right)! I fixed it! Let’s see if my fix valid. I now cache the materials instead of creating them a million times. This will affect both file formats but helps when the textures are embedded.
4 Likes
I feel we little offtopic here.
Btw. Nice, i created github issue for this. So if you fixed it, you might add comment there.
Tho i think it should affect only GLB, if cache is also for GLTF it might cause double-cache there now.
@sgold see below comment please.
4 Likes
Yeah, I don’t have enough rights but someone should move these to new topic. Starting from maybe even: Enhancements to the JME3 Rendering Engine - #122
4 Likes