To replicate “Spooky Action at a Distance” in 4.8 - start with a fresh Third Person Template BP project.
Drag in a basic cube and put this in the center of the floor. Size to about .5m square. Turn on physics and add 2.0 of damping (both fields). Preview the game and make sure you can push the cube around with the character.
Then select the character collision capsule and enable Use CCD. Now play the game and walk the character in a square (both directions) around the new cube at various distances from the cube. Something extra virtual and hidden seems to be protruding from the sides of the character and will occasionally catch the cube and drag it along with the capsule even from several meters away. There is a narrow range of angles (cube face / axis vs character orientation during the pass) that will work - so circumnavigating the cube should do the trick.
I’m attempting to use CCD to get better Hit Event generation (on the character) when the character hits and pushes a small physics actor. I find that the character can push a cube or sphere for long distances and never generate a HIT. If the physics actor is already in motion or has gravity disabled the HITs at the character are slightly more reliable. If the physics actor is pinned between a static object and the character then the HITs seem to be nearly perfect. In other words, the character can push the cube across the floor with no HIT generated - until the cube stops up against a wall. All these collision attempts are generated at very low character speeds and fps of 60–90.
The character mesh will do an excellent job of pushing the physics actor even with limbs that extend beyond the collision capsule - but HIT events are not being generated. Often it seems like the physics actor is not awake (I have start awake on and ‘always create physics state’ on) for notification purposes and doesn’t stay awake for long after a significant collision that does start the HIT notifications.
For the two issues that you’re reporting here are my findings:
CCD on Capsule Component:
I was able to reproduce this and have submitted UE-18952 for this to be assessed by the engineers. I will post an update here with any relevant information I have.
Hit Event
I set this up in two simple ways, but was not able to see the issue you’ve described.
The first way I set this up was using my character BP event graph and using the Event “OnComponentHit”. I pulled off the “Hit” pin to get a “Break Hit Result”. I then pulled off the “Hit Actor” pin to print string so I could see what’s going on in the game.
Running around and hitting static meshes and simulated meshes didn’t result in any issues for that I could see.
For the second way, I did the exact same test, except that I setup a BP with my simulated object and had it print string when it was hit. I tried this with static and simulated objects and got the same results working as I would expect.
If you have any thoughts on that please let me know.
Great news on the tractor beam. For the Hit Event:
I’m using the Event Hit node on the character bp.
. Not sure where to find OnComponentHit Event node as it won’t come up even with ‘context sensitive’ turned off. I’m probably sounding like a noob by now but I’ve put together a [sample project][2].
This is based on the third person template from 4.8. Three movable actors have been placed in the arena for you to push around. The character capsule has been reduced in size to make it easier for you to achieve collisions between the character mesh and the environment without getting the capsule involved. The simplest test is to walk around and do a head plant into the floating cube (top half of character extends beyond capsule).
It should be easy to push the objects around without getting the impacted actor’s name printed to the screen.
Perhaps the mesh hit events aren’t making it to the character container or I’m missing something important.
For the OnComponentHit Event node you can locate this and other event nodes by selecting the capsule component in the components tab (top left) of your BP. Then in the details panel on the right you can scroll to the very bottom where you can find these with a Green + that will add them to the Event Graph.
Looking at your project, the capsule component is not meant to be scaled like this for a larger mesh. This component is there to be simple collision for our mesh. It’s not feasible to use to the entire mesh of the character for collision as this can get expensive for performance. Traces would typically be used to determine collision for the character mesh. Also, the character has very basic collision setup within it’s Physics Asset. You can see these collision setup by opening the SK_Mannequin_PhysicsAsset or using the console command PXVIS Collision while in game to view collision hulls. The reason the even is not being generated is because the Physics Asset collision for the character is blocking the capsule from hitting to generate the event.
However, to simply fix the issue you can open the Physics Asset and select all the collision hulls for the character that need to generate the hit event. You can select these hulls and in the details panel on the right you’ll see the option for “Simulation Generates Hit Events.” Simply check the box and this will now generate a hit event when ever your characters collision hits any object.
Hi . Your reply was very useful - so thanks for the info. Let me try to clarify the point I’m raising even if it might be a disagreement over the default character configuration rather than a bug.
The default collision capsule on the Third Person character is set to Block all PhysicsBody actors – effectively creating a force field around the character that will push small physics actors when the mesh is still some distance away. These collisions generate hit notifications and often the rebound / notification seems really broken since there is no contact visible between actors on the screen.
When the character mesh protrudes beyond the capsule due to a skeletal pose and the character mesh (PhysicsAsset) collides with a physics actor we get a very nice interaction. It looks like physical contact occurred and the physics actor responds to the collision. So the computational grunt work has been done. The collision occurs (and looks real) but the hit notification is missing.
The default configuration is a mess. Physics actors bounce off an invisible capsule and hit notifications are generated. When actual contact with the character mesh occurs we get very nice interaction but no notification. With the default capsule size the character feet protrude at idle and the situation gets worse during locomotion.
I’m looking for consistency. So a better configuration seems to be: Collision Capsule should NOT block physics actors; let the character PhysicsAsset do the collisions properly. I created a MyCapsule Collision Object Channel with Default Response set to Block. Then modify the Collision Preset for PhysicsActor to Ignore MyCapsule. Set the Character Collision Capsule to Object Type MyCapsule. For notifications, follow your instructions above to set the hit flag on the collision hulls.
perhaps UE-18952 should be expanded. Further testing has demonstrated that character motion around physics spheres (with linear damping at 0.1) will cause the sphere to move without contact with the character or character capsule. This only seems to happen after the sphere has been bumped once. Let it stop rolling, then move the character and see if some motion has returned to the sphere. This is with CCD off. Since the sphere accelerates without contact it may not be a damping issue.
UE-18952 is actually a duplicate of UE-18773 which was already being discussed with Nvidia as a PhysX bug. Once there has been an update to the bug I’ll post back here.
I discovered the ccd bug today after I tested every single configuration possible regarding collisions and physics on both actors…for more than a week, until I found that indeed it was the ccd setting. I was about to post it then I saw this Good job
Hi , tbh I dont think so, this page comes as the 9th link on the first page of google. The problem was to actually realize it was a bug indeed and not human error. Thank you!
The CCD tractor beam does seem to be fixed in Preview 3. Since installing this update I’m also unable to reproduce the original complaint in 4.8.3. Did the fix touch a library shared between these versions?
Good job