Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MultiMesh buffers are sometimes reset to 0 on export #86396

Closed
GameBeastProductions opened this issue Dec 21, 2023 · 3 comments · Fixed by #87390
Closed

MultiMesh buffers are sometimes reset to 0 on export #86396

GameBeastProductions opened this issue Dec 21, 2023 · 3 comments · Fixed by #87390

Comments

@GameBeastProductions
Copy link

GameBeastProductions commented Dec 21, 2023

Tested versions

Found in v4.2.1.stable.official, v4.1.2.stable.official and v4.1.1.stable.official

System information

Godot v4.2.1.stable - Manjaro Linux - X11 - Vulkan (Forward+) - integrated AMD Radeon Vega 10 Graphics (RADV RAVEN) - AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx (8 Threads)

Issue description

I have a project where some levels contain multiple large-ish MultiMeshes (> 10000 instances), which were populated by a tool script and saved to the level's scene file. These MultiMeshes always render correctly when I run the game from the editor, however, they sometimes don't render correctly when I try to export the game. After some investigation I found that all the values in the buffer for said MultiMeshes had been reset to 0 in the exported build, so I think it is something to do with how the MultiMesh data is getting packed on export.

Unfortunately I haven't been able to reproduce this in an MRP (although I have included one that contains the offending MultiMeshes in case anyone else can). What makes it worse is that it seems to happen fairly randomly and is not specific to one version of Godot - in fact, after first triggering the bug I was able to consistently reproduce it in a previous version of my game (that had exported with no issues just a few months prior) using the same version of Godot that had been used to export said version of the game (4.1.1).

I was able to work-around the issue with a simple helper script that saves the instance transforms to a custom file which re-applies said transforms when the scene is loaded.

Steps to reproduce

  1. Generate several MultiMeshes with a large number of instances (10000+) (I'm currently unsure how many are needed to trigger the bug)
  2. Run the project from the editor
  3. Export the project

Expected behaviour

The MultiMeshes render correctly both when running from the editor and in the exported build of the project. See the grass in the screenshot below is visible:
working

Actual behaviour

The MultiMeshes render correctly when running from the editor, but sometimes after exporting the project the MultiMeshes disappear as a result of having zero-ed/null data in the buffer. See the grass in the screenshot below is now missing:
not working

Minimal reproduction project (MRP)

Multimesh Buffer Bug.zip

@bitsawer
Copy link
Member

bitsawer commented Dec 21, 2023

Could be related to #75485. Alternatively, could also be related to #66842 if you are exporting using --headless command line option.

You could also try disabling Convert text resources to binary in Project settings and see if that helps.

@GameBeastProductions
Copy link
Author

GameBeastProductions commented Dec 21, 2023

Could be related to #75485. Alternatively, could also be related to #66842 if you are exporting using --headless command line option.

You could also try disabling Convert text resources to binary in Project settings and see if that helps.

Hmm, that's one of the few things I hadn't tried. I'll give it a go, thanks. I am exporting in headless mode, but the material for the MultiMesh doesn't use a shader so I'm not sure if it's related to #66842.

Edit: disabling Convert text resources to binary does seem to resolve the issue for me, so I guess there is something wrong with how the MultiMesh data gets converted to binary.

@bitsawer
Copy link
Member

The --headless command line export is somewhat hacky in general, see my old comment here: #76121 (comment). If disabling Convert text resources to binary option helped, this issue might be related how the dummy servers and storage behave when using --headless (and if the relevant parts of the dummy functionality are currently even implemented). Or it could be something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants