Archived

This topic is now archived and is closed to further replies.

Organising Geometry Data Cache

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

I''m am currently re-designing the data structures that get passed to my render interface, and wanted to check out that i am working along the right lines. I have a shader state class which contains current states such as depth buffering, alpha testing textures etc.. This is how I group my ''GeometryChunks'' in the render queue to minimise state changes. Now my GeometryChunk will contain a compressed representation(eventually, but it is uncompressed for now) of the vertex data. It also contains a hardware buffer handle, which is NULL initially. When the renderer receives a geometryChunk it checks to see if the hardware buffer is NULL, if it is then a new HardwareVertexBuffer is created, or if has a value, then this checked to see if it is still in the cache, if it is then it is retrieved, if not then it is recreated. Should I also pass a matrix in the geometry chunk to represent the local transformation to allow reuse of the hardware buffer, for multiple instances of the same mesh. The only trouble that I will have with this is keeping the geometryChunk structures synchronised with each other. i.e. if in the render queue there are two geometrychunks that describe the same geometry, but have different transformation matrices, once the first one has been cached into the hardwareVertexBuffer, how will the second one know that the same geometry is already loaded into the cache? Sorry for the long explanation, but if anyone has any comments or suggestions on this method I, would like to know. James

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Should I also pass a matrix in the geometry chunk to represent the local transformation to allow reuse of the hardware buffer, for multiple instances of the same mesh. The only trouble that I will have with this is keeping the geometryChunk structures synchronised with each other. i.e. if in the render queue there are two geometrychunks that describe the same geometry, but have different transformation matrices, once the first one has been cached into the hardwareVertexBuffer, how will the second one know that the same geometry is already loaded into the cache?

Well there''s not enough detail given on the system you''re using, so this idea can be completely useless to you. But one possible way might be to only have one geometry chunk with specific piece of geometry, and have a queue (stack, vector, whatever) of transformation matrices in it so that when your renderer receives it, it can simply cache this single instance in hardware buffer then traverse the queue rendering the geometry requested number of times,(which could be anything from 1 to n ) each time with new matrix pulled from the queue?..

Share this post


Link to post
Share on other sites
Yeah, i could do that, but that would require some kind of merging system as I add things to the queue, since I am planning on using a ABT tree structure to organise the world. I think that what I will do is add an extra level of indirection i.e. a Renderable class which contains a pointer to a geometrychunk. This way the renderable class can contain the transformation matrices. Since the case where reuse of geometry will occur is going to be on instances of meshes, then the mesh class can hold the ''master'' geometry chunk and be responsible for its loading etc. and the renderable objects i.e. the instances of the mesh can point to the parent meshes geometrychunk.

However, thinking about it, your ideae will come in useful when processing the renderables with the same shaderstate. It will be trivial to check each renderable''s geometrychunk pointer to see if there are any duplicates, and clump these together in the render process, since I think that the hardware will probably perform better if it''s processing the same geometry succesively because in the case of the data not fitting in the graphics memory it may be swapped out, and back in again, causing a performance hit, any thoughts on that?

Share this post


Link to post
Share on other sites
Keep in mind that Direct3D (OpenGL also I think) manage VB & IB the same way as textures, that is using LRU algorithm (Least Rencently Used)

So the API will transparently swap the buffers and textures between video & system memory using the LRU if there is not enough video memory to hold everything.

Eventually, if your engine uses a huge amount of those buffers, the ones thar have not been used recently and which reside in system memory will be swaped to virtual memory (HDD).

The question is: Will you trust the API for your data swapping, or will you try to make your own caching/swapping system to improve performance.

With today 128MB video memory and such, it may not be necessary to worry about data swapping.

Profile your engine, and push it to its limits by benchmarking more and more complex scenes.

I hope that was helpful to you ...

Share this post


Link to post
Share on other sites