Runtime Mesh Component

Distribution UE Marketplace
,
259

I’d have to see more of how you have things configured. My first guess would be whether you have the light set as static, make sure it’s stationary/dynamic. Beyond that I’d have to see how you have the RMC configured as well as other lighting config like directional light/skylight/fog.

Haven’t had the time to follow much on the forums recently. I used to track what you were doing. Looks like you’ve made some serious progress!
As for 4.16. Unless there’s breaking changes introduced (won’t surprise me) it should already work. If you mean uploading it to the marketplace, I’m not sure I can for a preview build of the engine. I haven’t directly tried v2 in 4.16 yet, might have time in the next few days to give it a shot. RMCv3 is being developed on 4.16 and is likely to be 4.16+ only, might support 4.15 if it’s not much work but I won’t be backporting beyond that. You could get the RMC from github (if you do just get master branch, not the release builds) and install it to your project.

On another note, I’d be interested to hear your feedback on the RMC as to what you’d like to see added/changed/improved.

Those aren’t really meant to stick around as an member variable. They’re meant to live for the short time you’re creating/updating something. The one you had, like the one below, is the correct way to set that up. You could do it on the heap, but I wouldn’t recommend it. Inside whatever generation function you have, just create the 2 builders, do whatever, submit them to the rmc and let them get destroyed when they go out of scope.



	FRuntimeMeshComponentVerticesBuilder VertBuilder(true, false, false, false, false);
262

thanks ,


	FRuntimeMeshComponentVerticesBuilder vertices(&(meshData.vertices), nullptr, nullptr, nullptr, nullptr, nullptr);
	FRuntimeMeshIndicesBuilder triangles;
	vaseRuntimeMesh->CreateMeshSection(0, vertices, triangles);

this works for me.

But could you give a bit insight about “They’re meant to live for the short time you’re creating/updating something.”? It’s just a class, why can’t it stay as member of another?

Had another try on:


template<typename VertexType>
	void CreateMeshSection(int32 SectionIndex, TArray<VertexType>& Vertices, TArray<int32>& Triangles, bool bCreateCollision = false, 
		EUpdateFrequency UpdateFrequency = EUpdateFrequency::Average, ESectionUpdateFlags UpdateFlags = ESectionUpdateFlags::None)

using FRuntimeMeshVertex<true, false, false, false, 0> for VertexType


	TArray<FRuntimeMeshVertex<true, false, false, false, 0>> verticestest;
	TArray<int32> trianglestest;

	vaseRuntimeMesh->CreateMeshSection(0, verticestest, trianglestest);

fails compiling: ‘TypeInfo’: undeclared identifier at code


	virtual const FRuntimeMeshVertexTypeInfo* GetVertexType() const { return &VertexType::TypeInfo; }

Why can’t we use this? This seems to be a nice way to declare a vertices array, as you can specify what you want and what not.

ok …, tried your code from Github, which works when adding the modules
PrivateDependencyModuleNames.AddRange(new string] { “ShaderCore”, “RenderCore”, “RHI”, “RuntimeMeshComponent” })
like you explain in your wiki as well.


	TArray<FRuntimeMeshVertexSimple> verticestest2;
	TArray<int32> trianglestest;

	vaseRuntimeMesh->CreateMeshSection(0, verticestest2, trianglestest);

What VertexTypes are there?
Using the search function of VisualStudio I came across


DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexSimple);
DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexDualUV);
DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexNoPosition);
DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexNoPositionDualUV);
DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexHiPrecisionNormals);
DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexDualUVHiPrecisionNormals);
DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexNoPositionHiPrecisionNormals);
DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexNoPositionDualUVHiPrecisionNormals);

Which explains why I could not find it by searching for the class.

For our main project I want to use more than 2UV-Channels, they way to go seems to be FRuntimeMeshVertex<> where I can specify the amout of UV-Channels, but as shown above it does not work as compilation fails.

thanks in advance.

263

I just did this extension in a fork of repo and it worked for me. (Ignore the typo of triple, I know :wink: )

264

Those by default will keep an entire copy of the mesh wasting quite a bit of memory if you have more than a couple. There’s not really any point in keeping them around.

There’s several parts to making a new vertex. The way you should be able to do it is by using…



DECLARE_RUNTIME_MESH_VERTEX(FTestVertexConfiguration, true, true, true, true, 3, ERuntimeMeshVertexTangentBasisType::Default, ERuntimeMeshVertexUVType::HighPrecision)

in the header, and…



DEFINE_RUNTIME_MESH_VERTEX(FRuntimeMeshVertexNoPositionDualUVHiPrecisionNormals);

in a .cpp file. I think there might be a dll problem introduced recently with this so best thing would be to use the github version and alter the generic vertex header and cpp file like what Mase87 did above.

Now with that said, unfortunately you can’t actually disable normal/tangent/color and have to have at least 1 uv channel. you can only disable position if used with a dual buffer section. Won’t go into explanation on that right here, but it’s an engine thing. It should be working in v3 though.

265

EDIT : apparently, it still occurs with Procedural Mesh Component so I am going to answerhub, sorry for the inconvenience :slight_smile:

266

+1 for ‘instancing support’!

Great job on what you have done already. The community thrives on the work and support like you provide. Thanks! :slight_smile:

267

Hey, amazing plugin!
Can you please update it to 4.6?
And how would I go about replicating it? When I set the component to replicate it kicks the clients out of the server as soon as they login…

269

That’s pretty cool. I’m sure @ is already all over that.

I still wonder why Epic are flogging PMC. There is no reason to be using that over RMC at all. Maybe one day RMC will replace PMC entirely in the engine core. hint hint @JamesG.

+1 for a 4.16 marketplace update though.

270

Thanks! It’s been a long road and unfortunately haven’t had as much time recently as I would have hoped to continue on but I assure you more is coming (subject to what I’m about to say below)

I assume you mean 4.16? If so then yes it’s submitted to the marketplace team so it’ll probably take a few days before it shows up.

I am aware of that, and I’ll be investigating it shortly for the RMC. So hopefully in 4.17 we’ll have more efficient cooking without needing a custom compiled engine.

Well they haven’t put much effort into the PMC, and my guess is because the RMC exists. My bet is the collision work was really meant for a different tool that I’m about to bring up below and they just added it to the PMC because it’s obviously a useful addition.

Also I had talked to James a while back about replacing the PMC, and to my knowledge this is still an option but the reason I chose to go to the marketplace for now is it’s generally faster to push updates to. Pull requests can take quite a while, as an example the texture array PR that Hilmar submitted back in Oct 2015 that I resubmitted after some upgrades in early 2016 and then I’ve tried to support it as I have time since is still open. Hopefully some day that will be merged

My next post is going to lay out some things related to the future of the RMC, as right now I’m not entirely sure where it stands after seeing something on the ue4 roadmap…

271

Not entirely sure where the RMC stands currently. Initiating a chat with Epic to see what’s up.

Alright, before I start this. I personally have ZERO intention of dropping the RMC, and up until Friday I was still actively developing it, granted very slowly, but I’m in question/concern right now as to where my work stands.

@JamesG Within the next day I’ll be opening a new email chat with you and Ori as I’d love it if you could provide a little clarification on a few things about something on the roadmap linked below. Before I do, I saw the new async collision. Haven’t tried it but thank you and Ori both (and whoever else was involved) for moving forward with that! I like the new solution better than my quick and dirty get it running setup.

Now, I was pointed to this… Trello …Friday and is why I’ve currently halted my own work on the RMC until I can get a little clarification on a few things.

This post is honestly a bit vague beyond the obvious specific features of mesh editing. The engine already has the CustomMeshComponent, ProceduralMeshComponent and then I added the RMC on top of it to improve on them both. This obviously makes for a question I get nearly daily of “what should I use? what’s the difference?” So depending on where this goes I think before long the path of permanently replacing/merging the PMC/RMC is probably a good idea, and then it’s just a question of what should happen to the CMC, but we can come back to that soon.

So this new mesh editor has me a little confused/concerned. The very high level and largest question this brings up is does this new editor replace the PMC? and with that the RMC? Or is this a separate tool meant more for programmatic simple meshes like say a maze? Then for things like a full voxel engine, or terrain engine or model loading etc you’d still need the PMC/RMC. So until I can hopefully get some clarification I’ve stopped work on the RMC since I have a lot of time already into unreleased work on it and don’t want to continue if it’s going to be made useless by this new feature.

So to all of those currently using the RMC. I will still continue to support it and bug fix it for as long as it’s used, but I’m not currently moving forward with the new features until I verify what the RMC’s place is in all of this.

272

Sounds pretty reasonable to me. That trello post is a bit of an odd ball. Keep us posted man.

273

Just checking, did you get the confirmation email about it this time?

I tried installing the plugin from the source, but it throws a whole bunch of compile errors about headers not being in the right order. It looks like the RMC source hasn’t been updated to use the new 4.16 build targets or the whole “include what you use” movement started in 4.15.

274

I just installed it on 4.16.1 without problems.(vs2015)

275

When trying to build this plugin from a custom UE4 4.15 source build (via VS 2015), I’m getting the following output:


40>------ Build started: Project: MinidumpDiagnostics, Configuration: Development_Program x64 ------
37>  Performing full C++ include scan (building a new target)
37>  Creating makefile for UE4Editor (no existing makefile)
37>  Building UnrealHeaderTool...
37>  Target is up to date
37>  Deploying UnrealHeaderTool Win64 Development...
37>  Total build time: 0.34 seconds (NoActionsToExecute executor: 0.00 seconds)
37>  Parsing headers for UE4Editor
37>    Running UnrealHeaderTool UE4Editor "D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor.uhtmanifest" -LogCmds="loginit warning, logexit warning, logdatabase error" -Unattended -WarningsAsErrors
37>  Reflection code generated for UE4Editor in 8.8219289 seconds
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\RuntimeMeshComponent.cpp(1): error : Expected RuntimeMeshComponent.h to be first header included.
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\RuntimeMeshComponentPlugin.cpp(1): error : Expected RuntimeMeshComponentPlugin.h to be first header included.
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\RuntimeMeshCore.cpp(1): error : Expected RuntimeMeshCore.h to be first header included.
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\RuntimeMeshGenericVertex.cpp(1): error : Expected RuntimeMeshGenericVertex.h to be first header included.
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\RuntimeMeshLibrary.cpp(1): error : Expected RuntimeMeshLibrary.h to be first header included.
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\TessellationUtilities.cpp(1): error : Expected TessellationUtilities.h to be first header included.
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponentEditor\Private\RuntimeMeshComponentDetails.cpp(1): error : Expected RuntimeMeshComponentDetails.h to be first header included.
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponentSlicer\Private\RuntimeMeshComponentSlicer.cpp(1): error : Expected RuntimeMeshComponentSlicer.h to be first header included.
37>D:\UE4\SourceBuild\4.15\UnrealEngine\Engine\Plugins\Marketplace\RuntimeMeshComponent\Source\RuntimeMeshComponentSlicer\Private\RuntimeMeshSlicer.cpp(1): error : Expected RuntimeMeshSlicer.h to be first header included.
37>  Build canceled.
37>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets(41,5): error MSB3073: The command "..\..\Build\BatchFiles\Build.bat UE4Editor Win64 Development -waitmutex" exited with code 1.

I’ve tried swapping/correcting the ordering of each header, but it just generates a much larger list of errors, all of which are from the RuntimeMeshComponent source files (ie, the rest of the engine builds perfectly fine).
Perhaps the issue here is related to “RuntimeMeshComponentPluginPrivatePCH.h” not actually being the PCH for the project? IDK. Aside from a full GitHub build of RMC, I’ve also tried installing it via the launcher’s marketplace, and then manually copying “UE_4.15\Engine\Plugins\Marketplace\RuntimeMeshComponent” to the same location in my custom source build.
It yielded the same issues. Note that the plugin works perfectly fine in a normal, non-source engine build…

One thing I haven’t tried is simply creating a new UE4 project (from the custom build’s project launcher), and then adding the plugin into that project’s folder. But this is tedious, having to do this for every new project I create.
Not to mention, what a waste of disk space having multiple copies of the same thing all over the place. I’d much rather have the marketplace version, complete with slicer support, etc, literally built into my custom engine source’s plugins folder.

So, how can I achieve this? What am I doing wrong?

276

I get the same errors when I tried adding the source version to my project. I eventually gave up and am now just waiting for the marketplace version to be updated, which is taking a loooong time for Epic, which is the usual case for any plugin update. Epic needs a better system for rolling out updates faster.

277

Is it possible to use multiple materials? When converting from a static mesh component, it correctly uses multiple materials but I see no way of defining which triangle uses which material index or slot when manually adding sections.

Also when using “Get Section From Static Mesh”, it crashes in 4.15:


UE4Editor_RuntimeMeshComponent!FRuntimeMeshComponentVerticesBuilder::Reset() [d:\build\++portal+main+full\sync\localbuilds\plugintemp\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\runtimemeshbuilder.h:860]
UE4Editor_RuntimeMeshComponent!URuntimeMeshLibrary::GetSectionFromStaticMesh() [d:\build\++portal+main+full\sync\localbuilds\plugintemp\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\private\runtimemeshlibrary.cpp:408]
UE4Editor_RuntimeMeshComponent!URuntimeMeshLibrary::GetSectionFromStaticMesh() [d:\build\++portal+main+full\sync\localbuilds\plugintemp\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\private\runtimemeshlibrary.cpp:463]
UE4Editor_RuntimeMeshComponent!URuntimeMeshLibrary::execGetSectionFromStaticMesh() [d:\build\++portal+main+full\sync\localbuilds\plugintemp\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\runtimemeshlibrary.h:14]

When I use the same node from the procedural mesh, it works (but I can’t use the tangents output).

278

I know you are halting work until more information. But… is it actually working on 4.16? It is not in the marketplace.

Also, the example doesn’t seem to function on 4.16.1

279

One Material per section. If you want a face (triangle) to have a drifferent material, you would need to write it into another section.

You would need to add the vertices information to the other section as well for that face(location, normal, tangent, uv), no matter if smoothed or not. This is exactly how unreal handles different materials. You can check that by modeling a cube, setting it to smooth and importing it. Then set a different material to one face and import it again. Smoothed one material = 8 verts, smoothed two materials = 12 verts.

280

Thanks for the information!

Since I cannot get any material information from “Get Section From Static Mesh”, I assume there is no way to merge a bunch of static meshes (each with multiple materials) placed in the scene into some runtime meshes (one for each material) using blueprint, right?!

281

StaticMesh->GetMaterial, select the section. When putting the data into the runtime mesh make a section per material. On Merge: Check every section if the material already is in, if not create new section. Put the mesh data into the same section.

You can just append vertices data (Location, UV, normal tangent), triangle data needs to be offset to where the vertices data has been placed. Depending on what you are going to do, you might need to take care of the section sizes, as update times for the RuntimeMesh might grow to big. We have 50.000 vertices per section with a resulting update time of 5ms.

Also make sure that you define a radius from the stuff that you want to merge with the RuntimeMesh, as a single RuntimeMeshComponent counts as one Object. If there is just a little bit of the merged objects visible on the screen, the whole RuntimeMesh is taken into account for rendering.

If you need to get single meshes back out again, keep references to startindex and length of the data of every single mesh.