Hit location is wrong for fast-moving sprite with CCD

I have a projectile that uses a projectilemovement component to move until its first Hit event, at which point physics becomes enabled on the root component which is a sprite.

Even though the projectile is moving quickly, collision seems to work perfectly when it’s a projectile. But not when it’s simulating physics. At this point hit events sometimes get called when the projectile is not even near the thing it supposedly hit. I drew debug boxes to clarify it for myself. Sorry for the godawful appearance of the blueprint scripting.



Anyway does anyone have any idea of why this might be happening? This collision only happens after the thing it has supposedly run into has been successfully cast as a capsulecomponent. So you would think the hitlocation would be somewhere inside the bounds of the capsule. But it’s not and I don’t understand why. Is this location that I am getting the location AFTER the projectile has already “bounced” off of the thing it just hit? If so, then why would the hit location still be wrong? Thanks for your help.

EDIT: actually the same thing DOES happen even when the projectile is still moving according to the projectilemovement component, without physics simulated. so I guess it’s just a problem with fast-moving collisions? But then shouldn’t CCD resolve this problem? I could fix this problem by doing a raycast every tick, couldn’t I? But should I have to do that? Does this have to do with weird aspects of Sprites, like “collision thickness”? I have tried changing that property from 5 to 500 and it doesn’t seem to change anything.

After doing some research, the best conclusion I can come to is that this is just an inherent problem with the physics in UE4. Maybe it’s inherent to PhysX but I assume PhysX has some way to actually do CCD, it just doesn’t work in UE4 at least at this point as described by these people here:

I am also experiencing things like that just standing in the same spot pressing the same fire button key, the projectile behavior is totally inconsistent. Sometimes things will actually bounce backwards off of a surface which is almost parallel to the motion of the projectile, and sometimes it works normally. I have also encountered interesting bugs like that the InitialOverlap boolean of the hitresult of an onHit event will be incorrect. I am left to conclude that high-speed collision is basically broken in Unreal Engine 4 at this point.

It also doesn’t help that when I try to add breakpoints, this happens within about 60 seconds generally:


Even though my computer has 16GB of ram, the latest mac operating system and the latest unreal engine (4.15.3). It would be really nice if Epic would stop focusing on what new features they can add into the next Sizzle Reel Feature Showcase and make it so that doing random extremely basic fundamental things like adding a variable to a struct on which a datatable is based does not corrupt your entire project every single time, which apparently is business as usual and considered totally acceptable. Also, how are you supposed to develop on a platform where you never know if something isn’t working because the blueprint might just be “corrupted”? Like this person, for example:

So my next course of action at this point is to just rebuild the entire blueprint manually, and maybe it will work because the old blueprint was corrupted. But even if I do that, clicking on “replacing references” with the new blueprint I manually created might crash the unreal editor every single time, as it the last time I tried to do that, and therefore be impossible. In which case in addition to manually recreating the blueprint from scratch, I would have to go into every other blueprint that referenced this one and recreate/rewire every reference (although I assume some more things would break in the meantime while I’m trying to do that). But that still might not do anything because the blueprint might not be corrupted. There is no way to know. But no, adding Volumetric Fog and more new features for VR is a lot more important. But hey, at least performing the following operation: “Right click → create structure” no longer crashes the mac editor every single time, as of… yesterday (4.15.3 update)… Just my two cents…

Can you show me where the Center Value comes from? Might be a old Value you are using there? Also debug point would be better :stuck_out_tongue_winking_eye:

its coming from impact point

Mhh ok but do you debug draw it at the same frame? Asking because it looks like you draw from another event at later time. At least thats what the flow of the white wires suggests to me.

I’m not sure what you mean by that the flow of the white wires is suggesting that I draw from another event at a later time. Could you explain?

It kind of looks like I’m experiencing the same thing this guy was talking about:

However that was posted a year ago. And to be honest I figure OnHit events are so common I can’t imagine that this has just been broken for over a year with no one talking about. There must either be another way people are checking for collision or I am doing something very wrong.

There are some REALLY fundamental things wrong with physics enable in 2D. Objects will clip into each-other, especially low frame-rates, high velocity, or even high mass stacked on top of eachother. It is not uncommon for very obvious or game-breaking bugs to exist in 2D for years, and Unreal does not seem to intend on fixing them, so 2D developers have to work around the system.

I’ve been working on a 2D physics game (god help me) and the suggestion I got from an unreal discord was to create my own collision with ray-casting from scratch. I think this doubly applies for you, since you are just trying to detect collision.

If I were you I would use a BoxTraceForObjects or a CapsuleTraceForObjects node in blueprint since it looks like you are working with simple shapes.