🔒 Locked

Renderer Idea

Started by silvermace Jul 18, 2003 at 1:21 AM 3 replies 700+ views

Original Post

Jul 18, 2003 at 1:21 AM

hi, i need some advice from all you pro coders lurking around

the renderer creates a list of faces to render, then sorts them and flushes them i have an idea which may improve performace.. create aa 3 or so list buffer, each list has a maximum of say 500 faces once a list is full, it is flushed down the pipeline and waits to be filled again, so, while the list is being flushed, could i create another thread and sort the next list to be flushed, and sort everything while the data is being rendered? eg.


//call the renderer
renderer::sendfaces(...)
renderer::flush()

//implementation
void renderer::flush()
{
  while( !flush_complete )
  {
     while( !current_list_full )
        addfacetolist();

     if( renderering )
         createthread( sortlist(next_list) );
     else 
     {
         sortlist(current_list);
     }
 
     renderlist(current_list);
  }
}

im really bad at explaining things, but if anyone had done something similar, would you mind giving me some tips on implementation etc? thanx - danushka contact: MSN & email: silvermace007@hotmail.com edit: formating

A GOOD friend will come bail you out of jail... but, a TRUE friend will be sitting next to you saying, "Damn, we fucked up." Ingite 3D Game Engine Home -- Just click it [edited by - silvermace on July 18, 2003 2:23:43 AM]

drslush

Jul 18, 2003 at 12:40 PM

With modern hardware, rendering is asynchronous (its done independently from the CPU processing), your idea probably wouldn''t improve performance significantly (if at all). I''m no expert, however, so you could always try your idea to see if it worked.

silvermace

Jul 18, 2003 at 5:48 PM

i dont see how it wouldnt, but what about a HT system or MP system, i think there is room for a speed increase,

the renderer waits for the pipeline to flush before returning.

do you think i should not bother?

-- thanx
- danushka

A GOOD friend will come bail you out of jail...
but, a TRUE friend will be sitting next to you saying, "Damn, we fucked up."
Ingite 3D Game Engine Home -- Just click it

Namethatnobodyelsetook

Jul 18, 2003 at 7:25 PM

Sorting each face is generally a waste of time. A rough sort based on object position is generally all you need. For certain alpha-blended objects you may want to do per-face sorting, but there are typically few of these per frame, and they''re often low-poly, so sorting doesn''t take much CPU effort.

If you happen to have a high-poly, alpha-blended mesh, then you might want to look into some other optimal way to sort, but as mentioned. The GPU will draw the previous batch(s) of polys while you''re busying sorting the next batch.

Multi-threading has uses (streaming level data, performing AI, or handling network traffic), but typically you want in-order execution of your rendering. Spawning a sorting thread wouldn''t do much good, since the main thread would have to wait for the sorting thread to finish before it could continue. If you were thinking of drawing in the sorting thread, you''ve got even more problems, as you''ll have multiple threads all trying to change renderstates, and textures all at once. You''ve created a nightmare for yourself doing that.

Now, if we could set a renderstate flag to tell DirectX that we want it to sort the polys it could be good. It would break the current pipeline, but if hardware has a large buffer instead of a small vertex cache, and could optionally transform all the vertices, sort them, and only then rasterize them, that''d be a sweet feature. When the flag is off, it wouldn''t have to transform everything before rasterization, and everything could execute in a nice pipeline as it always has.

The reason why this would be sweet for hardware, is that for transparent objects, you have to make the CPU do all the world/view/project math and sorting, which eliminates the need for most GPU capabilities. If it''s a skinned model, you need to do skinning on the CPU too, to sort properly. If hardware could be told to do this, we''d have more realistic hair, fur, see-through aliens, and more.

Anyway, I''ll stop dreaming now.

Iemanji

Jul 22, 2003 at 6:35 PM

As has already been mentioned, face sorting is a bad idea. Object sorting is the way to go.

I would also add that you shouldn''t even sort at the object level if you don''t have to. You don''t need to sort non-alpha objects, and you can cut down on sorting alpha objects by special casing things. For instance, if you have two rooms separated by a pane of glass, and you know the camera will only be in room A, then the draw order should be:
- non-alpha objects.
- alpha objects from room B
- pane of glass separating the room.
- alpha objects from room A.
While it may still be necessary to sort the alpha objects for the individual rooms, it often isn''t, and this whole mess can be precalculated.

Another possibility would be to assign a priority to each object and always draw the objects from high to low priority.

If you need to draw a single object transparently and eliminate faces showing through from the rear of the model (ie, look like a ghost or something), draw it twice. Once with color writing off and zbuffering on, and then once with color writing on, zbuffering on, and the z function set to ZEQUAL.

And of course, if you need to perfectly draw a glass sculpture with crystalline support rods in an obsidian base flooded with water, I''ve found the best solution is to repeatedly hit the person responsible with a 2x4 until they don''t want to do it anymore.

Lastly, using threading to sort faces isn''t a good idea. The operation doesn''t need to be asynchronous, and on the vast majority of hardware (single-processor machines), all you''re doing is adding the overhead of the OS''s threading functions into your rendering loop.

Topic Locked

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