   Overwhelmed - Graphics Engine - Looking to understand concepts
  I've spent most of today reading about various ways of using/implementing a scene graph as well as terrain and skybox/dome/planes through forum articles, google searches, and the 3 game programming gems books I have (#1-#3). Now 12 hours later it seems pretty overwhelming and I haven't done one iota of coding yet today.Right now I got my camera working as well as my keyboard/mouse. (using 1 quad and 2 triangles as references in my "world") So I'm making a big leap. I have soooooo many questions but I want to start to do something today (probably my keymap) so I'll keep it to a few.Reading about ABT's in this forum, LOD managers here and in the GPG series I'm left to wonder how geometry is stored. When I first started coding my "little" project I had this idea in my head that I organize the vertices in an array and texcoords in another, a few OGL calls later, and magic happens and I see my object on screen. So each object has as part of its class those two arrays.Now reading the various posts on ABT's:http://www.gamedev.net/community/forums/topic.asp?topic_id=110342http://www.gamedev.net/community/forums/topic.asp?topic_id=385034http://www.gamedev.net/community/forums/topic.asp?topic_id=163240http://www.gamedev.net/community/forums/topic.asp?topic_id=123169... and a few more. It seems that the leaf nodes hold the geometry... not necessarily the objects. So if I had a large object it could easily span multiple nodes and each node would have it's own set of vert/tex coords. Is that correct?Is it correct that such a tree is expensive to create initially, in terms of CPU time, but maintaining/modifying it is fast? (I'm thinking you don't have to split faces as much... am I associating that this takes a lot more time than it actually does?)Face splitting makes me question the way I wanted to store my vertices in the first place. That and reading how LOD managers pop verts in and out of existence. I'm curious how you guys do it. Pick a vert and make an edge graph from it representing the part of the object in the node?Do you have 6 arrays? The vertices, an edge list, and texcoords for the hi-detail model and another set of those for the current LOD? Then you need two more right? Those two have the vertex and texture coords in the proper order for the OGL calls. I'm pretty new to this but to me that seems like a lot of space/redundancy. (I forgot about normals :/ ) Is there a better way?Thanks for your help   
  Moving to GP&T.   ;  To help get your head around these it might be better to code up samples of the different peices independantly in their own applications and then afterwards work out the best way to glue the pieces together..You don't necissarily need to split polys across quad trees, although you certainly *can* do that. What do you do if your geometry is moving though? Nothing stops you from just storing mesh objects in your bounding tree, and if a mesh is a bit larger than the node, expand the nodes size a little bit (Loose Bounding Tree). If its a lot larger, then either store it at a higher level or do a coarse grain split.Generally with lodding, Occams Razor wins unless you have a specific need. Just have a mesh per lod (or an index buffer per lod for the one mesh)   ;  Thanks Exorcist. I guess I graduated from the beginners forum :) but i'm not far beyond..... what's a "coarse grain spilt"?Using a mesh/level certainly seems a LOT easier then the pieces I was reading in GPG where it was a continuous LOD manager...... Is that something you would apply to terrain LOD as well (mesh/level)? Or is that a case where you'd want some sort of continuous-like process?The end goal here is something like SWG/LOTRO/EQ. I only have first hand experience with SWG but I figure the others are similar as far as terrain goes.   ;  No problems Robione.By a course grain split, i mean dividing your terrain into chunks, but chunks of a size that's easy to deal with - without going to the effort of splitting triangles at boundaries.It all comes down to requirements, how you should go about writing your terrain and its lodding system. If its procedurally generated then you don't have the luxury of offline-processing, which means your LOD system needs to be pretty dynamic. Where as if you are, say, converting a heightmap into your own format - then you can create multiple meshes per region of your terrain, including morph-target data for geo-mip-morphing etc.   