In the beginning i use 3ds as the map, but when it very big fps down. What format is better?I heard that majority of 3d programers use BSP trees(but it for action games, i think, if i wrong please correct me). BSP trees? What is it? Can i use it as the map for carmageddon style game(if(yes && it is the one of best ways) where can i find some tuts or samples and EDITOR)
It all depends what kind of environment you’re trying to render.
for indoor types you want perhaps BSP or octree. Never done a BSP myself, but Octrees are even simpler, because all the subdivisions occur on major axis. i.e. X axis, Y axis, Z axis. Very easy, and technically the bigger the world, the more efficient they become, because you can quickly cull out thousands of polys with very few tests.
For outdoor terrain, the simplest to get working would be a quadtree. Very simple. I might do some quadtree code for my website soon.
For indoor mixed with outdoor, do something like a portal engine, with a renderer attatched to each portal. i.e. mixing quadtrees and BSP’s n stuff… theres a whole myriad of combinations to try…
For racing game (outdoor), start by doing the track as a quadtree. I did a test a while back with about a million polygons in the level and had it running at about 60 fps… no matter how many more polygons were added it would not slow down, as it got more efficient the bigger the world!
They really are top!
Nutty
Please correct me if I’m wrong. You have modeled your world and stored it as a .3ds, right? but in your program, you’re rendering THE ENTIRE .3ds?? (including parts of the map that there aren’t visible at all).
Of course this approach is slow, no matter what format you’re using to store geometry, if you don’t determine what’s visible and what’s not.
The Portals, Octrees, etc. can be used to render just what will be seen on screen…
so no matter how big is your world or map, with Portals or a similar algorithm, you can render only the part of the world you’ll see… that’s the idea…
- Royconejo.
You will need to write some code which reads the .3ds and puts its geometry into some kind of spatial index. (www.gamasutra.com has a good discussion on spatial index as a game programming pattern)
Initially, you might want to do that as part of start-up of your program, but the .3ds format is sufficiently brain-damaged (unaligned floats and all that) that it’s going to run pretty slow while loading and converting everything. Thus, you could probably come up with your own data structure (like a quadtree with lists of vertexes/indexes per node) and write code to efficiently save it to disk and load it from disk. Then take your .3ds loader/converter code and put it in a “converter” program, which reads the .3ds and spits out your “flattened” tree. Your program can then efficiently read this format when it starts, cutting load time dramatically.
When you do the same thing for textures and other data (say, pre-S3TC compressed the texture data) your users will love you. Nothing is as annoying as a program which takes 3 minutes just to start up.
The deal is with the fps.
I am currently loading ASE format in a game I’am writing. But I saw very quickly that having 200 hi-quality models on my screen make it slow. ( obvious would you say ? ) So I tried to kick the texture out, but no differences. The solution was in the LOD (level of detail) You just have to look at the distance between the camera source and the object (sqrt( (xc-xt)² + (yc-yt)² + (zc-zt)² ) and use different shape for the distance you wish. I can tell you that, if you wish to make a game with some deep, first step is this !
Anybody agree ?
Originally posted by fabos:
[b]I can tell you that, if you wish to make a game with some deep, first step is this !
Anybody agree ?[/b]
No, I would disagree. A visibility system (portal/BSP/octree/quadtree/etc) is definitely more important than LOD (in at least 99% of cases). More often than not, you can get acceptable perform with a visiblity system and no LOD, but not the other way around.
I agree with LordKronos, but landscape engines still also need a LOD system (at least mine does, 10FPS is a little slow even when using a quadtree). LOD systems also, however give visual artifacts such as poping (this is currently my problem 
)in all but the best algorithms, which sometimes have more overhead than the benefits are worth. This is apparent withs BSP trees and ROAM, both of which will run slow on TnL cards, but drawing everything would be faster (in some circumstances).
Better is a static LOD system where the user can choose a detail to suit there system and wants such as the character detail in games like unreal.
Tim
So, I must use octrees and dinamicle LOD metod together? Or it will be slow?
One question more: what is faster calculate octrees on flying or load octrees from the file?
PS: my map it isn’t terran - it is the outdoor map
precalculated octree will obviously be faster (and is a must) but if you have have dynamic geometry then some kind of dynamic octree is needed (ouch!). But carmargeddon isn’t dynamic ( or particularly dynamic) so a normal octree would be fine.
10fps with just an octree??
How many polys per frame?
what hardware you running on?
How many polys in the bottom nodes?
How are you drawing the polys? Display list per node? glBegin/glend? glDrawElements?
How many passes?
Locked vertices?
VAR?
just curious…
Nutty
[This message has been edited by Nutty (edited 04-10-2001).]
I want to draw 10,000-15,000 polys per frame
I have Pentium III 650MHz, 128 RAM, TNT PRO 32 Mb.
glDrawElements(…);
what do you meen Locked vertices?
If you’re doing multiple passes on the geometry, you want to lock the vertices, so that the gpu/driver can cache the transformed vertices from the last pass, and reuse them, without having to re calculate everything.
There is an example of how to use them on my website. the Compiled Vertex Array demo.
www.nutty.org
I was posing my questions to Tim. Wondered why he only got 10fps.
Nutty
Originally posted by Nutty:
[b]10fps with just an octree??
How many polys per frame?
what hardware you running on?
How many polys in the bottom nodes?
How are you drawing the polys? Display list per node? glBegin/glend? glDrawElements?
How many passes?
Locked vertices?
VAR?
just curious…
Nutty
[This message has been edited by Nutty (edited 04-10-2001).][/b]
I have been on holiday for some time but now I can answer your question (well actualy ask my own- why is it so slow?)
First of all there is nothing fancy going on to speed it up such as vertex arrays. A simple quadtree frustum check (which seems to have problems of its own in that sometimes nodes that are on the bottom of the screen aren’t drawn and are discarded??) cuts down most of the polygons and although it isn’t optermised and very fast yet it is good enough for now. Seconfly I use opengl’s backface culling method to further reduce poly counts (to some unknown extent). The 10FPS is achieved with 2 passes (blending 2 textures to generate the terrain texture) and I get 20 FPS while single FPS. There is no dynamic lighting, it was precalculated and the colou map used to shade the 3 vertices with smooth shading. This was before I implemented a simple LOD system and it would draw about 400 nodes of size 55 vertices which creates 44 quads drawn in a tri-strip each = 2 tris 442 = 32 triangles, 32 * 400 = 12800 tris - those that are backface culled. This is on a p3 600, 128MB and a TNT2 M64 32MB. I have cleaned the code up a little removing extra binds and disabling states that aren’t needed but there is not speed gain. There is a skybox which is drawn is a display list and this is fairly fast. I am also using a little bitmapped fonts but I don’t think this would make it run this slow. The simple LOD system I made halfs the poly count and doubles the framerate (also compare this to the halfing of the framerate when I double passed the terrain!), however it is very ugly with popping and the joining of different LOD areas, this can be solved but of course would slow it down a lot. I have tweaked the graphics card settings, switched of vsync and done a few other recommended things to no avail. I guess it has to be using hardware acc. but why is it so slow, although it looks like it is limited by the harware speed I don’t hink it can be wth such a small polycount. I will have a look at your example, vertex arrays and such like is what I wanted to add next. Tim