I have a RuntimeMeshComponent that is procedurally generated. Currently this is a component on an actor. This actor class also houses the containers associated with the vertex positions the RMC is using. I have a TArray<FVector> for the vertex locations, TArray<int32> for the face assignments, and a TArray<myGameData> that holds additional vertex information (material types, offsets, etc…). Now recently I’ve built a menu system to allow me to visually edit the procedural mesh generation parameters and see the update occur. But, this causes a small hitch when “generate” is pressed as it runs through updating the RMC vertex positions, and their normals. So Ideally I would move this process to its own thread so that it doesn’t cause this hitch. I’ve run through Rama’s thread tutorial and I’ve seen how computing 50000 prime numbers while this is all going on and still having 90 FPS is great so I figure I could move the RMC vertex position update (and normal calculation) to another thread to achieve this. I just finished reading through this but I must admit its a little above my head. Still I’d like to push forward and get my feet wet. So I have a couple questions about multi-threading and the construction of all related.
There’s the render thread, and the game thread right? When I completed the Prime number tutorial I was adding that process to an entirely new thread, outside the game thread and the render thread? If my data is contained inside an actor class will I be able to modify the data in my containers within that class inside a new thread (the one I’m trying to create to do this heavy lifting)? If not how would I modify the vertex positions on a RuntimeMeshComponent->BeginMeshSectionUpdate() reference? After all this RMC is currently a component attached to an Actor class.