Jump to content
  • Advertisement
Sign in to follow this  
tchamblee

graphic object list!

This topic is 4865 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

Disclaimer: I am long winded and have been known to ramble. However, if you can make sense of any of my questions, I am in great need of advice! How should I implement the graphic object list in my engine? I will say "list" for lack of a more appropriate term, even though technically the objects may not be arranged in a list. I have a base GraphicObject interface class from which all of my game's graphical objects are inherited from. I have implemented the graphic object list as a simple linked list with the capability of heirarchical relationships between objects, but now I am ready to make the thing not just usable, but practical. First of all, what data structure should I use to implement the graphic object list? The list will need to support large numbers of objects with multiple additions/removals from the list. The list will also have to be sorted and/or minimized. Secondly, how should I seek to optimize the graphic object list? From what I know, I should try to minimize state changes, minimize overdraw, and batch vertices as much as possible. Should I sort my graphic object list according to the z-coordinate of the objects, sorting from front to back, and rendering in that order? And as for batching vertices, should I build a single large vertex buffer from all objects in the graphic object list, and then blast them to the display adapter? It seems like the cost of building the vertex buffer every frame would outweight the gains of cutting down the render state changes just a little. I have considered batching vertices on a case-by-case basis, depending on the number and type of objects. For example, if I have a game with a landscape where 50-100 trees are visible at any one time, and all of these tree objects use the same geometry and textures. I could remove these objects from the front-to-back sorting of the graphic object list, and batch them all together into a single large vertex buffer, rendering them all at one time, but increasing the overdraw percentage. I don't have much experience in 3D graphics and I would love to here some comments about this subject. Thank you!

Share this post


Link to post
Share on other sites
Advertisement
I am no expert. What follows is opinion, which will likely have varying degrees of correctness.

The arrangement of the objects should be in the way that makes the most sense with your setup. Some setups [like gui-heavy designs] might be better as trees for example, because you get auto-magical destruction and application of events to children of objects. Some setups don't have many linked children, and might be better as flat lists. Some setups do a lot of collision detection, and might need some benefit ingrained to the object. It depends...

Yes, [generally] texture switches are costly, as well as state changes and unneeded vertex drawing. Though doing it the most naive way possible will still be 'good enough' for many hobbyist games on modern hardware.

I would [and do] sort back to front, rendering in that order. After all, closer things would occlude farther things, right?

Yes, in an ideal world you'd have one large vertex buffer. Less buffers means less overhead. A number I've heard bantered about is that one texture switch is about as costly as pushing 1000 triangles to the buffer. I am not sure as to its accuracy, but such practices are pushed hard around here without much counter making me think it's close to that sort of impact.

In my experience, the first two or three tries at complex software suck. Just start with something you think is good. You'll learn well enough along the way what parts are good, and what parts are bad. Experience beats advice at this sort of thing any day.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
I would [and do] sort back to front, rendering in that order. After all, closer things would occlude farther things, right?


I don't think that's such a good idea any more. Early depth tests can mean it's actually better to sort front to back, so overdraw is discarded quicker. Personally, excluding of course translucent objects, I wouldn't spend the cpu time to sort at all.

Share this post


Link to post
Share on other sites
You might consider using a scene graph to store your graphics data in a hierarchical fashion. This recent topic goes into design issues of SG (including sorting) and also contains a useful link. Of course this can be overkill if you just want something simple. I do recommend it though, because a well built scene graph is very convenient to use.

Quote:

I don't think that's such a good idea any more. Early depth tests can mean it's actually better to sort front to back, so overdraw is discarded quicker. Personally, excluding of course translucent objects, I wouldn't spend the cpu time to sort at all.

I agree. However, note that proper sorting of translucent objects in general is impossible on object level (unless only convex, non-intersecting translucent objects are allowed). They only way to get proper images from scenes with multiple translucent objects, is by sorting individual triangles (and even then you may need to split them up). I believe BSP trees can be used for this (although I'm not a BSP tree expert).

Tom

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!