Hi I’m currently making my first level in Unity and I set my sprites speed to 10 times normal and if I run at any of the walls he just passes right through.
If there some way to make it impossible for the sprite to pass through an object regardless of speed?
Thanks
note: I set it to 10x normal to to test my dash mechanic I’m going to implement
physics interpolation?
Do you mean interpolate option on the ridgidbody2d?
Just so you know, interpolation doesn’t affect the physics simulation, it’s just an option to make rendering smoother by rendering from the old RB position to the new one. The transform position is adjusted each frame and is always ‘behind’ where the RB position is until the next physics tick. Extrapolation is the opposite; the transform is ahead of the RB position based upon the current velocity.
If you are positioning the RB yourself by modifying the transform then you are ‘star trek warping’ the RB from one position to another and bypassing the physics simulation. Doing this will cause you to skip right past/through objects so don’t do this.
if you are not doing this then set the collision mode from ‘Discrete’ to ‘Continuous’. Continuous is much more expensive to calculate (it is known as continuous collision detection or CCD) but will completely stop objects passing through each other at high speeds. When I say high speed however, you normally need to use ‘very’ high speeds to cause this to happen and I’ve no idea of what ‘10 times normal’ is but give it a try anyway. Note this option won’t make any difference if you are modifying the transform as I mentioned above. The RB needs to be moving under its own velocity for this to have any effect.
BTW: I am assuming that when the ‘sprites’ are at ‘normal’ speed they don’t pass through i.e. when you say sprites you mean a GO with a SpriteRenderer and a 2D collider on it.
Hop this helps.
This is probably not what you want to hear but I’d just not use the Unity physics system. With any canned system you will run into stuff like this and it just wastes your time trying to work around such things. If you want to use a canned physics system such as the one implemented in Unity then your best bet is to simply slow down the speed until you get the behavior you need.
The way to handle collisions is to look for them BEFORE moving not after. For example, in my 2D platform game I rolled my own physics. When moving… say the player is falling and is currently 2 pixels from the floor but he is moving down 7 pixels this frame. I just cast out a ray (my own not the Unity ray) looking for a floor. It is just a simple matter of 7 loops in this case. First checking 1 pixel below player’s feet, then 2 pixels, etc. If no floor is found he can move 7 pixels down as planned. However, in this scenario a floor is found just 2 pixels below his feet so he can move only 1 pixel down to end up standing on the floor.
Actually, thinking about it… Unity has ray casts so you could cast a ray out checking for a wall before the object moved. Not sure about when exactly or how you’d hook back into the normal physics reaction because I don’t use the stuff.
I don’t understand your reply. Box2D has solid collision detection, we even have tests as does the Box2D test-bed that stress-test this case with objects moving crazy fast (using CCD) with no interpenetration of other colliders.
If you perform actions that undermine the physics system, for instance, putting a dynamic rigid-body on a transform which is a contract that states that you want the RB to control the transform, then modify the transform directly then you are causing problems as this undermines the RB and warps the object from position to position.
if you don’t want rigid-body movement then sure, go ahead and set the RB to kinematic and add your colliders and use ray-casts to detect collisions.
Either way you need to chose which method you require but often mixing these is the root cause of the problems.
I was basically just getting at need to work with the system or else do not use the system.
In nearly every API I’ve used I end up fighting with the systems working around issues. So I made a habit of not using the “special” stuff. Many canned collision systems suffer from objects moving through each other due to them not checking for collisions until after the movement updates are performed. Like I said, I am not sure how Unity’s movement & collision checking is performed and it is simpler to just code it myself so I do know how it works and can change any behavior I do not want. Not knocking Unity physics or Box2D specifically.
Just wanted to chime in and say that turning on extrapolation will overshoot the target by a pinch, but always register a successful hit. For me the hit location is vital and should never exceed the target. I was able to solve this in 2D by grabbing my projectiles’ heading, then capping it based on the center x axis of the target. Hopefully somebody out there finds this useful.
This thread is from 2014.
Good for you, buddy, cause Google brought me here in 2017. Do you just scan the forums looking for replies to old threads to drop that ever-so-clever line?
If it’s still relevant, it’s still relevant. Now your comment just attracted another comment, so this thread is wide open again, pal.
It’s common forum etiquette, and usually a rule on most forums to not resurrect old threads with new posts but to create a new thread instead. It’s better to keep the whole thread within the same time period. Old threads are better left as read-only.
Do I scan the forums? No, I saw it get bumped to the top of the list, like every thread I see.
Thanks, Google brought me here in 2021 and helped solve an issue I was having!