[=;392031]
I’ve been messing around with ProceduralMeshComponent for modifiable terrain. While I have vertex generation and all that going on in separate threads the game stutters for like a second when swapping out the actual meshes (which I have generate physics enabled for). How many vertices do people usually shoot for when creating terrain chunks? I’ve also had issues with Mesh sections just disappearing when replacing sections, I don’t know if anyone knows whats causing that? I’m not sure if I should stick with ProceduralMesh for this or switch to making my own mesh component.
[/]
Our sections are about 2000-5000 vertices, and update physics (and recreating scene proxy) seems fast enough even on slower computers. You should attempt to do as much calculation on a separate thread and leave only physics and render mesh update on game thread.
Note about ProceduralMeshComponent – out of the box SceneProxy declares itself as Dynamic (via Result.bDynamicRelevance = true). This causes render thread to call GetDynamicMeshElements() each frame – make sure you leave this function as lean as possible. Alternatively, it works quite nicely if SceneProxy uses bStaticRelevance instead, but requires coding of DrawStaticElements() override.
We went one step further to employ Instancing of procedurally generated meshes, by combining code from InstancedStaticMesh* and ProceduralMesh* to get to performance comparable to Unreal’s stock foliage system.
The only missing item for us is baking static lighting at runtime 