2
\$\begingroup\$

I am working on a top down 2.5D game. In the game anything that overlaps on the screen should be 'colliding' with each other regardless of whether they are on the same plane in the 3D world. This is illustrated below from a side-ways view:

enter image description here The orange and green circles are spheres floating in the 3D world. They are projected onto a plane parallel to the viewport plane (y = 0 in the image) and if they overlap there is a collision event between them. These spheres are attached to other meshes to represent the sphere bounding boxes for collisions.

The way I plan to implement this at the moment is the following:

  1. Get the 3D world position at the center of the sphere.
  2. Use Camera.WorldToViewportPoint to project the point to the viewport plane.
  3. Move a Sphere Collider with the radius of the sphere to that point.
  4. Test for collisions using unity colliders.

My question is how to extend this to work for rotated cuboids. For instance if I have two rotated cuboids, if I follow the logic above it would not work as intended as the cuboids may not collide but they could still be intersected on the view plane. An example is below:

enter image description here

In the example above the cuboids are overlapping from the view of the player, but not colliding when they should be.

Is there a way to project a cuboid that would be aligned with the plane? Would it be a valid cuboid for all rotations if I did this?

EDIT: Corrected the images, before they were incorrectly projecting onto the y=0 plane at 0 rotation, not the plane parallel to the viewport plane.

\$\endgroup\$
4
  • \$\begingroup\$ Even Though it's a birds eye view couldn't you just project downwards parallel to the y axis? It's rather confusing why the objects and projection are parallel to the screen planes axis. \$\endgroup\$
    – Sidar
    Nov 11, 2013 at 12:05
  • \$\begingroup\$ Sorry, I uploaded incorrect images explaining the problem. The reason why I project onto the collision plane (parallel to view port plane) is because it matches up directly with what the player is seeing. Hopefully the new images make it clearer what I am trying to achieve. \$\endgroup\$
    – Jkh2
    Nov 11, 2013 at 23:53
  • \$\begingroup\$ But are you certain that would actually make a difference? The user is not going to notice any of the collision processing nor is he going to notice the angle in which they should collide. aesthetically it won't matter. It just going to see 2 objects overlap. Are you sure this is necessary? Projecting on the z axis should suffice i think. \$\endgroup\$
    – Sidar
    Nov 12, 2013 at 0:07
  • \$\begingroup\$ If there are two cubes side by side and they are both rotationally aligned with the view plane if you view them they won't be overlapping but if you project them straight down into the ground/Z plane they will be colliding which is incorrect as the player sees them as not overlapping. I will add an image with this example shortly. \$\endgroup\$
    – Jkh2
    Nov 12, 2013 at 1:21

1 Answer 1

1
\$\begingroup\$

You might use Plane's Normal (in math), get your view's normal, get spheres or other objects position and every objects, plane's normal by their rotation, scale for size of collision tests, get distances and make a simple Ray collisions, so you can use that Boolean ray for your game, if your framework has Physic engine then certainly that engine has ray tests.

Edit:

Idea 1 (Slow)

This idea might works! every collision cube has 2 planes with distance of scale-Y of cube and length of scale-x for accurate collision.

if any CollisionCubes is in view-port (CPU usage)

if number of CollisionCubes > 2

    then every CollisionCubes plane send ray from 4 tips of your planes to down & test with other cubes 

       if collision accured
          then you have collision

Idea 2 (Better & Faster)

This may be faster and much better, if you are using just in 2d like perspective,

every Collision-cube when rotate its length of collision to plane would change depends on, say you just Projected on cube without rotation and its Scale-X is your length of collision, if you rotate that Cube 90-degrees then you have Scale-Y as length of your collision, so, think of this cube as a Sphere that changes its Scale, that is simple you have Sphere collision that just changes its Scale when Rotate, this would be much easier to calculate just like first example you showed.

\$\endgroup\$
2
  • \$\begingroup\$ I am not sure I am completely following you here. If I get the normals of all the planes of the objects I am detecting I can project them down to the plane but what would I test the rays against? I dont have any surfaces to test collision against. \$\endgroup\$
    – Jkh2
    Nov 11, 2013 at 23:56
  • \$\begingroup\$ You may look at how parallel Shadows like Sun works, if you are using Unity-3d there is "Physics.Raycast" class (I do not know Unity), this may help you, I edited post with an idea, might be useful. \$\endgroup\$
    – daniel
    Nov 12, 2013 at 8:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .