We found that, in the packaged game, the ItNormal’s uint8* Buffer is assigned a nullptr. This happens because ShapeMesh’s FMeshBufferSet VertexBuffers apparently lacks the EMeshBufferSemantic::Normal channel, despite still having a positive ElementCount. Notably, this issue never occurs when running the game inside the editor.
We are still investigating the issue, why the packed version of the Shape Mesh is incomplete, but it has proven to be tricky. Any suggestions or insights on the matter would be greatly appreciate.
Additionally, from a robustness standpoint, it would be valuable if the code could safely handle the absence of this Normal channel, still applying the shape but skipping any potential normal modifications, rather than crashing. Implementing a safety check for a valid iterator and a quick and dirty fallback solution in these cases would be highly beneficial for stability, and for not blocking any other parts of the game’s pipeline.
(Does one best submit suggestions like this here, or should one turn somewhere else for that?)
Yes, I agree the code should not crash even if the data is not as expected. We will fix the crash.
As for the ShapeMesh not having normals in packaged builds. Are you compiling with CO maximum optimizations in editor? If compiling with maximum optimizations does present the issue then it could be a bug in the mesh data optimization step as the ApplyShape operation shape mesh needs the normals to operate correctly.
I have tried with all 3 optimization levels, and it works fine in the editor with all of them, none of them work in a package game.
I made a small workaround in the source code and managed to get it up and running, but solving the data not getting packed would ofc be better
I have also noticed that; when changing a float parameter that just changes a shape on the Shape Mesh and then runs the Update Skeletal Mesh Async, it does not trigger an update. It’s not really related to this, but might be good to know?
Ok, I just got a case (no real changes made to the Customizalbe Object) where the positioin data is also missing, even though it still had ElementCount.
Also interesting to note is that when I made a small fix for that, it not only doesn’t crash there anymore, but it also works as intended later on when I try to apply the shape again. It’s almost like the data just wasn’t ready yet??
We think the issue could be with mesh streaming. When a CO instance with streaming enabled is spawned it runs the generation skipping geometry loads for the high res LODs but the shape mesh needs to be fully loaded if skeleton reshape is done.
