Sorry your browser is not supported!

I was hoping to make a custom polygon collision (poly to poly, rather than db's sphere to poly). But i think im about to just give up on the idea.. I have something that kind of works (funnily, it seems to work perfect with spheres, but not cubes) but its not as accurate as i would like and its very slow on big objects. Unless someone has miracle idea on how to speed it up and i manage to fix the accuracey im just going to give up on it. Heres what i got so far:


scrap that, this post blew up on me. see below.

I have seen (but not understood!) algorithms for doing poly to poly collision, and they are pretty complicated.

In pseudocode:



ie. Every poly in the first object is tested against every poly in the second. You should perform other checks first (such as dist)

Gah, i should realllllly check my posts before going off and waiting for an answer, i see my code tag messed up -_-

Lets try again:



I do a very simular thing to your pseudocode. Basically, i get the object into memory and then start running through the vertices of the object. I use intersect object to check the collision. If i understand it right, intersect object casts a line from x1, y1, z1 into x2, y2, z2 and returns the distance to the point where the line hits a poly beloning to the object set as the first parameter. So effectivly in my function im drawing a line from a poly in obj a (well, i suppose from a vertex) to object 2 with intersect object so hopfully getting the distance between two polys. However, as you can see if you test my code (supposing it works this time!) its far from perfect, i must be doing something stupid.

Still, it needs much more optimising. Yes first you do a distance check to make sure the object is worth checking against, but i leave that upto the engine and not the collision function (my engine doesnt bother doing anything to objects a certain distance away ). Im pretty sure that if i want this function to be usuable im going to have to seriously limit the amount of polygons that are actually being checked against, and the only way i can do that is what i said earlier (no scrap that, my post boogered didnt it, i said nothing earlier according to it -_-) about getting the angle of the object, its direction and checking only the relevent side of the object rather than all of it. I dont know the maths or trig for this though.. even if i managed to get all the info i needed i would have no idea which polys to read out (ie, where to start in the mem and where to stop)

btw, if anyone does try out the code, please let me know of the results - fps, your system specs, how many million different ways did you manage to break it (not hard to do, this isnt finished) ect. And if anyone has ideas for this function or has done something simular before, tips on speed or completly different ways of doing it will be listened to and absorbed fully, thankyou

Intersect object chews up a lot of CPU cycles if you use it more than 24 times each loop. This is on a 1.5 Ghz AMD XP with a GIG of ram. 72 times I get 45 FPS.

I created a really cheap collision ring using intersect object so you can walk on .X models with no plug-ins etc. It's in the code snippets. It can use a TON of optimizing. If anyone wants to look at it then try to improve it, by all means do.

-Kensupen

Sephnroth, I'm not sure if this is any help to you whatsover but check it out anyway

http://www.realgametools.net/forums/index.php?board=8;action=display;threadid=15373

Sliding collision for .X level models using Object Intersect.

APEXnow

@Sephnroth

Certainly needs a lot of work. It works fine with some objects, but on others it reported a collision even if the two objects were way apart.

doh >_< I didnt realise it was *that* bad!

Thanks for all the links and tips guys. I may try and work on this some more.. but its giving me such a headache -_- My main fear being that if i ever got it working and accuratly it would still be far too slow and thus, a waste of time :/

The main reason for me wanting this function was because terrain collision and things in my game (in my game you are a tank) were just not good enough due to darkbasics poly collision treating one object as a sphere basically (at least, thats what i figure!). This meant my tank couldnt drive under trees! lol, ok that sounds bad, but what i mean is instead of stopping when coliding with the trunk it collided with the branches which were way up above the tank, so Y wasnt being taken into account and it was colliding against the maxium radius of my tree.

Currently im working on another (hopfully faster) idea, rewriting my map structure so that instead of the object struct containing model filenames for loading and placing it will have a node file name, like tree.node - my idea being that in this file i can store model filename n whatnot but also extra funky things like static collision settings. I can easilly write a little "node generator" tool which would allow me to specify collision areas on the object (using boxes to visualise it) and then storing this data in the .node file and when the engine loads the map it can setup static collision data according to each objects needs. That way i can personally ensure only the tree trunk is collidable with ect

But yea, if i have some amazing ideas i will continue to work on the poly to poly direct collision!

Well..Sephnroth..
I applied the concepts that i was explaining in my other discussion with you (Newcomers corner - Intersect object) to my case, and now i can move my tractor under the leaves but get a hit with the trunk..
I put an invisible cube around my model and i'm checking intersect object from tree trunk to model (and not viceversa).
The only problem left is to avoid to get stuck when moving away from the trunk in some cases (that may happen at some tractor angle values, when the tail gets below the limit while the front wasn't).
i am thinking of modeling a "bean" shape hidden object, perimetering the model, to be detected, rather than a too primitive shaped one (cube)

People here speak about 24 or 72 times detection,or whatever ,but to me the concept is different.

1) use the command only in your vicinity (that won 't be many objects, or polygons, actually it may be just 1)

2) no need to use the command more than 2 or 3 times at once:
the problem is to find out where to use it (what exact spot of the 3D world or model)
And that involves the coding "around" the command rather than using it 20 or 70 times around in the hope of precision.

3) Is there any hope that other methods will work faster and better? maybe, but my feeling is that the answer is no, so far.

You are mentioning usage of static collision boxes for tree trunks..what's the difference? it will still be sphere to boxes collision.

A cool way would rather be to put a hidden small vertical plane within your tank, make him always face the closest tree only(anglewise), and make him stay in front of the tree trunk offsetting it along/within the tank perimeter with a sin/cos formula, then check intersect object (tree to plane) right there.

this is what i am going to attempt next in my case.

probably there are other ways to be attempted which i have not thought about yet
I may be entirely missing your whole point, in that case , forget about this post

All the best

Scorpyo, as usual you have come out with some brilliant ideas and suggestions ^_^ It certainly gives me alot to play with and think about!

"You are mentioning usage of static collision boxes for tree trunks..what's the difference? it will still be sphere to boxes collision."

Well, you see the idea behind my static collision boxes was not to give each tree a box around it, for yes of course that would be just as awful. But the idea is that for nodes (objects, terrain, ect) to be accepted by my game engine they must first be ran through a little program im about to write which will generate an information file for the node, like object.node or something. To start with this opens up all kinds of doors because I can store whatever information i like in the node file which would be read into the map stack whilst loading the level - the most basic example of this is something like a "no hit" flag for disabling collision with this object or whatever, but the possibilitys there are endless.

But an even more intresting point is the ability to store static collision information inside the node file which can be configured by whoever is using the node generator. It would work basically exactally the same way as your box up the tree trunk User would be presented with their node and given a box object which can be manipulated (moved, resized, ect). I can then get that cubes dimensions and convert it into collision data. Even better still, you could add more than one box and setup multiple collision areas within one object. So i could load my tree, setup the needed node data and then make a box go up the trunk (just like you said) and then if i was bothered place another one higher up for the leafs or whatever. Then the data just gets stored in the node file and when the engine comes to loading and encounters this node, it opens the file, reads in the node info and then reads in the static collision information and uses it to calculate and setup static collision areas for the terrain on the map - supposedly static collision is VERY fast (well it should be, being static n all) and although it still wont be the most accurate thing in the world, the ability to define zones along a model for custom collision areas could proove to be quite usful

Its certainly something to play with

There are maths algorithms for detecting whether or not two polys collide, research those rather than using intersect object. Most of them are in C++, so you'll need to convert them to DBA code.

a few links:

http://www.gamedev.net
http://www.geometryalgorithms.com
http://www.igda.org
http://www.gamasutra.com/

I found a more precise link for what you are after (intersection of two triangles in 3D)

http://geometryalgorithms.com/Archive/algorithm_0105/algorithm_0105.htm#Triangle-Triangle