koobas.hobune.stream
How to adjust two colliders really close to each other w/o them colliding?
Hello,
SCENARIO :
I am building blocks on top of each other. Now when I play this block, I activate the rigid bodies on each block so that they obey the laws of physics. In order make building these blocks on top of each other easy, I have made an editor script to check for collisions which is this
private static bool CheckCollisionBetweenTwoColliders (Collider c1, Collider c2)
{
if(c1.bounds.Intersects(c2.bounds))
{ return true; }
else { return false; }
}
REQUIREMENT :
Now, lets say that the two colliders intersect - I want to adjust the colliders in such a way that they lay exactly on top of each other.
Is it possible?
Thank you for your time.
regards,
Karsnen.
$$anonymous$$ecraft does not work like that. there is a vast, vast amount of info on here about making $$anonymous$$ecraft. indeed, there is a total complete starter kit for it.
You have the Bounds.extents, Bounds.$$anonymous$$, and Bounds.max, so for a single intersection, you have the info to move one of the cubes so that it does not intersect the other. If your placement involves multiple possible collisions driven by arbitrary placements of blocks, then the problem becomes much harder as you attempt to satisfy a network of constraints.
Note if you blocks are a fixed size, wouldn't you be better off using some sort of grid system and just have the blocks snap to the grid?
@fattie : Sorry I do not get you. I was not talking about $$anonymous$$ecraft at all else I am not getting you.
@robertbu : Bounds is something I might want to tinker with. They have info that I could use but still not sure. $$anonymous$$ight have to play around. DId not try before. I am not trying to calculate or try to move colliders on loads of colliders. $$anonymous$$y target is just for two colliders and slowly move up. Finally, my blocks are not of the same size but they are fixed and more less equal to an extent of ten units.
Appreciate your time guys.
If they are active (non-kenimatic) rigidbodies, they will naturally act a little spongy. So the 4th ten-meter stacked cube will be something like 39.4 meters up. Last I looked, it wasn't something as simple as subtracting penetration distance.
I eventually locked most blocks in place, snapped to "correct" grid locations; and enabled physics selectively for "touched" blocks. But only because I was making an exact grid, with "fun" physics.
@owen - hmmm when you snap - do you ceil the float to int and make sure that all vertical blocks are aligned?
You could always attach a second collider to each object that is larger, and is set to be a trigger. You could use these colliders to detect 'close calls'.
But wouldn't you still have the same problem of how to fix it?
$$anonymous$$y version of this was to just change the collider into a trigger, then manually move it back and forth in a binary search over several frames in FixedUpdate (so I knew it synched with OnTriggerEnter/Stay/Exit,) stopping when the gap was like 0.01 or less.
Gaint pain. And the ending position still depended on exactly where you started, so adjacent blocks only almost lined up. But the movement didn't look too bad. You just saw the block float over to line up. The "wiggle" at the end wasn't really noticable, and looked like it was on purpose.
Well yeah. It just adds one more layer of collider which results in the same scenario. One the other hand, lets say that you align two colliders perfectly well but you can't really put them EXACTLY on top of each other.
Lets just place the two colliders on top of each as close as possible but not intersect the colliders. What could be done is that, you know what should be the final drag of your rigidbody so how about lerp the drag of the rigidbody from 50 to the required in say 1 or two seconds. In such a way, the bodies exactly land on top of each other. It actually worked while I tested it but I just can't commit on that solution until I do much more test.
