Jump to content
  • Advertisement
Sign in to follow this  
feti

OpenGL isometric depth sorting

This topic is 3940 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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! ;)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!