Sorry your browser is not supported!

Hey ^^

Ok, moving onto collision now. IntersectObject im told is the function im after (im loosing the darkbasic pro collision, box collision is too inaccurate for my objects and i found that the other collision was another major factor in why i was loosing so much speed, turning collision off gave me back like 10fps >.>). Thing is, i need someone to explain the command to me, please?
I dont get what an intersection point between two places is. I can probably devise some sort of system to use it.. but only if i understand what it is returning me :/ So what is this point of intersection? i understand that when you are using the intersection object function you are basically casting a line between two points, is the intersection point somewhere in the middle or something?

I would guess that i would do something like create vectors in important places around my tank (the back, the sides, the front and along the tank barrel?) and use the intersect object command on all of my visable (or within a certain distance?) terrain objects and check the distance to the point of intersection and act accordingly.. i think, am i right? Is there any "fully commented" source code demonstrating its use or a tutorial? I found one or two things in the code snippits forum, but not really commented that well, usually just a case of "this works use it"

Thanks for any info

maybe here you can find some help...
I included dba and media in the walktest.zip

http://www.realgametools.net/forums/index.php?board=3;action=display;threadid=15135;start=20

Check this one too (long thread , be patient, but it has some drawings)

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

Scorpyo, thanks! I now understand what the command does But i have another question if your up for it ^^

A little qoute from the manual: "Ideal for bullet calculations and fast manual polygon collision."

Now, im super tired so forgive me if im wrong, but to calrify:
Intersect Object draws a line from x1, y1, z1 to x2, y2, z2. It then returns a value if the object specified by paramter one intersects with that line anywhere, tellings you the distance to that point. right?
Now im after polygon collision here. If i set player object x, y, z as my first vector (the x1, y1, z1) and cast the line to the object the collision is being checked against's x, y, z as vector 2 then i will basically be checking for a point from the center of each model right? Isnt that more like spherical collision rather than polygonal? though i do belive that the object intersection distance will be returned from the first polygon it hits.. but as its only checking collision against ONE object on a line it wont be literal polygon to polygon collision right? So how do i do this fast manual polygon collision that the manual speaks of? The only idea i can come up with sounds like over kill.. but thats to load objectA into a memblock, read in the vertex data and cast the intersection line using the vertex co-ordinates as vector a and into the object im checking the collision in.. running through each vertex and doing that..

But that sounds slow (imagine doing this with high polygon models!), over the top.. and well, im sure im just being stupid whilst tired and missing some obvious point (2 points short of a vector here )
so if you could maybe give some hints i would very much appreichate it ^_^ Thankyou for all your help so far too, much appreichated!

Well..see, it will give you the closer polygon distance depending on the start to end line direction..I use that for a space sim i am writing for detecting my distance ( height ) from the ground of the planet when i am approaching it.
so my cx,cy,cz is the space ship position ( actually i am flying with the cam at the moment cause i can roll and level it to the planet ground from any approach angle ) and pos1x,pos1y,pos1z are the planet position (which corresponds to the center of the sphere)

checkheight:
h1#= intersect object (1,cx#,cy#,cz#,pos1x#,pos1y#,pos1z#)
return

this gives me my height,which means how far i am from the closest polygon of the sphere on top of which i am, and actually , if you approach the planet till very close but fly over it you'd see that h1# decreases and increases again as you pass by( and it s 0.0 when you hit the ground).
Now the problem is : if i go under the planet surface, h1# will start returning the sphere radius minus my position..which makes sense of course, because that is what i am checking basically and the sphere is empty, so basically to check my undergronud i should subtract the radius from h1# or reverse the line direction.

If you are going to code bullets you must code in order to have your intersect line always pointing like the gun direction when you shoot, then have the start x,y,z of the command sitting on the bullet,you may use an optimum range,not too big since bullet hit detection needs close distances only, and skip the detection when the bullet(s) is past your enemy with a distance function (Pitagora or whatever).
Most probably, intensive usage of the command won't produce any slow down , since it s a rather lean command.
in case of bullets and plenty of enemies, you must keep track of each enemy position in turn (not too much hassle i believe)in order to disengage the detection.
You could use the command also to check the enemy distance and if he is in the aim if you think about it.

Polygon to ploygon collision between 2 fighting characters may be a completely different story. I have never tried it but i envisage it will be more complicated.
basically you would have to keep the starting x,y,z at each of the hot spots (hands , feet and sword or whatever) and detect from there in the direction of your opponent.
It all depends on how accurate ( and fast )you need to be.
Consider that in all fighting games you always see a lot of fast action ( which helps to hide poor accuracy ) but basically the spots detected are very few (head,hands,feet,knees,weapon [and butt?])

To me the command has great potential, but as all commands it may not suit you in all situations
cheers

hmm, i think i understand it. Well i have been working on a little polygon collision routine using intersect object and memblocks. Heres my current work if you are intrested:



Its is unfortunatly not very fast (i get 72 fps doing it against a cube as the player (i dont think the target object polycount really matters that much) and around 105fps with both objects as cubes) and not as accurate as i hoped it would be :/ Although, reading your post i think that accuracey issue is because of the distance going back up again - i was relying on it returning a minus number, but, doh me, of course it doesnt! your right it does make sense. Im not entirly sure how to account for that though, subtracting the radius of the object yes.. but how to know wether to subtract the width, height or length is currently baffling me a little as i think about it whilst writing this. it all depends on which side you just went through at what angle? I dont know, am i even making sense?

But i guess this is a little futile anyway unless i speed up this function somehow.. considering if i rem out the polycol() line in my code i get a nice 400fps and with it on i get between 75 and 105 depending on wether im checking with a cube a sphere.. thats a hefty frame loss -_- Although, as im intersecting against the world position of each of the models vertex's i guess its vertex collision and not poly

Ahh, what do you think? You reckon theres hope for this function? The only reason im trying to write it is because in my game your a tank, and theres trees. These trees have leafs n whatever. Dbp's polygon collision only checks against one objects polys and the other seems to be treated as a spherical collision.. well basically that meant that i couldnt drive *under* my tree leafs/branches ect without it causing a collision.. and suddenly stopping because you got too close to an tree leaf which is in actual fact 1 meter or two above your tank isnt very good for a fast paced tank deathmatch XD

this is what i use for my trees..i'm doing a similar thing with a crawl tractor

colltrees:
if inkey$()="r" then return
for n=firsttree to lasttree
if object exist(n)
diffposx#=abs(object position x(active)-object position x(n))
diffposz#=abs(object position z(active)-object position z(n))
collsqrt#=sqrt((diffposx#*diffposx#)+(diffposz#*diffposz#))
if collsqrt#<80 then x#=collx#:z#=collz#:return
endif
next n

basically you could engage accurate collision detection ONLY IF distance with a tree is below a certain value by calling another subroutine (n would hold the tree number in such a case)

As to me, have not decided yet if to go via intersect or other methods.
So far i have your same problem, it's all right with front and back collision but sides and corner collision is laughable since i get stuck rather far from the tree.
I am considering of re-orienting continuosly the intersect line angle since trees are in fixed world positions but tank is moving, it will be easy to know the tree x,y and z values (START of intersect line) and the the tank/tractor position , and when close to a tree i can easily trigger from the code above the appropriate reaction.
So i am thinking of the following:

As soon as i am close enough to a tree (code above):

start checking intersect FROM TREE TO TANK (high enough not to pass under eh eh)

if intersect is below a certain ( small for closeness ) value trigger reaction to detection.

In this case it should be rather easy and accurate because only one model is moving.
Also it should not eat much frame rate

I haven't coded it yet, but i plan to do soon

Let me know what you think
cheers

Checking the distance to an object to see if its close enough to bother calculating collision on is a good idea, I already use it too ^_^ Currently my engine checks the distance to all objects and hides all ones that are a certain distance away (this gave me back a good 20/30 fps, well worth the hastle of a small function ^^). There is also another function running which does basically the same thing, but checks a much smaller distance and current enables and disables darkbasic's polygon collision accordingly (this in turn actually gives quite a boost of speed, polygon collision running activly on 500+ objects isnt so cool )

As for calculating the collision, yes i agree, with still objects like trees and other terrain it makes life a little easier ^^ It should be quite accurate too.. im going to go have my dinner and then play with all these ideas.
I must admit though, it would be very nice if i could simply get my polycol() function working accuratly and moderatly fast, im still going to mess with that a little too ^^ Anyway, dinner time, im going to go ponder these things