Posts: 4
Threads: 2
Joined: Sep 2023
I have a spline with dynamically placed and bent/stretched meshes (a bunch of wires). In runtime this rebuilds every frame, I wonder if there is any way to avoid rebuilding the meshes once in runtime and instead just stick to bending and stretching the meshes created?
Either to have them create once at start or just once in the scene. It would save on performance but it would also keep them from popping in new meshes during runtime.
Posts: 2,114
Threads: 92
Joined: Jun 2017
Hi
I believe you are describing a use case that uses both the Volume Spots module to define the placement, and the Deform Mesh module to bend/stretch the meshes.
There is right now no way to freeze the output of the Volume Spots module while allowing the Deform Mesh to update itself. Either both will update when the spline is modified, either none will update.
A way to work around this is to use the Input Transform Spots modules, which allows to define fixed spots:
1- Generate the game objects the usual way in playmode
2- Export these game objects (see the Create Game Object module)
3- Disable these object's mesh renderers/colliders, we don't need them
4- Use the exported objects as inputs for the Input Transform Spots, to define fixed spots
5- Use the fixed spots as inputs for your Deform Mesh.
I hope this helped.
Have a nice day
Please consider leaving a
review for Curvy, this helps immensely. Thank you.
Available for freelance work—feel free to reach out.
Posts: 4
Threads: 2
Joined: Sep 2023
Has there been any updates or considerations to updates to handle this case?
We are using the splines in our game for static meshes which is ok but also for cables and chains etc. And those chains become increadibly cpu heavy since they need to update each frame. And we really just want the vertices to move each frame (from the mesh that was created in the level), not have the entire mesh rebuilt.
Posts: 2,114
Threads: 92
Joined: Jun 2017
Hi,
I would like you to give me more information to dive deeper into your use case. Can you send me a reproduction case, or at least the profiling data?
I suspect (but I can't be sure without what I asked above) that most the CPU load is from the actual mesh deformation. In other words, I suspect that mesh placement and mesh "creation" (I used quotes because at runtime, the meshes are pooled and not recreated) don't take that much CPU time compared to the mesh deformation.
If my suspicion is correct, that would mean that the solution to your problem can be:
- Optimizing the mesh deformation code: I don't see any obvious significant optimization that can be done without a radically different implementation (more about this bellow). The mesh deformation is already multi-threaded, and the deformation code is quite optimized. Surely there is always room for improvement, but I don't think we can get that much improvement.
- Using simpler mesh: Less vertices => less time deforming meshes.
- Allow mesh deformation only x times per second. You can do this by disabling the Auto Update setting of the generator, and refreshing it via API only at some specific frames if it is marked as dirty.
- A radically different implementation: If the deformed mesh is used only for display (no physics, no gameplay logic), then a solution would be to do the deformation GPU side, using shaders. Shaders are perfect to apply the same operation (in this case deformation) on a multitude of mesh data.
Currently, I do not plan to implement GPU-side deformation. However, if you are interested in this feature, it may be possible to include it as part of a contract work arrangement.
I hope this helped.
Have a nice day.
Please consider leaving a
review for Curvy, this helps immensely. Thank you.
Available for freelance work—feel free to reach out.