Screen coordinates to a multilevel isometric world

Question

I have an isometric world that has stuff on multiple levels, i.e. it has an XYZ coordinate system, and tiles can be stacked on each other, accumulating screen Y offset as they go. I currently have an algorithm in place that converts the screen coordinates to world XY coordinates, but it doesnt take into account that there might be e.g. a hill under the mouse and selects the tile behind it instead.

Is there a generalized form algorithm for this? I need a generalized form because all the variables are unknown (I'm writing a game engine):

• Tile width (as in the width of a single tile rectangle)
• Tile height (as in the height of a single tile rectangle)
• Tile depth (as in how much Y offset each level contributes)

I suppose one option is run down the map with something like this (pseudo code):

p = screenToMap(screenPos)
bestMatch = null

for (x=p.x, y=p.y, z=0; x<mapWidth && y<mapHeight; x++, y++, z++) {
  b = highestPlacedBlockInPos(x, y)

  if (b.z === z) bestMatch = [x, y, z]
}

But I'm wondering if there's a better way? This seems pretty ineffective especially if you have a big map.

Answer 1

Depending on the specific requirements, it might be better to use a color picking system rather than converting the coordinates back manually.

Basically give every selectable object/tile a unique color and when you render the object also render it's silhouette to a secondary unseen buffer. Then when the user clicks look up the color at the coordinates they clicked and look it up.

This would allow you to ensure that what the user clicks on is what they select. You could select a plane flying high above the ground for example. Or pick out a object in a stack of overlaying ones. It is also more general solution that could work with any rotation and completely different engine types. You can even expand on it to do per-polygon picking in 3D.

Of course it has the cost of some extra memory (for the buffer) additional rendering time (possibly a 2nd pass depending on what you are using to render) and having to keep track of the objects. Neither of which would be an issue on any hardware now days (or decades ago even).

Answer 2

Another approach could be to store your tiles as an array or stack of tiles for each x, y. So let's say ..

map[1, 2] = ["grass", nil, "hill"]

You can just take the mouse coordinates and calculate the map coordinates and just take the top tile as what the user selected.

The catch to this is that the "hill" tile's coordinates are actually x=3, y=4, z=2. But for rendering and click detection purposes it belongs to x=1, y=2. Note that if you don't actually care about being able to calculate the real coordinates of the top tile, and just want the tile itself, you can leave out the nils. They're just there to preserve depth.

Another upside to this approach is say the player is located at x=1, y=2 and you want to show the tile the player is standing on and perhaps show overlapping tiles at 50% transparency you just draw the top tile at 50% before drawing the player, then draw the bottom tile.

If you don't actually want to store your map data this way you can do something like ..

for (x=0; x<map.width; x++) {
    for (y=0; y<map.height; y++) {
        for (z=0; z<map[x, y].depth; z++)
            //not entirely sure how you're storing your tiles
            render_map[x - z, y - z].add(map[x, y].tile_at_depth(z))
        }
    }
}
//Doesn't preserve depth with nils

I'm making some assumptions about your map object but I think you get the idea. Hope this helps.