Hi everyone!

I have just joined this forum and I have questions about how to render 3d game level and collision detection.

I have already created a few 2d games and now I want to start to create a 3d game.

The first problem I encounter is I don't know how to render a game level efficiently.

Now, I just load the whole level to my game and render it, but the performance is not quite good.

How do I optimize it?

Second question is how can I detect collision with the level, say I have a character and I want to have collision detection between character and the game level?

I know how to detect collision between characters, but is the idea of collision with game level similar to collision with other characters?

Thanks!

First answer :

At the data management level, you have many examples out there to teach you how to stream / page / cache parts of your levels from disk to main memory if your level data exceeds it.
For example, you can use thread pools to prefetch blocks of your level asynchronously in a view / position dependant basis for more immediate use.
For sure, you need a good understanding of your needs to design a data structure that will efficiently serve your engine or specific concept.

Make sure to use small textures and try to stick to a polygon roof-top budget. The goal (rarely achieved though) is to keep the same average size for all your polygons on the screen, whatever their distance to the camera.

At the rendering level you have 3 popular techniques :

- First you can do backface culling, detecting and skipping primitives that don't face the camera. (easy)

- Frustum culling whereas you select only polygons inside the view and skip shading others. (intermediate)

- Occlusion culling is the next step where you can try to detect if further polygons are not already occluded by closer ones. (advanced)

You have to benchmark your code so that you can easily detect where it stalls and add some workarounds accordingly.

This last point is very important because it will help you to predict if your jobs will fit before even getting through tedious efforts.

Second answer :

Collision detection can be achieved through a sequence of ray-face intersections. You are going to test collision between 2 operands, object A and B. Thus, you have to make sure your both operands are holding very few primitives. Then you can try to "ray-face" test every edges of object A against every faces of object B.
People typically use dummy geometries, bounding volumes that may barely represent your operands general aspects, since physics events can render great, even if the objects tested are far less detailed than the mesh used for the rendering process.

There are very mature libraries that have pushed very far the subject and may help you to get started from the right point.

I personnaly recommend Bullet Physics.

Thanks for the advices!

For the collision part, if I want to implement by myself, is it right that I need to create bounding boxes for all of my objects in my level, so that I can detect collision between characters and level like I detect it among characters?

Thanks

[quote name='icqqq123' timestamp='1338127391' post='4943710']
The first problem I encounter is I don't know how to render a game level efficiently.
Now, I just load the whole level to my game and render it, but the performance is not quite good.
How do I optimize it?

I strongly suggest aggressive batching. I've been doing about 50k easy vertices with easy pixel shaders at about 60 fps for ages. If your level complexity is 2004 or earlier, you can probably draw it completely with no issues at all. If your level is as complex as 2001 or earlier, you can probably draw it a few times and still hit 60 fps. What's your problem exactly?
Portals and antiportals are ... not trivial at the very least. I'd leave them as a last resource.

For the collision part, if I want to implement by myself, is it right that I need to create bounding boxes for all of my objects in my level, so that I can detect collision between characters and level like I detect it among characters?

No, it is wrong. First, you're going to aim two guns at your feet. Second, the bounding box is only one of the various collision shapes available, you need at the very least box, sphere and hull. Third, characters ("kinematic" objects) are a problem by themselves, they are game-dependant and even context-dependant, they are o not-trivial problem even on top of an existing collision library.
[/quote]

Thanks for your advice. But what are the meanings of 2004 and 2001?

So, what I need to do to deal with the collision between character and game level?

Thanks

ok, I got it. Thanks very much!