Managing Geometry Collections with Chaos Physics: Field Responses and Controlled Destruction

Development Asset Creation
, ,
1

Hello!

We’re currently working with GeometryCollections and Chaos Fields/Chaos Destruction in order to have various destructible objects.

One thing we’re trying to avoid is mesh swapping. As a result, we need to have a way to keep geometry collections in tact from a damage/strain perspective in some contexts, but allow them to freely shatter in others.

For example, we have an object that needs to act as a pushable physics object, but only have it shatter in response to some field systems (Ex: Object creates a strain and force field to destroy itself and create an impulse on surrounding objects. But the strain needs to only affect specific object types while still allowing other surrounding physics bits be affected).

I’ve looked in to the field meta data and object filtering. But I’m a little confused with how it works. EFieldObjectType seems to define what each field affectable object is, but I can’t seem to find where you set what this is for individual objects.

Is there a way to dynamically change an object type for geometry collections and other physics capable actors/components at runtime? I saw [Content removed] which talks about how we can potentially add collision channel filtering. But not sure if this is something that is intended to be done with Chaos destruction/physics.

I’ve also looked at the EFieldPhysicsType::Field_CollisionGroup for transient physics fields. And I don’t quite understand how this is meant to be used and what field node you should provide the transient field when using this physics type.

Can you explain a little how this works and what the intent around using it is?

To accomplish what I described at the beginning of the post, we’re currently trying two techniques:

  1. Cache the damage thresholds and swap them out with stronger ones so the object can remain in tact, but then when we want to destroy, swap in the lower damage thresholds. That way the object breaks when we want it to in response to a self spawned physics field.
  2. Create an invisible cluster on top of the existing leafs in the geometry collection. And then set the first threshold to be really high, and then manually shatter that cluster.

However, there seems to be some workflow issues with doing it this way. Additionally, visualizing what each clusters damage value is does not seem to work and they just display as 0.0.

Apologies as this is a bit of multi tiered question. But we’re trying to see how far we can push the utilization of Chaos. And wanted to get your thoughts on it, as well as clear up some of the less documented portions of Chaos.

Appreciate any advice/info you have on the matter!

Kind Regards,

Darien

2

Hello [mention removed]​

Thank you for reaching out.

I know you have done a few questions, but I wanted to address this one:

Is there a way to dynamically change an object type for geometry collections and other physics capable actors/components at runtime?

Have you tried calling Set Object Type on the Geometry Collection Component, like so:

[Image Removed]You would need to expose the component call to RecreatePhysicsState() to Blueprints. I’ve used a BPFL in the example:

[Image Removed]You can also try to swap the CollisionObjetType using gameplay events:

[Image Removed]That might also require calling RecreatePhysicsState() after every change.

I’ll check those other questions as well, but I wanted to give you this quick reply to help unblock you.

Let me know if this is helpful.

All the best,

[mention removed]​

3

Hello again!

I’ve thought of another question and it relates to the field system plugin. All resources seem to point to using this in tandem with Chaos Destruction. The tutorials say to use the field actors provided by Epic in the content examples.

However, after taking a look at it, I have some concerns for the use of these at runtime. They’re BP heavy and rely on spawning components at runtime. Even if they were to be nativized, they still have a pretty heavy overhead. I’m wondering if it’s worth using these fields at runtime to spawn for example explosions, applying strain/force on bullets/projectiles, etc.

Is this currently a system that is being used at runtime on any of Epics projects? (It seems in the Valley of the Ancients examples, all the fields are utilized to create cached simulations. Rather than spawning them at runtime.). I have noticed that in the GeometryCollectionComponent, there is a MakeRadialField function, which seems like the better way of constructing fields on the fly without needing the actor/component overhead.

Kind regards,

Darien

4

Hello Rafael!

I appreciate the response. Recreating the physics state is a good shout. I don’t think I was clear with that portion of the question. I meant is it possible to change an objects EFieldObjectType at runtime. I believe the method you posted just changes EObjectStateTypeEnum which can be achieved using fields as well.

5

Hello [mention removed]​

I agree with you. The FS_MasterField is a huge Blueprint, as are all the others provided along with the engine.

I’ve always considered them as examples, prototyping aids, rather than something to be shipped in a finalized project.

I’ll ask Epic if they are used for internal projects, but I would be surprised if they are.

MakeRadialField looks interesting, indeed.

Have you profiled the usage of the standard actor/component spawning of fields?

Let me know if it’s a measured issue or an educated guess that this will eventually become a problem.

All the best,

[mention removed]​

6

Hello [mention removed]​

I’ve done a little profiling and I’ve been able to confirm a few things. I confirmed that spawning these master fields are not at all performant. Ideally, these can be pooled, nativized, and trimmed. I confirmed that spawning the fields separately by building and dispatching your own field commands yielded a result of < 0.1ms, while spawning 2 master fields that handle the same thing took 4ms. Granted, this is also because of the time it takes to spawn, but mostly laying it out this way as Epic really pushes their raw use as is.

In terms of memory usage, I will need to take a deeper look at it, as I believe I’m not tracking the spawned actors correctly when comparing. But technically, we don’t have the overall memory added of the components/actors, just the memory allocated from dispatching the field command which happens for the master field as well.

7

Hello [mention removed]​

Indeed, you are right; that method was changing EObjectStateTypeEnum.

I’ve checked the source code and could not find a method to set the EFieldObjectType.

I found no way to set the CollisionGroup using a Field.

Extending the engine, the strategy described in [the case you [Content removed] might be the only way to achieve this.

But if I understood your objective correctly, you might be able to reach something similar through other means.

For instance, if you structure your Geometry Collection (GC) levels conscientiously, and manipulate variables that are tied to the level, like Damage Threshold, Collision Profile Per Level, One Way Interaction/Level, Max Cluster/Simulated Level, you will be able to change who can collapse a GC, who it will collide with and at what level, and control the behavior.

Have you considered this approach?

Also, testing CollisionGroup, it looks like only GCs utilize it.

It might be a bit limiting if you want your GCs to interact with Static Meshes, since it only works when GCs collide with other GCs.

All the best,

[mention removed]​

8

Hello [mention removed]​

I’ve asked Epic, and the answer was pretty much the same as I’ve told you: it’s highly doubtful that they would use such a heavy BP in any internal project; their purpose is more educational and for quick prototyping.

Thanks for profiling and confirming.

All the best,

[mention removed]​

9

[mention removed]​

Hey Rafael,

Thank you for your reply!

We considered those as options for us but I was looking in to options that give us more control from a gameplay perspective rather than from a setup perspective. As we will have a lot of variable object destruction, some are small, highly mobile objects, while some are structured. We’re trying to utilize fields as well as oppose to calling impulse/velocity functions directly on primitive components. Is it recommended to utilize fields to this degree? (Even though in some parts of the code, at least for GCs, we dispatch a field command to do this anyway).

On the topic of fields, I looked in to meta data filters and they worked to a degree. However, they’re currently quite limiting. Do you know if there’s a roadmap/planned work for the physics field system? For example, we can only have 1 meta data filter per field. Are there plans to potentially extend this?

Apologies for the overload of questions, just trying to gather as much info as I can.

Kind regards,

Darien

10

Hello [mention removed]​

No worries!

Your doubts are all legitimate and show that Documentation is currently lacking.

Anyone using Fields and GCs deeply will face the same hurdles as you did.

I wouldn’t be surprised to see a talk or updated documentation motivated by this discussion.

Regarding the roadmap, I’m not privy to the roadmap.

There is a roadmap site, but I haven’t seen any mention of changes to the Field Systems.

This information is mostly internal to the dev team, but if you like, I can escalate the case to Epic, and you can get answers directly.

I can ask, but the round trip usually takes longer.

Let me know.

All the best,

[mention removed]​

11

[mention removed]​

Hello Raf!

Awesome! I really appreciate the support.

About raising this directly with Epic, I’ll talk with my team first just so I don’t jump the gun on this. And I’ll get back to you with a decision on if we want to raise this directly and work with them 1 on 1 to iron out these concerns.

Appreciate the continued support!

Kind regards,

Darien

12

Hello [mention removed]​

Thank you for marking my answer as Best.

I’ll take it as you want me to escalate the case so Epic can answer about the roadmap.

I hope I was able to help you.

It was a pleasure working with you.

All the best,

[mention removed]​

13

Hello [mention removed]​

You replied, and the website did not update, so I missed it…

I replied and escalated it without seeing your response.

Sorry about that.

But escalating is of no consequence; someone from Epic will respond to you directly.

You can continue the conversation or request that the case be closed.

All the best,

[mention removed]​