Runtime Mesh Component

[John_Alcatraz]

@wilberolive;693676

Since updating to 4.15 I’m getting an odd exception in PrimitiveSceneProxy.cpp. My C++ code is identical between my 4.14 and 4.15 projects. I compile and run both projects, the 4.14 version runs fine, but the 4.15 version triggers a breakpoint with an exception.

The exception occurs on line 599 of PrimitiveSceneProxy.cpp, which is an engine file. Here is the actual code from that file. Line 599 is at the ensureMsgf call.

This exception comes up when I try to create a runtime mesh section for the first time. I have a valid material assigned to the mesh section. If I close the breakpoint exception dialog in Visual Studio and click Continue, then it continues running as per normal and the runtime mesh works fine from that point forward, until I close and run again, then I hit it again. So every time I run my project, I hit the breakpoint, close the exception dialog, then click Continue to keep going.

I saw the same issue, and I solved it with just commenting out the ensureMsgf there, it’s surely not clean, but it works.

[Kobbersvard]

Hey guys, anyone tried to raycast runtime mesh? My test collide by LineTraceSingleByChannel is only working on static meshes but not procedurally generated mesh, I try all the options of channels/responses but with no success…

[wilberolive]

@Alcatraz;694545

I saw the same issue, and I solved it with just commenting out the ensureMsgf there, it’s surely not clean, but it works.

That requires modifying the UE4 source and recompiling it right? If so, I’d rather avoid something that drastic and find an actual fix for the issue. Any idea whether this is an issue with the runtime mesh component or with UE4 itself?

@shunwang;694622

Hey guys, anyone tried to raycast runtime mesh? My test collide by LineTraceSingleByChannel is only working on static meshes but not procedurally generated mesh, I try all the options of channels/responses but with no success…

Yes, it does work. Make sure you have collisions turned on when you create your runtime mesh section. Then ensure the collision channel of the runtime mesh and the channel of the line trace are both set to block each other (or overlap if you just want that).

If all you care about is knowing whether your runtime mesh has been hit or not, this will work fine. If however you want more detailed information depending on which face is hit, then you will need to store this additional information yourself in an array that you populate in the same order as you add triangles to the runtime mesh. Unfortunately, the runtime mesh component doesn’t have a facility to store a custom data blob on a per face basis… perhaps that could be a feature request, unless there is something I’m not aware of??? Very useful in situations where you are using a runtime mesh to render hundreds of batched objects for example and you want to know which object the player shot or clicked on for example. You could store an object index integer per face that can be retrieved from the hit face.

[anonymous_user_118991ad]

For rendering cube-shaped voxels aligned to a grid (think minecraft), does RMC have a performance or feature benefit over instanced static meshes? I know this is a high level question, I just wanted to do a bit of research before deciding if it’s worth diving into this.

[wilberolive]

@ryeguy;696028

For rendering cube-shaped voxels aligned to a grid (think minecraft), does RMC have a performance or feature benefit over instanced static meshes? I know this is a high level question, I just wanted to do a bit of research before deciding if it’s worth diving into this.

RMC is exactly what you need for a situation like that. I would break the world up like an octree. Then use an RMC per node in the tree (so they can be culled) with a mesh section per material type.

[Koderz]

@DavidNSilva;684180

I ended up rolling code to “manually” calculate the tangents and normals, the PMC’s code is dreadfully slow not even suitable for editor time let alone runtime. if you’re are going to push an update to v2 (which I would really appreaciate) and I am the only one affected by the CalculateMeshTangents problem then I would say not to brother fixing it for me cause I’m no longer using that functionand V3 is coming anyways. However…there is something else that bothers me with V2…I’ve looked through your code and examples to find the cause and I found a few hints. When selecting (in editor) an actor with a RMC the “selected outline” (that little orange line that outlines the selected object) actually fills the entire component/mesh instead of just outlining. To make matters worse, if the update frequency is set to “Infrequent” the outline/fill will Never disappear! not even by unselecting the object. when the update frequency is set to “Average” the outline/fill disappears when the actor is deselected…but the problem is the outline is not a outline but rather it fills the entire mesh changing it’s color and making debugging and level design a lot harder as it drastically changes the color of the mesh. Where’s a picture of the problem:

I know your time is limited and if you can only push a fix or two I would rather you fix the outline problem than the tangents one

P.S - Please note they bug out more often when freshly dragged in from the content browser (100%) but they can also get stuck after being saved in a level, it’s just more rare. But in all cases I would rather have an outline instead of that annoying “fill” effect.

Surprisingly I guess I haven’t seen this myself even though I work with it daily. What specifically will cause it to get stuck?

@Thumper;689266

I’m having trouble getting RMC to work in UE4 4.15. Is it possible to get the plugin with the project file? There’s no way for me to rebuild the plugin (fixing any dll issues) because it isn’t included in the zip file.

I’m a bit late here but yes you can add it directly to your project file. You’d just want the download from github master, not the release version, and then make sure you uninstall it from the engine if you installed it there.

@linmeeka;691862

Hello,i’m trying add collision to the mesh.I used function RuntimeMesh->AddCollisionConvexMesh(Positions);.
However,The collision body is not exactly the same as the mesh shape.As the picture shows,when i use TArray Positions create the wave-shaped mesh,the collision body seems like a big cuboid.And when i create a mesh that middle part raised,the collision body seems like a Round table body。
I added fluid to see collision body shape.the red line draws the collision body shape i am looking for.

so the problem is,when i use l lot of point to create a complex collision body,it will be a convex hull instead of the mesh shape.
How should i solve it?
please help me!

The solution for you specifically would be to use the MeshCollisionSections not the convex as you’re right it will get turned into a convex hull. The Convex collision is required for moving bodies but for static objects like your ground there mesh collisions will give you the per triangle detail you need.

@wilberolive;693676

Since updating to 4.15 I’m getting an odd exception in PrimitiveSceneProxy.cpp. My C++ code is identical between my 4.14 and 4.15 projects. I compile and run both projects, the 4.14 version runs fine, but the 4.15 version triggers a breakpoint with an exception.

The exception occurs on line 599 of PrimitiveSceneProxy.cpp, which is an engine file. Here is the actual code from that file. Line 599 is at the ensureMsgf call.

This exception comes up when I try to create a runtime mesh section for the first time. I have a valid material assigned to the mesh section. If I close the breakpoint exception dialog in Visual Studio and click Continue, then it continues running as per normal and the runtime mesh works fine from that point forward, until I close and run again, then I hit it again. So every time I run my project, I hit the breakpoint, close the exception dialog, then click Continue to keep going. Any idea what might be causing this @?

I have that fixed in v3 but haven’t gone back to v2 to fix it. Is this still causing you problems?

@shunwang;693859

Hi ,

I’m Going To Build My Own Theme Park With Blackjack and Hookers (c), but I need your amazing plugin for that! With best colliders on mobile platforms/HTML5, with great skeletal mesh creation possibility, with a lot of other unbelieveable stuff Please keep this (membership in my Theme Park?) in mind next time when you open up your project!

(Hmm, almost 's style, it seems that I read his posts a lot

Anyway man, you are the best, please keep the work, I wish you a lot of energy and positive ideas!
Will wait for next version! cheers!

Thanks! I am still quietly working on it, just far slower than I’d like. Good luck on your project!

@;694355

Hey . In out project it can happen that really small actors are created, talking about 0.0001cm³. This causes issues, as it seems, with collision cooking for the RMC. The following error is dispatched.

PHYSX: (D:\Build++UE4+Release-4.15+PhysX_Compile\Sync\Engine\Source\ThirdParty\PhysX\PhysX_3.4\Source\PhysXCooking\src\mesh\TriangleMeshBuilder.cpp 1080) eINTERNAL_ERROR : cleaning the mesh failed

You now if this is something that could get fixed? Or a way for us to get a notification about that issue and provide a self made collision shape in that case?

That’s a PhysX error so I probably can’t do a whole lot about it. Why are you needing collision on something that small? You might be able to get around it by making the mesh larger and then scaling it down but something that small is likely to break other pieces of PhysX internally.

@shunwang;694622

Hey guys, anyone tried to raycast runtime mesh? My test collide by LineTraceSingleByChannel is only working on static meshes but not procedurally generated mesh, I try all the options of channels/responses but with no success…

@wilberolive already got most of this (and yes it really does work) but I wanted to add one other thing. You might have to set bTraceComplex to true on the raycast parameters if you’re raycasting against the mesh collision. I don’t remember offhand what the defaults are for a ray trace but a standard static RMC with mesh collision will for sure work as I do that daily.

@wilberolive;695001

If all you care about is knowing whether your runtime mesh has been hit or not, this will work fine. If however you want more detailed information depending on which face is hit, then you will need to store this additional information yourself in an array that you populate in the same order as you add triangles to the runtime mesh. Unfortunately, the runtime mesh component doesn’t have a facility to store a custom data blob on a per face basis… perhaps that could be a feature request, unless there is something I’m not aware of??? Very useful in situations where you are using a runtime mesh to render hundreds of batched objects for example and you want to know which object the player shot or clicked on for example. You could store an object index integer per face that can be retrieved from the hit face.

I assume what you’re talking about doing here is using the face index of a ray cast to index into your array of data? I hand’t really thought about adding any direct support for things like that to the RMC other than possibly being able to take a raycast face index and telling you the section and face index within section since that face index is based off a monolithic mesh created from all the sections of one RMC. I will likely do that part but storing actual data per face I’m not as sure about. What do you see that being used for?

@ryeguy;696028

For rendering cube-shaped voxels aligned to a grid (think minecraft), does RMC have a performance or feature benefit over instanced static meshes? I know this is a high level question, I just wanted to do a bit of research before deciding if it’s worth diving into this.

Wilber beat me to it but yes the RMC will usually far surpass the performance of ISMC/HISMC for things like block voxel. Be warned it is harder to work with. The common approach for things like Minecraft, as wilber said is to break the world into chunks (I believe MC is 16x16x256 but I could be wrong on that) within each chunk, you create one RMC, with one section per material you need and add all the blocks using that material to that same mesh section. To handle multiple textures, the usual approach is either an atlas, or texture arrays (the latter of which isn’t yet supported in the engine unless you count the Pull Request I’m assisting to bring support) That lets you have multiple different textures of blocks in the same material which is how you really get the performance benefit. ISMC/HISMC are based on hardware instancing which has some overhead in the vertex processing to instance the input mesh. The RMC doesn’t need that, so you can get more throughput in vertex processing, with the same few draw calls if setup correctly. The only downside to the RMC is it means far more memory usage for the mesh data as instead of one 36 point mesh (24 vertices, 36 indices) combined with an instancing list (basic transform information, with some added properties) it becomes the combined sum of all visible faces. The naieve way is to just add all the blocks to the mesh, this is the worst idea as it will create thousands of unseen faces due to adjacent blocks. The basic upgrade is to not add faces to the mesh that are up against an adjacent block. There’s ways to go further but I wouldn’t try them until you’re comfortable with building a full MC like system at this level.

[DavidNSilva]

@;696145

Surprisingly I guess I haven’t seen this myself even though I work with it daily. What specifically will cause it to get stuck?

Setting EUpdateFrequency to “Infrequent” will cause the outline to always get stuck 100% of the time. EUpdateFrequency::Average seems to solve the problem, but nonetheless on any updatefrequency there still remains the problem that the entire mesh get’s a fill effect and not an outline which causes the color of the mesh to change and makes it very hard to debug materials without deselecting it. As a workaround I added an #if WITH_EDITOR flag to my code to set the updatefrequency conditionally so it works on the editor and doesn’t affect the performance of the shipped game.

[wilberolive]

@;696145

I have that fixed in v3 but haven’t gone back to v2 to fix it. Is this still causing you problems?

Yep. I do most of my work in C++, so after every compile and run I hit this exception in PrimitiveSceneProxy.cpp. Any chance you could update the marketplace version with the fix?

[Koderz]

@DavidNSilva;696313

Setting EUpdateFrequency to “Infrequent” will cause the outline to always get stuck 100% of the time. EUpdateFrequency::Average seems to solve the problem, but nonetheless on any updatefrequency there still remains the problem that the entire mesh get’s a fill effect and not an outline which causes the color of the mesh to change and makes it very hard to debug materials without deselecting it. As a workaround I added an #if WITH_EDITOR flag to my code to set the updatefrequency conditionally so it works on the editor and doesn’t affect the performance of the shipped game.

Ok, well I’ll see if I can replicate that. I obviously see the fill effect but haven’t ever seen it get stuck.

@wilberolive;696351

Yep. I do most of my work in C++, so after every compile and run I hit this exception in PrimitiveSceneProxy.cpp. Any chance you could update the marketplace version with the fix?

I might if I get some time. The problem is I fixed that in the new RMC which is architecturally different and don’t remember what I had to do to fix that off hand.

[wilberolive]

@;696413

I might if I get some time. The problem is I fixed that in the new RMC which is architecturally different and don’t remember what I had to do to fix that off hand.

OK, fair enough. Is the new version stable enough to work with and is it a drop in replacement for 2.0 or has the public interface changed too? This bug is driving me to try anything at this point.

[Koderz]

@wilberolive;696438

OK, fair enough. Is the new version stable enough to work with and is it a drop in replacement for 2.0 or has the public interface changed too? This bug is driving me to try anything at this point.

I’m trying to remember what caused it, as I think if you did one specific thing without changes in the RMC it would shut up.

As for V3. the core is very stable, but it’s not feature complete,or technically even feature parity of v2. The public interface has changed, but if you only ever use the basics (create/update/clear) then it hasn’t changed a whole lot and there’s deprecated functions to ease the transition.If you accessed the sections directly, and some of the collision stuff has changed and there’s not a good way to wrap some of that. They’re all changes that would be easy to update for, but it’s still technically got breaking changes. My hope is to set in on v3 here in about 2 weeks (this week is ECGC and end of course exams and stuff so it’s super hectic) so it’s still likely 4 weeks out to a usable version that I’ll start sharing (that won’t be feature complete or the final version obviously but I’ll let people start testing it that want to)

I might be willing to share a subset of it earlier but that’s still likely 2 weeks.

[Rumbleball]

@;696145

Hey . In out project it can happen that really small actors are created, talking about 0.0001cm³. This causes issues, as it seems, with collision cooking for the RMC. The following error is dispatched.

PHYSX: (D:\Build++UE4+Release-4.15+PhysX_Compile\Sync\Engine\Source\ThirdParty\PhysX\PhysX_3.4\Source\PhysXCooking\src\mesh\TriangleMeshBuilder.cpp 1080) eINTERNAL_ERROR : cleaning the mesh failed

That’s a PhysX error so I probably can’t do a whole lot about it. Why are you needing collision on something that small? You might be able to get around it by making the mesh larger and then scaling it down but something that small is likely to break other pieces of PhysX internally.

Thanks. The player is able to create objects at runtime and able to scale itself as well the object that is created. Thus, objects can get pretty small. Well, will try to play with scaling.

EDIT: Was able to resolve it for now. Scaling the object down to the size of the player and calculating the relative meshdata of the RMC by Vertex/size. This ensures the object stays visually the same and is not rejected by PhysX cooking. Thanks . Keep up the great work.

[wilberolive]

@;696468

I might be willing to share a subset of it earlier but that’s still likely 2 weeks.

OK, I will wait and just press on with the bug as I have no idea how to fix it on my end. Thanks for working on RMC.

[Kobbersvard]

@;696145

@wilberolive already got most of this (and yes it really does work) but I wanted to add one other thing. You might have to set bTraceComplex to true on the raycast parameters if you’re raycasting against the mesh collision. I don’t remember offhand what the defaults are for a ray trace but a standard static RMC with mesh collision will for sure work as I do that daily.

Thanks for both of you, collision works almost out of the box - problem is (and thats why I thought its not working) that raycasting does not affect last generated mesh. It can collide with old mesh which was generated some time ago but fresh mesh is not colliding.

So question is - how can I get to know that collision is cooked so I can wait for it or maybe use whole render in the thread? I use this True parameter of CreateMeshSection because I need not convex collider. I creating tunnels and try to raycast from inside of each tunnel its sides to get points on it.

Thanks again guys!

[Koderz]

@wilberolive;697381

OK, I will wait and just press on with the bug as I have no idea how to fix it on my end. Thanks for working on RMC.

I seem to remember a way around it if you setup the materials/sections correctly but don’t remember what that was… Also could be thinking of something else.

@shunwang;697921

Thanks for both of you, collision works almost out of the box - problem is (and thats why I thought its not working) that raycasting does not affect last generated mesh. It can collide with old mesh which was generated some time ago but fresh mesh is not colliding.

So question is - how can I get to know that collision is cooked so I can wait for it or maybe use whole render in the thread? I use this True parameter of CreateMeshSection because I need not convex collider. I creating tunnels and try to raycast from inside of each tunnel its sides to get points on it.

Thanks again guys!

By default the collision is cooked at the start of the next frame. This alleviates the problem where you update multiple sections in the same frame where the PMC would cook for each call to Create/Update/Clear which made an already slow process far slower. If you need to ensure the latest mesh is available in the same frame after you update it, there is a function to force it to cook but I don’t remember what it was off hand. It would be something like UpdateCollision or CookCollision.

[anonymous_user_547b7549]

I have been using RMC and am loving it, THANKS A TON!

I have a question regarding collision cooking. In a previous post you stated that there would be the ability to cook collision data from another thread and send it to the RMC component to use as the collider.

My question is: Is this implemented? if so, where should I look to use this feature?

[Kobbersvard]

@;698491

By default the collision is cooked at the start of the next frame. This alleviates the problem where you update multiple sections in the same frame where the PMC would cook for each call to Create/Update/Clear which made an already slow process far slower. If you need to ensure the latest mesh is available in the same frame after you update it, there is a function to force it to cook but I don’t remember what it was off hand. It would be something like UpdateCollision or CookCollision.

It calls CookCollisionNow() and works perfect, thanks!

[Kobbersvard]

I have one more question and now its about lighting. I have a generated mesh which is one sided, normals are generated by:

CreateMeshSection(SectionIndex, Verts, Tris, true, EUpdateFrequency::Infrequent, ESectionUpdateFlags::CalculateNormalTangent);

But it looks like surface are filled by the light not as the closed tunnel, but like transparent roof of tunnel skip the light to the floor and its bright as just open surface. If I use this flat tube as double sided (poligons are inside and doubling for outside) its the same effect. But outer, normal objects, convex models are fine and shadows/lights there are correct. Please share your ideas whats wrong with my mesh

here is view from inside of tunnel

and this is from outside

[ioFlow_Studios]

Hi ,

Sorry to be a (predictable) pain in the ***, but do you know if you’ll get a chance to look at updating your plugin for the new 4.16 preview?

The new volumetric fog is such a breakthrough for my galaxy simulation (which is based on RMC) and I’m really looking forward to being able to try the two together…

If you haven’t seen what I’ve been doing with RMC lately, have a look at the end of my eden thread:

The Eden Project

[Rumbleball]

I’m trying to go with some of the helper classes on the runtime mesh but everything seems to fail. Can anyone help out?

Until now I was using

	void CreateMeshSection(int32 SectionIndex, const TArray<FVector>& Vertices, const TArray<int32>& Triangles, const TArray<FVector>& Normals,
		const TArray<FVector2D>& UV0, const TArray<FColor>& Colors, const TArray<FRuntimeMeshTangent>& Tangents, bool bCreateCollision = false,
		EUpdateFrequency UpdateFrequency = EUpdateFrequency::Average, ESectionUpdateFlags UpdateFlags = ESectionUpdateFlags::None);

to create my meshes. But the helper classes are there for some reason, make it abit easier, keep stuff where it belongs. Thought to give it a try.

Trying to use

	void CreateMeshSection(int32 SectionIndex, IRuntimeMeshVerticesBuilder& Vertices, FRuntimeMeshIndicesBuilder& Indices, bool bCreateCollision = false,
		EUpdateFrequency UpdateFrequency = EUpdateFrequency::Average, ESectionUpdateFlags UpdateFlags = ESectionUpdateFlags::None);

for the ‘IRuntimeMeshVerticesBuilder’ I’m trying to use ‘FRuntimeMeshComponentVerticesBuilder’.

#pragma once

#include "GameFramework/Actor.h"
#include "RuntimeMeshComponent.h"
#include "Vase.generated.h"


UCLASS()
class VASEGENERATOR_API AVase : public AActor
{
	GENERATED_BODY()

public:
	// Sets default values for this actor's properties
	AVase();
	~AVase();

protected:
	// Called when the game starts or when spawned
	virtual void BeginPlay() override;

public:
	// Called every frame
	virtual void Tick(float DeltaTime) override;

private:

	UPROPERTY()
		URuntimeMeshComponent* vaseRuntimeMesh;
	FRuntimeMeshComponentVerticesBuilder verticesBuilder; // fails cause there is no default contructor
	FRuntimeMeshIndicesBuilder triangles;

	// The outline of the vase when looking from the side
	TArray<FVector> outlineVertical;

	// The outline of the vase when looking down from the top
	TArray<FVector> outlineHorizontal;

};

So trying to construct that ‘verticesBuilder’

//The constructor im trying to use
//FRuntimeMeshComponentVerticesBuilder(bool bInWantsNormal, bool bInWantsTangent, bool bInWantsColor, bool bInWantsUV0, bool bInWantsUV1)
FRuntimeMeshComponentVerticesBuilder verticesBuilder(true, false, false, false, false) //fails with: error C2059: syntax error: 'constant'

another try

Vase() : verticesBuilder(true, false, false, false, false) {}
FRuntimeMeshComponentVerticesBuilder verticesBuilder; //fails telling me there is no default constructor

well, trying pointer

Vase()
{

}
FRuntimeMeshComponentVerticesBuilder* verticesBuilder;

Compiles fine. Able to open the project.

Vase()
{
    verticesBuilder = new FRuntimeMeshComponentVerticesBuilder(true, false, false, false, false);
}
FRuntimeMeshComponentVerticesBuilder* verticesBuilder;

this compiles, but crashes the project… “The game module could not be loaded. There may be an operating system error or the module may not be properly setup”.

returning back to

Vase()
{

}
FRuntimeMeshComponentVerticesBuilder* verticesBuilder;

I again can compile and open the project. What am I doing wrong?

verticesBuilder = new FRuntimeMeshComponentVerticesBuilder(true, false, false, false, false); // whats the issue?

‘FRuntimeMeshComponentVerticesBuilder’ is not of UClass type.