Skip to main content
gamedev.net
🔒 Locked

[.net] Efficient entity sorting

Started by transwarp 5 replies 1k views
Original Post
transwarp
transwarp
Hello world, :) I'm currently developing a game with Managed DirectX and C# 2.0. In my custom engine I organize renderable Entity in one or more Scene classes. During the render process these Entities need to be sorted in multiple ways: - Opaque entities from front-to-back for better performance with the ZBuffer - Alpha blended entities from back-to-front - All entities from front-to-back for Mouse Picking And when I render the same scene from a different angle (e.g. for a reflection) I need to resort everything again. Currently I store the entities like this:
private List<Entity> Entities;
Whenever I need to sort the entities, I use the List's .Sort() method, which allows me to pass a custom Comparison delegate:
public void Render()
{
   ...

   Entities.Sort(new Comparison<Entity>(CameraDistDiff));

   ...
}

private int CameraDistDiff(Entity entity1, Entity entity2)
{
    // Compares the distance of two entities to the camera
}
So far this method works just fine, however I suppose once my scene starts containing more objects (currently it's just about 10) resorting the list multiple times every single frame might become a serious bottleneck in the render loop. Now here are my questions: - Is there some more efficient way to handle all this sorting? - Would it make sense to create a copy for each required order of the list, recreating and resorting these copies whenever the base list changes? - Is a List<> a good storage method anyway? - Might it be worth the hassle turning my single-threaded application into a multi-threaded one, to better handle the sorting on Dual Core systems? Eagerly awaiting your opinions, Bastian
gharen2
gharen2
The best way to increase the efficiency of the sorting is to implement culling. Make sure that you're ONLY sorting scene objects that will be rendered. This can be further sped up by using one of the more advanced means of organising your scene, such as octrees.

Making a copy of each sorted list is reasonable. Copying and storing them each frame would also allow the user to make use of each version.

List or the related classes (such as Dictionary) are a perfectly acceptable way of storing your scene objects. Sure, an array might be slightly faster, but it's inflexible.

I wouldn't put the sorting in a different thread. The two threads are meant to run side by side independently, but sorting is something that has to be done prior to rendering. Thus your rendering thread would have to stop and wait for the sorting thread anyways. It would be better to use the other thread for physics or resource loading or something.

[Edited by - gharen2 on April 2, 2007 2:24:42 PM]
transwarp
transwarp
Hey, why didn't I think of culling? :D
I just implemented a frustum culling test for rendering a few days I go. I never thought of the fact, that I could cull away stuff even before I do the sorting. Thanks for the hint!

I was kind of dreading the mentioning of octrees. Currently I believe my game is not advanced/complex enough to be worth really advanced methods of scene organisation. But I'll keep it in mind just in case...

What would be a better idea: Recopying the complete list every frame or update the copies on a parallel basis?

Btw: I was never really thrilled about writing thread safe code anyway. :)
gharen2
gharen2
I personally haven't written anything that requires advanced scene organisation either. It's not something I'm going to do unless it's absolutely necessary.

What do you mean by parallel basis? Do you mean retain the differently sorted lists each frame and update them, rather than recreating them? Personally I'd just recreate them. If you retain them, as objects are created or deleted you'll have to update each list accordingly. If you recreate them, you just have to update the "master" list with new or deleted objects.
transwarp
transwarp
Quote:
Do you mean retain the differently sorted lists each frame and update them, rather than recreating them?

Yes, that's exactly what I mean.

I would also prefer recreating the sorted lists each frame (a lot easier to code and maintain), I'm just wondering whether parallel lists might not be more efficient.
ToohrVyk
ToohrVyk
Personally, I wouldn't use a list. I would use a space partitioning scheme, such as a grid, octree or adaptative binary tree. This way, I could cull unseen objects much faster, while also traversing objects in an almost-sorted way.

All that's left after that is to individually sort each grid/tree cube (by keeping a list of contained objects, for instance), which is pretty quick. Even better, since the order of objects probably doesn't change a lot from one frame to another, it would be possible to use a sort algorithm optimized for small nearly-sorted sets of objects, such as insertion sort.
stanlo
stanlo
Quote:
Original post by transwarp
I was kind of dreading the mentioning of octrees. Currently I believe my game is not advanced/complex enough to be worth really advanced methods of scene organisation. But I'll keep it in mind just in case...


If your game isn't complex, you can probably get away with frustum culling only.

Some other ideas are to perform a depth-only pass. I've had problems with older hardware with this for some reason though.

Another idea is to just find big, close objects and render those first. For example, if you have a small clock on a wall, it's never going to be occluding much except when you're staring straight at it up close. Big trees or pillars or walls will probably always be occluding things if they're close to you though.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.