PDA

View Full Version : basic renderer questions...



Allan Walton
04-21-2002, 07:22 AM
Alright?

I'm about to start programming a basic renderer for something i'm working on and would like to know what areas of OGL i could look at to speed up performance and get things going (e.g i know about vertex pointers, vertex arrays etc but there may be other areas i havent though of yet.)

i was basically going to set up a linked list of objects each with its own vertex array / data that the renderer goes through in sequence and processes. Each object, once added to the list will remain until a corresponding remove obect funtion is called.

Is this a good idea or am i going to run into trouble with something i havent thought of?

Cheers

Allan

Nutty
04-21-2002, 07:36 AM
Thats sounds like a good idea for objects.

If you have two objects of the same model, do not store 2 copies of the mesh. Apart from saving memory, there is another good reason for this further down.

In order to speed things up further, theres a few things to consider.

1) Dont draw what you can't see. Sounds simple, yet soo many ppl still dispatch a couple thousand poly model to the card, even the it's behind the camera.. Object level culling is what you want. Dont bother about culling polys in the object that are offscreen, it's a waste of CPU time, and the gfx card can do it faster.

2) Vendor specific extensions. i.e. VAR (on nv) for storing your vertex data in fast AGP or video memory.

Locked (compiled) vertex arrays, provide good speedup, on data rendered more than once. When I said before if you have more than 1 of the same model, make the objects reference the same vertex arrays, that way using LOCKING on the vertex data, will allow the GFX card to pull that particular mesh into AGP, and do subsequent rendering from there.

3) Write a state wrapper, for changing OpenGL states. Changing states is costly, and the GL API doesn't check if it's already set. So make your wrapper check 1st.

4) Sort your objects by Shader, then by Texture. This helps reduce the total number of state changes per frame.

Hope that helps.
Nutty

[This message has been edited by Nutty (edited 04-21-2002).]