Why does allowing collisions stop AddForce from working?

I have a pawn, BP_Fighter, with a skeletal mesh, to which I’m adding forces and torques to maneuver, and which doesn’t collide with anything. If I enable physics collision in mesh component’s collision settings, it will no longer move. For some reason, collision on = physics disabled. This doesn’t make any sense!

These are settings I had been using whilst attempting to do collisions:

Changing ‘Collision Enabled’ under collision settings to ‘No Collision’ allows ship to move. Why is this case? PhysX can obviously handle collisions and forces on physical objects all at once, so what’s deal?

Thanks.

Hey ,

I haven’t been able to reproduce this issue. Could you show me your BP_Fighter’s EventGraph so I can see what method you’re using for movement? Thanks!

Hey ,

Here’s a picture with my event-driven movement (with a debug tooltip to prove that I am in fact applying a real force). With old collision settings, fighter moves, but with settings in following album, AddForce no longer functions, and ship refuses to move.

When you have your Mesh set to Physics Actor, with Object Type set to PhysicsBody, does this same behavior persist?

I have done following in MeshComponent’s Collision settings, in BP_Fighter blueprint:


AddForce continues to have no effect.

Hey ,

I have still not been able to reproduce issue. You say adding force to your character only stops working when you give character collision, but it works fine before adding and after removing collision? Does this happen if you swap your skeletal mesh out for another mesh? Does it happen if you try same setup in a different project? Or in a new Blueprint with same setup but a different mesh?

If you’d like to link me to a place to download a test asset that this occurs in, I’d be happy to take a look. It looks like you’re using a custom parent class for your ship. Is this a C++ project or a Blueprints project?

Hey ,

You are correct, except it is a Pawn, not a Character (after all, it seemed Characters were for bipedal movement, not spaceships :slight_smile: ).

I’ve uploaded my barebones 4.2.1 project, with a basic AddForce node called when pressing W. BP_FighterNoCode uses my original mesh, and BP_FighterNewer uses a half-scale mesh with a different setup (in terms of where root node lies and all - check out mesh files), but both result in this issue.

To reproduce - go to defaults tab of BP_FighterNoCode or BP_FighterNewer blueprints, and change collision settings to have enabled collisions. fighter will no longer move on a press of W key.

https://.com/file/d/0B6wtQNL4MWucUVpZV2JGdGZFUWM/edit?usp=sharing

Let me know if above doesn’t work - if project won’t run (I didn’t include some generated files due to size), just strip out and view assets separately :slight_smile:

Thanks!

Okay, I see issue now. Unfortunately I don’t know what’s causing this behavior. It looks like Add Force just doesn’t want to work when component has collision on it. I’ll have to check in with developers to see if something isn’t working correctly or if there’s something we’re missing. I will let you know as soon as I can whether this is a bug or not, probably sometime Monday.

Thanks for providing test project!

Hey ,

Okay, looks like problem is in fact some under–hood physics calculations going on. Once collision is enabled, mass of your ship comes into play and you need a LOT more force to move ship. If you play now with collision enabled and hold down W, you can actually see it move very very slightly. If you go into your XAxis Event for your Ship and increase Val multiplier from 5000 to 5000000, your ship will move very easily.

That’s an insane amount of force, though.

A better option would be to give each physics body in your ship’s PhysicsAsset a Simple Collision Physical Material. Create a new Physical Material and lower Raise Mass to Power value to 0.1. Then in your SK_dummyFighter01_halfScale_PhysicsAsset, select root bone (bn_root) and use your new Physical Material in Simple Collision Physical Material spot. Save all that, and now you should see your ship move without having to jack up force that much.

Hope that helps. Let me know if it doesn’t work!

Hey ,

So you’re correct in that adding a massive amount of force does make ship move in its default setup (with collisions enabled), and changing Raise Mass To Power value to 0.1 does drop ship’s mass, and required force, by quite a lot.

However, ship will not react to AddTorque - it used to be fine with values between 0 and 10, but with collisions enabled, and even with your latter suggestion, torque values of 5000 will only slightly rotate ship (at almost 1/4 of rotation speed we used to achieve with a value of 5).

Additionally, I have to question why this workaround is necessary - old mass was 1,500kg, and we needed 5,000,000 Newtons of force to move it in a usable fashion. Something’s going wrong here - I was under impression that PhysX used SI units (kg, Newtons, and so on), and realistic equations. If that were case, consider this - an 18,000kg F-14 requires only ~247,000 Newtons of force to achieve its high velocities, whilst also working against air friction and like, but we need >5,000,000 N for 1,500 kg in space.

There must be something else happening under hood. Are kg values for mass in UE4 editor not actually being used as PhysX kg?

Thanks.

EDIT: Just did some bullet testing - bullets with basic sphere colliders (radius 20, mass 13 kg) hitting ship without Mass To Power changes (i.e. ship is 1,500 kg) at a velocity of 75000 units/s (750 m/s), should impart only 9750 Newtons on impact, yet they throw ship way more than AddForce with millions of Newtons ever did (it reacts at several hundred m/s).

Sorry to throw all this data at you - it just seems off.

Hi ,

Our units for force are actually kg cm / s^2 so this means that in case of an f-14 you’d actually need 24,700,000 units of force.

reason for this is that rest of engine uses cm as a unit of distance. This comes into play for torque as well.

Hope that helps, let me know if you have any more questions about this.