How to create collision information for procedural geometry?

Development Programming & Scripting C++
1

When generating custom geometry at runtime, it is possible to render by deriving from UPrimitiveComponent and using FPrimitiveSceneProxy, FVertexBuffer, FIndexBuffer, etc.

I wanted to know if it is also possible to enable collision detection for procedural geometry?

It seems like this should be possible by implementing the UBodySetup * GetBodySetup() method, but it is not clear to me how to set up a UBodySetup object. The AggGeom, CookedFormatData, TriMesh, and TriMeshNegX fields all seem related, and the only clear setup method, CreateFromModel(…), appears to be editor only, and thus inappropriate for use at runtime.

Any help or insight into how to approach this problem would be appreciated.

1 Like
2

I am interested in this as well, I look forward to an Epic response!

:slight_smile:

1 Like
3

I’ll add my name to the interested list :slight_smile:

4

Hi sgorsten,

You are on the right track. As long as you can define your collision using an aggregate of simple shapes (spheres, boxes, capsules, and convex hulls) then you can define it at runtime. The algorithmic fitting stuff is not available at runtime however.

Something like UPaperSprite::RebuildCollisionData() is a reasonable starting point to see how you would build the data out. In this case UPaperSprite is the asset, and UPaperRenderComponent implements GetBodySetup to return it from the currently active asset. If you don’t have an asset you can still create one on the instance or wherever else makes sense for your use case.

Cheers,
Michael Noland

5

Thank you for your response, Michael. Unfortunately, the geometry I am hoping to use comes from applying marching cubes to a signed distance volume which is modified at runtime, which I think would be very very difficult to approximate with simple shapes. I really am hoping to be able to use a triangle mesh to capture the polygon-soup nature of my geometry. I don’t need to re-mesh every frame, and due to the nature of marching cubes can easily break my geometry down into individual chunks which could be re-meshed on demand.

It looks like the most important function for generating PxTriangleMesh instances is FDerivedDataPhysXCooker::BuildTriMesh(…), a private method on an editor-only class. I decided to try to replicate the behavior of this method. I’ve found that if I call GetTargetPlatformManager()->FindPhysXFormat(“PhysXPC”) (or use FPlatformProperties::GetPhysicsFormat()), that I am able to get a pointer to an IPhysXFormat instance, which provides access to CookTriMesh(…) (and also CookConvex(…)). I copied the body of the FDerivedDataPhysXCooker::Build(…) method and modified it to manually cook triangle meshes from my procedural mesh information, and placed the result into the CookedFormatData field of my UBodySetup instance. I found that if I do this, set the UBodySetup::bHasCookedCollisionData field to true, and call UBodySetup::CreatePhysicsMeshes(), the TriMesh and TriMeshNegX fields become populated with valid pointers. Unfortunately, objects in my world do not seem to be colliding with my procedural meshes.

Does anyone have any tips as to where I should look to figure out how to convince the Unreal Engine to “refresh” the physics or collision information of my objects once I have updated my UBodySetup? When I look at the bodies of functions like SetActorEnableCollision(…), there seems to be some additional work needed to tell the engine that the collision geometry of the actor has changed, but I’m having difficulty navigating all the myriad flags and states involved in setting this up.

As before, a preemptive thank you to anyone who can provide any information.

6

Have a look at UModelComponent, that should be a good model to follow. You want to implement IInterface_CollisionDataProvider and the GetPhysicsTriMeshData, ContainsPhysicsTriMeshData and WantsNegXTriMesh functions. Then you add your own UBodySetup pointer to the component class, and create when needed. Make sure when you allocate the BodySetup that you set its Outer to be your new Component class. The BodySetup will see if its Outer implements that interface when creating collision geometry.

Edit: I’m not quite sure from your post if this affects what you are trying to do, but I’m afraid we do not support cooking collision geometry at runtime.

7

It is absolutely necessary for our project that we cook collision geometry at runtime. Neither our triangle meshes nor the data we use to generate them will be available prior to runtime. Is there any way at all to circumvent this restriction? Would it be possible to link directly against the PhysX 3.3 libraries, instantiate a PxCooking object ourselves, and produce the necessary PxTriangleMesh objects? Or is there some appropriate location we could hook into Unreal’s physics code to manually perform collision detection between AActor objects and our runtime triangle meshes?

I am loathe to point it out, but the Unity engine does allow for the creation of Mesh objects at runtime, with arbitrary geometry, which can then be passed both to MeshRenderer and MeshCollision components. Unity is clunky, has wildly unpredictable performance, and severely constrains our artists relative to UnrealEngine’s more sophisticated toolset, but in the past we have had no real choice because of our hard runtime mesh generation constraint. I am hoping that with UE4’s direct C++ access that we can figure out how to get this up and running, so that we can migrate our team away from Unity permanently. I am willing to do arbitrarily large amounts of work to get this working, so please let me know if there is any path that you see which is feasible.

8

I don’t think JamesG was suggesting that you cant add collision, as he then goes on to explain how to do.

I think he just meant that you cant create the mesh, and then save the collision as a cooked asset for the engine to load in the future in a packaged game context.

You absolutely can create the collision at runtime, as you are wanting to do!

But you will have to create this collision at runtime every time the game is loaded,

as opposed to saving pre-calculated collision geometry to hard disk.

It is not a big restriction, given that the collision primitives are quite low level.

You could easily create all your custom collision when the game is first loading :slight_smile:

I have a tutorial on how to save/load any data you want from binary file

you can of course save all of your specifications for custom collision to file, and then just load and process that file.

So it will effectively be the same as having cooked collsion minus the runtime CPU cost at the time the game is first loaded and all the collision files are processed.

You are going to have such a load cycle anyways, for your runtime generated meshes :slight_smile:

See my signature for the Binary Save tutorial

Enjoy!

PS: the reason for this cooked restriction I imagine is because that would involve Unreal Editor code, (not just the Runtime) which we are not allowed to reuse in our games as per the legal licensing agreement.

If you did, you’d only be able to share the resulting product with other licensees

so it is a legal issue, not an engine capacity issue.

9

I should clarify somewhat for context.

Our use case is that we have a volumetric representation of our world’s solid geometry which is modified at runtime by the user’s actions, and therefore will not be known in advance in any form. This representation is stored as a three dimensional grid of signed distance values from an implicitly defined isosurface, and events which occur at runtime mutate this grid of values.

For visualization purposes, we triangulate our grid using a standard implementation of Marching Cubes, similar to what is described on http://.net/geometry/polygonise/, and this resulting triangle mesh is loaded into UnrealEngine vertex and index buffers and rendered normally using a scene proxy object.

However, our use case requires us to also have in-game objects and characters interacting with and navigating over this geometry. Given the underlying representation, an aggregation of simple primitives will not work, but a PxTriangleMesh should have no problems, and could be built from the same triangulation we are using for visualization, or perhaps a lower resolution triangulation. It looks like the only way to instantiate a PxTriangleMesh object in the PhysX SDK is to bake a binary representation using an instance of the PxCooking class, and then load the PxTriangleMesh from that binary representation. This cooking functionality seems to be packaged into a separate set of libraries (See ThirdParty/PhysX/PhysX-3.3/lib/Win**/VS2013/PhysXCooking**.lib) from the core PhysX runtime.

If PhysXCooking**.lib is linked into the UE4 runtime, then it should be possible to build a mesh at runtime. If it isn’t, I was hoping that it might be possible to manually link against PhysXCooking**.lib separately, strictly for the ultimate purpose of being able to generate new PxTriangleMesh objects at runtime. I don’t actually need to serialize or deserialize any UE4 assets or objects once these meshes are created, I just need to be able to create them and use them for collision detection at runtime.

10

Do you have a video of this awesomeness you are describing in action?! It sounds amazing :slight_smile:

**I am hoping Epic can reply to you on this matter, **

I would really like to know the answer to this as well, as I would love to generate my own PxTriangleMesh from a dynamic mesh!

11

I have reimplemented the CustomMeshComponent example class (renamed GeneratedMeshComponent) and integrated the elements you mention. However, the generated mesh still does not provide collisions. Maybe I am doing something wrong. For example, since it is a generated mesh, every time I set the triangles, I regenerate the UBody (instead of checking if it is NULL). I do not do it in PostLoad. I did SetActorEnableCollision(true) in the parent actor.

Here is the code: http://www.base64.com/GeneratedMeshComponent.7z

Can you look at it and tell me if I am missing something?

12

I’m interested in this as well for real-time mesh deformation. I also come from Unity where collision mesh generation is easy but a performance bottle-neck. I’m hoping to find more control over collision mesh generation in Unreal.

Here is my related question on the on answer-hub:

13

With the source you can do anything :slight_smile: We only recently made the change to stop linking the cooking libraries in on platforms that use cooked content, though currently if a platform uses APEX is still requires the cooking library, so this only affects mobile right now. Basically we don’t currently plan to support this as we think the runtime cost will be too high, and want to save the executable size by not including the cooking code. But it really shouldn’t be too hard (as you point out) to enable it yourself if that is a requirement for your project!

14

James,

As you saying that the modified CustomMeshComponent code I have posted cannot work without cooked content? If it can what am I missing?

15

I’m trying to get to your point to try out a few things, but I’m getting unresolved externals trying to derive UBodySetup. Which module did you include?

16

Under the covers, the engine does the PhysX cooking work when required. So your code may well work, but I have not tried it! We are making a change to disallow physics cooking on platforms that require cooked content, but this should be a fairly easy change to work around if your project requires it.

17

Any reason for this design decision? It just makes it harder to manage procedural meshes. Unity has this functionality out of the box, see this.

I implore you to allow cooking at runtime in a more easy fashion than this roundabout way. At least provide an optional module that we can link to allowing cooking.

I have started a Feedback thread on the subject, as I am disappointed in the direction you are taking.

EDIT: James as responded in the Feedback Thread on this subject, and it is good news.

18

@ IInterface_CollisionDataProvider/ GetPhysicsTriMeshData works with runtime collision data (triangle mesh from procedural terrain).

You can starts with the code from UShapeComponent/UBoxComponent, with the relevant changes as below:



void UVoxelTerrainCollisionComponent::UpdateBodySetup()
{
	if (ShapeBodySetup == NULL)
	{
		ShapeBodySetup = ConstructObject<UBodySetup>(UBodySetup::StaticClass(), this);
		ShapeBodySetup->CollisionTraceFlag = CTF_UseComplexAsSimple;
		ShapeBodySetup->bMeshCollideAll = true;
	}
}
// Called after the triangle mesh has been set to the component
void UVoxelTerrainCollisionComponent::UpdateCollision()
{
	if (bPhysicsStateCreated)
	{
		DestroyPhysicsState();
		UpdateBodySetup();
		CreatePhysicsState();

		ShapeBodySetup->InvalidatePhysicsData();
		ShapeBodySetup->CreatePhysicsMeshes();
	}
}

Not sure if it is necessary, but I also have:



	Mobility = EComponentMobility::Static;
19

It works! Well, I need to fiddle a bit due to logic issues, but I have collisions! I will clean up my class and update the procedural mesh generation example on the wiki, since it’s the same class.

Thanks muchly :smiley:

20

Note that this will probably not work in non-editor builds yet, because of the issues outlined in the other thread!