Runtime Mesh Component

[housekiller]

@duke22

Yeah you’re missing an include. I don’t know what one exactly, I use Visual Assist so it tells me

I’m using visual assist but it doesn’t tell me more than to add RuntimeMeshComponent.h which is already added. But intellisense has been a PITA in this project so I’m just ignoring it.

Another more annoying issue I’m having with v2; I’m using:
runtimeMesh->CreateMeshSection(meshSectionInt, vertices, triangles, normals, texMap, vertexColors, tangents, false, EUpdateFrequency::Frequent);

I run that in a loop that adds +1 to meshSectionInt every loop.

The problem is that I end up with only 1 object, where i expect about 150 of them. Only the last object is in the runtime mesh. Any idea what I’m doing wrong here?

Edit:
I seem to have misunderstood the inner workings, I though I could add pieces to a runtime mesh by calling createmeshsection multiple times for the same runtimemeshcomponent.

I have an actor that wants to create multiple meshes for itsself with different materials, how is it best to create multiple URuntimeMeshComponent instances? Any example with a piece of code? Or do I need to create an actor per mesh?

Edit2:
I seem to have overcome the issue with adding components to the actor;
URuntimeMeshComponent* newComp = NewObject<URuntimeMeshComponent>(this, objectName);

Edit3:
I have not solved it nor have i managed to figure out what the int index (first parameter of createmeshsection) does, when adding creating a meshsection with index 150 for example, i get a component with 149 empty elements and an element on the 150th component with no apparant way to fill the other 149 components.

When making an extra component during runtime I can’t even get a mesh in it to show up for some reason, I can only get it to work if the component already exists when the actor is created. Any clues?

[rYuxq]

@housekiller if I remember right, mesh sections are indexed. read the wiki, its explained there. if you want to manipulate or create one of the sections, you always have to specify the index you want to work at

[housekiller]

I was able to solve my issues, I’ll post here what I did wrong so others may be helped.

@housekiller

Another more annoying issue I’m having with v2; I’m using:
runtimeMesh->CreateMeshSection(meshSectionInt, vertices, triangles, normals, texMap, vertexColors, tangents, false, EUpdateFrequency::Frequent);

I run that in a loop that adds +1 to meshSectionInt every loop.

The problem is that I end up with only 1 object, where i expect about 150 of them. Only the last object is in the runtime mesh. Any idea what I’m doing wrong here?

I kept overwriting my variables which created the object, thus I created the last object many times over.

@housekiller

Edit:
I seem to have misunderstood the inner workings, I though I could add pieces to a runtime mesh by calling createmeshsection multiple times for the same runtimemeshcomponent.

I have an actor that wants to create multiple meshes for itsself with different materials, how is it best to create multiple URuntimeMeshComponent instances? Any example with a piece of code? Or do I need to create an actor per mesh?

Working with sections works like a charm, my problem was that I kept creating new objects and did a CreateMeshSection for each of them.

@housekiller

When making an extra component during runtime I can’t even get a mesh in it to show up for some reason, I can only get it to work if the component already exists when the actor is created. Any clues?

Solved by using RegisterComponent() after creating a new object in the actor. This is how I create the empty objects;

URuntimeMeshComponent* newComp = NewObject<URuntimeMeshComponent>(this, objectName);
newComp->RegisterComponent();

[a_prototype]

Thanks ! Still on the previous version as i can’t afford anything to break right now - looking forward to give 3.0 a testrun though.

On a different note: i couldn’t find any info on this but i am wondering if the runtime mesh component supports getting UVs from Hit results? I couldn’t get it to work right away.

[duke22]

Is it possible for RMC to generate a distance field for itself?

[Koderz]

@duke22

Did some include fixes in V3

You probably have unity build on which hides these errors.

https://github.com/GeorgeR/RuntimeMe…ee/Version3Dev

Hey, will take a look at that. Always forget about UBT hiding some stuff like that.

@a_prototype

Thanks ! Still on the previous version as i can’t afford anything to break right now - looking forward to give 3.0 a testrun though.

On a different note: i couldn’t find any info on this but i am wondering if the runtime mesh component supports getting UVs from Hit results? I couldn’t get it to work right away.

Both current versions should I think but I haven’t tested it in a while.

@duke22

Is it possible for RMC to generate a distance field for itself?

Currently, no it’s not. This is something I want to add but it’s not trivial and right now also isn’t possible. I tried a few months back to get Epic to accept a couple very minor engine changes that would allow it but unfortunately they rejected them. Here’s the PR if you’d like to see more info on that.
https://github.com/EpicGames/UnrealEngine/pull/4125

[a_prototype]

Both current versions should I think but I haven’t tested it in a while.

Hey ,

i had a quick look into the RuntimeMeshComponent.cpp and found this section

#if ENGINE_MAJOR_VERSION == 4 && ENGINE_MINOR_VERSION >= 13

// See if we should copy UVs

bool bCopyUVs = UPhysicsSettings::Get()->bSupportUVFromHitResults;
if (bCopyUVs)
{
CollisionData->UVs.AddZeroed(1); // only one UV channel
}
#endif

so my guess is that it the collision should have the neccessary UV information for a UV trace. I’m on 4.18 on MacOS, support uv from hit in project settings is enabled and working on simple static meshes.

Whatever i do though, i can’t get it to show anything else than 0,0. I tried using non overlapping UVs in 0-1 space, swapping through all sorts of collision settings on the “Add RMC” blueprint node. Do you have any idea what i could be doing wrong? Do you know if Normals/Tangents have to be setup up correctly for the UV Trace to work?

What i am doing is creating multiple RMCs with a single mesh section each within a simple blueprint Actor.

EDIT: Quick follow-up:
I made a very simple setup of just a box in an empty BP Actor and Create Box Mesh

The Procedural Mesh component works flawlessly whereas the Runtime Mesh component doesn’t return the UVs on LineTrace. Any clue what could be causing this?

EDIT 2: The Simple Box Setup from the first edit was created inside the Construction Script.
Doing the Geometry Creation on BeginPlay in the EvenGraph stops both, RMC and PMC from returning UVs.

[duke22]

Hey, will take a look at that. Always forget about UBT hiding some stuff like that.

Both current versions should I think but I haven’t tested it in a while.

Currently, no it’s not. This is something I want to add but it’s not trivial and right now also isn’t possible. I tried a few months back to get Epic to accept a couple very minor engine changes that would allow it but unfortunately they rejected them. Here’s the PR if you’d like to see more info on that.
https://github.com/EpicGames/UnrealEngine/pull/4125

I can’t say I completely understand their reasoning. The people that would use it understand the implementation might change. Anyhow, i’m probably going to split out that mesh slicing you did as a separate plugin that depends on runtimemeshcomponent as I’m going to need that pretty soon

[Koderz]

@duke22

I can’t say I completely understand their reasoning. The people that would use it understand the implementation might change. Anyhow, i’m probably going to split out that mesh slicing you did as a separate plugin that depends on runtimemeshcomponent as I’m going to need that pretty soon

I really don’t get their reasoning to be honest. It’s not like things that are exposed on the engine API this release can’t be broken next even in the uppermost layers of what people interact with. Each engine version I have to change a few things in the RMC, in 4.18 for example they changed a return reference to a pointer. I expect this type stuff, especially in the lower levels of the rendering subsystems. I had plans of upgrading the slicer to directly slice a distance field which means you still have all the distance field support for meshes you go hacking apart with the slicer. After that I was planning the utilities needed to do full runtime generation of distance fields. All of that got put on hold until either they decide to accept it (or open it up in a way they’d prefer) or I get some other things done that more people can use and then come back to it since that will take a source compile of the engine with that PR to allow it.

What did you mean by splitting out the mesh slicing? btw RMCv2s slicer is pretty broken. I’m working on its replacement and it should be up in the next day or two hopefully.

[duke22]

What did you mean by splitting out the mesh slicing? btw RMCv2s slicer is pretty broken. I’m working on its replacement and it should be up in the next day or two hopefully.

Oh ok i’d never used it before so I didn’t know it was broken, i’ll leave you to the replacement then!

[anonymous_user_2a8b03f9]

The snapshot of the last downloaded from github gives build error:
RuntimeMeshComponent\Source\RuntimeMeshComponentEditor\Private\RuntimeMeshComponentDetails.cpp(28): error C2228: left of ‘.GetSelectedObjects’ must have class/struct/union
RuntimeMeshComponent\Source\RuntimeMeshComponentEditor\Private\RuntimeMeshComponentDetails.cpp(28): note: type is ‘const IDetailsView *’
RuntimeMeshComponent\Source\RuntimeMeshComponentEditor\Private\RuntimeMeshComponentDetails.cpp(28): note: did you intend to use ‘->’ instead?

Replacing . with -> makes it buildable, but leaves doubts…

[duke22]

Yes that’s the fix for the latest 2.0.

[Rama]

@duke22

Did some include fixes in V3

You probably have unity build on which hides these errors.

https://github.com/GeorgeR/RuntimeMe…ee/Version3Dev

Thank you for doing that @duke22

I couldn’t get this to compile though, I got a ton of errors about things not being 16-bit aligned (need use const & for those parameters)

I also tried the absolute latest on git, and could not get it to compile in 4.17 due to the unity build issues as well as other errors even after I attempted the unity build fixes myself.

Thank you so much for this plugin @ I can’t wait to try update 3 when it will compile for 4.17+

Thanks again!

[rYuxq]

Thank you so much for this plugin @ I can’t wait to try update 3 when it will compile for 4.17+

I’m probably not using the latest release on github, but I am running V3 in UE 4.18.3.

[Koderz]

Thank you for doing that @duke22

I couldn’t get this to compile though, I got a ton of errors about things not being 16-bit aligned (need use const & for those parameters)

I also tried the absolute latest on git, and could not get it to compile in 4.17 due to the unity build issues as well as other errors even after I attempted the unity build fixes myself.

Thank you so much for this plugin @ I can’t wait to try update 3 when it will compile for 4.17+

Thanks again!

Hey ,

I’ve applied those unity build fixes duke22 did several commits back. Granted I haven’t tested it again since I added a couple things, but I’ll check that later if I have some time.

Right now v3 should run fine on 4.17 and 4.18. I have a local branch for 4.19 since some RHI stuff changed but that should show up on GH soonish. As far as I know it will compile fine for windows/linux/html5. I don’t have the ability to test mobile/console so can’t guarantee those. What platform/compiler are you using that’s complaining about 16-bit alignment? If you can send me the error output I’ll gladly take a look.

[alfiare]

I’ve been testing out UE4 for a few months now trying to validate how well it would work for a project. Really like the runtime mesh component and was testing out V3. I can’t seem to get collisions to work in a packaged build. Works fine in the editor. I know you said it needs async cooking to work, is there something special I have to do to make that work?

Thanks!

[alfiare]

Think I got it, though it was a little fun to find. I was calling SetCollisionUseAsyncCooking(true) right after I created the RMC (NewObject<URuntimeMeshComponent>()) figuring I would set it there to be sure. For some reason that doesn’t seem to work and the underlying bUserAsyncCooking was getting set from the post load. Seems to work fine if I call SetCollisionUseAsyncCooking(true) right before I call CreateMeshSection.

Thanks so much for this plugin, I’m coming from Unity and all the infrastructure I had built there around doing this very thing, unreal looks much more promising.

[Koderz]

@alfiare

Think I got it, though it was a little fun to find. I was calling SetCollisionUseAsyncCooking(true) right after I created the RMC (NewObject<URuntimeMeshComponent>()) figuring I would set it there to be sure. For some reason that doesn’t seem to work and the underlying bUserAsyncCooking was getting set from the post load. Seems to work fine if I call SetCollisionUseAsyncCooking(true) right before I call CreateMeshSection.

Thanks so much for this plugin, I’m coming from Unity and all the infrastructure I had built there around doing this very thing, unreal looks much more promising.

Yeah there’s some usability improvements I want to do to a couple of those things. I don’t like the part where I had to move those settings down into URuntimeMesh but that’s a side-effect of trying to separate mesh data from the component so multiple components could share it. Glad you got it to work. Not quite sure why that’d be changed in postload, where was that happening? I’m going to try to push a PR to Epic this weekend to solve that issue but that’s still likely to take weeks to months to get into a released version of the engine. When I do that though I’ll push the PR into my GitHub fork of the engine for anyone willing to compile the engine themselves.

I might actually force async cook on known engine versions that are broken for synchronous cook. I actually have an idea on a way to get around it, but it’s far from ideal and tricky to setup but I might still do it for the interim.

Btw: Welcome to UE4! I gave up on Unity for this type stuff a long time ago simply because I couldn’t make it do what I wanted!

[Rama]

@anonymous_user_58ee2499erz

Hey,

I’ve applied those unity build fixes duke22 did several commits back. Granted I haven’t tested it again since I added a couple things, but I’ll check that later if I have some time.

Right now v3 should run fine on 4.17 and 4.18. I have a local branch for 4.19 since some RHI stuff changed but that should show up on GH soonish. As far as I know it will compile fine for windows/linux/html5. I don’t have the ability to test mobile/console so can’t guarantee those. What platform/compiler are you using that’s complaining about 16-bit alignment? If you can send me the error output I’ll gladly take a look.

Hi there! Thank you for the reply @

Sorry for the confusion, I was compiling the RMC plugin using the Clang workflow that is used to compile plugins for Marketplace distribution, and I had to modify the build.cs of the RMC modules to negate the -iwyu flag that the UE4 CLang batch file defaults to:

//Add to build cs's
PCHUsage = PCHUsageMode.UseSharedPCHs;

CLang auto-build workflow for UE4 Plugins:

!!! Make sure to run this batch file inside of an empty folder called PluginStaging, the batch file nukes anything in its path !!!

"C:\Program Files\Epic Games\UE_4.18\Engine\Build\BatchFiles\RunUAT.bat" BuildPlugin -Plugin="E:\YOURPROJECTPATH\Plugins\RuntimeMeshComponent\RuntimeMeshComponent.uplugin" -Package="%CD%\RMC18" -Rocket

I use this workflow for all my plugins to generate all binaries for a plugin for all platforms I want to support, I was initially told about this tool by Marketplace staff when code plugins first became a thing.

whitelisting so the batch tool works:

//.uplugin
 "Modules": 
    {
      "Name": "RuntimeMeshComponent",
      "Type": "Runtime",
      "LoadingPhase": "Default"**,
            "WhitelistPlatforms" :
            
                "Win64",
                "Win32"
            ]**
    },

If I compile RMC as part of my project it works fine

**formal parameter with requested alignment of 16 won't be aligned**



[quote="anonymous_user_58ee2499erz, post:417, topic:66022"]


What platform/compiler are you using that's complaining about 16-bit alignment? If you can send me the error output I'll gladly take a look.
[/QUOTE]


Regarding the 16-bit alignment, I still get those errors when compiling for **Win32** using the Clang workflow for plugins, and it errors out on the following:

[spoiler]
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateSignatureImpl.inl(530): error C2719: '<Params_1>': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateSignatureImpl.inl(621): error C2719: '<Params_1>': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(100): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(152): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(156): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(160): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(164): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateSignatureImpl.inl(40): error C2719: 'unnamed-parameter': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateSignatureImpl.inl(551): note: see reference to class template instantiation 'TBaseDelegate<TTypeWrapper<void>,int32,FVector4>' being compiled
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(58): note: see reference to class template instantiation 'TBaseDelegate<void,int32,FVector4>' being compiled
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateSignatureImpl.inl(530): error C2719: '<Params_1>': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateSignatureImpl.inl(621): error C2719: '<Params_1>': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(100): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(152): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(156): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(160): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\rmc18\hostproject\plugins\runtimemeshcomponent\source\runtimemeshcomponent\public\RuntimeMeshBuilder.h(164): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateInstanceInterface.h(39): error C2719: 'unnamed-parameter': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateInstanceInterface.h(49): note: see reference to class template instantiation 'IBaseDelegateInstanceCommon<void (int32,FVector4)>' being compiled
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateInstancesImpl.h(873): note: see reference to class template instantiation 'IBaseDelegateInstance<void (int32,FVector4)>' being compiled
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateInstancesImpl.h(1009): note: see reference to class template instantiation 'TBaseStaticDelegateInstance<TTypeWrapper<void> (int32,FVector4),TArray<uint8,FDefaultAllocator> *,int32,int32>' being compiled
\RMC18\HostProject\Plugins\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\RuntimeMeshBuilder.cpp(71): note: see reference to class template instantiation 'TBaseStaticDelegateInstance<void (int32,FVector4),TArray<uint8,FDefaultAllocator> *,int32,int32>' being compiled
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateInstanceInterface.h(56): error C2719: 'unnamed-parameter': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateInstancesImpl.h(881): error C2719: 'unnamed-parameter': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateInstancesImpl.h(954): error C2719: '<Params_1>': formal parameter with requested alignment of 16 won't be aligned
c:\program files\epic games\ue_4.18\engine\source\runtime\core\public\Delegates/DelegateInstancesImpl.h(1024): error C2719: '<Params_1>': formal parameter with requested alignment of 16 won't be aligned
\RMC18\HostProject\Plugins\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\RuntimeMeshBuilder.cpp(277): error C2719: 'Value': formal parameter with requested alignment of 16 won't be aligned
\RMC18\HostProject\Plugins\RuntimeMeshComponent\Source\RuntimeMeshComponent\Public/RuntimeMeshSlicer.h(65): error C2719: 'SlicePlane': formal parameter with requested alignment of 16 won't be aligned
\RMC18\HostProject\Plugins\RuntimeMeshComponent\Source\RuntimeMeshComponent\Public\RuntimeMeshSlicer.h(65): error C2719: 'SlicePlane': formal parameter with requested alignment of 16 won't be aligned
\RMC18\HostProject\Plugins\RuntimeMeshComponent\Source\RuntimeMeshComponent\Private\RuntimeMeshSlicer.cpp(481): error C2719: 'SlicePlane': formal parameter with requested alignment of 16 won't be aligned
ERROR: UBT ERROR: Failed to produce item: \RMC18\HostProject\Plugins\RuntimeMeshComponent\Binaries\Win32\UE4-RuntimeMeshComponent.lib
[/spoiler]


**Solution:**

The easy solution is to just make sure these parameters become const &

So here's an example from RuntimeMeshBuilder



```


FORCEINLINE static void WriteNormalTangentPackedRGBA16N(int32 Index, **FVector4 Value**, TArray<uint8>* Data, int32 Stride, int32 Offset)
    {
        return Write<FPackedRGBA16N>(Index, Value, Data, Stride, Offset);
    }


```



becomes



```


FORCEINLINE static void WriteNormalTangentPackedRGBA16N(int32 Index, **const FVector4& Value**, TArray<uint8>* Data, int32 Stride, int32 Offset)
    {
        return Write<FPackedRGBA16N>(Index, Value, Data, Stride, Offset);
    }


```




**Why It's Important**

The reason this bit alignment matters as far as I know is if anyone is using the RMC plugin on **consoles like XBox or shipping win32 builds**

**Epic's Ben Marsh** explains here:
[https://answers.unrealengine.com/que...ign16-won.html](https://answers.unrealengine.com/questions/50892/shipping-formal-parameter-with-declspecalign16-won.html)



Thank you again for the RMC, and thank you for the new version of the RMC you are making, URuntimeMesh for multiple components = awesome!!!

♥

[Rama]

4.19 of Pre Version 3 or after Version 3?

Anyone have a working version of RMC for 4.19, possibly even pre-version 3?

I tried to do the update but I am getting a crash on attempt to access the tangent data:

void FLocalVertexFactoryShaderParameters::SetMesh(FRHICommandList& RHICmdList, FShader* Shader, const FVertexFactory* VertexFactory, const FSceneView& View, const FMeshBatchElement& BatchElement, uint32 DataFlags) const
{
SetSRVParameter(RHICmdList, VS, VertexFetch_PackedTangentsBufferParameter, LocalVertexFactory->GetTangentsSRV());

I presume I have to indicate somehow when tangent data is not present

Someone made an issue related to this:
https://github.com//RuntimeMes…nent/issues/87

I know @ mentioned making a 4.19 branch, I was hoping to not pressure him and see if we could figure it out while waiting