Well i am not using colliders and even if i do, 2D colliders are not rotated they are axis aligned so they would be like the second example in the image when i need the third example.

I just have a bounds type and a general ray casting method currently. If the object is rotated the bounds isn't accurate to the object as per the image i posted (the second one is where the issue lies) so i get issues. The hit point may be in the bounds but not in the actual segment. Hope that makes sense.

Since the objects are static on the x:z plane and non moving theres no point in 3D colliders or even 2D colliders, using the physics engine is wasted performance and my environment is pretty big it won't be feasible for me to use it.. I was hoping to make it more optimised by checking if the point hits the bounds but making sure the bounds was accurate to the segment (the third example in the image).

The physics system is very efficient, especially if you user layer masks intelligently. The size of your environment shouldn't matter much. And the Physics2D library essentially mirrors its 3D counterpart, so you can just use Physics2D.OverlapBox.

If you're insistent on not using the physics system (I tend to avoid it but in the case of pure raycasting and intersection checks I find it's very useful), I guess you'll just have to write your own OBB logic

Yeah thats the best way to learn :) Plus even if i did use their system. It would be of no use for rotated objects anyway unless i use 3D colliders.

Yeah thats the best way to learn :) Plus even if i did use their system. It would be of no use for rotated objects anyway unless i use 3D colliders.

Physics2D.OverlapBox has an angle parameter for rotation. But writing it from scratch for educational purposes is perfectly respectable imo.

Yeah thats the best way to learn :) Plus even if i did use their system. It would be of no use for rotated objects anyway unless i use 3D colliders.

Physics2D.OverlapBox has an angle parameter for rotation. But writing it from scratch for educational purposes is perfectly respectable imo.

Would the angle parameter be for the box you are applying on top of existing colliders? The colliders would need to be rotated and then do a point overlap rather than a box for raycasting no?

Yeah thats the best way to learn :) Plus even if i did use their system. It would be of no use for rotated objects anyway unless i use 3D colliders.

Physics2D.OverlapBox has an angle parameter for rotation. But writing it from scratch for educational purposes is perfectly respectable imo.

Would the angle parameter be for the box you are applying on top of existing colliders? The colliders would need to be rotated and then do a point overlap rather than a box for raycasting no?

Yes, the angle is for the imaginary box that overlaps the returned colliders. For normal 2D raycasts just use Physics2D.Raycast, but if you're talking about a mouse ray (or anything that uses the z-axis with 2D colliders), yes you'll need to use OverlapPoint (or just use 3D colliders and raycast along the correct axis, but that's less efficient).

IIRC, 2D colliders rotate around the z-axis corresponding to their transform by default, so you shouldn't need to worry about rotating them yourself.