x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

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?

Product Version: Not Selected
Tags:
more ▼

asked Jan 28 '15 at 09:35 PM in Blueprint Scripting

avatar image

Parakeet
111 6 7 13

avatar image Elathan Mar 17 '15 at 10:59 PM

I have the same question. I use c++, and a collisionbox primitive is checked against a capsule for example. Event fires, but the SweepResults is empty. Any idea how to get more detail on the collision? I would like to have the world coordinates of the point of intersection.

avatar image Cmiller28 Mar 20 '15 at 09:46 PM

add me to the people looking forward to an answer for this question

avatar image madmouse Mar 23 '15 at 08:01 PM

I have also stumbled against this issue and i have no idea if i'm doing something wrong or it's a bug

avatar image ZoltanE May 25 '15 at 09:26 AM

I would also like to know how to make this work.

avatar image tanis2000 Dec 16 '15 at 06:17 PM

Is this ever going to be fixed?

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

9 answers: sort voted first

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:

 void AMyPawn::OnComponentBeginOverlap(class AActor* OtherActor, class UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult)
 {
     if (OtherActor && (OtherActor != this))
     {
         TArray<FHitResult> AllResults;
 
         // Get the location of this actor
         auto Start = GetActorLocation();
         // Get the location of the other component
         auto End = OtherComp->GetComponentLocation();
         // Use a slightly larger radius to ensure we find the same result
         auto CollisionRadius = FVector::Dist(Start, End) * 1.1f;
 
         // Now do a spherical sweep to find the overlap
         GetWorld()->SweepMultiByObjectType(
             AllResults,
             Start,
             End,
             FQuat::Identity,
             0,
             FCollisionShape::MakeSphere(CollisionRadius),  
             FCollisionQueryParams::FCollisionQueryParams(false)
         );
 
         // Finally check which hit result is the one from this event
         for (auto HitResult : AllResults)
         {
             if (OtherComp->GetUniqueID() == HitResult.GetComponent()->GetUniqueID()) {
                 // A component with the same UniqueID means we found our overlap!
                 
                 // Do your stuff here, using info from 'HitResult'
                 OnComponentBeginOverlapWithInfo(OtherActor, OtherComp, OtherBodyIndex, bFromSweep, HitResult);
             
                 break;
             }
         }
     }
 }

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 SweepMultiByObjectType. In particular I suspect FCollisionObjectQueryParams and FCollisionQueryParams could be used to reduce the search space.

I hope this will help someone, somehow :) but it would be great to hear a better solution!

more ▼

answered Aug 05 '15 at 06:37 PM

avatar image

amcofi
525 9 83 49

avatar image AlexW88 Aug 06 '15 at 05:20 AM

I'm using the same attempt, but I feel like the Trace happens few frames after the overlap, making it unreliable. Though that might be cause I'm using it with an animation.

avatar image amcofi Aug 06 '15 at 06:11 AM

Yeah, I also got the impression it's not super reliable. I didn't investigate it much though and it might be that I just did something wrong while testing. Anyhow, I worked around that by making the radius 10% bigger: auto CollisionRadius = FVector::Dist(Start, End) * 1.1f; Some quick testing gave me the impression that it works for my use case.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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

more ▼

answered May 28 '15 at 01:29 PM

avatar image

StewardH
39 1 3 5

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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

more ▼

answered Jan 08 '16 at 10:46 PM

avatar image

Maelgrim
71 1 5 8

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

I'd do a line trace on the overlap to both my actors and break off the hit event from there

more ▼

answered Jul 02 '15 at 05:59 AM

avatar image

TheFoyer
171 9 16 30

avatar image ZoltanE Jul 02 '15 at 06:54 AM

How do you determine the two ends (or the start and direction) of the trace?

avatar image TheFoyer Aug 05 '15 at 06:42 PM

Well in my case, the start point is the center of my 'player' and the direction would be in the actual velocity direction. Or in my case which ever direction the player happens to be aimed at.

avatar image amcofi Aug 06 '15 at 04:37 PM

But doesn't that give you quite a big error, depending on which velocity (angle) an object has when it overlaps? Or even worse; that the line trace could completely miss the object, if you hit it on an edge. And also, isn't the impact normal then always equal to the velocity (just in the other direction)? Here a picture that hopefully clarifies a bit what I mean:

overlap vs line trace

Sorry if these are stupid questions, but I'm still new to UE4. I guess the performance of a line trace would be much better than the sweep I do, I just wonder if it really works for a more generic use case.

line_trace.png (4.7 kB)
avatar image TheFoyer Aug 06 '15 at 05:32 PM

Ok yeah, I think you're right there. I misspoke so let me clarify what's going on. After reviewing my situation may be a little different than yours. First I should say my end goal here was to play a sound to represent the impact noise. So all I needed to figure out was the impact velocity.

So it turns out I'm using the hit event, and then I'm getting the hit location, and I'm doing a trace from the center of my actor to the hit location. Then I grab the linear velocity and multiply it by the impact normal (to get the impact velocity) and do a calculation to determine how loud that sound should play. It works well. Except for when you are moving up or down hill, for some reason hit events fire while moving on a slanted surface.

avatar image amcofi Aug 07 '15 at 04:31 AM

Thanks for the clarification!

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Here is a quick and dirty blueprint solution for a spherical trigger:
(EDIT: Actually it should work for any trigger shape as long as the sphere trace encompasses it.)

First we make sure that although multiple overlap events can fire per actor per frame, we work with each actor only once:

alt text

(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.
The next step is firing a very very short sphere trace. Zero length (actual sphere) doesn't work so we make it 1 cm long which is spherical enough. This spherical trace now covers the trigger sphere and returns all hits inside.

alt text

Let's go through the hit results in a "for each" loop. The loop body starts like this:

alt text

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:

alt text

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.

more ▼

answered Aug 07 '15 at 11:05 AM

avatar image

ZoltanE
1.6k 79 93 142

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Hey everyone,

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.

Cheers,

TJ

more ▼

answered Jan 27 '16 at 06:19 PM

avatar image

TJ V ♦♦ STAFF
41.1k 1009 183 493

avatar image nuclearping Feb 04 '16 at 01:50 PM

I can't confirm this. At least not in C++. I migrated my 4.9.2 project to 4.10.2 just for that reason.

This is the collision setup for the hitbox of my weapon:

And this for my character's capsule component:

Hit event is fired. But no matter what, SweepResult.ImpactPoint, SweepResult.ImpactNormal, SweepResult.Location, SweepResult.Normal are all FVector( 0.f, 0.f, 0.f ).

avatar image TJ V ♦♦ STAFF Feb 09 '16 at 08:35 PM

Hey nuclearping,

Keep in mind that my setup is in blueprints, but I tested this with the exact collision setup pictured above and I still get values returned.

I suggest making a new post in the C++ Programming section and make sure to include your code.

avatar image HuntaKiller Sep 23 '16 at 01:40 AM

In 4.11 none of the hit result is populated on Begin Component Overlap. This is not solved. Blueprint only

avatar image TJ V ♦♦ STAFF Sep 29 '16 at 06:41 PM

Hey HuntaKiller,

I just tested this in 4.11 3rdPersonTemplate using the below setup. The Normal / Impact Normal that OP mentioned output correctly. Could you provide repro steps and/or a test project showing the results that you are seeing?

alt text

overlap01.png (91.3 kB)
(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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).

Here was the post that helped: https://forums.unrealengine.com/showthread.php?124652-Overlap-hit-return-all-0s-result-Get-Velocity-for-a-collision-box-in-a-blueprint-return-all-0s

more ▼

answered Dec 09 '16 at 06:18 AM

avatar image

uw19
25 7 6

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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

This is when values are not populated

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

alt text

untitled.png (108.1 kB)
untitled1.png (67.2 kB)
more ▼

answered Dec 24 '16 at 02:25 PM

avatar image

Mlody "Swidwin"
327 12 11 25

avatar image TJ V ♦♦ STAFF Dec 27 '16 at 02:39 PM

Hi Mlody,

You would probably have better luck getting help with this is you posted it as a new question in the C++ section of AnswerHub. Feel free to include a link to this issue so other know a similar BP issue has been reported.

Cheers,

TJ

avatar image Mlody "Swidwin" Dec 28 '16 at 08:55 PM

Will do when I get back home

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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.


Solution.

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)

more ▼

answered Dec 28 '16 at 09:09 PM

avatar image

Looniper
766 22 7 36

avatar image pulp_user Dec 31 '16 at 02:37 PM

On the Overlap, enable the smaller volume's collision and trigger a 'growth' in relative scale using [x] Sweep.

How do I do this? I thought that when you sweep, you move a shape trough the world, I didn't find any option to "grow" it instead of move it.

Btw: A feature request of mine made it into the Unreal Engine Issues, that would provide a hit normal and location equivalent on BeginOverlap.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question