When I use IDBStorageEnabled = true, load scene.gltf(with scene.bin) from server, the scene.gltf.manifest In the same folder:
{
“version” : 1,
“enableSceneOffline” : false,
“enableTexturesOffline” : false
}
I can load it successful.
Then, I update scene.gltf and scene.bin in server , and change scene.gltf.manifest :
{
“version” : 2,
“enableSceneOffline” : false,
“enableTexturesOffline” : false
}
Now , load scene.gltf unsuccessful:
Uncaught (in promise) Error: Unsupported geometry type.
at decodeMesh (dc4aae5c-806a-4cda-8212-54a29bfc79be:37:17)
at dc4aae5c-806a-4cda-8212-54a29bfc79be:130:29
Then I Delete indexedDB data from browser, I can load scene.gltf successful!
I speculate that when the gltf model version on the server changes, the front end does not load the latest bin file correctly, resulting in the new gltf file and the old bin file.
@HouLingLXH , would you be able to reproduce that on the playground so I can trace the source of the wrong call? I am pretty sure you are right we just need to see where we make the call that skips the caching mechanism.
quick note - v3 seems to not render correctly, however it does load without an error. This is unrelated to the database. even if I load v3 standalone after emptying the database the same thing happens.
When version +1 in scene.gltf.manifest, only update new scene.gltf to indexedDB, but the .bin file is not update. Then load scene.gltf , will use old .bin, This is the problem…
I am trying to follow, but can’t really understand what I am doing wrong. There should be no difference if I deploy this on a server, or use the github link. For both it’s a new URL (for me). What exactly do I need to do to reproduce this? Using the links you have provided. Step by step please, so I will be able to reproduce this correctly.
Because then you can update the gltf(with bin) files on the server(gltf and bin need different, but has same name),and change the manifest file, to simulate the model on the server has been updated.
The bug is model on the server has been updated, but babylon load the new gltf with old bin file in indexedDB.
Use the same url(same name) to load different gltf(with bin) .
Do any other members of your team know about IndexDB to solve this problem?
The issue occurred after the server updated gltf and bin, babylon could not load the new model with the same name correctly.
If someone understands the purpose of IndexDB during server model updates, they should be able to understand how to reproduce and fix it.
Just wanted to follow up on this - i downloaded everything, copied and served from my own server, and everything is workign as expected.
I wanted to note - your model v2 has manifest v4 (and both flags on, as opposed to the original message), and the v3 has manifest v3. This will not work, manifest versions should increment. I will try once again to reproduce, but so far, the models both load correctly, when copying the manifest and the files.
On another matter, i would personally try to avoid naming all of my scenes “scene.gltf”, especially if they are a completely different model, but this is just a personal taste thing
Again - i can’t reproduce, but will continue trying.
Why am I naming different models the same “scene.gltf”?
Because I need to simulate the same model being updated on the server!
This problem occurs because the server model has been updated, and since it is updated, of course, the files of different models have the same model name.
So, I’ll be honest and say that until you manage to show me a proper reproduction I can’t really help. I understand everything you are saying, but again, i can’t reproduce. Here is a screencast of me using your assets, locally, in the playground, using the latest babylon version. You will see I am loading the first asset, which loads correctly, afterwards I am copying the files, updating the manifest and running the scene again. This works as well. on the 3rd time I am running the scene again, and the data is loaded from the database, because the manifest version hasn’t changed.
I can’t upload it here since it is too long.
Everything is working as expected. I will never say that we are bug free or that something is working unless I have tested it myself, since we do have bugs from time to time. But this - as far as I can see - is not a bug. But again, if you manage to show me a proper reproduction, I will be happy to look into it again.
