You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use a Windows or macOS machine to work on Blender. Create and use both a material called "white" and one called "White". Export using Blenvy.
Build and run the Bevy app on a Linux machine.
The game will now crash with "Expected white.glb to be loaded" or "Expected White.glb to be loaded"
Problem
Blenvy stores a file for every material based on its name. In this case, it will try to store the following two files:
white.glb
White.glb
This is no issue on Linux, but on other OSes, this will silently overwrite whatever was stored first because of case-insensitiveness., This results in only one material being written. The truly insidious issue now is that a Blenvy user won't notice or care, since when loading the materials white.glb and White.glb, it will again be case-insensitive and just read the one existing file both times, resulting in the game running normally (assuming both white and White look similar enough that you won't notice).
But! When distributing binaries to other OSes, Linux users will have the game crash, as their Blenvy will try to find both white.glb and White.glb, which won't work since only one of these exists!
Why is this relevant?
This happened to me because I use Windows to develop and uploaded my game jam entry to itch.io, which triggered this on Web for players (thankfully before the submission deadline). I had these naming "clashes" because I imported a lot of third party assets, which often bring in generic material names like "orange", "grey", "gray", "DarkGrey" or "Dark_grey". As you see, it's only a question of time until these imported materials have the same name with a different capitalization.
Workaround
Simply rename your materials. If you have two variants of "white", chances are you can just remove one and use the other for all models.
Solution
I can think of the following solutions:
Append a hash of the material name to the exported material file. That way, macOS and Windows will not run into naming conflicts.
Print an error or warning in Blender when exporting materials that run into this.
Print an error or warning in Bevy while analyzing the exported stuff to catch this before it can crash the game without a good message.
The text was updated successfully, but these errors were encountered:
Reproduction
Problem
Blenvy stores a file for every material based on its name. In this case, it will try to store the following two files:
white.glb
White.glb
This is no issue on Linux, but on other OSes, this will silently overwrite whatever was stored first because of case-insensitiveness., This results in only one material being written. The truly insidious issue now is that a Blenvy user won't notice or care, since when loading the materials
white.glb
andWhite.glb
, it will again be case-insensitive and just read the one existing file both times, resulting in the game running normally (assuming bothwhite
andWhite
look similar enough that you won't notice).But! When distributing binaries to other OSes, Linux users will have the game crash, as their Blenvy will try to find both
white.glb
andWhite.glb
, which won't work since only one of these exists!Why is this relevant?
This happened to me because I use Windows to develop and uploaded my game jam entry to itch.io, which triggered this on Web for players (thankfully before the submission deadline). I had these naming "clashes" because I imported a lot of third party assets, which often bring in generic material names like "orange", "grey", "gray", "DarkGrey" or "Dark_grey". As you see, it's only a question of time until these imported materials have the same name with a different capitalization.
Workaround
Simply rename your materials. If you have two variants of "white", chances are you can just remove one and use the other for all models.
Solution
I can think of the following solutions:
The text was updated successfully, but these errors were encountered: