Sign in to follow this  
l0calh05t

Scene graph/render graph design

Recommended Posts

l0calh05t    1796
I'm currently working on writing my first complete game/3d engine and I wonder about one thing: How should I best organize my Mesh data? I was planning on sorting the render calls in some way (to eliminate excessive texture&shader binding and unbinding) Of course I can't use the same tree/queue for frustum culling and collision detection due the lack of spatial information, so I decided I should create a separate tree structure which contains spatial information (perhaps a ABT or tree of AABB's or something else, haven't really decided yet). Basically I want to split it into a scenegraph and a rendergraph... But how do I take care of the mesh data/vertex arrays/vertex buffers?? because collision/physics might also need mesh information I can't really have that data in the rendergraph and I want to minimize interdependency between the two, and rebuilding the renderqueue including vertex/mesh data each frame seems like a huge memory hog, can someone help me with this? (As soon as this problem is solved expect more problems and questions from me, because I had the crazy notion of creating an engine designed for city rendering, which means huge amounts of depth complexity etc.etc.)

Share this post


Link to post
Share on other sites
l0calh05t    1796
Quote:
Original post by okonomiyaki
There are already a couple discussions going on about this.

http://www.gamedev.net/community/forums/topic.asp?topic_id=261688

You have a very general question, and there are many ways to go about it. It depends on the requirements of your engine.


Well, I've already seen that thread and searched for similar ones, but my question wasn't answered in those, so I decided to start a new thread. Besides, my question isn't *that* general: I don't want to know in what order I should sort things (thats simply a matter of profiling and this is what really depends on the requirements of my engine), but how to best manage vertex/mesh data (and nothing else for the moment) without having to rebuild a huge array of vertices (and their indices) every frame and yet be able to transfer the data to the GPU as efficiently and not on a per-mesh basis.

Share this post


Link to post
Share on other sites
okonomiyaki    548
Well, hopefully you have access to vertex buffer objects. Using those, I would recommend reserving a large portion of video memory, and managing the memory yourself. This lets you come up with some neat schemes similar to operating system caching.
Comparing your interaction with the memory, think of the reserved memory as RAM cache, and then your data not residing on the GPU as the hard disk. You should come up with a scheme that efficiently caches the data onto the reserved video memory. With today's hardware, you should be able to reserve large enough portion so that swapping doesn't happen very often, maybe only when a new object appears in the scene. But most likely every frame most things will already be cached (uploaded to vram) so you simply render it. If your scene gets very complex, some swapping might go on every frame, but depending on your scheme it shouldn't be horrible. It's better than depending on the drivers to switch to system memory when video memory is getting low.

I figured you weren't asking how to just manage mesh data on the HDD/RAM, but rather managing it between the system and the video card. Sorry if my answer was off.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this