Hello all. I am new to GameDev as a user but a long time fan. I have, as a hobby, in the past built basic rendering engines with DirectX and am currently working on an ambitious project in my spare time. I will not make claim that it will be the best engine ever nor even garauntee completion but I would love to learn more about game-engine design and programming. I've been programing as a hobby on and off for about the last 18 years...yet, in my opinion, know very little and make rookie mistakes and ask rookie questions. So that's my introduction. Hopefully you can all accept me in your community and help me learn. That is why I've come here. Cheers! Now for my question! All of my previous experience has been with small games with small environments. I am currently trying to expand my skills to the realm of MMOGs. I have been designing an Octree structure that I can store and load from disk. My grasp of the theory is fairly sound however I'm getting stuck on a few points. 1) When I subdivide my static world meshes am I storing actual polygons at the leaf nodes or references to them? If I am actually storing polygons then I am not subdividing my larger meshes based on the node percision? Is that a good thing? 2) And here's where I hit the brick wall...How do I represent water in my world and still be able to draw only the polygons that are visible to the view frustrum? I'm thinking looking out to the ocean from the beach. I would like the water to move obviously which means I can't subdivide the mesh into the leaf nodes of the tree. They must remain one mesh. I think I'm starting to answer my own questions...it feels as though I should be storing the meshes seperately and referencing the polygons from the octree for quick collection for the renderer. If I do that however then 1) how do I store that on disk without subdividing the meshes and 2) how do I use the higher mesh helper functions in DirectX when drawing out the data from the octree? I could pull a reference to the mesh and break it into subsets that I can call. I need more guidance on this... Perhaps for world geometry I'll have to pull the polygons and make a new mesh from the result. LOL ok if you can help me please post back. Thanks. // *End Babble*

Thanks Crazy and Koob! Upon further reflection my concepts of octrees and scene management seem flawed. The problem I think is that I'm thinking of octree's as storage structures rather than reference structures.

What I'm used to doing with octrees is loading the meshes seperately and using the octree to use pointers to reference polygons in each leaf node. That way when you need to use an octree to find a subset it's easy and pulling up the list of polygons by reference.

But this doesn't work so well when you want to then save that structure to disk in a way that can be loaded node by node. The application I am looking at is for an MMOG with a large static world. I've been looking at papers discussing etrees. They are basically large linerized octrees stored on disk and loaded through a caching system when needed.

What I can't wrap my little head around is how to maintain relationships between polygons as larger entities when they are being subdivided and saved to files.

For example: I have a large mesh that makes up an ocean. Each frame you run ocean and wave physics on it to simulate water movement and waves. This relies on having a continuous mesh of shared verticies. If I, by creating this etree, subdivide the mesh then don't I break the ocean? The verticies wouldn't be shared any longer.

The only solution I can think of is to check when loading neighbor nodes to see if any of their verticies share the same coordiantes with existing verticies already in the index then create a pointer instead of a new vertex. But is this the correct solution or am I missing the ball entirely?

I'll be reading the paper on etrees again tomorrow to see if I can find any answers. Night all!

If it is static geometry, then you almost want to duplicate the data. The vertices you'll use for collision etc will be in the octree as a list of collision friendly triangles etc.

As well as that data each leaf node will also have a render friendly primitive stream which should be able to just be dumped out to render. Go through the leaves in the view frustrum, just firing them all off. If neightbouring leaf A and B share vertices, just leave them duplicated. Because you might only render A or B, not always both.

So the triangles are duplicated in the 2 formats in a friendly way for the 2 different purposes. Its that trade off of memory against processing time.

How were you thinking of animating your water? All in a shader so the geometry doesn't move, but the texture looks like its moving? You could also write a dedicated water renderer.... which isn't even in the octree, but is just rendered using the camera view matrix. This would just render 'infinite' water from the camera position to the far clip plane.

I'd definitely recommend handling water (or heightfield terrain) separately from "static mesh" geometry.

As for handling static mesh type geometry, I wouldn't initially recommend splitting it up based on octree node membership, rather I'd recommend putting each chunk of static mesh into whatever node fully encompasses it. This lets you do all sorts of useful things like limiting your octree traversal by frustum visibility, and heirarchical visibility queries.

As to how to handle terrain and water, there's plenty of good reference on clip-maps out there, which seems like the best current solution for modern hardware.