TCP Project - Collision - Discussion

#1 Edit:

Note To Self: Read the admin forum first next time. :)

Hey guys... I do have a question regarding collision (or, more accurately, reading in collision details from a player model) You can find it on the Torque Engine forum... if you want, I guess I could copy it here... ?

Any help would be greatly appreciated. :)

#2 Hy all,

I downloaded last head of torque this evening, and try the nrew racing mod. I found that it is very good and collision seems to be well managed by the engine.
I will stress test it this week, and post some profiler outputs end of this week. I need some time to merge it with my current release of torque and add some 'log point' inside it to output a correct log.

#3 Who is working on or needs high speed projectiles?
I need to simulate rounds moving at approx 2500 fps, who else is facing these same issues?

#4 hmm ..
I think you should not bother using a round at that speed ..
you wont see it anyhow.

this is easily handled with a ray from here to there.

#5 Moving an actual model can be a pretty big waste of resources considering how it can't be seen.

2500 fps = instant when you're dealing with most interactions with the object in most game engines, so you might just want to take the more conservative (and common) approach and use a ray like Badguy said.

#6 I have a rifle modelled at 2250 fps. It seems to work well enough as-is using standard Torque projectiles. Ray-casting is not suitable since the proper ballistics need to be modeled. At 1 mile range, it takes the round over two seconds of travel time with a drop of several yards.

#7 I have tried faking it with a hitscan and it is a poor solution at best. Also if the projectile does not have to have an actual model attacked does it? Maybe I can subclass that and remove that code behavior for extremely fast or extremely small projectiles

2500 fps at 1000 feet introduces enough flight time to not be realistic. Rounds should take time to hit over a distance.

This is one of the problems I plan of solving with what I term a "simu-listic" solution. Something that simulates realistic physics.

Granted at .50 BMG does not drop THAT much over 1000 feet, but it does drop some.

Now that is 250ms of travel time, that seems like very little but it IS noticeable when playing that the round hit instantly instead of the slight pause.

Also instant hitscan makes developers add in stupid "features" to compensate for the instant hit. Like ridiculous amounts of visual sway or randomness in the spread, or extremely nerf like damage models, etc.

OPF has flight time over long distances like 2000 meters.
You fire, and see the puff just a little bit later, from the behavior of the game it does NOT seem that they are post drswing effects as you have to lead targets with every weapon. Granted 7.62 NATO rounds fly about 1200 fps so they are more noticeable but it is extremely hard to hit anything at that range, but when you do it is very satisfying. The 830ms difference is a skill the player has to develop and learn to compensate for.

Anyone with any thoughts on this PLEASE feel free to give me some suggestions as long as they take into account the first rule, simulistic behavior.

#8 Hmm actually, I think I have cranked it up over 2000fps before.

I think my current "crossbow" from the demo is almost an instant shot.

Duh! Next time I'll look over my work think before I make dumb statements :p

#9 Well, I tried to post this before but it looks like it got eaten. What I said was, more or less:

A way to deal with high, but not infinite speed, projectiles (ie, hypersonic bullets, but not lasers) is this:

95% of the time, the projectile is going to hit something right off. So what you do is, figure out how far it'll move in a frame (do this in code, frame rates vary), then do a hit ray from its current position to that ending position. If nothing hits, then it keeps going. If it hits nothing, then it does; do what's appropriate. Apply physics, etc. to it as normal. You can do drag or whatever this way. You can even render the bullet if you like (perhaps if its moving slowly enough? Above a certain speed small things are essentially invisible.).

Advantages: fast, efficient, deals well with very fast objects.

Disadvantages: requires coding, another "type" of thing to deal with.

#10 Is there any thought on adding more physics to the engine? I've noticed the addition of the rigid class for rigid-body physics, but it only seems to be used by the vehicle objects. I don't remember enough of my physics to know if this class is robust enough or even appropriate for players or other non-vehicle physical objects. Any comments?

#11 When you're talking about these super-speedy projectiles, are you talking about projectiles with mass and BOUNDING BOXES? Because that's very cool and impressive if so; I was under the impression that, if a game even modelled those projectiles at all as opposed to raycasting (which is one of my most hated things about FPS games nowadays; it makes the combat extremely one-dimensional), I was under the impression that they didn't use projectiles with actual physical properties -- instead it would just do a set amount of damage. But this way, it could be modelled -- it damages you in relation to where it hits AND how much force it has in relation to the angle (ie, you could have actual 'glancing blows', although this would necessitate a largeish physics overhaul to give per-poly collision detection (and to allow models to be assigned physical materials properties on a per-poly basis, so the chest area is covered with body armor on model X). I mean, imagine the amount of force that a .50 military sniper rifle bullet would have; it would knock you back quite a bit.

THis is all just rampant "wouldn't it be l33t" speculation on my part. Man I am tired. More Marble Blast, less talk. Oh oh and there's an apple pie in the kitchen, I gtg.

#12 If anyone's still interested in implementing something like this, you would do well to take a look at Infiltration, a mod for Unreal Tournament. The mod essentially makes use of something similar to what Ben described above, whereby it calculates based on a series of successive raycasts ("hitscans" in UT, iirc), calculated for bullet drop and velocity loss (and therefore energy loss). This is certainly less processor intensive than actually calculating a full-on physics model for each projectile flying through the air (I think WW2 Online had this problem initially). And a light clarification to Jarrod's mention of OFP: only the sniper rifles make use of proper ballistics.

Now, the danger, at least too this layman, of using a very fast-moving projectile, is that unless you account for interpolation, a bullet could actually go "through" something without registering a hit, if your framerate is low enough.

#13 @Teck: The danger you mention is real. The possibility of going through things without hitting, due to moving too far per frame, is the biggest problem with fast projectiles. Ben Garney gave a solution for it though. I have pasted it below. The "hit ray" he mentions is designed to check whether the bullet would pass through something between frames.

Ben Garney said:
95% of the time, the projectile is going to hit something right off. So what you do is, figure out how far it'll move in a frame (do this in code, frame rates vary), then do a hit ray from its current position to that ending position. If nothing hits, then it keeps going. If it hits nothing, then it does; do what's appropriate. Apply physics, etc. to it as normal. You can do drag or whatever this way.

#14 Hmmm... perhaps the bullet could duplicate a ghost object in between frames and then a ray could be traced to the ghost object from the true bullet and if the ray overlaps the target's collision then its a hit? I'm just speculating here of course.

#15 What I suggest is this. Specify a new class of high speed projectiles that aren't even projectiles at all. When fired they should cast a CONE based on the rate of travel and the fastest rate of travel of targets to the pre-specified length of travel.


So lets say we had a round that had a speed of 5000 units per second and a lifetime of 2 seconds which leaves a possible 10,000 unit cone length. Next lets say that the fastest target on the server is a player with a maximum speed of 30 units per second. In two seconds the player could move 60 units so the cone radius would be 60 units at the 10,000 unit length and narrows to zero at the barrel of the weapon of course. Now It's assumed at this point that you have already calculated any drift and drop for the projectile and we now have a ballistic cone hanging in space. If there are no targets within this cone then there is no possibility of a collision and the projectile should just fire harmlessly(all the sounds and smokes, no real projectile). If any "target" objects are within this cone then they become potential impacts and a new firing of the weapon is scheduled based on the exact time of impact should the potential target and the "projectile" collide. At that scheduled time a raycast is done from the original firing coordinates and if the target has indeed moved infront of the ray(target did not change direction or speed) then an impact is registered and handled appropriately. This method should allow almost perfect handling of high speed projectiles.


The important thing to remember here is you are trying to simulate analog physics in a digital world. Projectiles do not fly in straight lines, they teleport from point to point inside the game, so you have to use a dual system to compensate for that accurately. Bens method is a good one for most situations. But if you want, or need higher precision, then a simple cast is not quite enough. IMO a dual firing collision predicting cone would give all the accuracy you'll ever need.

Note, there is a little more to it than I explained above. In addition to the cone looking for targets, the ray should be cast to look for static interception of the path. Could not the audio cones be adapted to be used in this manner? Just a thought.

#16 Any realistic system should have a plugNplay interface for using external 3rd party physics engines.

It is unlikely that GG will surpass http://www.ageia.com/ Novodex engine.

I think this is a glaring deficiency, one that even ORGE does not have.

#17 @Nanomid: Others have integrated external physics engines before, like ODE.

Isn't Novodex a physics engine... ? GG is a company, do you mean TGE ? TSE maybe, Torque core. In any case Novodex isn't competing with Torque and vice versa, its an external physics engine that can be integrated with a "Game" engine, like Havok... whats unique to Novodex is it seems it will have ties to the companies hardware accelerated physics chip. What comparisson are you making between it and "GG"?

#18 The point was that 3rd party (Not-GG) physics engine should be planned if not actively supported.
Torque isn't competing with Novodex, so why not support their (and other's) physics engine?
A game engine without a physics engine isn't very useful.

Am I missing something? Is there external physics support somehere in the TSE code and I'm just missing it?

I just checked out the TSE CVS again, to make sure. I don't see anything in the collision directory.

OGRE already has a 3rd party impl of their physics utilizing Novodex.

This is my point.

#19 Nanomid,
We are *very* well aware of the 3rd party physics libraries out there.

Torque's collision and physics is spread across the engine instead of being bundled up in a nice/neat little library you can easily swap out. However, if you take the time to understand how the current system works you can integrate other 3rd party physics solutions (as has been proven several times over now).

The biggest issue with using 3rd party physics libraries is that *none* of them support networked physics very well. You can shoehorn them into doing some basic networked physics but this runs poorly and tends to have a lot of disturbing artifacts (check out HL2DM). With an engine that is built around networking from the ground up like Torque this is a pretty big issue.

We are aware of the issues and are working towards addressing them.

#20 Point taken: real-time distributed processes are not easy. I doubt OGRE has been through these weeds yet.

I've looked at it more in depth, and think I can probably grow a set of libraries that may one day congeal into a physics SDK.