Sign in to follow this  
Hibbs

Object Management

Recommended Posts

Hibbs    126
Im working on a space sim, having gotten to the stage where i have object(mesh's mainly) and particles(billboards) classes working. I now realise that i need to sort the particles so that i can render them back to front. although my mesh's don't contain any alpha polys so they could be rendered first. My question is, with the dynamic nature of my scene would it be advisable to impletment some sort of tree structure to manage the objects, for sorting initally, but also to help with culling and collision later on. I think ive read some where that BSP trees are to slow to work with dynamic environments. any thoughts?

Share this post


Link to post
Share on other sites
Aldenar    378
I don't know how your render is set up, but instead of sending particle systems for rendering, queue them in a list. Once all the opaque objects are rendered you can sort that list you created and render all of it's elements.

I would do the sorting on a particle basis within a particle system (you don't need to sort additive blended particles), but sort by particle system when rendering back to front.

A BSP is mosly good for static indoor scenes, since you work on a space sim, you are probably better with a quadtree|octree or a simple uniform 2D|3D grid.

Share this post


Link to post
Share on other sites
Hibbs    126
i cant see how sorting by particle system will work, as some of my emitters output multiple particle types at the same location.

Anyway ive updated my particle engine to use a staticly declared vertex & index buffer, so i can have all of my emitters outputing to a managed buffer - which at the moment tracks which parts of the buffer use which textures and calls the draw command in batches. Im planning to change this to use a texture which holds a tiled array of textures so I can call the draw command once and alter the Tu & Tv variables instead. Is there an upper limit size of a texture, and can these tiled textures be generated at runtime or is it easier to create them in paintshop or some equivalant?

As the particles need sorting would it be more benifical in the long run to implement an octree (which i could use for culling & collision later on) to handle the sorting?

Share this post


Link to post
Share on other sites
Aldenar    378
That's true if you have multiple particle systems spawning from the same location. The way I use particles in general is that I have a few unrelated emitters that does not intersect each other, so making a huge particle pool isn't worth it.

As you know by the question you asked, sorting all the particles may result in quite a huge amount of texture changes, which is pretty bad performance-wise. Batching multiple particle textures into one big texture is simple using your favorite graphic software, will work fine with any graphic API and it has the advantage of allowing you to use compressed texture formats easily.

Otherwise, it shouldn't be too hard to modify your texture manager to fit many textures into another one. The maximum texture size depends on your graphic card, it can be up to 2048x2048 (and more), but using smaller formats is usually better for compatibility and to help the graphic card's texture cache. For example, you should be fine with 512x512 textures and since particles are often using small textures (32x32, 64x64 or 128x128) you'll be able to pack a lot of them into one texture.

As of octrees, I never really worked with them, I just use qsort() (using Z distance from the camera) and since I don't have 50,000,000 particles, it works just fine :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this