Jump to content


Choice of Rendering Algorithm location


  • You cannot reply to this topic
3 replies to this topic

#1 RabidCicada

    New Member

  • Members
  • Pip
  • 2 posts

Posted 23 September 2005 - 06:12 PM

Hi everyone...first post, here goes.

I am a budding graphics programmer and have a question that I find very important but can't find any info on.

What do you think is the best strategy for locating rendering code for an in game "Object"?

I have thought about just using a generic rendering algorithm that just renders using a list of vertecies based on certain rules like rendering Coutner clock wise starting from the top etc.
The only problem is that I see certain objects may be rendered in a more efficient manner by exploiting their structure. For example: think of a wire frame sphere(using longitudinal lines and latitudinal lines). The top most and bottom most polygons are triangles/a triangle strip where the longitudinal lines converge on the center point. Elsewhere are quads/quadstrips.
I thought about storing the rendering algorithm inside of a C++ class in something like object->render(x,y) where x,y are the center co-ordinates in the modelview etc. There would probably be more info passed to render but I am maintaining simplicity. This strategy would require strong objectification of everything.
I haven't taken a strong look at source for any gaming engine/system but I'm sure there is a variety of ways to go about structuring your rendering code.


PLEASE enlighten me to some of your strategies and why or why not to use them.

#2 Reedbeta

    DevMaster Staff

  • Administrators
  • 4979 posts
  • LocationBellevue, WA

Posted 23 September 2005 - 10:48 PM

The object-oriented structure you described works very well in practice. In most cases there are indeed specialized rendering algorithms for each type of object - not necessarily spheres, cones, cylinders, etc but a more advanced engine might have different rendering code for landscapes, buildings, items, characters, and so forth. Don't worry too much about using triangle strips vs triangles vs quads etc - this makes very little difference to the speed of rendering, and so most people keep everything rendered in plain triangles unless there is a compelling need to use tri-strips or something else. One thing to look into is index buffers, as these allow you to easily re-use vertices between multiple triangles in a more general way than tri-strips allow.
reedbeta.com - developer blog, OpenGL demos, and other projects

#3 RabidCicada

    New Member

  • Members
  • Pip
  • 2 posts

Posted 24 September 2005 - 04:07 PM

Thankyou very much for your response...sounds good.

#4 Alex

    Valued Member

  • Members
  • PipPipPip
  • 152 posts

Posted 25 September 2005 - 10:29 AM

On the main page of devmaster is a link to "ATI's GDC-E Presentations Now Available". There you can find a rather detailed description how to get the most performance out of d3d9. On opengl the rule of thumb for me is to use the same or similar ways of submitting geometry as the latest quake/doom does as these paths are mostly pretty well optimized.

If you read the document on the ati page you'll see how awefully complicated it is to get good performance. It can make quite a difference to submit optimized static indexed tristrips to local video memory or plain trilists from agp. Also sorting for render states is very improtand.

Alex





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users