@: Any ideas what causes those errors when trying to work with RMC and splines in c++? This is the only thing holding me up from integrating RMC into my main project…
I just finished creating a obj importer so that I can convert meshes into RMC data. In a test I decided to try and compare RMC performance with Hierarchical Instanced Static Mesh. HISM is a lot faster and if you have collision enabled (I was using per poly collision in both RMC test and HISM test) it’s not even comparable. I ran a test with 317 tree stumps, for a total of around 1.5 million polygons. I had the converted obj stump duplicated and rotated into place (identical transforms as with the HISM) I loaded up a RMC and turned collision to true. This was barely playable, serious FPS drops. I did the same test instead spawning instances of the same stump on the HISM component, but this time I imported the mesh through the editor. I set complex collision on the static mesh. UE4 barely slowed down. The test was barely playable using RMC, and with HISM I was able to put the oculus rift on and walk around jumping around on the tree stumps. This got me thinking about collision differences. So I ran the same test again, but this time I spawned both, all 317 stumps on an single RMC and also all 317 stumps on HISM, but I turned collision off on the RMC, and I turned visibility off on the HISC (for some reason this still allows the collision to exist). This basically made the RMC run as fast as the HISM. Very bizarre but also really cool. I guess the downside would be having to double spawn up front, but performance wise it’s so much better.
Visibility doesnt affect collision btw.
But wait… You are saying that RCM with collision is much slower than having RCM for visibility (without collision) and HISM without visibility (for collision) running at the same time, overlaying each other?
Cool, yeah it just seemed strange is all.
Yup. The test I mentioned above was pretty straight forward. The exact same mesh was imported into code to be added to a RMC 317 times and it was imported through the editor (FBX) and added to a HISM component in code, and then 317 instances were created. I toggled the Use comlex as simple in the editor imported Static mesh. Then when creating the RMC I did so with collision off. The performance wasn’t even close. The order of performance went
1 = HISM (Visual mesh and Complex collision) = Ran on Oculus Rift perfectly
2 = RMC (visual mesh, no collision) and HISM (no visual mesh, but with collision) = Ran on Oculus rift, less performant than 1
3 = RMC (visual mesh with collision) = Could barely run in editor, no need to test in Oculus Rift
To add to the above I just looked into some other combinations and I discovered more odd behavior. I was curious if there was a difference between setting the HISM visibility to false, and setting the actor holding the HISM component Set Hidden In Game = true; I wondered if this would make the collision of the HISM go away, as you indicated it did not. But, it did further increase the performance while maintaining collision. I was getting around 26 FPS using stat FPS in the editor. With the just mentioned setup, of setting the actor hidden in game, I’m up to 35 FPS steady. The collision is still there. Crazy…
The slowdown from collision could be because the runtime mesh create dynamic physx actors by default, so it can’t apply fancy optimizations.
Does it run better if you force it to static after spawning? (using SetMobility method)
First off, thanks for this ! This plugin has been a huge help to me.
Now for a very newb question, I’m sure. Is there a way to get a mesh from the RMC to render in the editor, rather than only at run time?
Will this be updated for 4.15 with the new minimal headers etc?
There certainly is, just call it from the onConstruction event.
any news on LOD support?
or are there manual ways to assign the unreal LOD system, like to draw a mesh multiple times in different resolutions?
really need this for our current development.
we intensly use the PMC to draw loads of meshes in VR. but in bigger worlds, all the distant meshes easily add up to 1 million+ vertices which drops fps.
just can’t handle all the vertices without LOD support…
I’ve just implemented my own LODs, but I am curious about how one could get the dither blending? Also, I saw on the marketplace page some description about collision only sections. How can I do that. Currently I just duplicate the visual mesh and then set that section to no visible.
Well here goes another long post of replies! Haven’t been watching this like I should recently but I’m both here to catch up on answers. In my next post I’ll give an update on what’s coming.
You can specify collision shapes, either as a separate mesh, or as one or more convex shapes. Not sure I get what you’re having issues with from that image.
Thank you both for your support! Glad it was useful to you. It would be amazing to receive a dev grant for the RMC.
Well that’s a new one. Did you ever figure this out? I haven’t personally tried to use both of them in the same component. Working from blueprint doesn’t surprise me since that looks like an include issue within the headers.
Not quite sure I see how you set that up but the first things I would question would be this… If you have 317 different sections within an RMC or 317 different RMCs then that’s not surprising since that’s a large amount of draw calls. If you combined them all into one mesh then you’re always drawing all of them no matter what. The HISMC has some internal culling IIRC. As for collision, after the absurd cook time it would take to process all of that on startup it should in theory run ok as I’ve seen maps with substantially more polys run ok in physx collision. The HISMC wouldn’t need to cook anything as it would just have physx instance the same precooked mesh 317 times. So would need to know more about how you set things up before I could really answer why you’re getting the performance characteristics you are.
By default the RMC will create mesh collision which is always static as PhysX doesn’t support moving collision on polygonal meshes. For standard mesh collision it should have almost identical performance to the standard static mesh after it’s cooked, but the cook times can get pretty insane for large meshes (2-20ms)
As ioFlow already said yeah you can get it to render in editor by creating the mesh in the construction script in bp or cpp. Some times you might have to force tick enable in viewports though IIRC.
Honestly, this version I’m only kind of maintaining right now. It will be running on 4.15 soon though. Actually I’ve already submitted the marketplace update, so that should be up within the next week, and the github version has been updated to support it. I haven’t gone through the headers to simplify them though as I’m more focused on the next version (more in my next post).
I’ll answer the first part in my next post as to what’s coming. It’s definitely coming, but it’s not here quite yet. As for a temporary measure, the way I’ve seen several people do it is just manually track it and turn visibility on/off on separate sections for each LOD. It works, but you don’t get things like dithering or even the likely more efficient LOD management the engine can do for you.
I think you can actually do dithered fade yourself within a material, but it means manually managing it. Again, see the next post for what’s coming.
How can I setup a Collision only section? Am I doing it right by making a normal section and then setting the visibility = false? Thanks for all the information. I’m actually getting close to showing some of what I’ve been doing with this extraordinary plugin.
That is one way to do it, but depending on how you configure it when you create it there might be an unnecessary gpu resync performed internally. The best way to do that is via SetMeshCollisionSection() and then ClearMeshCollisionSection() or ClearAllMeshCollisionSections()
You can see more about those here… https://github.com//UE4RuntimeMeshComponent/blob/master/Source/RuntimeMeshComponent/Public/RuntimeMeshComponent.h#L1147-L1156
Upcoming Version 3 Details
So recently I’ve been getting quite a few questions and requests from people about when/if a feature was going to be implemented in the RMC. So here’s a quick breakdown on what is coming. This list is not everything I want to add, and I also can’t guarantee all of this will actually be added or even when it will be done.
First, the next version (v3) of the RMC is going to be a drastic change. It is almost a 100% overhaul of the entire plugin both to pick up a large set of new features that just don’t work well with the current setup as well as to take advantage of things I’ve figured out about how UE4 operates internally. This means that it WILL NOT BE 100% API COMPATIBLE!! While I’ll try to support upgrading to the new version as well as possible, there are some breaking changes in the design.
The group of new features I’m focused on implementing at the same time are instancing, lod, and sharing a single mesh copy between a several RMCs much like how the static meshes work. To support those the RMC is getting restructured into a setup much like how the UStaticMesh, UStaticMeshComponent and UInstancedStaticMeshComponent work. So there will be a rough equivalent to them being URuntimeMesh, URuntimeMeshComponent, and URuntimeInstancedMeshComponent. The first two, which are needed to replicated what version 2 of the RMC can already do but in the new structure are almost complete at a functional level. They’re not up to feature parity of the current RMC and likely won’t be for a few weeks. Once they are at least functional I’ll mirror that branch to my github repo where you’re free to use it if you don’t need the other features of the current RMC. I’m hoping to have all of the current features reimplemented on the new RMC within 4 weeks but I don’t really know one day to the next how much time I’ll really have available to work on it so it might be sooner or it might take longer. When it’s complete it should offer a very nice memory improvement to anyone that has multiple copies of the same RMC as well as anyone who needs LOD.
Now, there’s a pretty long list of other things I want to do to the RMC long term which if you look at them as a whole would basically bring as much of the engines features supported by normal static meshes to any runtime generated mesh. There are things that just aren’t practical to do at runtime, and those will be obviously be left out, but I hope to bring it as close to feature parity to the normal StaticMesh/ISMC/HISM and possibly even splines/skeletal meshes as is reasonably possible. So here’s a starter list, in order of my own priority as to what’s coming to the RMC.
Things I definitely want to do.
- Mesh sharing. (Maybe you want 10 copies of the same runtime mesh that can all be moved and handled independently)
- Better collision support. (Lessen impact of cooking as much as possible, fully support all simple collision shapes)
- LOD (This one is just an obvious performance improvement that’s badly needed)
- Thread safety of mesh data. (This would allow cross thread read/write of mesh data without worrying about the GC and letting the RMC take care of updating its internal state correctly on the respective threads for you)
- Dithered fade in/out of section updates
- Instancing (This one is another relatively obvious performance improvement for cases of needing hundreds of the same object)
- Distance Field support (This would make the RMC support things like DFAO, or the Distance Field Shadows, or even DFGI if Epic continues on that front at some point)
- Load once optimizations (Maybe you just use the RMC to load a model at runtime but never need to change it after that. There’s some memory and performance related improvements the RMC could do internally in these cases)
- Sub-section updates (Maybe you have a 1m vertex mesh but you only need to update like 1000 of them in one area, why resync the entire mesh to the GPU?)
- Brand new slicer designed for the RMC (The slicer in the PMC, while useful, lacks quite a few things that I think would really help. First being simple utilities to directly slice a staticmesh or ISMC/HISMC instance or even spline/skeletal into 1-2 RMC sections without having to manually do all the conversion)
- Splines! (Why not be able to spline a runtime mesh?)
Utility updates as a part of the above:
- Brand new mesh builder usable from both c++ and bp that removes the need to work directly with separate arrays like the PMC, and also makes it easier to create efficient meshes.
- Upgrade normal/tangent calculation to be able to do hard or smooth normals, and overhaul the algorithm to not be exponentially slower with larger meshes.
- More shape creation utilities (Sphere/Capsule/Pyramid/Cylinder etc)
- Mesh transformation utility for moving/rotating/scaling something to be combined within a larger mesh.
Things I’m thinking about:
- Skeletal (This one I haven’t really investigated but had several requests for and I can see the use for some things)
- Networking/Replication support. (This one is one I’d like to see support for just because it’d be an easy way for some people to get multiplayer support for their game but it can easily be 10’s of MB of data which isn’t exactly a good thing to try to arbitrarily sync across the network. Usually there’s a better way to do this, but it’s always specific to the project. For example voxel data is almost always smaller than the mesh data it creates. Or in a simpler case a position and radius is a lot less data than a high poly mesh of a sphere)
I have more things in the works for the RMC, but I’ll keep them to myself until they’re further along and I’m happy with how they’ll actually work before I get anyone’s hopes up!
As always, I’m open to suggestions for other features or changes to existing. Usually the best way to find me is on the UE4 Discord
Wow, very cool. Looking forward to seeing these improvements. I built a hacked lod system that I just got working. It’s just 4 sets, each set containing many sub rmcs. And it switches their visibility on /off. Sharing a mesh between rmcs sound amazing.
That is some great news for the plugin.
In the meantime, is it hard to push a 4.15 update to the marketplace? Even if nothing changes other than putting the compatible version number up. I would love to upgrade my project to 4.15 but RMC is holding me back 
No, actually I thought I submitted it but apparently I never actually sent it! It’s now sent so hopefully it will get updated once Epic has time to get it through their update process.
Hi, is there a way to import FBX objects to UE4 (and store it as a .uasset) in a runtime with this tool?
Have anyone faced bug then RuntimeMeshComponent disappeared after editor reopening? It happens only with one actor. Others save their components.
Not really… The uasset creation tooling doesn’t compile into a shipping build. You could in theory load an FBX model at runtime but you’ll have to do it manually or use something like Assimp.
I can’t say I’ve seen that. What version of the engine is this?