Physics2D.boxcast explainer?

Hi all. I've been wracking my brain trying to figure out how Physics2D.boxcast works. I've been playing around with it and it doesn't make any sense to me. The reference is very vague. Some diagrams would be great, but even a code sample would be a start.

http://docs.unity3d.com/ScriptReference/Physics2D.BoxCast.html

My understanding goes as far as you give it an 'Origin', and then a box of 'Size' is cast out. But from where? Is origin the bottom left of the Size Vector2 or top right? Or the center?
Angle and Direction I think I can figure out myself, but Distance puzzles me. The reference says 'A BoxCast is conceptually like dragging a box through the scene in a particular direction. Any object making contact with the box can be detected and reported.'

But surely then if Size is a vector2, then isn't the distance just the y-value of that? Or am I misunderstanding the reference completely?


It sounds like it'd be perfect for what I want it for (essentially making a box trigger without using a box trigger collider, which isn't working the way I need it to), but I can't understand it. Any advice? Has anyone got one working before?

 

You'd think it's something like this right? I think the origin should be in the middle, not sure.

 

Yeah, that sounds about right. But I still don't really understand the direction there when it's 2D physics.

Also, some confirmation on the origin as well.

I've played around a lot with the x,y size values, but they seem arbitrary to me (of course I know they're not, I just can't figure them out). I increase the x value till it's working in one area, and then I move something so the boxcast hits it and turns out it's way longer than I thought it was. But lowering the x value then it stops working in the first area, which I'm assuming means the orgin is not where I thought it was.

It's annoying that the unity documentation is so vague in places. The 2D tools have been around long enough to provide proper explainers for these kind of things, but the link above seems to spend more time on how a RaycastHit variable works, which is already explained in detail in numerous other places.

 

Tell me about it... lol

I'm pretty sure Unity Technologies don't care about 2D games. Or their developers are incompetent to make anything 2D.

I just encountered terrible 2D Physics issues which are inexplicable. There are also a lot of graphical glitches on 2D sprites that happen when the camera is moving.

And I'm even using their 2D scripts that are provided in the Asset Store...

I mean even the colliders are so broken! If I have multiple tiles next to each other which have box colliders the character movement gets jerky in between the colliders.

Well enough bitching, let's just hope they update it soon.

 

Somewhat similar experience here, I'm having a hard time making pretty simple stuff glitch free. The 2d physics apparently operate within an extremely small threshold or something, joints collapse frequently and a lot of the implementation direction in general is unintuitive.

Thats pretty clear, and the description of the properties are similar to the rest of the cast's. You're working in 2D so its just a box, not a cube. The illustration above isn't accurate, the depth min/max would be along the Z axis in 2d space but its not literal, its going to use the depth levels as you specify in the sprites and such since the 2d physics engine does not consider the Z depth at all, its driven by the layer/depth system.

 

It is a box and a destination box, not a cube, it's hard to illustrate it without using 3D space, but imagine it in 2D.

 

Ah that makes sense, its not rotated to align so I assumed it was 3D.

 

I agree that it sounds clear and simple in theory, it's just that it doesn't seem to function like that in practice. Or if it is working like that, it's very hard to test that without any way to visualise it on screen.



Regarding the 2D stuff in general, yeah I'm finding it a bit buggy. This game I'm working on now is pretty much all physics based because it has to be, so I'm not looking forward to issues I'll probably come across. But yeah, I've done some rough platformer demos a while back, and I ended up striping out most of the physics stuff with the character. I found it way too hard to get it to feel like a platform game using the physics engine.

 

Just to clear this up, I had a bit of trouble with boxcasting as well but came to the conclusion that the Size parameter is actually from one end of the "box" to the other, like to the size parameter in Bounds. What is described in the image above as "Size" would actually be 1/2 of the Size parameter.

 

@Shadeless the 2D physics glitches you're talking about are the same with every other engine as long as you use rigid bodies. You're better off using standard collision checking by code if you want to avoid that.

BTW I've been looking into BoxCast as well as that could be an optimization when casting lots of rays checking for collisions while moving, but I don't get where the origin is supposed to be. Anyone who actually found out how those parameters work?