Runtime Mesh Component

[Koderz]

Runtime Mesh Component

Version 3.2 available on GitHub! Coming to Marketplace soon with full 4.17-4.20 support!

The RuntimeMeshComponent, or RMC for short, is a component designed specifically to support rendering and collision on meshes generated at runtime. This could be anything from voxel engines like Minecraft, to custom model viewers, or just supporting loading user models for things like modding. It has numerous different features to support most of the normal rendering needs of a game, as well as ability to support both static collision for things such as terrain, as well as dynamic collision for things that need to be able to move and bounce around!

Now, the RMC is very similar in purpose to the ProceduralMeshComponent or CustomMeshComponent currently found in UE4, but it far surpasses both in features, and efficiency! It on average uses half the memory of the ProceduralMeshComponent, while also being more efficient to render, and far faster to update mesh data. This is shown by the ability to update a 600k+ vertex mesh in real time! The RMC is also nearly 100% compatible with the ProceduralMeshComponent, while adding many features above what the PMC offers.


Please Consider Supporting the RMC's development! Donations will be counted towards a pre-purchase of the upcoming Extended RMC.

More info can be found here: https://github.com/Koderz/RuntimeMes...e-development!


Current list of features in the RMC

• Full support for async collision cooking (See below for a known problem with UE4 regarding this)
• Brand new normal/tangent calculation utility that is several orders of magnitude faster
• Up to 8 UV channels
• High precision normals support
• Collision only mesh sections.
• Tessellation support
• Navigation mesh support
• Fully configurable vertex structure
• Ability to save individual sections or the entire RMC to disk
• RMC <-> StaticMesHComponent conversions. SMC -> RMC at runtime or in editor. RMC -> SMC in editor.
• Static render path for meshes that don't update frequently, this provides a slightly faster rendering performance.
• 70%+ memory reduction over the ProceduralMeshComponent and CustomMeshComponent
• Visibility and shadowing are configurable per section.
• Separate vertex positions for cases of only needing to update the position.
• Collision has lower overhead compared to ProceduralMeshComponent

** The RMC fully supports the cooking speed improvements of UE4.14 and UE4.17 including async cooking. As of right now, the RMC is forced to always use async cooking in a shipping build due to an engine bug which I've submitted a fix to Epic for




Some requested features that I'm looking into: (These aren't guaranteed to be added)

• LOD (Probably with dithering support)
• Dithered transitions for mesh updates
• Instancing support (Probably ISMC style unless there's enough demand for HISMC style support)
• Mesh replication

Supported Engine Versions:
v1.2 supports engine versions 4.10+
v2.0 supports engine versions 4.12+
v3.0 supports engine versions 4.17+

The Runtime Mesh Component should support all UE4 platforms.
Collision MAY NOT be available on some platforms (HTML5)

Tested Platforms:
Windows, Linux, HTML5
(Also tested with HTC Vive, and Oculus Rift)


Downloads:
GitHub: https://github.com/Koderz/RuntimeMeshComponent

Examples:
https://github.com/Koderz/RuntimeMeshComponent-Examples

Documentation:
https://github.com/Koderz/UE4RuntimeMeshComponent/wiki

Issues/Help:
https://github.com/Koderz/UE4Runtime...mponent/issues


640k vertex animated mesh! (Not great quality gif)


Convex collision support for movable objects!


Same familiar API as PMC from Blueprints!


New Simpler to use API from C++! (Still supports the PMC style API as well!)

[Rumbleball]

Since UE4.20 they've added the ability to apply a render target to the landscape as displacement.. without the runtime functionality. How feasible would it be with the RMC?

Take a texture (RenderTarget is a texture), create a plane with subdivisions, read the pixel and displace the vertex Z position depending on the color value, update the vertices to the RMC. Its a bit of coding but not that problematic if you only want a texture that maps to a fixed size plane. Needs C++ tough.

[THEAETIK]

Since UE4.20 they've added the ability to apply a render target to the landscape as displacement.. without the runtime functionality. How feasible would it be with the RMC?

[Rumbleball]

So i tried to get it work in 4.19. but it does not work at all. Can you give a simple setup?
Edit: Seems like you can't see the Tessellation in Wireframe Mode

nope, you can't ^^ not sure why though. Maybe the wireframe shader takes another render path or is not run on the GPU.

[HOUmmel]

So i tried to get it work in 4.19. but it does not work at all. Can you give a simple setup?
Edit: Seems like you can't see the Tessellation in Wireframe Mode

[Rumbleball]

It works with static meshes. The Engine crashes with PN Tessellation. Flat Tessellation has no Effect. Maybe because i use 4.22?

Maybe, but can't help ya there.

[HOUmmel]

works out of the box for UE 4.19.
Is you material working on static meshes? (Tessellation is enabled via the applied material)

It works with static meshes. The Engine crashes with PN Tessellation. Flat Tessellation has no Effect. Maybe because i use 4.22?

[Rumbleball]

Can somebody explain how to use Tessellation with RMC?

works out of the box for UE 4.19.
Is you material working on static meshes? (Tessellation is enabled via the applied material)

[HOUmmel]

Can somebody explain how to use Tessellation with RMC?

[Rumbleball]

Does this still have a marked improvement over Epic's ProceduralMeshComponent for basic, not updating a mesh every frame operations?

I assume as long as Epic didn't do any improvements. It was mentioned that Epic was working on an more performant solution, though I have no clue what happend to that.

[duke22]

Does this still have a marked improvement over Epic's ProceduralMeshComponent for basic, not updating a mesh every frame operations?

[JackMaDrinkCafe]

[MENTION=141752]Koderz[/MENTION] - So I eventually got everything compiling and running. Those warnings from my previous post are still there though. Looks like the build files haven't been updated as needed.

I was so excited to upgrade as I thought I might finally get rid of that annoying bug I have... but to my great devastation, I'm still hitting that same exception breakpoint every time I try to use RMC for the first time. See my other previous post from a while ago about it. It breaks out to VS at some exception breakpoint in the engine code. I then have to click Continue to keep going. Then I can continue using RMC with no problems until I stop the current game and then click play again. Then it happens all over again. So frustrating when you have to click play, let it break to VS, click continue in VS, then go about testing your game... like 100 times a day.

I've tried different engine versions as well as creating new fresh projects. It was all working amazingly for me back in 4.14. Don't understand why I'm seemingly the only person hitting this problem, unless nobody else uses RMC in C++... surely not. If you use it just in BP then there is no issue.

I remember you saying that you fixed this issue... was that for v3 though?

I have the same isuue while I resolve it .The erro is I have not createDefaultSubobject ,To make the component in the constructor function . Hope it may help sombody! chinese guy jack!

[IronSuit]

When can we expect v4.21 support?
Also any new on the extended plugin version?

[ioFlow Studios]

Thanks for the tip about moving the #if Ryvar, I was pretty stuck for a moment there...

[Ryvar]

Update:
I tried reinstalling, deleting binaries and intermediate files, etc., updating the target.cs of the editor files in RuntimeMeshComponent, still doesn't work, as the error below persists:

Severity Code Description Project File Line Suppression State
Error LNK1181 cannot open input file 'C:\Program Files\Epic Games\UE_4.20\Engine\Plugins\RuntimeMeshComponent-master\RuntimeMeshComponent-master\Intermediate\Build\Win64\UE4Editor\Development\RuntimeMeshComponent\UE4Editor-RuntimeMeshComponent.lib' DungeonOfTimePaul C:\Users\paull\Desktop\Unreal *****\DungeonOfTimePaul\Intermediate\ProjectFiles\LINK 1

This is probably due to the changes to Plugin include paths in 4.20/4.21.

In your [Project Directory]\Plugins\RuntimeMeshComponent\Source\RuntimeMeshComponent\RuntimeMeshComponent.Build.cs file, comment out the PublicIncludePaths and PrivateIncludePaths lines and replace them with the new ModuleDirectory-relative paths like so:


// PublicIncludePaths.AddRange(
// new string[] {
// "RuntimeMeshComponent/Public"
// // ... add public include paths required here ...
//}
// );
PublicIncludePaths.Add(Path.Combine(ModuleDirectory, "Public"));

// PrivateIncludePaths.AddRange(
// new string[] {
// "RuntimeMeshComponent/Private",
// // ... add other private include paths required here ...
//}
// );
PrivateIncludePaths.Add(Path.Combine(ModuleDirectory, "Private"));


Do the same in RuntimeMeshComponentEditor\RuntimeMeshComponentEditor.Build.cs

This *should* probably cover it for 4.20. For 4.21 you will need to take the "#if ENGINE_MAJOR_VERSION == 4 && ENGINE_MINOR_VERSION < 21" line in RuntimeMeshComponent.cpp and move it from above GetPhysicsTriMeshData() to above CreateNewBodySetup()

I have no idea whether this has any impact on physics in an actual shipping build, but it will get your project compiled and running a Development Editor build for the time being.

Edit: quick update - tried packaging a shipping Win64 build of the default map to which I added a runtime MeshSlicer BP. Works great; slices respond to player and projectile physics as expected.