Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / High Speed Bullet Collision

Author
Message
Ruler8163
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: Atlanta, GA
Posted: 28th May 2005 03:13
Link
Alright, I have a game(somewhat) but im having trouble detecting bullet collisions using intersect object and/or static line of sight. It would be greatly appreciated if anyone could post an example (that works) which detects if a bullet has collided with the player. This code must also work when the bullet is traveling extremely fast, but not instant.

Any help is greatly appreciated, Thanks

There are no restrictions to a language...
Back to top
Profile PM
RiiDii
20
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 28th May 2005 03:34
Link
Intersect Object should work just fine. You just have to make the line long enough. The other set back of Intersect Object is that you have to check for all possible object collisions. Here's some concept code (psuedo code):



"Droids don't rip your arms off when they lose." -H. Solo
REALITY II
Back to top
Profile PM Email
Supremacy
21
Years of Service
User Offline
Joined: 30th Dec 2003
Location:
Posted: 28th May 2005 03:41 Edited at: 28th May 2005 03:42
Link
this is the one i like most:

oldx#=object position x(obj)
oldy#=object position y(obj)
oldz#=object position z(obj)
move object obj,dist

x#=object position x(obj)
y#=object position y(obj)
z#=object position z(obj)
move object obj,-(dist)

collide=intersectObject(1,1,oldx#,oldy#,oldz#,x#+rt,y#+(rt*2),z#+rt,0)


this uses sparkys collision dll, but its exactly done the same way in ncglory, sparkys dll is free,

the way this works is simple, the "obj" var is your bullet, the intersect object command detects collision from your bullet movement vector and a specific object, in this case the player, wich is in group 1 (read sparkys manual for better understanding of collision groups, its pretty straightforward and easy), finally, when "collide" is bigger then one, the bullet has hit the player, or any object in group one (Ex: a gang of enemys), then just call this code when u press mouse button, and for several bullets or something just make a timer variable, that calls the fiering code if mouse button is pressed and if the timer is equal to 0, the just increment the timer somewhere in the main loop and when it reaches the fiering intreval reset it to zero, something like that but not exactly how ive said, my english is not the best, but i hope i was of any help, cheers

Quote: "Riddi u basterd u got here first while i was typing "


Back to top
Profile PM Email
Ruler8163
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: Atlanta, GA
Posted: 28th May 2005 04:01 Edited at: 28th May 2005 04:02
Link
I like your code Riidii, but it looks like it does a lot more than necessary(more time). Thanks both, Ill try you code Supremacy but ive been trying things along those lines. If you dont mind, could you explain what some of the variables in the intersect object command mean, such as (rt)? And why your multiplying it by 2. One last question, what is the second parameter for in interesect object(Yours)? You have too many!

There are no restrictions to a language...
Back to top
Profile PM
Ruler8163
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: Atlanta, GA
Posted: 28th May 2005 04:20
Link
Ok i tried your code, and it doesnt work. I think it may have sometihng to do with the information that the function (intersect object) returns. It doesnt return whether or not theres something in the way but the distance to that that intersection. Any other ideas ? And i already have a system that controls multiple bullets so ill be running this code for every bullet that exists.

There are no restrictions to a language...
Back to top
Profile PM
G Man
20
Years of Service
User Offline
Joined: 17th Nov 2004
Location:
Posted: 28th May 2005 04:34 Edited at: 28th May 2005 04:46
Link


Call this code once each rendering loop for each bullet in flight. If it returns anything but 0 (zero), your bullet hit something and you need to react accordingly (the return value is the number of the object it hit btw). Also, you need to account for a maximum range on the bullet and ensure that the bullet either stops flying or ricochets if it hits the level. Note I don't have DBPro here at work so there might be some syntax errors in that code, but you should be able to get the idea from it.

Intel Pentium 4, 3.4GHz, 1280MB RAM, NVidia Quadro FX3000/256MB, 240GB HD, XP Pro
Back to top
Profile PM
Ruler8163
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: Atlanta, GA
Posted: 28th May 2005 08:42 Edited at: 28th May 2005 08:43
Link
I will give it a try, but im tryin to make a game that will work on a large variety of cpu's. I mean that this will most likely lag on a standard cpu along with the rest of my code. Do you have anyway of detecting a collision without searching through all of the possible objects to hit for each bullet?

There are no restrictions to a language...
Back to top
Profile PM
Ruler8163
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: Atlanta, GA
Posted: 28th May 2005 08:52
Link
Nevermind, I know understand what this function does exactly. Their(The Game Creators) definition about the first parameter isnt exactly the best. I was putting the actual bullet instead of the "obstacle" and therefor making it check to see if it had collided with itself(A the simple $#!T) . Thanks for your help, its appreciated.

There are no restrictions to a language...
Back to top
Profile PM
Supremacy
21
Years of Service
User Offline
Joined: 30th Dec 2003
Location:
Posted: 28th May 2005 08:52
Link
sorry, the code i provide are just guidlines, it doens actually work, its just for explaining you what u should be after, right now i dont have the time, try sparkys collision dll and watch is demo, youll understand it all, for the multiple bullets u dont need to call that code for each bullet, that will waste a lot of memory, u should instead call that code as many times has many bullets you shot, thats what i tried to explain, give a shot at sparkys dll, if u cant do it still ill upload working code for you

Back to top
Profile PM Email
RiiDii
20
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 28th May 2005 09:10 Edited at: 28th May 2005 09:11
Link
Your main obstacle in lag ultimately won't be cycling through all the possible objects, because for that you can limit it to object that are in the area - it's a matter of clever coding for that.

Instead, you'll be confronted with the problem of terrain. Now, maybe I'm skipping ahead here a bit, but at some point, a matrix won't cut it for you as terrain and you'll want to use an object as terrain. When that happens, you will experience the problem of collision with that terrain, and not just with bullets.

Pretty much, just thinking about using polygon collision on a terrain object will bring the pc to a virtual lag-halt. The solution is Intersect Object. You can turn off the Object Collision all together with Intersect Object. Also, it's more flexible and often faster than the included collision commands.

Excluding the terrain problems, a lot of decent models are fairly high poly count as well. If you need an accurate bullet hit/miss system, you will face the same problems as listed for terrain. So, advice is to use Intersect Object and give it a shot (no pun intended ). I suspect you can check hundreds of collision possibilities before most pc's even begin to show any lag.

If you want to use object collision for bullets, just stretch out your "bullet" to be as long (or slightly longer) than it's move speed. Then simply check for collision each time you move your bullet forward. Example: If your bullet move speed is 100 (Move Object bulletID,100), then use something like; Make Object Box bulletID, .5,.5,101. Then just check for collisions (oc=Object Collision (bulletID,0).

Alternatively, moving the object multiple times during each sync happens pretty fast, so let's say you still want your bullet to move 100, but want to prevent it from getting confused if it hits 3 objects at once. The solution is to make the object smaller (maybe 1/10th the size) and move it multiple time (10x).


Note that there is no Sync in the loop. It's not needed and will run almost as fast as a single move of 100 and a sync (well 10 x 0.3miliseconds, or something like that)

Quote: "Now who's the basterd?"


"Droids don't rip your arms off when they lose." -H. Solo
REALITY II
Back to top
Profile PM Email
Ruler8163
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: Atlanta, GA
Posted: 28th May 2005 11:01 Edited at: 28th May 2005 14:18
Link
Ok, I dont mean to stretch the topic of this subject, but you noted something about terrains and checking them for collisions. Is a terrain considered an object and if so, do you know of any good terrain editors.

I knew that i would have to switch over eventually since i cant detect collisions with a matrix, so why not now

One last question that isnt too far off the topic, is there a way to find if two(say people) can see each other? I know of the command "static line of sight" but it doesnt quite work. (I think it may have something to do with my sky sphere.) Any help would be great

I promise this is my last question


Thanks for the help.

There are no restrictions to a language...
Back to top
Profile PM
RiiDii
20
Years of Service
User Offline
Joined: 20th Jan 2005
Location: Inatincan
Posted: 30th May 2005 01:13
Link
Quote: "since i cant detect collisions with a matrix"

Technically, this can't be done, but simply checking if the Ground Height is above a certain Y-value (i.e. the bullet's height) at the given coordinates, then a collision occured. However, there are a lot of other limitations on matricies that terrain objects overcome - for example; vertical walls (like cliffs), buildings, folded terrain (like caves and outcroppings).

Quote: "Is a terrain considered an object"

Yes, terrain is simply an object you use as the terrain.

Quote: "is there a way to find if two(say people) can see each other?"

Not sure if you mean "see", as in two cameras: :use a second camera, and maybe Set Camera View

Or if you mean see as in AI seeing a player or another AI: The easy way of doing this is to create a large sphere and position it on the AI-object that's doing the "looking." Then check the sphere for collisions with object that you are checking "to see". If there is a collision, then the object is considered to be "seen." Again, checking for 1 object at a time is probably better than checking for all objects. The reason: What happens if you use the global Object Collision (obj,0) and there are multiple objects in range?

A more complicated way, but faster in processing time, is to calculate the distance each object is from the AI object you want to check for using d2#=(dx#*dx#+dy#*dy#+dz#*dz#) (where dx#= x1#-x2#, and so on, is the distances between the two objects on each coordiante). This is basically the Pythagorean Theorem except 3D and excluding the final square root. The reason is that square root is so slow (also squaring is slower than multiplication), so just deal in "squared space" whenever possible. So, if you want to check a distance of 50, simply do the math yourself and check if the "squared space" result is less than or equal to 2500.

"Droids don't rip your arms off when they lose." -H. Solo
REALITY II
Back to top
Profile PM Email
DcZee
22
Years of Service
User Offline
Joined: 28th Apr 2003
Location:
Posted: 31st May 2005 00:50
Link
My recommendation is to fake it. Trying to collision test every bullet is kind of a system hog issue. Once you have established what the gun is pointing at when the trigger is pulled, then fall back to a statistical placement of bullets in that area. One bullet is a breeze, but when you are firing a machine gun, lag can become your friend. Instead, calculate the percentage of bullets that might hit that target based on the players ability, the gun type, the distance to target, the targets armour and the damage caused by each successful bullet..it could be a look up table of values making it very very fast,..then throw the bullet splatter effects and the blood squirting effects and then onto the next target. The only repeat that has to occur is the tracing of your direction to find what object you are hitting. If you move off target, spray the ground, or wall or tree that is now being detected by your raycast. You could also tailor your bullet detection routine to match the type of weapon you are using. A single shot weapon can be single bullet traced without compromising speed. fake it, fake it, fake it,...

As for terrains, ive been using .X files and they work great. I use a combo of geoscape and ac3d to make them, psp 8.1 for the textures, and action3d to retune the poly levels. A typical larger terrain runs at about 480 fps without any objects on it. The critical thing, and with most dbpro commands, is to size your terrain inside your modeller. Over scaling inside dbpro causes lots of functions to stop working properly, like hardware light shading. At the most, I apply only about 200 scale max to any object inside dbpro. If you go over that then you will lose the functionality of many of the cooler dbpro commands.
Back to top
Profile PM Email Website
Raven
20
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 31st May 2005 01:17
Link
I agree with DcZee.
The solution I'd use without Nuclear Glory Collision or Newton Raycasting, would be to create an invisible triangle/polygon that is attached to the barrel end.

You then enlarge it until it collides with something.
Then if it's colliding with the model, you do the damage of the bullets based on a timer of how quickly they'd make it that far.

It's not a very accurate model because the bullets will always follow the gun, so really quick firing guns would change thier direction. Still it stops taking up valueable processor power. ^_^

Back to top
Profile PM Email Website
Max
20
Years of Service
User Offline
Joined: 4th Apr 2005
Location: Behind your back....
Posted: 31st May 2005 01:20 Edited at: 31st May 2005 01:22
Link
The technique I am using is this (when there is a crosshair):

if the return obj is an enemie then you hit him!

Back to top
Profile PM Email
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 31st May 2005 01:24
Link
In DBPro, bones are regarded as limbs, so that gives you the position of each joint on your enemies. If you gave each bone a radius, a line to circle collision check could give limb based collision. That's what I did in Lonewolf, and that's afforded me gibs, blood spurting from wounds, and pain jerks in whatever part you shoot at. I even use the bones on the enemies gun to project the bullet and aiming calculation, which gives the 3D location, the direction vector, and from those making a bullet system is real easy. My bullets travel, like they have speeds so this does'nt apply, but you could detect the level collision of the bullet first - like you'd project your line for a real long distance and grab the collision point, then the collision point is stored and the line between the start and the collision point is all you need worry about, anything in the path get's hit, then that's it - bullet done. Often it's the tracking and constant checking of multiple bullets that instigates the slowdown, well more than a simple intersection check anyway, like wasted collision checks are enemy #1.

It's not ickle at all, but then nothing really is that does it's job properly. I like Sparky's .dll, I use it for bullet collision, but for detecting character collisions there's only so much you can do with it.


Van-B

Back to top
Profile PM Email
Max
20
Years of Service
User Offline
Joined: 4th Apr 2005
Location: Behind your back....
Posted: 31st May 2005 01:38 Edited at: 31st May 2005 01:38
Link
Quote: "In DBPro, bones are regarded as limbs, so that gives you the position of each joint on your enemies. If you gave each bone a radius, a line to circle collision check could give limb based collision. That's what I did in Lonewolf, and that's afforded me gibs, blood spurting from wounds, and pain jerks in whatever part you shoot at. I even use the bones on the enemies gun to project the bullet and aiming calculation, which gives the 3D location, the direction vector, and from those making a bullet system is real easy. My bullets travel, like they have speeds so this does'nt apply, but you could detect the level collision of the bullet first - like you'd project your line for a real long distance and grab the collision point, then the collision point is stored and the line between the start and the collision point is all you need worry about, anything in the path get's hit, then that's it - bullet done. Often it's the tracking and constant checking of multiple bullets that instigates the slowdown, well more than a simple intersection check anyway, like wasted collision checks are enemy #1.

It's not ickle at all, but then nothing really is that does it's job properly. I like Sparky's .dll, I use it for bullet collision, but for detecting character collisions there's only so much you can do with it.
"



I didn't really understand that.. could you give a code sample?

Back to top
Profile PM Email
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 31st May 2005 02:17
Link
It would take a while to make an example, as it requires that you know the radius of each bone that your checking, but maybe I can word it better.

For each bullet, you would have a start and an end point, like the bullets path in 3D stored as 2 sets of coordinates. Then stepping through each limb in an object, you would do a sphere-line collision check using the bullet path as the line and the object limbs as the spheres. You could also do halfway checks, like work out the mid point between 2 limbs and the average sphere radius and do a check on that as well. If you imagine each enemy walking around wearing a bubble costume, like the Michellin man, that's how they'd look if the sphere's were visible.
When the sphere-line collision check returns a positive, you know which limb has been hit, and then things like gibs are much easier, as are head shots etc. With a standard mesh collision check you still have to work out which limb has been hit, it may be the case that the sphere-line check is done after a positive mesh intersection check, depends a lot on the bone structure.

It's certainly worth doing, things get a whole lot more fun when you can see them flinch or bleed more realistically. I just use a random interference on the limbs when they get shot, like rotate them a little and dampen it smoothly so the limb goes back to normal smoothly afterwards - I use it for gun recoil as well. When you can detect which limb has been shot, you can store the states in an array and refer to them to do effects like this, and with the limb positions it's easy to get blood spurts working.


Van-B

Back to top
Profile PM Email
Max
20
Years of Service
User Offline
Joined: 4th Apr 2005
Location: Behind your back....
Posted: 31st May 2005 03:47
Link
Thank you! got it all right this time =]

Back to top
Profile PM Email
Ruler8163
20
Years of Service
User Offline
Joined: 10th Apr 2005
Location: Atlanta, GA
Posted: 31st May 2005 06:07
Link
wow........., well i think all of my questions have been answered. Thanks a million.

There are no restrictions to a language...
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2025-06-06 17:35:39
Your offset time is: 2025-06-06 17:35:39