Help with collision management

Started by
13 comments, last by Gammastrahler 19 years, 4 months ago
I need help writing my collision engine for my game. Right now I have it set up so that objects are drawn normally, but then when objects move, it then checks the collsion ray tracing for each object when the object requests a move. This method seems really slow, but it's the only way I know of. Is there any other better ways that are faster ?
Advertisement
A general solution is to eleminate the number of objects you check agaist. This is very specific to how you store your data. Perhapes your ray-tracing code already does this. Another way is to decrease the complexity of your collision detection system. Ie: insted of using ray-tracing try simplifing it to a 2D collision map. I'm assuming your game is 3D. Do you really need to check all your collisions in 3D?
Anyways, it's pretty specific to how you represent your objects.

Nick
Nick
My game will need to check a lot of objects for collisions.
My goal for my game is to create a giant city with buildings with
inside rooms and more. So I'm trying to figure out a way to do all
of this. Collisions is just my first step to try to get things going.
So if anyone knows any better ways for doing the collisions in the way
that I want to, I would really need the help.
Well, if it helps, I know a lot of games eliminate processing of objects that they know the user won't be in contact with in the near future when they build large areas. For example, if the player goes into a building, you could halt collision detection/object updating outside of the building, or do so in a really simplified way if you feel you still have to. That way, you're culling the total amount of things that have to be processed at once.
-Vendal Thornheart=) Programming for a better tomorrow... well,for a better simulated tomorrow. ;)
But how would you know when a object is inside a building or not ?
For my engine, for my building objects, the walls are made up of seperate
wall objects, which could be anything, solid walls, walls with windows, doors, fences, etc... so even with the player inside the building, the engine has to go through all the walls in the scene that are visible (unless stepping backwards) and check them for collisions. I know of no other way to do this.
Perhaps you could divide your whole world/scene into zones.
For example a specific building is one zone and the different rooms are subzones of the buildings zone.
Then tag every object so you know which zone they belong to.
Now you can check for collision with only the objects that belongs to the zone your in.
To know which zone you're in you could use some kind of trigger in every doorway(could be a box or sphere that you check for collision with).



<-Sweenie->
Wow, that is good information, thanks Sweenie.

I have already thought about using zones. And in a way, the building
would already be considered a zone since it has it's own boundries
since it's an object made up of several real-time objects (because of
doors being able to swing open and windows able to open up too.)

But I don't know about the part with checking for which zone the
player is in. After all zones would be square shape so you wouldn't
be able to put sphere or box triggers all around the zone for outside.
And then with the door, that would be hard to check because the sphere
and the box triggers would have a radius on them, which would be sticking
outside the boundries. Because you wouldn't want the box trigger to be
inside the building because then it wouldn't detect the player doing a
collection on the building's outside walls.

But my building lay to another problem. It would be faster if the player
went inside the building and then the game wouldn't draw the outside
world, but I'm heading to realistic and speed, I want it so there are
windows the player will be able to look out of to see the city streets.
If anyone has played the game called Silent Hill 4, you will understand
what I mean for when your looking outside the window of the apartment.

But now this doesn't have to do with my original topic anymore. LOL.
Why not use "octree-like" collision culling? Divide the world into massive bounding boxes. The clip planes have a "tag" saying which bounding box they're in. So you don't check against planes that aren't in the current bb.
Is there any tutorials on the net for using an octree collision culling?
I'm using DirectX 8.0, so any of those websites would be useful.

With my original topic, I have thought that maybe instead of me using that whenever an object moves that a collision detection starts, that maybe instead I can have for when each object renders, and after so many frames that it will do a cache of collisions with objects, and then when anything needs to know the collision, it will then look it up in that cache. Which of these ideas would be better ? Are there any better ones ?
why don't make another 3d object, besides the object that you render, and in this new, one, you will includ polies that actually are likely to be involved in the collision detection. then use a simple octree that devides this object. just search for octrees in gamedev. and you'll find a whole lot of stuff.
K'-P = ME

This topic is closed to new replies.

Advertisement