Thank you so much for another great release! I appreciate those a lot:
Build only the WASM version of the engine when running Build HTML5
Make the building artifacts independent for the Build HTML5 and Build options
The editor is crushing on this version on one of my projects. I investigated the issue and found that the source of the crush was one model. I can share it via Discord. It crushes not only on build but even if you try to open it.
Even better if you share it here or on GitHub. You can put it in a zip archive before uploading.
Thank you! 
I have a material with two textures that was visible in the build but not visible in the editor with 1.9.3. I have already reported this in
Now with 1.9.4 the material is not visible also in the build. @jhonny.goransson
EDIT: I see no error nor warning in the console about the related shaders.
EDIT2: I managed to get the material working again in the build. I changed the Coordinate Space value for the vertex attribute position from Local to World. However, it is still not visible in the editor.
I don’t quite understand what the general ‘vertex space’ world / local option for the whole material is for since each vertex attribute now has its own option for the coordinate space it refers to.
I’m having this issue but in reverse. I am having a 3d model appear in the editor but not in the build
Editor:
Build:
Please create a bug report on GitHub and include a small project with the model
Heh, I didn’t know that I could share ZIP.
Here the model
sea_thief_M.zip (21.1 KB)
Edit: I found the source of the issue issue. I tried re-export the model to collada and gуе the error that the model has multiple root - bones.
So, the workaround makes only one root bone.
Anyway, It would be great if that gltf exporter did not crush the Editor =)
Hi!
Thanks for reporting!
Which version of the editor are you using?
Also, as we weren’t able to reproduce this before releasing, do you have a repro case you could share with us?
unfortunately there is no example, this was seen on a working quiz project.
Can you reproduce it in this project? What kind of fonts are you using? How are the fonts configured?
Chat GPT recomended use those parameters…
cache_width: 2048
cache_height: 4096
and gradually reduce them to find a balance between memory usage and performance. After that, the problem disappeared.
Everything looks like the cache width and height stopped being set automatically when the values are set to 0.
It would be nice if you share a repro case project (it would be enough to create a project with this font and one big text field that uses most of the glyphs).
Using 0/0 for Cache Width and Height should be the default way to keep it up to our build system to calculate the optimal size.
Thanks for adding a ticket and a repro case!
WHile we did change the internal code, the cache should have worked the same way as before.
I’ll look into it tomorrow morning!
My another project also crush I have create ticket
I tried your repro case, and it behaves the same way in 1.9.3.
Did you experience a regression between versions?
The way the cache size is calculated, is a “good guess”. As the font has “all characters” set, we don’t want to create a possibly gigantic texture.
So the solution is the recommended one, if you know you need more cache space, you set the cache size explicitly.
So for now, unless you can find a regression, I will mark this as “works as intended”.