Simplified case to explain it all:
Actor containing 2 Spheres.
Outer sphere overlaps everything (doesn’t block anything)
Inner sphere blocks everything (besides the outer sphere)
When the actor collides, the outer sphere overlap should decide if the inner sphere should penetrate the object or get deflected.
The Problem
On high speed, the inner sphere hits the objects before the outer sphere overlap is triggered to do the calculations. (which should by design be triggered before, to decide if the hit should even occur)
How can we force the overlap event to trigger before the hit happens?
p.s. CCD enabled on both spheres
it does fire the overlap event. at low velocities everything works fine, but at high velocities sometimes overlap triggers first, while sometimes it’s the hit.
When you get a hit with the inner sphere you could force check the outer sphere and see if it has been updated.
Why must you use the outside sphere to decide if the hit is deflected. Can you setup collision channels to avoid the issue?
Is the outer sphere event firing at all? ( I’ve certainly had problems with overlap only collision not doing what I think it should )…
So, this is some sort of projectile, that can sometimes penetrate and sometimes bounce?
If it’s something that’s moving that fast, it’s probably easier to do the calculation along with the line trace…
nope. the spheres are just a simplified version. it’s not suitable for ProjectileMovementComponent.
Can’t do the former, because if a hit has occurred - it’s already too late. (because all the velocity gets deflected by the object bouncing back from the hit, while i need to preserve it)
For your question - that is because in the real case (which is more complex than the simplified example), most of the time it must be deflected (by deflected i mean just block response between the objects), while only sometimes, if overlap decides so - get penetrated. of course i achieve that by playing with the channels back and forth,
it’s usually not that fast. only in some cases it gets fast, if too much force is used.
also such a line trace wouldn’t be reliable too in my case, as the object’s movement is much more complex than a projectile. it’s controlled by a VR player so sudden unpredictable movement could change the effect. (like stopping just a moment before the penetration)
it’s all a chaotic physics simulation based system (an absolutely mandatory thing in my case)
I don’t know if you’ll be able to change the detection order, but you may be able to work around it with collision channels.
Set up two collision channels for your colliding objects, one that check for overlap only, and one that checks for overlaps and blocks.
Initialize your objects with the overlap-only channel. When an overlap is determined to become penetrating, change the channels of those objects to become blocking. When the two objects stop overlapping you can change the collision back to overlap-only.
Not sure if that will work in your specific, but it’s an idea.
that is exactly how it is set up right now.
at least with assumption that you have meant disabling the block upon penetrating rather than enabling it. (blocking objects cannot penetrate each other)
in any case that is not the problem. the problem is that the overlap event triggers too late on high velocity, after the hit were deflected already.
If hits are being triggered you don’t have it set up like I suggested at all. If you aren’t changing collision channels during runtime, then you aren’t doing what I suggested. If you are already changing collision channels during runtime, then you haven’t described your situation very well.
I’ll try to explain again:
I didn’t at all mean disable the block upon penetration. I mean enable hit check only if you have an overlap and not at any time before.
Create two separate collision channels. Have one detect overlaps and blocks, and the other one only check for overlaps.
Apply the overlap only channel to your actor. Do not apply the blocking channel. You are only checking for overlaps. Turn off all collision checks on the inner sphere.
When and only when you have already detected an overlap/penetration of the outer sphere, then enable (and I do mean enable) the blocking check on the inner sphere.
When the overlap is complete, turn off the blocking checks on the inner sphere.
i am of course changing the channels during runtime. there is no other way to achieve dynamic penetration. as i’ve mentioned, everything does work on low velocity, which implies channel response changes during runtime.
enabling/disabling hit events isn’t the matter. i don’t talk about events - i talk about the physical block reaction between two non-overlapping objects. i want these to stop happening, not the hit event.
regards your suggestion, why would the inner sphere even check for blocks? the inner sphere is not a collision trigger, it is a mesh that is either flying trough a wall or getting deflected by the wall. the outer sphere is the one that decides if it happens or not by checking the stuff on overlap.
but the overlap happens too late, because it gets deflected (by default) before the check (inside onBeginOverlap) even triggers.
Nothing you said previously even implies dynamic changing of collision responses.
Your question now:
“regards your suggestion, why would the inner sphere even check for blocks? the inner sphere is not a collision trigger, it is a mesh that is either flying trough a wall or getting deflected by the wall”
From your original post:
“Inner sphere blocks everything (besides the outer sphere)”
Good luck, buddy.
After reading through all the comments it seems that you just don’t want an object to always be stopped by a wall and use overlap checks to allow it to penetrate this wall. You can use the Hit event to check if it should penetrate and manually reset is velocity and collision channel to allow it to continue into the wall. I’m pretty sure Hits give you a distance along the trace the hit occurred so you can even set it to the correct position as well. If it is meant to deflect then you can go ahead and do nothing.
i assume that people do understand that “penetrating” means getting trough something, in other words - not blocking it.
the original post is still just as valid as it was. the inner sphere blocks everything until a penetrating overlap is forced on it by the outer sphere.
thanks, that sounds very interesting.i will check that and report back with results. hope it works. i’ve never thought of a hit as of a trace.
p.s. you are a true hero to read trough all of that, haha :]
“i assume that people do understand that “penetrating” means getting trough something, in other words - not blocking it.”
You mean the inner sphere?
" the inner sphere blocks everything until a penetrating overlap is forced on it by the outer sphere."
Oh, you mean the outer sphere.
So the inner sphere blocks?
“why would the inner sphere even check for blocks?”
I don’t know, you said:
“the inner sphere blocks everything”
So I thought that meant the inner sphere blocks everything.
“i assume that people do understand that “penetrating” means getting trough something, in other words - not blocking it.”
Um…
- The inner sphere blocks everything by default
- When outer sphere detects a overlap and a high enough velocity - inner sphere temporarily gets overlap over the wall to penetrate it, then gets back to blocking everything.
That’s all
p.s. perhaps we have misunderstood each other with “checking for blocks”. in my terminology - checking for blocks means having overlap relationship with something, and constantly query other overlapping stuff to decide if should block or not. pretty much what the outer sphere does.
as far as i understand - in your terminology “checking for blocks” is simply “blocking”, in which case it applies to the inner sphere.