Runtime Mesh Component

[housekiller]

@;635227

Well static meshes don’t have any replication capabilities of the mesh data. They assume the mesh itself already exists with the game install on both server and client. The RMC has support for natively saving itself, but it’s a custom format meant to quickly load/save itself, not a full interchange format like OBJ.

Are there any other limitations of the RMC when compared to the StaticMeshComponent that you’re hoping for?

The main limitation is that I have to adjust older code of my own that doesn’t take procedural meshes into account. :rolleyes:
I have implemented replication based on the system I already had but it’s for static objects only atm. I’ll look into replication of completely dynamic meshes later, I have much to learn still about the programming side of it but the idea is pretty solid and very do-able.

@Mtimofeev;637645

Can anybody advice me on how to do a proper lighting with the runtime mesh component without taking a performance hit? I am unable to maintain 90fps in a oculus rift with Geforce 1070 after I turn on dynamic lights and shadows from a single directed light source with a very simple scene - an apartment with 2-3 rooms, where every room is an actor with 3 subComponents - floor, ceiling and walls - all of them are a single RuntimeMeshComponent, although the walls component has many different sections - 4 to 30, depending on the room topology, every section is a flat surface though. My meshes are procedurally generated once at a startup from a text file and never touched afterwards.

Have you tried the difference with normal imported movable static meshes? Try optimizing such a scene first for VR performance, it’s not an easy feat making a game perform well in VR while still looking good.
I’m finding performance with procedural meshes to be surprisingly good but having lots of dynamic lights and objects will always be hard on the GPU and is not necessarily linked to procedural meshes (rather to all dynamic objects).