Jump to content
  • Advertisement
Sign in to follow this  
redbaseone

OpenGL suitable rendering algorithm ?

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

Hello,

Im trying to make a simple 3D shooter games in wich
i have many poly's for the level. I'm using OpenGL for rendering.

I have a level (or a map) with lot's of triangles ( aprox. 10000 triangles in my scene). Sending all these triangles at once to OpenGL and rendering them directly is not a good solution, knowing that most of the time some areas are occluded by other triangles.

So, using a algorithm for partitioning space (scene's triangles) will help.

I know that there exist lot's of algorithms for sorting and rendering lightning fast the 3D geometry (at least some of them when implemented good) like:

* binary space partitioning tree (or leaf bsp tree further) .
* octree / quadtree.
* portal rendering
(portals must be done i think at the design/creation time of the map
with the application's level's editor)

My question is (and i hope to learn maybe from your coding experience and knowlege):

* what algortihtm are modern games using for sorting/partitioning/rendering
FAST and LARGE enviroments (i.e. 3d polygons) ??

I just have a "soup of polygons" and i want to sort them somehow so that
rendering will be as fast as possible !


Thank you in advance!

Share this post


Link to post
Share on other sites
Advertisement
10000 tris is nothing on modern hardware! Forget about space partitioning. Dump them in a VBO. Use frustum culling if you must.

Share this post


Link to post
Share on other sites
Thank you for the fast answer !

Should i use hardware occlusion culling extension like
"GL_NV_occlusion_query " toghether with Frustum Culling to be one step further ?

I know that framerate drops when triangles are overlapping ,
so i'm trying to find a solution to this.


(sorry my english is bad)

Share this post


Link to post
Share on other sites
If you group your triangles by proximity to one another then you can quickly filter out a bunch of them at a time if you know they are not in your view.

Otherwise, your best bet is to use binary tree to organize everything.

Share this post


Link to post
Share on other sites
Your triangle count may be reasonably low, but if you just blast them out in any old order it's likely going to punish you on fillrate. Frustum culling 10,000 individual triangles is not going to be very CPU-friendly either, and you need to consider leaving headroom for particle effects, models, etc. So even with such low triangle counts there still remains a lot to be said for doing it the old-fashioned Right Way rather than being lazy (and expecting your customer to pick up your slack for you by buying faster 3D hardware).

Some form of space partitioning will certainly help here. There are well known and well understood solutions for this such as BSPs, Quadtrees and Octrees, which you've already mentioned. You want to be able to reject large groups of triangles quickly before they even get to your GPU, as well as order your scene geometry from front to back (so far as is possible) so as to make best use of your Z-buffer.

Batching your geometry so as to minimise state changes and enable you to submit large groups of triangles with a single draw call is also critical.

I don't recommend use of hardware occlusion queries for this. There is a certain overhead with issuing queries and you need to blaance things finely so that not drawing objects that fail them gains you more than you lose from that overhead. Even worse, reading back the results can stall the pipeline, so you'll need to either accept that or else accept up to a few frames of latency in the results by reading them back those few frames later (which would not be acceptable for your main scene geometry).

The best thing to do is to look at some real-world examples that are known to work, such as the Quake engines, and take inspiration from them.

Share this post


Link to post
Share on other sites
Quote:
Original post by Simon_Roth
10000 tris is nothing on modern hardware! Forget about space partitioning. Dump them in a VBO. Use frustum culling if you must.


Seconded. I've used 20K+ triangles per mesh before without barely taxing the GPU. Mind you I didn't have too many meshes on the go at once, but still- 10K is nothing.

The only optimisation I'd recommend you to do beforehand is to sort the triangles by texture so that you can render all triangles of the same texture in one batch. State changes in the graphics driver can be very expensive.

Other than that, unless this starts becoming a performance problem I'd suggest not to bother optimising at all. That goes for everything else too.

'Premature optimisation is the root of all evil...' [wink]

Share this post


Link to post
Share on other sites
The trouble is that this isn't a mesh. It's all of the scene geometry. Walls, floors and ceilings. Triangle counts are not the relevant item here, it's fillrate and overdraw, and we are deep in overdraw city.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!