General

Re: Data structure for a 3D scene

winipcfg — Mon, 06 Jul 2009 16:33:19 GMT

Thanks for reply

Actually I am not artist also, but i can find something free on the web. We can find 3d models, but not a world
So I have to build a world myself. However, it needs time to design the data structure

For example, I have build a class for multitextured terrain. But later I find that my terrain is not good for LOD.
Also, it is a very basic one and I cannot draw decals and roads on it. The world looks boring and only a few textures are used

I have already built several codes that can be used for my spaceship games.
But without a data structure for scene, I cannot continue my work and design which stuff is possible to implement.

Re: Data structure for a 3D scene

jwatte — Thu, 02 Jul 2009 22:18:36 GMT

I generally have static geometry ("terrain"), and dynamic entities ("culture" and "actors").

Generally, "culture" stays in place -- trees, buildings, etc, whereas "actors" move about. They are both, however, entities in the game entity system, but the static culture only has collisions, not separate physical animation or AI.

If your static geometry is highly complex with lots of shaders and lots of overdraw, you might want to slice it into pieces, and do some kind of recursive culling -- cell/portal, BSP tree, occluder/PVS, etc.

For the simulation and collision part, you clearly need some kind of spatial index -- I prefer a loose octree, but anything that floats your boat could work fine.

Re: Data structure for a 3D scene

Eckish — Thu, 02 Jul 2009 21:37:00 GMT

That is a pretty tough question, because there are many solutions that would be considered 'good'. There are also many questions left unanswered that would help make the final decision for most programmers. You also wouldn't have any single data structure for what you ask. It would be a combination of tools.

A dynamic scene does not necessarily mean that you can't use a static model for it. And I use 'static' loosely. What I actually mean (and what I think you actually meant) is a 'single' model. There are certainly some good algorithms out there for applying deformations to an mesh. So, just because your battlefield is a single model built in Blender, it doesn't mean you can't later carve out a crator from a bomb by messing with the mesh at runtime. Don't get me wrong. It would not be trivial to do. But it is possible.

There are two things that would deter me from using a loaded model for terrain. One is scale. If you have a very large map with a high complexity per square unit, it is going to take up a lot of memory. And if that map is large enough that it extends well beyond the view of the player, then you are keeping unnecessary information in memory to load the whole map up. If memory isn't an issue, than neither is loading the whole map. Otherwise, I would look at alternatives, which could be as simple as breaking a large model up into smaller models or as complex as procedural terrain generation.

The second thing that would deter me, is lack of talent. I am no artist. I can't sit there with a modeling tool and create fantastic alternate realities. I do however have a good grasp on math and algorithms. If I don't have an artist to create models, I won't let that stop me. I'll look at prodedural terrain generation.

And that is just the terrain. For your actual game objects that you would be interacting with, you need consider the many options for physics, collision detection and drawing. For these, you would probably want to search for spatial partitioning and batch instancing. This site has an example on model instancing you can look at for drawing a lot of the same models. For spatial partioning, I prefer loose octrees. However, there is certainly some merit in using grids or bsps instead.

Data structure for a 3D scene

winipcfg — Thu, 02 Jul 2009 15:26:40 GMT

Hi,

I am writing a spaceship shooting game.
The ship needs to enter the enemy base and destroy buildings (Entities).

May I ask how people would design the data structure of scene so that it is easy to create, load and maintain
Will people build a large mesh and place entities on top of it?
How about if the scene is dynamic, i.e, cannot be represented by static model