From a 32x32 grid i created a level with one mesh and for each grid
meshbuffers (1 quad for each side). This way i created a big dungeon
(32x32) with only having only "boundary" walls (one big empty hall) and
everywhere floor and ceiling. I only used 3 different type of textures.
Passing this mesh to OctTree it created 169 nodes and 4224 Polys.
Now the problem, the performance:
the quakemap example with irrlicht creates 318 nodes and 7753 polys and i get around 90 fps.
My above grid-level gives me only 20 fps !
So what i am doing wrong ?
Whats the best way to do the "cell"-like dungeon rendering ?
whats wrong ?
without seeing your map in the level editor, I cant honestly tell you. Things to look out for are how you create what is call brushes. If you have any that over lap, it will cause the Wpoly count to skyrocket, and for an engine to decide on the fly if it needs to cast these to the view on screen can take up lots of time. Even how you lay out your rooms can cause the Wpoly count to go up and reduce the fps. If you can see into a room or a lot of other rooms, this is going to cost in performance. Lots of maze type of levels go to a lot of trouble trying to lay out a map so you will not be able to see off in the distance a long ways, and your view or a raycast of the engine will not have to do a lot jumping through hoops to decide if it needs to display a sliver of some area that may be peeking from a doorway, or a window. Books have been written up on the subject, and there are tons of web sites out there that have tips and tricks to keep the Wpoly count down.
Basicaly, try to make your rooms that will lend itself to a L shape pattern, and dont make them so that you could stand looking in a doorway that will tend to look through another doorway, and on and on. make it so two doorways cannot be seen standing in mostly any area of a room. If you want doorways on the same side of the wall, you can do an old trick by using a bookcase or a stack of crates to hide the view of the other door, making you walk around to the other side of it.
Butt up your brushes so they are aligned, but do not overlap, i.e. the ceiling should be sitting on top of a wall and a wall should just be sitting on top of the floor. Same with crates or other things or even staircases for that matter.
Basicaly, try to make your rooms that will lend itself to a L shape pattern, and dont make them so that you could stand looking in a doorway that will tend to look through another doorway, and on and on. make it so two doorways cannot be seen standing in mostly any area of a room. If you want doorways on the same side of the wall, you can do an old trick by using a bookcase or a stack of crates to hide the view of the other door, making you walk around to the other side of it.
Butt up your brushes so they are aligned, but do not overlap, i.e. the ceiling should be sitting on top of a wall and a wall should just be sitting on top of the floor. Same with crates or other things or even staircases for that matter.
The level i did is very simple:
Imagine 32x32 cubes (with 6 inside faces) connecting to eachother.
Now for a big hall every cube has a top and bottom face (ceiling, floor) and
the "outer" cubes have also walls to close the area:
---------
| |
| |
---------
The cubes are tight to eachother perfectly, they still don't share the same vertices because of texture-coordinates.
What i wonder is, that the poly-count in my map (after putting into octtree) is not so high than in the quakemap example, but the performance is so different, i measured it again : 120 <-> 20 fps !
Imagine 32x32 cubes (with 6 inside faces) connecting to eachother.
Now for a big hall every cube has a top and bottom face (ceiling, floor) and
the "outer" cubes have also walls to close the area:
---------
| |
| |
---------
The cubes are tight to eachother perfectly, they still don't share the same vertices because of texture-coordinates.
What i wonder is, that the poly-count in my map (after putting into octtree) is not so high than in the quakemap example, but the performance is so different, i measured it again : 120 <-> 20 fps !