On Component Begin Overlap Sweep Result not populated
When I use OnComponentBeginOverlap event in blueprint, the event fires appropriately, but when I try to break the sweep result with break hit, all of the values are 0. I'm trying to find the impact normal of two actors overlapping but I don't want them to actually collide with one another so I thought overlapAll and bgeneratesoverlapevents would be the ticket. Is there something I need to do to get this event to generate the expected result? Should I take another approach?
asked Jan 28 '15 at 09:35 PM in Blueprint Scripting
I'm having the same problem and worked around it by doing a spherical sweep when I get the overlap event. This seems to work for me, but I also use a spherical collision hull. Here is my code, slightly simplified to be more generic:
This solution sucks, but it's the best I could come up with. You could probably still tweak it a bit with the parameters of
I hope this will help someone, somehow :) but it would be great to hear a better solution!
answered Aug 05 '15 at 06:37 PM
Unfortunately the onOverlap events are not able to output any collision information.
There is a work around solution but is quite a hack: You can use onHit events and disable the contact forces generated in physX. Therefore you get the FHitResult (contact normals, contact points etc), while the objects overlap.
As you can probably tell this can only be achieved in C++. You also have to alter the engine's source files. What's awesome is that UE4 is truly open! The sky is the limit! and the time of course ;). If you can afford to dig that deep look at collision filtering and contact modification in physX: https://developer.nvidia.com/sites/default/files/akamai/physx/Manual/Callbacks.html
answered May 28 '15 at 01:29 PM
Another solution that might not work for all cases, Make a socket in the component you are calling the on overlap event and at the moment of hit you have the location of the socket, Useful for spawning impact emitters for combat events
answered Jan 08 '16 at 10:46 PM
I'd do a line trace on the overlap to both my actors and break off the hit event from there
answered Jul 02 '15 at 05:59 AM
Here is a quick and dirty blueprint solution for a spherical trigger:
First we make sure that although multiple overlap events can fire per actor per frame, we work with each actor only once:
(Part of the node network to the right is omitted for brevity.)
Then we pick an arbitrary point which is definitely outside the detection sphere. That is our starting nearest detected point, used in comparisons later, to find the closest point on the actor at hand.
Let's go through the hit results in a "for each" loop. The loop body starts like this:
Two things to note here: First, since we started this whole process after an overlap event occurred, we can be sure that the current actor is (partially) inside the sphere so it will be initially overlapping with the sphere trace as well. When that happens then some hit result properties change their meaning. For example "Normal" then stores the depenetration vector, a direction from the center of the sphere pointing toward one of the nearby points on the current actor. I have no idea how those points are picked I just saw that they are close and they are many.
Which brings me to the second important note: Multiple hit results will be about the same actor, containing a different one of those "nearby" points. So if we want to be as precise as possible then we can not break from the foreach loop when we found our actor the first time: we will have to check all hits and pick the closest of the nearby points.
Since so far we only have a direction of such a point we do a line trace in that direction to see how far our actor actually is. We iterate through the trace hits:
If we found the actor in question then we see if the hit point is the new nearest or not. And in any case we break out from the loop since the rest of the hits are irrelevant. After that we carry on iterating through the sphere trace's hit results and doing this same line trace every time the current actor shows up. When we are done we should have the closest of the available points.
This method is not very precise, especially when the actors involved are moving fast, but might be good enough until we get a more elegant native solution.
I just tested this in 4.10.2 and the Normal and Impact Normal now output the correct values. However, I'm not sure that it is outputting the exact information that everyone here is expecting but I believe it is outputting what the OP (Parakeet) was originally asking for.
Parakeet: Please give it a try if you like and let me know if you were expecting different results and why.
answered Jan 27 '16 at 06:19 PM
TJ V ♦♦ STAFF
I had the same issue while trying to get multiplayer networked -- the ComponentOverlap hit result for the server would work fine, but the clients wouldn't. If the ComponentOverlap doesn't fire immediately, then the 2 areas can merge slightly. In this case, there are infinitely many overlapping points so it chooses (0,0,0) for vectors. I solved this by having a point on my projectile that it chooses if the location vector is (0,0,0).
answered Dec 09 '16 at 06:18 AM
Hi everyone I have the same problem I'm using ue 4.14.1 and coding in c++, SweepResult values are not populated although the overlap event occurred also I happen to know that these values can also be invalid for example impact point is not correct as it says that overlap occurred next to component bounds. This is happening only in certain situations for example if there is a frame drop just before overlap, when another application becomes active just before overlap event, when UE editor window loses input just before overlap event, when you drag and move UE application just before overlap event, this is also true for packed project when App looses focus just before overlap event, when you drag application window just before overlap event
EDIT: This also happens when your objects begin play close to each other
And here where the values are incorrect impact point X should be 466.0 and not 466.000031 this is also true when object moves very close to the other object OverlapEvent is fired although objects do not overlap
Overlap takes place as collision volumes occupy the same space, not on contact. A "Hit Location" isn't given because it would be a 'volume' rather than a point location.
Duplicate the Overlap volume as a Hit volume of a slightly smaller scale (disabled collision by default)
On the Overlap, enable the smaller volume's collision and trigger a 'growth' in relative scale using [x] Sweep.
It will eventually 'Hit' the same object that overlapped the original, and will have a hit location/normal to use.
If precision is important (must hit an external point) - you can use the normal and the hit location to solve for a vector pointing back at the colliding object..
Tracing in on that vector to the "Overlap" volume to find the point it would have hit on that volume. (^ this part may not make as much sense as it does in my head, I'm caffeine deprived)
Follow this question
Once you sign in you will be able to subscribe for any updates here