I’ve been struggling and have found that physics fields don’t act reliably and consistently on Geometry Collections.
This is making it impossible to create an environment that reacts to forces predictably.
Below I have used the engine’s own master field (FS_MasterField) and Anchor Field (FS_AnchorField_Generic) to demonstrate the issue. The structures are my own from Blender, however the cylinder on the left I generated in Unreal Editor.
Left: The cylinder breaks about the location of the field. Centre Left: The wall ignores the stress field. Centre Right: The turret has a ring that falls off but otherwise ignores the stress field. Right: The tower disintegrates completely except within the anchor field.
The cylinder is the only Geometry collection to respond properly and logically to the physics field.
The other structures have their own responses that don’t make any sense.
Damage settings are default for all Geomtery Collections (except for Damage Propagation: 0.001). All physics fields use the Engine’s default settings with added delay (15s). All actors were created in, and imported from Blender using the same method.
Subsequent testing has revealed that the wall (possibly the turret body) is genuinely impervious to the Master Field despite having been treated the same.
Setting damage threshold to a value of 1 still did not result in destruction:
So I looked into collision and there was something wrong with it. Importing even simple shapes from blender seems to result in very odd hitbox behaviour.
In all instances Falloff Type is set to “None”, so in theory the entire field should be at generating a stress of 9,999,999,999. The max damage threshold of the Geometry Collections is 500,000 so it should be eviscerated.
I first removed the hitbox and then changed Collision Complexity to “Use Simple As Complex”. This had some positive results.
Im not sure what is implied mathematically by the field around and the oeigin of the pulse.
Meaning the strenght at the origin has to be the maximum, but as you move around the sphere the values likely disintegrate to 0.
In this case, the force being applied to an item wouldn’t necessarily be enough to break it apart depending on settings.
If the item breaks once the origin hits the collision, then something along those lines is going on.
Well, a cilinder is a valid collision shape.
If the inside is hollow, then you need multiple convex hulls or boxes to create the collision geometry (could be the case for the castle tower).
Use primitives when you can. Use the engine if you are in a pinch, it can generate its own collisions for Solids.
Failing both, make geometry as simple as you can, broken up on several parts, name it correctly, and try to import it along (tick import collision, or remove generate collision).
Ps:
Turn on collision view. Its a command line control. Actually there are several. One is PhysX driven which may now be wholly irrelevant. Surely, they went and hid some of those for chaos similarly as to how the physx did it.
Seeing that the geometry collection has been given the right collision is a good start towards knowing that isn’t the issue.
[Note: I think this might be the point you were making above, but I have failed somehow to prevent overlap, despite using “Simple as Complex” and trying to move the vertices of the meshes so they don’t overlap. I have also triewd using the actual mesh as the hitbox without success.]
The issue is not with the meshes but their proximity to one another.
It seems Geometry Collections cannot be near one another. This is true even if the vertices have been separated so that they don’t overlap i.e. even when the models are separated and hitboxes do not share space .
If you have multiple meshes and drag them out of the content draw together, so they enter the viewport world correctly arranged, they then do not work as destructible geometry collections .
A single mesh, extracted alone from the content draw, functions as expected.
I cannot find a way to view GeoCollection collsions.
I’m not expecting you, MostHost_LA, to solve this for me I’m just keeping the thread alive in case I find a solution and someone else runs into the same problem.
Question.
Do multiple meshes just require more force, or not break at all?
If it takes 2x the force for 2 meshes in proximity, then it would seem like a bug that needs reporting… however test this with engine stock objects just to make sure and to provide paths that support can replicate without having your model(s)…
The multiple meshes would not break whatsoever, and I am fairly convinced that destruction is deeply bugged.
I improved the situation by doing the following:
A). Remove simple collision and use complex on each mesh before creating a geo collection (I’m not even sure if this does much but it’s what I have been doing).
B). Create a geo collection for each mesh on its own. You cannot select multiple meshes and crate a parent Geometry Collection with the two meshes inside of it.
You probably should be able to, but doing so resulted in collections blowing up or not being interactable (maybe see if this is the case for you).
C). Give all neighbouring geo collections the same Cluster Group Index.
The above steps will work for some collections. I have found for some, that it does not. It will even work in one project and not in another with the same mesh.
Deleting the various geometry collections that make up a structure will reveal it is one or two collections that cause everything to explode, despite having the same settings. In my case for example, I have a ring on the turret that regularly causes issues, though sometimes works in test files.
I do not yet understand how anyone is using this engine to create destructible environments beyond crates or tables.
Edit: The random events were due to a malfunctioning anchor field. Try replacing it EVEN IF all the settings are correct and it was working before hand. Mine was not behaving correctly.
I am guessing the wider community has no idea what Unreal is doing because there isn’t a video out there showing someone making a complex structure that can be partially damaged.
I doubt anyone working on AAA quality project would even think about leaving something as important as destruction of things up to the engine.
We have always made our own system/our own assets. And the swap system that goes from one static mesh the the broken collection.
I suggest you do the same while you wait for someone to chime in - if they ever do.
Yeah I was really referring to the smaller individuals like myself, AAA game makers are likely very busy and I don’t expect them to give away their time and knowledge for free in the form of long tutorials.
I found out that an anchor field - despite being identical to other functional anchor fields - was bugged. So I replaced the anchor field and the explosions stopped . I will never understand why.
So step D) if you have random physics events like explosions or flying objects after steps A through C, try changing the anchor field even if it was working previously and hasn’t been changed.
Adding my 2c here to say that I also experience deeply bizarre and unexplainable issues with destruction fields. There really seems to be something intrinsically wrong deep inside this system which is causing issues.
.
.
.