As a warning, this isn’t going to be an easy fix, and may require a drastic structural change in how the RMC works. It appears the StaticMesh Rendering now uses 4 independent buffers, {Position}, {Normal/Tangent}, {UVs}, {Color} and each has an associated SRV with their datatype. Since the position/tangents/uvs/colors don’t share a datatype I think it might be required to keep them in separate buffers now. This isn’t exactly hard to support, and it’d be nearly invisible for anyone using the blueprint API, or the MeshBuilder, but that’d be the end of single/dual/triple buffers and it’d just become a quad buffer full time, so if you set the mesh data with the single array of FRuntimeMeshVertexSimple it’d end up having to split it, so that’d slow that function down a bit, same with dual buffer, same with triple. So the best solution would be to pretty much rely entirely on the meshbuilder from this point forward and deprecate out all the old API but not sure that’s what I want to do. Will have to investigate this more once I have some more time.
Nuts, I’m trying to get a packaged build working of 4.17 with RMC 2 with using light propagation volume, the packaged build doesn’t work in 4.17. (This issue: Unreal Engine Issues and Bug Tracker (UE-49205)).
It got fixed for 4.19 but then I can’t use RMC, I’m thinking to reproduce the change in 4.17 made to make LPV work, but I’ve never edited or compiled the engine before, anyone who can deduct what files I’d need to change?
Edit: I’m trying to just comment out the assert that makes it fail, no idea what it’ll do though.
-> This resulted in the packaged build being able to run, but lpv didn’t work. Guess I’m waiting for 4.19 then.
When opening my project I get a message stating that I need to rebuild the RMC plugin, after agreeing it rebuilds the entire engine, how do I prevent that behaviour?
Thank you for letting me know @, and thank you again for your work on the RMC 
For those of you wondering if I’m going to support 4.19… Yes, but unfortunately it might be a little bit, due to some non-trivial changes in the engine. For more information see here…
Thank you for the update @, if there’s anything I can do to help let me know!
Yeah thanks @, love ya work
Hi there, I must be doing something wrong, I tried to create a custom vertex type like this:
DECLARE_RUNTIME_MESH_VERTEX(TexArrayVert, true, true, false, false, 3, ERuntimeMeshVertexTangentBasisType::Default, ERuntimeMeshVertexUVType::Default)
Then I fill each of these:
TArray<int32> Triangles;
TArray<TexArrayVert> testVertices;
And call this:
RuntimeMesh->CreateMeshSection<TexArrayVert, int32>(0, testVertices, Triangles, true, EUpdateFrequency::Infrequent, ESectionUpdateFlags::None);
RuntimeMesh is declared as:
UPROPERTY(EditAnywhere)
URuntimeMeshComponent* RuntimeMesh;
So when I try to load a level (int the editor) with an actor having this CreateMeshSection call in the OnConstruction it crashes out D3D11Util.cpp line 233:
UE_LOG(LogD3D11RHI, Fatal,TEXT("%s failed
at %s:%u
with error %s"),ANSI_TO_TCHAR(Code),ANSI_TO_TCHAR(Filename),Line,*ErrorString);
Code = Direct3DDevice->CreateInputLayout( InVertexDeclaration && InVertexDeclaration->VertexElements.Num() ? InVertexDeclaration->VertexElements.GetData() : &NullInputElement, InVertexDeclaration ? InVertexDeclaration->VertexElements.Num() : 0, &InVertexShader->Code InVertexShader->Offset ], VertexShaderCode.GetActualShaderCodeSize() - InVertexShader->Offset, InputLayout.GetInitReference() )
Filename = D:\UnrealGitHub\UnrealEngine\Engine\Source\Runtime\Windows\D3D11RHI\Private\D3D11Shaders.cpp
Line = 257
ErrorString = E_INVALIDARG
So this would lead me to think that something is wrong with the setup of the vertex declaration that the DECLARE_RUNTIME_MESH_VERTEX is creating or I’m just completly doing this wrong 
Any updates on the 4.19 fixes? Holding off on updating a project til this is done
Which Engine version and plugin version is recommended right now for a new project? Which is most stable and performant?
Very anxiously awaiting the 4.19 update. <3
Thank you for your awesome work!
Is it possible to add support for different rendering modes (wire and point) in runtime? It would be super-awesome for an upcoming project, and maybe for others too.
cognitedata (see link below) has added 4.19 support to the RuntimeMeshComponent. Rather than using the pre-built plugins, it’s often better (quicker, more flexible) to simply add the plugin source tree to your project.
- Create a Plugins sub-folder to your project directory.
- Clone the git repo into it. Use SourceTree if you don’t have git installed or don’t want to use the command line.
- Re-open your project and the plugin should be compiled.
Note: I have not tested any of the above with a blueprint project, only a C++ project.
We managed to get rid of compile errors, but unfortunately still getting crashes. Better to wait 's offical update.
Burak
Cognite Inc.
Hi, I noticed that “Collision MAY NOT be available on some platforms (HTML5)”, is collision in mobile the new feature of RMC 3.0? Can I make use of collision on mobile without rebuild Engine to allow RuntimePhysxCooking?
I’m really eager to see this be updated to 4.19, I’ve done extensive work to my projects in 4.19 and I’m not sure if its viable or even possible to rollback a version without losing a lot of progress.
I’m using procedural mesh component for a large pocedurally generated open world terrain mesh but its is really slow loading sections limiting the overall size of the world and making instantiated areas that require a level change an impossibility because the load time on the terrain will take forever. So the forums have brought me here in hopes that you may have a solution.
Thanks for your contribution.
Tried today as we were still on 4.16 and tons of crashes and bugs kept me from continuing work. Thus I now forced the project update to 4.19 and stuck on this stuff 
Had no compile errors but crashes as you mentioned. Could easily fix one, but now I get crashes in rendering stuff. 
I found this Bug Entry, that is exactly my issue I get with the RuntimeMesh. Seems to be a general issue with dynamic mesh rendering.
Fix is 4.20 …
This seems related to: https://github.com//RuntimeMeshComponent/issues/87
Hey guys. I’ve been using this plugin for a while. Even contributed to make it compatible with 4.17 once upon a time.
https://github.com//RuntimeMeshComponent/pull/61
Could you please explain where 50% memory reduction is coming from? Is there some tricky stuff with collision cooking? Or smth else?
Hi, my packaged project crashes after I use SetRuntimeMesh.
We work with the custom UE 4.18 using the plugin from github. The RuntimeMeshes are initialized at the begin and stored inside a map for later use. When we spawn a new Actor with a RuntimeMeshComponent and set the RuntimeMesh of the RuntimeMeshComponent we are able to see the mesh for a few frames.
Inside the editor, everything works like a charm.
Any ideas?
PS: Thank you for this amazing plugin
Edit: I figured out it’s not SetRuntimeMesh. The Game crashes after the actor with the runtimemeshcomponent gets set to a new location.
Hello @, I’m running into a few problems with flipped and invisible faces when trying to update the Runtime Mesh Component; for some reasons these problems only happen in the packaged version of our project though and not in the editor. Are you aware of any such issues that are specific to packaged projects and/or might you be able to help me out with these problems if I provide you with a detailled description of what is going wrong?