isometric depth sorting

I use the z-buffer to sort my isometric sprites. They are rendered to different sized cubes and have matching texture coordinates so that they look "2D". You must use alpha testing with this approach, blending does not work well with z-buffer. I render the world in a 2-1 perspective/diamond shaped tiles/cubes. I would recommend this to anyone who is rendering isometric 2D shapes with OpenGL. A picture showing hypothetic texture coordinates for a "tree sized"-cube:

Numbers on last image is just a rough guess where the texture coords should be.

Working with tiles in this way OpenGL will take care off all z-order issues automatically. The cubes provide you with the correct z-buffer value. Good luck.

O-san,

Great example. The 2d sprite that you draw looks normal correct? There's no skewing when you draw it in photoshop or whichever application you use? Also, let's say the trunk of your tree is 1 tile, although it uses up 2x2 to render it, you have a separate collision box for the trunk?

[Edited by - feti on November 2, 2007 8:34:37 AM]

I have split up my trees in two boxes.. one 2x2x5 box for the tree trunk and a 6x7x9 for the tree top. I have no seperate collision boxes atm.

Quote:

If I'm doing isometric in opengl, and I'm moving all stuff based on world coordinates, is it safe to use GL_DEPTH_TEST and render my rectangles for the sprites with a z offset in order to force proper depth?

It should be safe, provided you stick strictly to 2D quads and use all-or-nothing transparency. If you know the z-offset, though, it should be simple enough to perform a depth-sort prior to rendering, in which case the DEPTH_TEST is unnecesary, and you can use the full alpha range.

Quote:

They are rendered to different sized cubes and have matching texture coordinates so that they look "2D".

Why? Why not simply use Quads that you position on-screen to simulate an isometric layout? It should be simple enough with a little Matrix math.

Oh wait, that is right. I'm going to have alpha blending issues if I use opengl's depth sorting instead of rendering back to front myself. Dangit. I wanted to avoid that.

Oh wait, that is right. I'm going to have alpha blending issues if I use opengl's depth sorting instead of rendering back to front myself. Dangit. I wanted to avoid that. That shouldn't be too big of a deal I suppose.

Now, the way I'm drawing my isometric view is that I first rotate 35 on the x axis, then -45 on the y axis. Then I draw my tiles. Is this a stupid way to draw tiles? I'm thinking it might be. Should I physically draw diamond shape quads instead?

I'm thinking it will be very hard for me to determine which tiles need to be drawn if I continue to use my rotate then draw style. But if I physically draw diamond shape tiles I will know ahead of time which ones I need to draw. It just seems a tad silly for me to draw diamond shape tiles.

Quote:

Original post by Pelagius Why? Why not simply use Quads that you position on-screen to simulate an isometric layout? It should be simple enough with a little Matrix math.

If I only render them as quads they would be flat in the z-buffer. The cube renders varying depth values to the z-buffer.

How would the z-buffer know how to interpret the following example using flat quads? They would both generate the same z-buffer (light gray area) regardless of the 2D shape underneath.



With flat quads I need some sort of sorting, either by manually placing them at the appropriate z-value or by sorting them in the right order (which is not always possible). The z-buffer solves the painter’s algorithm dilemma:



What order should you draw the 2D sprites in? The z-buffer solves this by checking each pixels depth value before rendering.

Umm, it might be simpler just to say that the z value is equal to the y value (or maxy - y). that way the closer to the bottom of you're screen the sprite is, the more "on top" it is.

I might have missed something that you're doing that's making this a bad idea, but I've always been of the "Keep It Simple, Stupid" school.

That solution generally works... but consider this scenario:



I can't find a way sort these 2D sprites without one overlapping the other. That causes restrictions in the way you place your 2D sprites. Either you cut the objects into smaller cubes with seams that match (heavy workload on the artist) or you force your level editor to reject such placements. Either way you have compromised. The z-buffer removes this problem. With today’s graphic cards that can render loads of polygons, replacing the sprite quads with cubes which have depth values isn’t a big impact on the frame rate. I would prefer the z-buffer method any day if it allows me to build without restriction… bridges, tunnels, houses with many floors etc..

If you aren't convinced of the MAGIC that is the z-buffer I don't know how to explain it better! ;)

Quote:

Now, the way I'm drawing my isometric view is that I first rotate 35 on the x axis, then -45 on the y axis. Then I draw my tiles. Is this a stupid way to draw tiles? I'm thinking it might be. Should I physically draw diamond shape quads instead?

I've found that glRotatef(54, 1, 0, 0), followed by glRotatef(45, 0, 0, 1) will give you a precise diamond-shape for tiling along the xy plane. (Strictly speaking, 54 degrees should be asin(sqrt(2/3)), to be exact.) Get the resultant matrix and use this to position your quads in two dimesnions to simulate 3-dimensional placement.

Quote:

I'm thinking it will be very hard for me to determine which tiles need to be drawn if I continue to use my rotate then draw style. But if I physically draw diamond shape tiles I will know ahead of time which ones I need to draw. It just seems a tad silly for me to draw diamond shape tiles.]

If you're talking about performing frustrum culling, then this should be very simple with 2d sprites. Once you position the quads, you can simply check to see if the 'image' bounds intersect the viewport bounds.

Quote:

If I only render them as quads they would be flat in the z-buffer. The cube renders varying depth values to the z-buffer.

If you have the 3-dimensional position of the objects they're intended to represent- which would, I think, be more or less required in order to set up your cubes- you can simply convert those into screen coordinates, then vary the z-value for the Quads you render. You'll still have those alpha blending problems, of course.

I'm just not seeing the benefit of this added complexity.