I have a TextureManager class who makes sure only one unique texture is loaded and returns the index to that texture. I'm using hash map to keep the textures. Then I have a Renderer class which have a list of all faces. that are going to be drawn. This list is seperated into two simple arrays that are sorted by z-buffer for the transparent ones and texture id for the rest. The SceneManager class will then have a list of every face in the world and will use the camera frustum to check which ones that are visible and send it to the renderer. 1. Is this design good, or will I stumble on problems later? 2. What data structure should i use in the SceneManager class so it will be easy to find the visible faces. 3. Should an item in the SceneManager list and Renderer list be one face, or one mesh or something else? 4. Should I use the same data structure in the SceneManager for collision, or should I use a seperate data structure for that?

I don't have a game planned. I will probably make a simple FPS to test out the engine. But if I want to create another game after that, I don't want to rewrite the core. This is a hobby project, so I'm not after the best solution there is, but rather something nice and clean. Using someone else's engine, doesn't really help me since my project is to create the engine. And I don't want to look and copy someone elses source code. I already created a 2D engine, so this will be only for 3D.

I wasn't sure if I should go with faces or models. But should I seperate the models and the level? Using BSP to divide the level and check for visibility and a using a seperate list and checking for models?

I am no expert on this but I have been looking into scene graphs lately and if you don't want to look at other people's source code I strongly suggest you read up on the theory.

Usually 3D scene graphs have a concept of nodes and leaves (a tree) where the leaves represent geometry meshes (models) and nodes are used to group them together. There are many advantages of doing this, the main ones being able to cull large sections of the tree by examining high level nodes and being able to apply properties (transformations etc) to multiple elements in one place.

I would buy a good book on the subject and read up!

As I understand it, I shouldn't use a Scene Graph for visibility and/or collision tests. What I've read, is that Scene Graph is used for better translations of objects around the world. But I'll try it out.

Any good book recommendations?

Usually the scene nodes/leaves have simple bounding geometry for collisions, as I said I'm no expert at this (just learning myself). I can't really recommend a book as the way that I am learning is by looking at the many open source engines that are out there. That's just my preference though. As you don't want to look at (copy) existing code buying a book is the next best option :-)

It's an interesting (and huge) challenge to write a 3D engine and I wish you well!

You'll read a lot about how the scene graph is not a spatial but a logical structure (that is, after you sift through the mud in the form of dozens of shallow scene graph tutorials written by people who barely know what they are talking about). However, transforms are usually propagated in a scene graph, and that itself is already spatial information. Scene graphs are also cited as providing you with a unified interface to your scene, but personally I find the benefits of that a bit doubtful (or perhaps over-hyped). What they are good for is the kind of rigid constraint where two objects must remain attached to each other (torch and player, sound and sound source) without you having to manually keep track of their relationship - they will remain in sync as a consequence of being in a parent-child relationship when you propagate the transforms.

For collisions and hidden surface removal, however, there are better scene structures that are actually organized on spatial characteristics (see Captain P's response). Note that you are not limited to just one such structure - you can have both a scene graph and an octree, independent of each other. Both are just ways of organizing your data.

The concept of faces is too low level for scene organization, but too high level for rendering. For rendering, I believe that you should organize your structures around the optimal way to send data to the graphics card. For instance, in my renderer, I don't deal with vertices or faces but with vertex streams and index streams that can be buffered to the card.

I doubt you can create a clean engine without a concrete game in mind, certainly not on your first try. In that kind of case, you need to support multiple paths and ways of doing things, which is the antithesis of keeping things clean. You'll just end up with interface bloat until you lose track of where you're going.

[Edited by - lightbringer on June 11, 2009 5:30:05 AM]

I'll create the renderer so it takes a vertex stream that the level manager generates by looking at the visible nodes in a bsp tree and a vertex stream that the model manager generates by looking in another structure. Is a vertex stream just a list of vertices/textures/normals?

I don't have a problem to build the engine for a certain game, but does that mean that I can't use my scene management in another type of game and have to rewrite it? Let's say that I'm focusing on creating a FPS. What structures should I use for level management and model management? To check for visibility and collision detection.

Vertex stream in my case is a native FloatBuffer, which I believe is backed by a native array so in the end it's just an array of vertex data. I interleave mine, so it ends up as a single stream, with each vertex packed together (so first all coordinates, normals, texcoords for vertex 1, then for vertex 2, etc). You can also keep them separate. I create these buffers when I load my meshes, so that I don't have to do the conversion each frame. The index buffer just holds a list of triangles to draw (the index is a reference to the position of the vertex data in the vertex buffer). You need something like this if you want to share vertices between triangles.

I'm not set up to handle different textures per buffer, since my vertex data comes to the renderer packaged together with a material (lighting properties plus texture in my case), but theoretically you can do it that way since you can draw one part of the buffer, change state, and draw another part. The idea here is that every renderable object can provide such a chunk of renderable data, and the renderer takes care of drawing it, but the actual object might provide the data in different ways - a static model might link to its meshes, an animated model might have its own copy of the mesh and deform it, a particle system would generate the buffers on the fly, keeping track of its particles and supplying that as the data, etc.

You can certainly reuse anything that is reusable. I'm just warning you against trying to be too reusable and getting bogged down by it. Down that road lies the dreaded "you ain't gonna need it" syndrome, where you code features in advance because you might need them, sometime, someday, maybe two games later. With your current knowledge, and lack of manpower, you can't realistically compete with the big boys (such as Unreal) and even the small boys (such as Ogre3d, Nebula, or Irrlicht), but what you can do is write your own game (either using your own renderer etc or using one of theirs).

Can't really help you with picking a spatial structure - I haven't gotten around to implementing one yet, and I just finished ditching my second scene graph. You could look through the archives though, as I am 99.9% sure that a question that is the same or very similar has popped up before.

Thanks for all the help :)

I have tried to search for an answer on past forum post, but I didn't find anything useful. Guess I'm searching for the wrong words. I'll think I try out some implementations and see where it leads me. I'm not planning to complete the engine anytime soon anyway. It's just a fun project that I'm working on.

Implementing stuff that you don't need is probably waste of time. But then I'm not competing with anyone, so I'm not worried about that so much :)

Quote:Original post by mt123It's an interesting (and huge) challenge to write a 3D engine and I wish you well!

It have been fun this far :). Thanks, and I hope everything works out with your engine too!