Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Physics2D.BoxCast bug or incorrect usage

Discussion in '2D' started by shopguy, Mar 5, 2015.

  1. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    I've read that there are a lot of bugs/issues with Physics2D in Unity, mostly trying to use anything other than RayCast, but I need this to work so I'm hoping I'm just using it wrong.

    I'm working on a 2D platformer style game. I have several objects/sprites with 2D box colliders. I'm not doing any movements with animations (I use legacy animations, but not to actually move objects), and I'm not using any RigidBodies (not moving anything by physics). I'm doing all of my movement inside FixedUpdate.

    For each object with a collider, inside FixedUpdate, I calculate the new position it wants to move to, and then I use this function to check for detection between the current position and the new position:
    Code (CSharp):
    1.  
    2. public static int HitTestPath2D(Vector2 from, Vector2 to, Vector2 size, RaycastHit2D[] hits)
    3. {
    4. int layerMask = ~(1 << 5);
    5. return Physics2D.BoxCastNonAlloc(from, size, 0, to - from, hits, Vector2.Distance(from, to), layerMask);
    6. }
    7.  
    The layer mask is just to avoid collision with some UI elements.

    I'm not really sure I understand all of the parameters to BoxCastNonAlloc. I pass in these values:

    from = the current position of my object/sprite

    to = the position I want it to move to

    size = the size of the collider attached to the object/sprite

    hits = a static array of 10 elements

    The problem is, 75% of the time the collision detection works correctly, but often enough to be a real problem, it just doesn't detect the collision. I might expect the imperfection if I was mixing Physics and Legacy Animations and direction positioning (via script), but I'm not mixing any of that... so if this code was outside of Unity, in some engine I wrote for a real simple game, it would be easy and work perfectly... it's just checking for overlapping boxes, and always should know exactly where every box is.

    It isn't even just the complex angles or "near misses" that fail 25% of the time, even just a simple "one object not moving at all, and the other going at a 90 degree angle at a constant/slow movement rate" doesn't even work all of the time.
     
  2. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,326
    Not that I know of looking at the current list of known issues. Care to share which ones you mean and/or report then?

    It's hard to say why in your project you're seeing it work only 75% of the time without a reproduction case. If you can duplicate this in a simple project, report it and send me the case number I can look at it immediately.

    Note that there was a bug reported and fixed in 4.6.3p1 and will also be in 5.0.0p1 with the release note of "Physics: Fix incorrect calculation of fraction & distance using Physics2D BoxCast/CircleCast methods (and variants).". This doesn't sound like your problem but you never know.

    Hopefully you're not saying that you're adding 2D colliders without a Rigidbody2D component and moving them! These are static colliders and should never be moved at runtime; it gives lousy performance.
     
  3. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    I know I've read at least a few posts in forums and Q&A, but nothing specific or that I have handy to link. So, yes, my next step will be to recreate in a simple project if I can, and maybe that will help me find the solution.

    I just upgraded to 5.0.0f4 yesterday, and it is still happening. I was using some 4.6.2f1 before that.. so if I hadn't upgraded to 5.0.0f4 I would have guessed that was my problem. I'm going to assume 5.0.0f4 is newer than p1, even though I don't know what the letters mean.

    I am doing just that, however my method of moving and usage might not be what you are thinking, and I'm getting great performance (I haven't tested on low-end Android devices, but 60 FPS on decent devices, with 20+ colliders in view). I'm only moving them using transform.position, not any physics. I also not using any of the built-in collider functions like OnCollisionXXX, I'm only using them as a size for my BoxCast, and then also so that my BoxCast will "hit" them.

    If this really is wrong, maybe that is why I am seeing problems others aren't, as I imagine this setup doesn't get a lot of testing, if others know not to use it. I don't want to use physics, I need more control for that, for an old-school Mario style game-play.. but would there be a good reason to attach a kinematic rigidbody to every object with a collider? Intuitively I would think more components = more overhead.

    Also, I'll have to read the new v5 feature list again, but I thought I remember reading something about static colliders, and maybe them not having the performance hit (or as much?)... could have been static meshes or something else.

    Almost forgot my manors, thanks a ton for the reply/info!
     
  4. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    I wasn't able to recreate, so far, in a simple project. I tried adding a RigidBody to the object that the BoxCast2D was not hitting/finding. If the RigidBody isn't Kinematic, it seems to work correctly every time (tried about 50 times, normally I can recreate a miss every 5 times or less). If the RigidBody is Kinematic, I get the same results as no rigidbody at all, it misses about 25% of the time.

    I might think I'm breaking some rules.. like "rigidbodies can only collide with other rigidbodies", but if it was something that obvious I'm doing wrong, it seems like it would never work, but it is working most of the time.

    Will start the process of stripping out code/objects from my game, see if I can get down to a simple project that way, since I wasn't able to do it with a brand-new simple project.
     
  5. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    I ran out of time, so will have to submit my bug report with sample project tomorrow or over the weekend, but I think I have it narrowed down pretty well, in a pretty simple project. Here is some related code for now:

    This is my Venus fly-trap that spits fireballs (used to be a lot more code and didn't use a coroutine but I simplified it to this here. If the Fireball object that it clones isn't a child of this object (normally it is), that FIXES the issue. Also, if I remove the code in FixedUpdate that moves this object, that also FIXES the issue.. even though this object below isn't related to the collision at all, the collision is between my Fireball and another object.

    Code (CSharp):
    1. public class Venus : MonoBehaviour
    2. {
    3.     public Fireball Fireball;
    4.     const float SpitSpeed = 1f;
    5.  
    6.     protected void Start()
    7.     {
    8.         StartCoroutine(SpawnFire());
    9.     }
    10.  
    11.     IEnumerator SpawnFire()
    12.     {
    13.         while (true)
    14.         {
    15.             yield return new WaitForSeconds(1);
    16.  
    17.             GameObject fbo = (GameObject)GameObject.Instantiate(Fireball.gameObject, Fireball.transform.position, Fireball.transform.rotation);
    18.             if (transform.localScale.x == -1)
    19.             {
    20.                 Vector3 fbs = fbo.transform.localScale;
    21.                 fbs.x = -1;
    22.                 fbo.transform.localScale = fbs;
    23.             }
    24.             fbo.SetActive(true);
    25.         }
    26.     }
    27.  
    28.     protected void FixedUpdate()
    29.     {
    30.         Vector3 pos = transform.position;
    31.         pos.x -= 0.1f * Time.fixedDeltaTime;
    32.         transform.position = pos;
    33.    }
    34. }
    This is my Fireball code, which is also just a simple movement script, and does the BoxCast, I'll try to reduce this down before I submit the bug, depending on how much time I have:

    Code (CSharp):
    1. public class Fireball : MonoBehaviour
    2. {
    3.     public BoxCollider2D[] Colliders;
    4.     const float Speed = 4f;
    5.     public static RaycastHit2D[] Hits = new RaycastHit2D[10];
    6.  
    7.     void FixedUpdate()
    8.     {
    9.         float screenLeft = Camera.main.ScreenToWorldPoint(new Vector3(0, 0, 0)).x;
    10.         float screenRight = Camera.main.ScreenToWorldPoint(new Vector3(Screen.width, 0, 0)).x;
    11.  
    12.         // Set speed based on direction of travel.
    13.         float speed;
    14.         if (transform.localScale.x == -1)
    15.             speed = Speed;
    16.         else
    17.             speed = -Speed;
    18.  
    19.         // Start with current position
    20.         Vector3 pos = transform.position;
    21.  
    22.         // Adjust horizontal motion based on speed and time
    23.         pos.x += speed * Time.fixedDeltaTime;
    24.  
    25.         // If we go far off the screen we just destroy this object
    26.         if (transform.position.x > screenRight + 30 || transform.position.x < screenLeft - 30)
    27.         {
    28.             GameObject.Destroy(gameObject);
    29.             return;
    30.         }
    31.  
    32.         // Check each collider...
    33.         for (int colliderIndex = 0; colliderIndex < Colliders.Length; colliderIndex++)
    34.         {
    35.             BoxCollider2D collider = Colliders[colliderIndex];
    36.             Vector2 fixedColliderCenter = collider.offset;
    37.             fixedColliderCenter.x *= transform.localScale.x;
    38.             int hitCount = HitTestPath2D((Vector2)transform.position + fixedColliderCenter, (Vector2)pos + fixedColliderCenter, collider.size, Hits);
    39.             if(hitCount != 0)
    40.                 Debug.Log("Fireball hitCount " + hitCount);
    41.             for (int hitIndex = 0; hitIndex < hitCount; hitIndex++)
    42.             {
    43.                 RaycastHit2D hit = Hits[hitIndex];
    44.                 Debug.Log("Fireball hit " + hit.collider.name);
    45.             }
    46.         }
    47.  
    48.         // Set new position
    49.         transform.position = pos;
    50.     }
    51.  
    52.     public int HitTestPath2D(Vector2 from, Vector2 to, Vector2 size, RaycastHit2D[] hits)
    53.     {
    54.         DebugDrawBox(from, size, Color.red);
    55.         DebugDrawBox(to, size, Color.blue);
    56.         int layerMask = ~(1 << 5);
    57.         return Physics2D.BoxCastNonAlloc(from, size, 0, to - from, hits, Vector2.Distance(from, to), layerMask);
    58.     }
    59.  
    60.     public static void DebugDrawBox(Vector2 center, Vector2 size, Color color)
    61.     {
    62.         float halfWidth = size.x / 2f;
    63.         float halfHeight = size.y / 2f;
    64.         Debug.DrawLine(new Vector3(center.x + halfWidth, center.y - halfHeight, 0), new Vector3(center.x + halfWidth, center.y + halfHeight, 0), color);
    65.         Debug.DrawLine(new Vector3(center.x - halfWidth, center.y - halfHeight, 0), new Vector3(center.x - halfWidth, center.y + halfHeight, 0), color);
    66.         Debug.DrawLine(new Vector3(center.x - halfWidth, center.y + halfHeight, 0), new Vector3(center.x + halfWidth, center.y + halfHeight, 0), color);
    67.         Debug.DrawLine(new Vector3(center.x - halfWidth, center.y - halfHeight, 0), new Vector3(center.x + halfWidth, center.y - halfHeight, 0), color);
    68.     }
    69. }
    70.  
    That's all the code that is running... the only other thing I have in my scene is a GameObject that has nothing but a BoxCollider2D on it -- that the Fireball should pass through (hit) every time. The Debug line shows that a Fireball only hits the target about 20% of the time now (so even worse than my full project).

    I think the very telling clues are what I mentioned above, the 2 minor changes I can make to fix the issue, that seem like they should have nothing to do with the issue:

    1. Move the Fireball object out from under (not a child) of the Venus object that spits the Fireballs.

    2. Not move the Venus object (not set transform.position)

    All I can figure is one of those 2 things is causing Unity to rebuild/invalidate colliders (static cache?), maybe until the next frame or physics update... just long enough for me to miss the very small window available to detect collision.

    I would have just uploaded my project... but I still have a lot of assets to remove from the folders/etc, even though none of them are being used or doing anything that would invalidate this testing.
     
  6. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,326
    There's a lot to reply to here so forgive me if I miss something:

    5.0.0p1 means patch #1 i.e. the first patch release for 5.0.0. This hasn't been released yet however the fix I mentioned is already in 4.6.3p1 which has been released.

    When you modify the transform that has a Rigidbody2D component or a Collider2D component then you are modifying physics. If you don't add a Rigidbody2D but do add one or more Collider2D then you are adding static colliders which should never be moved at runtime. This is because it is relatively expensive to do so and should always be avoided and doesn't scale well. It doesn't mean it'll kill your performance immediately but you're wasting cycles that could otherwise be spent elsewhere. Just add a Rigidbody2D and set it to Kinematic.

    Sure, adding components is always overhead however it's pretty small and scales well. The same can't be said for moving lots of static colliders.

    That's for 3D physics. The overhead on 2D physics for moving static colliders (fixtures in Box2D speak) isn't as high as it was for 3D physics but it's still a no-no or in your case, you need to choose what gives you better/worse performance.

    This is what confuses me. If you are not moving these objects under their own velocity but simply warping them from position to position then the only thing that can change is that by using a dynamic body against a non-trigger, the physics system will ensure there's no overlap.

    Honestly, looking at your code, I have no idea why you're doing all the hard work doing something that the 2D physics system can do for you, especially for projectiles, including using continuous-collision detection to ensure that objects don't pass through each other which is possibly what is going on here. You're simply algorithm may just be failing; an immediate possibility is that you start the case inside (overlapping) the object you're hoping to detect. There's an option in the 2D physics setting to turn on/off detecting objects that already overlap.

    In the end, it's your choice here and there may indeed be a bug and I look forward to seeing your reproduction case. Please post the case number here when it's done and I'll take a look at it, over the weekend if need be.
     
  7. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    I started out trying to use the physics engine, but I couldn't get the level of control I wanted, and when I started searching for answers almost everything I can remember reading, people were making their own character controllers or using the ones on the asset store. The fact that their are at least a couple on the asset store seems to say that their is a need for them, unless people just aren't figuring out how to use the physics engine or other native options.

    http://www.gamasutra.com/blogs/Yoan...hobbyist_coder_1_2D_platformer_controller.php

    I don't know if his 2nd bullet point is valid, but if so that's a major issue, but his first bullet point is mostly the conclusion I came to, and what I mostly saw in other places I read and videos I watched:

    Maybe I should have only taken that approach for my main character, but once I had to do that work, it seemed logical to me to use the same movement/collision logic for everything else... I want my other characters (enemies/etc) to be able to jump, glide, fly, walk, run, change directions.. pretty much all the same things my main character can do, so seemed logical.

    Going to finish up my test case project and submit that tonight... stay tuned. (edit: submitted it using the new in-game feature, pretty slick, just waiting for the email which I assume will have a ticket #, then I'll post it)
     
    Last edited: Mar 7, 2015
  8. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    Bug report #678158
     
  9. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    Here is a rough draft preview of my game, so you know what style/etc I'm going for. I'd be happy to hear if anyone has any examples, tutorials, etc.. that show that I am doing things the hard way, and can achieve similar results letting Unity do more of the work for me. I'm going to take another look at the 2D game that was released with Unity 4.3, the potato guy, but I seem to recall finding a lot that I didn't like about that, when I was thinking about using that design.. but that was over a year ago, so worth another look.

     
    GarBenjamin likes this.
  10. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    The 2dCharacter example in the Unity 5 sample "standard assets demo" sure looks sweet... I mean, it isn't as polished as I would like, but I know it's just a demo, and the tiny amount of code required to make it work sure seems enticing.

    After playing with that a bit, I'm going to give the physics engine another shot. I should know from experience with my last game, which did use physics, that you can't give up easily on it, sometimes all it takes is tweaking the mass or gravity scale of an object, to go from a horrible experience to a great one.

    I can't find many examples easily now, but I know I read a lot of comments like this one: http://answers.unity3d.com/questions/622050/2d-moving-platforms-physics-issues.html where Calum.McManus says to not use physics, and use raycasting instead... and the link I posted earlier.

    And most of the other stuff I went back and read again, like http://deranged-hermit.blogspot.com/2014/01/2d-platformer-collision-detection-with.html -- is talking about the old character controller, not the physics engine. Looks like most of the people talking about issues that I read before, were trying to use the character controller, or some 3rd party or homemade version of it.

    So guess I need to give physics another shot... hopefully my bug report results in fixing something that needed to be fixed anyway. Either way, thanks for the help Melv, and thanks to the Unity 5 team for the nice 2D platformer demo to get me started.
     
  11. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,326
    Good luck with it and post back if you have success/problems either way,
     
  12. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    I decided not to give up just yet, since I'm happy with game design except this one issue, so...

    Looks like the problem might be that GameObject.Instantiate doesn't always copy the public array of BoxCollider2D objects I use for hit testing. That is, this:

    Code (CSharp):
    1. public BoxCollider2D[] Colliders;
    Sometimes has a Length of 0, even though the original object I'm cloning, has 1 element in the array.

    If I check the array right after the GameObject.Instantiate call, it is always zero length. If I check it later (future FixedUpdate event) it sometimes has the correct Length (1) and sometimes is still 0.

    Goofy... but at least I'm narrowing in on the issue, and it might not actually be with the BoxCast, which would explain why I'm only having issues with the objects I spawn/clone, not the ones that are pre-created on the scene. To be honest I don't understand what "static" means in the concept of colliders (I know static in C#/C/C++), but maybe related.
     
  13. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    Holy cow... I'm such a dork. I had 2 Fireball scripts attached to my Fireball. One didn't have the array of Colliders set, and the other did. So the GameObject was being moved twice by the same script, once with the colliders array (so hit testing was happening) and the other time without (so no hit testing). Explains why it seemed so random.

    Sorry to have wasted your time, and I'll go delete/close/cancel the bug report I submitted.
     
  14. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    This looks very good and honestly to me it has a much better look and "feel" to it than the games I see using the physics system. It looks very well executed so far.

    It sounds like you develop using a style very similar to mine. Not using the built-in physics system and so forth. I actually track the position of all GameObjects inside their script with a Vector2 v2Position variable and a corresponding v2PixelPosition variable. Velocity and forces are all implemented by my own systems and applied to the v2Position. In the Update() v2PixelPosition is set to the integer values of v2Position and finally the GameObject.transform.position is set to the v2PixelPosition to get that "pixel perfect" display. This is how I have done the past 4 game projects.

    What I don't get is how the heck do we just turn the built-in physics system off completely? If all of these problems are caused by trying to do things in a normal way (by normal I mean any game not actually using Box2D or any other canned physics system) then surely the ideal would be to have some way to just turn the physics system off period if we do not need or want to use it. I figured by simply not using RigidBodies and only using the colliders and raycasts/boxcasts none of the physics system would be in play. But based on the posts above it sounds like the physics is tightly integrated into everything.

    Anyway, if you run into any issues feel free to send a message because I may have already wrestled with the same issues and found a solution since it sounds like we are developing using a similar style. I don't use the Animator or anything for that matter. All of that stuff is just so simple and quicker to do in code.
     
    Last edited: Mar 8, 2015
  15. shopguy

    shopguy

    Joined:
    Jan 12, 2013
    Posts:
    282
    Thanks for the info, nice to know others are having success doing things in a similar way. I assumed the same about the physics not being "in play" if you don't use any rigidbodies. Since I'm not really seeing any performance issues with the "static colliders" (no rigidbodies) it does make me wonder if we are avoiding that issue, and the physics engine really isn't doing much, because we aren't using ANY rigidbodies. Possibly it is the mixing of moving static colliders and having rigidbodies in the scene that causes most of the overheard? I can imagine when the physics system does have to move something (which I think would only be rigidbodies) it probably does a lot of calculations and caching/etc.. but maybe sense we have no rigidbodies at all, maybe it is smart enough to not do any of that.
    I've published 3 games (all 2D and mobile-friendly) prior to the one I'm working on now, and I did use rigidbodies for those, and they worked well. For sure I love the Unity physics system for a lot of styles of games, but maybe not so much for platformers.

    Same. Sometimes I check my game email/forums daily for a few weeks straight, other times I go a few weeks without checking it... since this is just a hobby for me, at least until I win the lottery.
     
    GarBenjamin likes this.
  16. bryantdrewjones

    bryantdrewjones

    Joined:
    Aug 29, 2011
    Posts:
    147
    Hi MelvMay,

    I didn't see the BoxCast fix in the 5.0.0p1 release notes today. Did it get pushed back to a later patch release? :(

    Cheers!

    Bryant
     
  17. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,326
    Unfortunately I don't think the notes for fixes that come from a previous version get added right now. I can confirm that the fix that went into 4.6.3p1 is present in 5.0.0p1.
     
  18. bryantdrewjones

    bryantdrewjones

    Joined:
    Aug 29, 2011
    Posts:
    147
    Excellent! :) Thank you for the quick response!

    I downloaded the patch release and gave it a try, but something about the way BoxCast behaves still doesn't feel quite right :-/

    Do you still happen to have the repro project I included in Case 669805? I added a non-kinematic RigidBody2D component to my pink box, and it fell until it landed on the ground with a final Y-coordinate of -1.485184. I then exited Play mode, removed the RigidBody2D component, and performed a BoxCast (direction: (0, -1), distance: 1.0) from its starting point towards the ground. The hit data returned from the BoxCast would have put the box's final Y-coordinate at -1.495 (Hit Point: -7.028 -1.9975, Hit Fraction: 0.245, Hit Distance: 0.245).

    Shouldn't that small gap between the pink box and the ground be consistent between the RigidBody2D behaviour and the BoxCast behaviour?

    The reason why it's a concern to me is that, like shopguy, I'm using BoxCast for a non-physics-based character controller. And if I actually move my pink box to that -1.495 y-coordinate, it becomes permanently stuck; all future BoxCasts (including ones along the X-axis that should never be hitting the ground) report a hit with that ground object (Hit Fraction: 0, Hit Distance: 0).

    I can submit a new repro project demonstrating that behaviour?

    Sorry for the long reply :) Thanks for your time, MelvMay! :)
     
    asicath likes this.
  19. bryantdrewjones

    bryantdrewjones

    Joined:
    Aug 29, 2011
    Posts:
    147
    Quick followup! :)

    The code I really want to be able to write essentially boils down to this:

    Code (CSharp):
    1. // Where moveBy = desired amount to move by after taking into account current velocity
    2. int hits = Physics2D.BoxCastNonAlloc( boxCollider.bounds.center, boxCollider.size, transform.rotation.eulerAngles.z, moveBy.normalized, raycastHitBuffer, moveBy.magnitude, layerMask );
    3. if( hits > 0 ) {
    4.     var hit = raycastHitBuffer[ 0 ];
    5.     transform.Translate( ( hit.fraction * moveBy.magnitude ) * moveBy.normalized );
    6. }
    ...but translating my object by the fraction of the BoxCast distance is moving my object so close to the colliders in the scene that it gets stuck :(
     
  20. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,326
    Update: There was another bug reported on both 4.6 and 5.0 where the 2D box/circle cast methods miss contacts. I have fixed this and it will be available in the next available patch release for both of these releases.
     
  21. bryantdrewjones

    bryantdrewjones

    Joined:
    Aug 29, 2011
    Posts:
    147
    Hi MelvMay,

    Thank you for the update! :) Is that bug you mentioned the same one I reported in Case 690123? I hope so!! :) :)
     
  22. Zek23

    Zek23

    Joined:
    Mar 23, 2015
    Posts:
    21
    That sounds very promising for my similar issue: http://forum.unity3d.com/threads/blocking-movement-on-collision.319654/ Any guess on when these patches usually come out?

    In my case I'm using pseudo-physics by manipulating the velocity of the player directly, so it seems that using standard physics collisions on the walls isn't an option since the player doesn't have a real mass/force. I really wish Unity 2D had a better answer for this sort of "retro physics."
     
  23. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,326
    Patches come out
    I'm looking at the case now; I don't think it's related.
     
  24. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,326
    Patches come out weekly.

    If you're setting velocity directly, the physics system still detects collisions and solves them. If you use continuous collision detection then you can guarantee you won't get overlaps or pass-through stuff. You've got ray/shape-cast support to help you detect stuff as well. I'm not sure what else you would want from Unity but I'm always happy and willing to listen to ideas/suggestions.
     
  25. Zek23

    Zek23

    Joined:
    Mar 23, 2015
    Posts:
    21
    Basically to summarize my requirements:

    1. The player uses custom movement code to directly modify velocity in FixedUpdate. Same for enemies.

    2. Walls are completely immovable, any attempt at pushing into one will ignore the vector pointing towards the wall (leaving the perpendicular vector)

    3. Characters and enemies pass through each other, this is handled manually with knockback + invuln frames.

    Does this sound like something the physics engine should support? When I tried to use normal physics, the walls would always get blown away by the player movement even if they have a huge mass. I assume this to be because the direct velocity assignment essentially gives the player infinite force against heavy objects.
     
  26. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,326
    That's what static colliders are for. Don't add a Rigidbody2D component to objects that are immovable (static) and they will never move.

    That's the only problem you describe.