Quote:Original post by fareed_d
If the rendering was invoked from each node, surely this would mean that every node that contained geometry would need to be updated every frame?

For every frame each geometry node is required to be tested whether or not it needs to be rendered (keyword "visibility culling", you remember; some ways of speeding up like a suitable spatial management structure and frame coherency, if needed, can be used). This _may_ mean that for each node the global matrix needs to be re-computed (if it is dirty) just for the case of visibility culling. Only geometry that has passed the visibility check will be handled further, i.e. passed through the rendering pipeline.

However, the geometry, if it is static or skinning is done on the GPU or some other trick like this, already is on the GPU and hence need not be transferred again (that is why it is called static geometry). Only geometry where vertices are changed by the CPU need to be transfered again.

Quote:Original post by haegarr

Quote:Original post by fareed_d
If the rendering was invoked from each node, surely this would mean that every node that contained geometry would need to be updated every frame?

For every frame each geometry node is required to be tested whether or not it needs to be rendered (keyword "visibility culling", you remember; some ways of speeding up like a suitable spatial management structure and frame coherency, if needed, can be used). This _may_ mean that for each node the global matrix needs to be re-computed (if it is dirty) just for the case of visibility culling. Only geometry that has passed the visibility check will be handled further, i.e. passed through the rendering pipeline.

However, the geometry, if it is static or skinning is done on the GPU or some other trick like this, already is on the GPU and hence need not be transferred again (that is why it is called static geometry). Only geometry where vertices are changed by the CPU need to be transfered again.

Well, thats great! The question is, how would I set up a VBO in openGL so that only geometry whose vertices have changed are transferred, and static geometry stays on the GPU?

Thanks a lot for your help, by the way ^^

Quote:Original post by fareed_d
The question is, how would I set up a VBO in openGL so that only geometry whose vertices have changed are transferred, and static geometry stays on the GPU?

OpenGL knows the modes STATIC, STREAM, and DYNAMIC for its VBOs. There are further MapBuffer, UnmapBuffer, and BufferData routines. There is e.g. a White Paper from NVIDIA that explains the differences.

Quote:Original post by haegarr

Quote:Original post by fareed_d
The question is, how would I set up a VBO in openGL so that only geometry whose vertices have changed are transferred, and static geometry stays on the GPU?

OpenGL knows the modes STATIC, STREAM, and DYNAMIC for its VBOs. There are further MapBuffer, UnmapBuffer, and BufferData routines. There is e.g. a White Paper from NVIDIA that explains the differences.

Thanks for that :>
Reading that whitepaper, I think that I have discovered the difference in our ways of thinking; the projects that I am thinking of developing with my scenegraph are the sort where most objects will be textured quadrilaterals; as such, only 4 vertices per geometry object would be transformed in one go. With complex objects, I am sure that rendering Geometries individually using a VBO for each one is the way to go.

For GL_QUAD objects (I've decided against using openGL 3.x for now), surely the quickest way to render them is to push and substitute their vertices into a single static array, and then use one glDrawArrays call to render them all in one go? That is what my application is doing currently.