Runtime Mesh Component

[Koderz]

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.

@pickersZ;654400

I am currently having some issues with line trace. It seems the collision bounds are different from the odd shape runtimemesh. Is there a way to pass the collision shape to the runtimemesh function?

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.

@AlexJ16;656500

This is long shot but it’s worth a try. I started a thread, and hope to get support from others like me using the RMC in the hope that we can convince Epic to give a dev grant for the work he’s done on the RMC.

I’d like to thank for the work he’s done so far!

If you use the RMC and think Epic should look into giving a dev grant, please support it here: Nominate the RuntimeMeshComponent for a dev grant! - Feedback & Requests - Epic Developer Community Forums

@Vertex Soup;657836

Just stopping by to say I started to use it and it is great! Thank you very much for such a great free addition @!

Thank you both for your support! Glad it was useful to you. It would be amazing to receive a dev grant for the RMC.

@Zireael07;659435

Bug report: Trying to #require Components/SplineComponent.h in a project that has this plugin (doesn’t have to be the same class that uses RMC) results in a spate of errors from VS:

Curiously enough, I can work with splines and RMC in blueprints.

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.

@Thumper;664034

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…

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.

@Zeblote;664757

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)

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)

@Lekyaira;665739

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?

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.

@Rikard.Herlitz;667364

Will this be updated for 4.15 with the new minimal headers etc?

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).

@edstoica;667667

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’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.

@Thumper;668201

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.

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.