Jump to content
  • Advertisement
Sign in to follow this  
icqqq123

questions about how to render 3d game level and collision detection

This topic is 2274 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
For 3d level rendering, you'll want to look into Portals, Occlusion Volumes and Frustum Culling to start with.

For collision I'd really recommend using a 3rd party library, but if not then typically you'll want to perform collision the same way as you do with other characters. However I'd recommend attempting to simplify collision meshes as much as possible to make the calculations much faster. For example, a character walking along a flat surface only really needs to collide with a box bounding the feet.

Again, part of the solution depends on what kind of 3D game you're going for. A dungeon-crawler might not really need much in the way of collision at all and you can use Portals and frustum culling to great effect and ignore occlusion volumes, whereas a space-fighting game would need frustum culling and occlusion volumes but portals won't be any use.

Share this post


Link to post
Share on other sites
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. Edited by (ok)

Share this post


Link to post
Share on other sites

...I want to start to create a 3d game....


Use a preexisting engine like Unity3D or UDK. Don't write your own stuff if all you're after is a game.


[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]Now, I just load the whole level to my game and render it, but the performance is not quite good.[/background][/font]


[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)][/quote][/background][/font]


[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]What are you rendering? Optimizing depends on what you're doing. [/background][/font]



Also look at PhysX/Bullet for collision detection.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

[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

Share this post


Link to post
Share on other sites
I think he's referring to the years 2004 and 2001 and the sort of complexity you'd expect from scenes around that time.

Share this post


Link to post
Share on other sites

I think he's referring to the years 2004 and 2001 and the sort of complexity you'd expect from scenes around that time.
That is correct.

So, what I need to do to deal with the collision between character and game level?
As others have suggested, you are strongly advised to use a collision library. That's seriously the best suggestion I can get you.
As for kinematic objects... I still have not found a satisfying solution myself. I'm currently investigating my current approach in more detail and I'd rather not elaborate on that. I've looked various online forums and mailing lists with little success. I strongly encourage everyone in sharing their strategies.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!