Hit or overlap events can’t be used, because if it is used, you could just touch the centre of the hoop, then fall back the same side you tried to enter. So you did not actually pass through it, but the system will think that you did.
So again, how to detect if the hoop was actually passed?
You don’t have to give the code or the blueprint, you can just explain the principle. But if you can give the blueprint, that would be even better.
P.S. I’m looking for elegant solutions, so having invisible triggers on each side of the hoop for example is not a good solution.
One way I thought of doing this is to use overlap start and end, and record player’s Dot product to the centre of the hoop. And on end check if the dot is the opposite of the overlap start dot.
But looking for better and more reliable solutions than this.
Maybe you dont understand enough of collisions to know:
You can tell what direction something is going in and out of a collision by just doing dot product of the directional vector of the object compare to that of the item.
Maybe you also don’t know enough as to track an object through a collision:
When the collision starts, save the object passing in to an actor variable if the variable is null (assuming its an actor but almost everything is)
Save the vector that actor entered with as well.
When the collision ends, check the actor is the same who entered.
Compare its exit vector to the entry one.
The dot between the 2 shouls be less than ±.25 apart to mean it went out the same side it came in more or less (25% of 180%).
After you do your math you set the actor value you saved to empty/null.
That should get you going.
Trig is all it takes though. You dont really even need collisions. They just help isolate when to calculate.
Also, it appears you had already though of the best way to do it. Just maybe not in its entierty.
How do I get the entry and exit vectors? What exactly are they?
I tried getting entry and exit positions, but since they are not normalized, the dot between them gives huge numbers. And it wouldn’t make sense to normalize (get the unit of) a position.
I also tried getting the Forward Vector of a rotation oriented towards the ball (entering actor), both during entry and exit, and get the dot between them. It does give a value range of -1 to 1, but very incosistently (One time I pass it gives 0.98, then again it gives 0.2, then gives -0.9, etc.). So I think this is also wrong.
If the entry direction is aligned with the exit’s, it’s big score time. This will not work if you shoot balls into a twisted pipe whose entry / exit face the same way.
Occam’s Razor: invisible triggers on each side of the hoop is the simplest (and most flexible) solution. Should at least try it before ruling it out. Especially if nothing else has worked thus far.
Not at all flexible. If the triggers are big enough to reach the centre of the hoop, player still can touch both triggers, but exit the same way he entered (Player is a physics based rolling ball btw, but doesn’t really matter). If the triggers do not reach the centre of the hoop, then a small ball won’t detect passing through.
Tried this. Works if the ball goes straight through it. But if for example It enters the trigger straight, then leaves the same way, but not straight back, but kind of diagonally, almost along the horizontal axis of the loop (the box trigger), it gives random values. Same for exiting. If enters straight, exits the other side diagonally, again random values.
EDIT: Well not exactly random values, it obviously gives the correct dot, but the dot it gives is inconsistent for any logic to be implemented. It can be positive, negative, bigger than 0.9, lower than 0.1, all depending how dumb the ball behaves inside the loop.
IMO on end overlap dot direction vector of hoop center to ball location against hoops forward to know if the ball went through. Same check could be done on begin overlap to be extra sure the ball came from 1 side and exited the other.
Seems more logical, indeed. I wouldn’t use forward in case OP needs to shoot from the back / sides. We went from jumping to shooting balls. Not sure what’s the best generic way. The above is not it, me thinks.
You guys are missing the bit where I said to check that the dot is in a specific range…
Thats all you need for glancing shots/twisted or even “defalted” (parabolic) shots to be accounted for.
Thats a bit extreme.
If going through a hoop, one can lower or heighten the range of the check up to .5 before the objects is coming back around entierly.
I’d do something like .48 for the example you show.
So long as the volume of the “hoop” is a small enough size, the bounce probaly wouldnt even be possible/detected/a problem…
The important part is that it foesnt have to be the same exact value in as it is out.
Else, instead of doing dot you can just compare forward vectors.
Thats resolved by scaling the collision of the ball in the direction of trave by the speed of trave.
So your collision for a ball going 100uu per frame will be scaled by 100uu + original size - in a way that each frame will automatically be able to check even a single plane for collision.
(Sure you are checking ahead, not at the actual spot, but the speed of travel also means you get there mid frame).
:
