Tribes:Ascend Forums

FAQ • Login • Register

please address the many CORE PHYSICS ISSUES ASAP
Author	Message
-AEnubis- Joined: Fri Aug 05, 2011 2:40 am Posts: 4823 Location: NA East	Re: please address the many CORE PHYSICS ISSUES ASAP Actually, I don't think any of the bullet weapons have more than 20% inheritance for that reason. _________________ Physics \| CTF Scoring \| Team Selection
Sun Apr 08, 2012 8:59 pm

hvcterr Joined: Thu Jun 16, 2011 3:41 am Posts: 1567	Re: please address the many CORE PHYSICS ISSUES ASAP Physics engines often have difficulty with high-speed movements beyond certain thresholds, doubly so for game engines where there are time constraints on how responsive it needs to be. If anyone wants to claim maximum-speed of projectiles won't be an issue in T:A, I'd like to at least see some math to go with it. _________________ Did you know you can disable annoying signatures? Look under Board Preferences >> Edit Display Options.
Sun Apr 08, 2012 9:09 pm

Schottingham Joined: Wed Sep 14, 2011 4:07 pm Posts: 644	Re: please address the many CORE PHYSICS ISSUES ASAP blecro wrote: I think the biggest issue is jet physics. Agreed. blecro wrote: Tribes 1 and Tribes 2 Classic use mostly the same system and it's an important part of the Tribes feeling. Andrew's code speaks volumes, in particular Player.Jet and the "jets and acceleration" part of Player.Tick. I also wrote about the general idea in another post. Instead of adopting and expanding this system, Tribes Ascend starts fresh with a new system based on velocity rotation (air control). This might end up being great, but I can't help but think it's silly to throw away such an important part of the old games. You don't need to clone it, but at least keep the general idea! I was reading through this code again recently to see how T1 handled vectored thrust--because I know it wasn't possible to accelerate horizontally forever--and I found something interesting that I wanted to share: Currently in T:A, it seems that you get some directional thrust until your velocity magnitude is >= 72km/h. Clearly while pressing W and jetting from a standstill, you accelerate faster than you would with air control alone. Once you reach 72km/h, no matter the direction, your jets basically cease to accelerate you (acceleration drops by about 90%, from ~10km/h/s to ~1km/h/s), causing players to trace straight lines through the air. As it turns out, Tribes 1 did have a speed cap on the jetpack, but ONLY IN THE HORIZONTAL PLANE. Here's the code segment that implements it: (mostly copied from Player.Jet) Code: float JETFORWARD = 22 ... float forwardVelocity = MetersToUnits( armor.JETFORWARD ) if( some irrelevant stuff ){ float orientation = velocity.Dot( moveDirection ) if ( orientation > forwardVelocity ) sidePower = 0 else if ( orientation < 0 ) sidePower = armor.JETSIDEFORCE else sidePower = ( 1 - ( orientation / forwardVelocity ) ) sidePower = Min( sidePower, armor.JETSIDEFORCE ) Vector3 sideForce = ( sidePower * jetForce ) * moveDirection Vector3 upForce = ( ( 1 - sidePower ) * jetForce ) * Gravity.upNormal return ( upForce + sideForce ) } else { // straight up, full jets return ( jetForce * Gravity.upNormal ) } To paraphrase: Armors get a maximum thrust force they can output, "jetForce". If you jet without pushing a direction key, you get full jetForce in the upward direction. At low speed, pushing a direction key while jetting directs JETSIDEFORCE (80% of jetForce) in that direction (20% of it remains in the upward direction) The cap comes in when you are moving at or above JETFORWARD (22m/s or 79.2 km/h), and try to use your jets to accelerate in the same direction you are already moving. The game will then take the component of your attempted jetting that is in the direction you're moving, and redirect it upwards. What this last point means is that you can't use your directional jets alone to accelerate faster than 79.2km/h horizontally, but you can use them to turn or slow down no matter what your speed (by jetting perpendicular or opposite to your velocity, respectively). Important differences compared to Ascend: - Vertical jet thrust is never limited based on speed. - Thrust that is not applied because of the speed limit is redirected upwards. (moot, since Ascend performs the speed limit check in all dimensions) - Directional jets still work for turning at high speed. Postin' this again, because it's still relevant. Red is Ascend jetpacks, green is T1/T2 jetpacks. As best I can tell, Ascend looks at your speed (no matter the direction!), and if it's over 72km/h, says "no more directional thrust for you, and you only get enough upward thrust to cancel gravity". The result is that jets cannot be used for turning at speed, less height is gained when jetting upwards at speed, and even the ridiculous bug of not being able to slow yourself down when falling faster than 72km/h. --- So there you have my sort of "unified theory of why Ascend's jetpacks feel terrible". The T1 horizontal cap was not really even significantly higher than Ascend's, but that dot product and uncapped vertical thrust make all the difference. To be clear, I am suggesting 3 changes (which would amount to porting the T1 Player.Jet code): 1) Perform 72km/h check only in horizontal plane. Full vertical thrust available at all speeds (positive AND NEGATIVE). 2) Make it a vector compare instead of magnitude only. Full side thrust available when directed perpendicular to or opposite your velocity. 3) Any thrust subtracted as a result of hitting the horizontal limit should be directed upwards. No thrust should disappear the way it does currently. _________________ - Fix Jetpack Physics (video) (video) - Remove regen, bring back health kits - Buff explosive jumping - 100% inheritance for "bullet" weapons (nova blaster included)
Mon Apr 09, 2012 2:44 am

RootbeerAlamode Joined: Mon Dec 05, 2011 5:01 pm Posts: 1538 Steam Gamer Name: D-Hearts	Re: please address the many CORE PHYSICS ISSUES ASAP hvcterr wrote: Physics engines often have difficulty with high-speed movements beyond certain thresholds, doubly so for game engines where there are time constraints on how responsive it needs to be. If anyone wants to claim maximum-speed of projectiles won't be an issue in T:A, I'd like to at least see some math to go with it. So what you are saying is that Hi-rez chose to use an engine that is ill suited for a tribes game. _________________ 100% Inheritance, 100% Intuitive. Inheritance Demonstration [video] Tips for Aiming with 100% [video]
Mon Apr 09, 2012 3:20 am

DrNope Joined: Sun Jan 29, 2012 6:04 am Posts: 296	Re: please address the many CORE PHYSICS ISSUES ASAP hvcterr wrote: Physics engines often have difficulty with high-speed movements beyond certain thresholds, doubly so for game engines where there are time constraints on how responsive it needs to be. If anyone wants to claim maximum-speed of projectiles won't be an issue in T:A, I'd like to at least see some math to go with it. As far as I remember about collision stuff (coded a physics/collision engine about 1.5 years ago): Collision handling could be a problem at high speeds if UE3 doesn't support predictive collisions (or if its simply too calculation expensive). Non-predictive systems advance one frame in the physics sim, and then just check for intersections at that point of time, causing fast objects to tunnel through geomentry, if the distance traveled is higher then half the depth of the own geometry perpendicular to the collision plane/poly (between 0.5 and 1.0 of that value the collision can be recognized, but on the wrong side... depending on intersection handling the colliding objects are either simply moved far enough away to not colide anymore or are propelled as if the intersection depth applied a spring force to them). Predictive systems look ahead in time and resolve collisions in order they occur (forcing the system to recalculate some of the nearby collisions of the first one that could have changed). It's way more expensive calculations-wise, and i'm not sure if both systems can be mixed very well (but I think it can be done for different use-cases), so i'd guess it's a matter of performace that its not done (can't imagine UE3 doesn't support it... every somehow decent pool billard/pinball game needs this to get really accurate impact angles and therefore predictable results etc..). But if bullets in T:A use this (they are very fast and small, so it would be a problem with them first) I see no reason why other projectiles shouldn't have it (modeling the projectile as a point in space -> the check for predictive collision is done with a line against a plane vs. having a sphere with radius X and checking where that line is in X distance from that plane, 2 results, take the closer one, is not that big difference...). _________________ Ingame: DrNoes Credits alternative Fix Fusion Mortar physics Give autos their role as finishers and for chasing
Mon Apr 09, 2012 5:07 am

hvcterr Joined: Thu Jun 16, 2011 3:41 am Posts: 1567	Re: please address the many CORE PHYSICS ISSUES ASAP I wish I knew the speed of the fastest current projectile relative to in-game measurements. Then you could use an assumed tick-rate of 30 to determine the "thinnest allowable wall" if it were doing naive collision checks. (And not something like swept volumes.) _________________ Did you know you can disable annoying signatures? Look under Board Preferences >> Edit Display Options.
Mon Apr 09, 2012 5:32 am

DrNope Joined: Sun Jan 29, 2012 6:04 am Posts: 296	Re: please address the many CORE PHYSICS ISSUES ASAP hvcterr wrote: I wish I knew the speed of the fastest current projectile relative to in-game measurements. Then you could use an assumed tick-rate of 30 to determine the "thinnest allowable wall" if it were doing naive collision checks. (And not something like swept volumes.) Don't forget that the saber missile speed (for example) is added to the fastest bullet ingame (the velocities of moving objects are taken into account to make it a "one-moving-object-against-a-static-object-problem"). AFAIK, colission tests are always done against planes in the first place (as long as there are not very optimized formulas for capsules etc. I'm not aware of, but for the most part picking the right poprtion of the polygon cloud via oct-trees etc. and then perform some early-exit checks should be the way to go... any game dev gurus here?), so theres no real "thickness" of a wall (maybe followed by containment checks). I guess the projectiles are modeled as spheres and are early-exit-checked against collision-spheres of everything other (-> only if the min distance in the coming frame between the two will be <= r1+r2 other checks are performed). Checking the min distance of a ray-segment against a plane is pretty fast, so bullet velocities should never be a problem imo (as long as floating point accuracy-problems don't kick in, but that should only be the case in extreme cases). Just having axis-aligned-bounding-boxes around every projectile/bullet seems like unoptimized overkill to me (cacluation-cost-wise) and I can't believe UE3 does it like that. But I can just guess here.. never testet UDK3. _________________ Ingame: DrNoes Credits alternative Fix Fusion Mortar physics Give autos their role as finishers and for chasing
Mon Apr 09, 2012 5:57 am

blecro Joined: Sat Jul 03, 2010 11:09 pm Posts: 192	Re: please address the many CORE PHYSICS ISSUES ASAP Schottingham wrote: [jet stuff] Yes! Tribes 1 and Tribes 2 essentially adjust your jet angle upward as the scalar projection of your velocity onto your horizontal jet direction increases, but Tribes Ascend does its own thing. The thrust pack has similar unexpected behavior, as discussed in another thread.
Mon Apr 09, 2012 6:22 am

Njordstar Joined: Fri Dec 30, 2011 7:39 am Posts: 33	Re: please address the many CORE PHYSICS ISSUES ASAP I did some search on my PC and found this tutorial video from Mirage in T2. This shows very well how movement with jet pack ought to be..... Thanks to Mirage for this awesome video! Nordstern
Mon Apr 09, 2012 6:46 am

root Joined: Tue Mar 15, 2011 11:30 pm Posts: 856	Re: please address the many CORE PHYSICS ISSUES ASAP Schottingham wrote: So there you have my sort of "unified theory of why Ascend's jetpacks feel terrible". The T1 horizontal cap was not really even significantly higher than Ascend's, but that dot product and uncapped vertical thrust make all the difference. To be clear, I am suggesting 3 changes (which would amount to porting the T1 Player.Jet code): 1) Perform 72km/h check only in horizontal plane. Full vertical thrust available at all speeds (positive AND NEGATIVE). 2) Make it a vector compare instead of magnitude only. Full side thrust available when directed perpendicular to or opposite your velocity. 3) Any thrust subtracted as a result of hitting the horizontal limit should be directed upwards. No thrust should disappear the way it does currently. Wow, I'm kind of surprised by this. I'm not a coding guy, but playing T1 for... what... 2 years competitively followed by another 2-3 casually... I could have sworn that T1 did not have a horizontal speed cap. Sometimes when I'm real high in the air in T:A and I want to just go forward another few meters, I hold "W" and jet. It takes me almost nowhere. I attribute that to the horizontal speed cap, yet in T1 I felt like I could "push forward" using my jets, even going faster than 72km/h. Perhaps I'm just perceiving it wrong, due to T1's transfer of the vector thrust or whatever you call it.
Mon Apr 09, 2012 9:23 am

Display posts from previous: Sort by

please address the many CORE PHYSICS ISSUES ASAP

Author

Message

-AEnubis-

Joined: Fri Aug 05, 2011 2:40 am
Posts: 4823
Location: NA East

Re: please address the many CORE PHYSICS ISSUES ASAP

Actually, I don't think any of the bullet weapons have more than 20% inheritance for that reason.

_________________

Physics | CTF Scoring | Team Selection

Sun Apr 08, 2012 8:59 pm

hvcterr

Joined: Thu Jun 16, 2011 3:41 am
Posts: 1567

Re: please address the many CORE PHYSICS ISSUES ASAP

Physics engines often have difficulty with high-speed movements beyond certain thresholds, doubly so for game engines where there are time constraints on how responsive it needs to be.

If anyone wants to claim maximum-speed of projectiles won't be an issue in T:A, I'd like to at least see some math to go with it.

_________________
Did you know you can disable annoying signatures? Look under Board Preferences >> Edit Display Options.

Sun Apr 08, 2012 9:09 pm

Schottingham

Joined: Wed Sep 14, 2011 4:07 pm
Posts: 644

Re: please address the many CORE PHYSICS ISSUES ASAP

blecro wrote:

I think the biggest issue is jet physics.

Agreed.

blecro wrote:

Tribes 1 and Tribes 2 Classic use mostly the same system and it's an important part of the Tribes feeling. Andrew's code speaks volumes, in particular Player.Jet and the "jets and acceleration" part of Player.Tick. I also wrote about the general idea in another post. Instead of adopting and expanding this system, Tribes Ascend starts fresh with a new system based on velocity rotation (air control). This might end up being great, but I can't help but think it's silly to throw away such an important part of the old games. You don't need to clone it, but at least keep the general idea!

I was reading through this code again recently to see how T1 handled vectored thrust--because I know it wasn't possible to accelerate horizontally forever--and I found something interesting that I wanted to share:

Currently in T:A, it seems that you get some directional thrust until your velocity magnitude is >= 72km/h. Clearly while pressing W and jetting from a standstill, you accelerate faster than you would with air control alone. Once you reach 72km/h, no matter the direction, your jets basically cease to accelerate you (acceleration drops by about 90%, from ~10km/h/s to ~1km/h/s), causing players to trace straight lines through the air.

As it turns out, Tribes 1 did have a speed cap on the jetpack, but ONLY IN THE HORIZONTAL PLANE.
Here's the code segment that implements it: (mostly copied from Player.Jet)

Code:

float JETFORWARD = 22

...

float forwardVelocity = MetersToUnits( armor.JETFORWARD ) 
if( some irrelevant stuff ){
   float orientation = velocity.Dot( moveDirection )  
   if ( orientation > forwardVelocity )  
      sidePower = 0  
   else if ( orientation < 0 )  
      sidePower = armor.JETSIDEFORCE  
   else  
      sidePower = ( 1 - ( orientation / forwardVelocity ) )  

   sidePower = Min( sidePower, armor.JETSIDEFORCE )  
   Vector3 sideForce = ( sidePower * jetForce ) * moveDirection  
   Vector3 upForce = ( ( 1 - sidePower ) * jetForce ) * Gravity.upNormal   
   return ( upForce + sideForce )         
} else {  
   // straight up, full jets  
   return ( jetForce * Gravity.upNormal )   
}  

To paraphrase:

Armors get a maximum thrust force they can output, "jetForce".
If you jet without pushing a direction key, you get full jetForce in the upward direction.
At low speed, pushing a direction key while jetting directs JETSIDEFORCE (80% of jetForce) in that direction (20% of it remains in the upward direction)
The cap comes in when you are moving at or above JETFORWARD (22m/s or 79.2 km/h), and try to use your jets to accelerate in the same direction you are already moving. The game will then take the component of your attempted jetting that is in the direction you're moving, and redirect it upwards.

What this last point means is that you can't use your directional jets alone to accelerate faster than 79.2km/h horizontally, but you can use them to turn or slow down no matter what your speed (by jetting perpendicular or opposite to your velocity, respectively).

Important differences compared to Ascend:
- Vertical jet thrust is never limited based on speed.
- Thrust that is not applied because of the speed limit is redirected upwards. (moot, since Ascend performs the speed limit check in all dimensions)
- Directional jets still work for turning at high speed.

Postin' this again, because it's still relevant. Red is Ascend jetpacks, green is T1/T2 jetpacks.

As best I can tell, Ascend looks at your speed (no matter the direction!), and if it's over 72km/h, says "no more directional thrust for you, and you only get enough upward thrust to cancel gravity". The result is that jets cannot be used for turning at speed, less height is gained when jetting upwards at speed, and even the ridiculous bug of not being able to slow yourself down when falling faster than 72km/h.

---

So there you have my sort of "unified theory of why Ascend's jetpacks feel terrible". The T1 horizontal cap was not really even significantly higher than Ascend's, but that dot product and uncapped vertical thrust make all the difference.

To be clear, I am suggesting 3 changes (which would amount to porting the T1 Player.Jet code):

1) Perform 72km/h check only in horizontal plane. Full vertical thrust available at all speeds (positive AND NEGATIVE).
2) Make it a vector compare instead of magnitude only. Full side thrust available when directed perpendicular to or opposite your velocity.
3) Any thrust subtracted as a result of hitting the horizontal limit should be directed upwards. No thrust should disappear the way it does currently.

_________________
- Fix Jetpack Physics (video) (video)
- Remove regen, bring back health kits
- Buff explosive jumping
- 100% inheritance for "bullet" weapons (nova blaster included)

Mon Apr 09, 2012 2:44 am

RootbeerAlamode

Joined: Mon Dec 05, 2011 5:01 pm
Posts: 1538
Steam Gamer Name: D-Hearts

Re: please address the many CORE PHYSICS ISSUES ASAP

hvcterr wrote:

So what you are saying is that Hi-rez chose to use an engine that is ill suited for a tribes game.

_________________
100% Inheritance, 100% Intuitive.
Inheritance Demonstration [video]
Tips for Aiming with 100% [video]

Mon Apr 09, 2012 3:20 am

DrNope

Joined: Sun Jan 29, 2012 6:04 am
Posts: 296

Re: please address the many CORE PHYSICS ISSUES ASAP

hvcterr wrote:

Physics engines often have difficulty with high-speed movements beyond certain thresholds, doubly so for game engines where there are time constraints on how responsive it needs to be.
If anyone wants to claim maximum-speed of projectiles won't be an issue in T:A, I'd like to at least see some math to go with it.

As far as I remember about collision stuff (coded a physics/collision engine about 1.5 years ago):

Collision handling could be a problem at high speeds if UE3 doesn't support predictive collisions (or if its simply too calculation expensive). Non-predictive systems advance one frame in the physics sim, and then just check for intersections at that point of time, causing fast objects to tunnel through geomentry, if the distance traveled is higher then half the depth of the own geometry perpendicular to the collision plane/poly (between 0.5 and 1.0 of that value the collision can be recognized, but on the wrong side... depending on intersection handling the colliding objects are either simply moved far enough away to not colide anymore or are propelled as if the intersection depth applied a spring force to them).

Predictive systems look ahead in time and resolve collisions in order they occur (forcing the system to recalculate some of the nearby collisions of the first one that could have changed). It's way more expensive calculations-wise, and i'm not sure if both systems can be mixed very well (but I think it can be done for different use-cases), so i'd guess it's a matter of performace that its not done (can't imagine UE3 doesn't support it... every somehow decent pool billard/pinball game needs this to get really accurate impact angles and therefore predictable results etc..).

But if bullets in T:A use this (they are very fast and small, so it would be a problem with them first) I see no reason why other projectiles shouldn't have it (modeling the projectile as a point in space -> the check for predictive collision is done with a line against a plane vs. having a sphere with radius X and checking where that line is in X distance from that plane, 2 results, take the closer one, is not that big difference...).

_________________
Ingame: DrNoes
Credits alternative
Fix Fusion Mortar physics
Give autos their role as finishers and for chasing

Mon Apr 09, 2012 5:07 am

hvcterr

Joined: Thu Jun 16, 2011 3:41 am
Posts: 1567

Re: please address the many CORE PHYSICS ISSUES ASAP

I wish I knew the speed of the fastest current projectile relative to in-game measurements. Then you could use an assumed tick-rate of 30 to determine the "thinnest allowable wall" if it were doing naive collision checks. (And not something like swept volumes.)

_________________
Did you know you can disable annoying signatures? Look under Board Preferences >> Edit Display Options.

Mon Apr 09, 2012 5:32 am

DrNope

Joined: Sun Jan 29, 2012 6:04 am
Posts: 296

Re: please address the many CORE PHYSICS ISSUES ASAP

hvcterr wrote:

Don't forget that the saber missile speed (for example) is added to the fastest bullet ingame (the velocities of moving objects are taken into account to make it a "one-moving-object-against-a-static-object-problem").

AFAIK, colission tests are always done against planes in the first place (as long as there are not very optimized formulas for capsules etc. I'm not aware of, but for the most part picking the right poprtion of the polygon cloud via oct-trees etc. and then perform some early-exit checks should be the way to go... any game dev gurus here?), so theres no real "thickness" of a wall (maybe followed by containment checks). I guess the projectiles are modeled as spheres and are early-exit-checked against collision-spheres of everything other (-> only if the min distance in the coming frame between the two will be <= r1+r2 other checks are performed).

Checking the min distance of a ray-segment against a plane is pretty fast, so bullet velocities should never be a problem imo (as long as floating point accuracy-problems don't kick in, but that should only be the case in extreme cases).
Just having axis-aligned-bounding-boxes around every projectile/bullet seems like unoptimized overkill to me (cacluation-cost-wise) and I can't believe UE3 does it like that.

But I can just guess here.. never testet UDK3.

_________________
Ingame: DrNoes
Credits alternative
Fix Fusion Mortar physics
Give autos their role as finishers and for chasing

Mon Apr 09, 2012 5:57 am

blecro

Joined: Sat Jul 03, 2010 11:09 pm
Posts: 192

Re: please address the many CORE PHYSICS ISSUES ASAP

Schottingham wrote:

[jet stuff]

Yes! Tribes 1 and Tribes 2 essentially adjust your jet angle upward as the scalar projection of your velocity onto your horizontal jet direction increases, but Tribes Ascend does its own thing. The thrust pack has similar unexpected behavior, as discussed in another thread.

Mon Apr 09, 2012 6:22 am

Njordstar

Joined: Fri Dec 30, 2011 7:39 am
Posts: 33

Re: please address the many CORE PHYSICS ISSUES ASAP

I did some search on my PC and found this tutorial video from Mirage in T2. This shows very well how movement with jet pack ought to be.....

Thanks to Mirage for this awesome video!

Nordstern

Mon Apr 09, 2012 6:46 am

root

Joined: Tue Mar 15, 2011 11:30 pm
Posts: 856

Re: please address the many CORE PHYSICS ISSUES ASAP

Schottingham wrote:

So there you have my sort of "unified theory of why Ascend's jetpacks feel terrible". The T1 horizontal cap was not really even significantly higher than Ascend's, but that dot product and uncapped vertical thrust make all the difference.

To be clear, I am suggesting 3 changes (which would amount to porting the T1 Player.Jet code):

1) Perform 72km/h check only in horizontal plane. Full vertical thrust available at all speeds (positive AND NEGATIVE).
2) Make it a vector compare instead of magnitude only. Full side thrust available when directed perpendicular to or opposite your velocity.
3) Any thrust subtracted as a result of hitting the horizontal limit should be directed upwards. No thrust should disappear the way it does currently.

Wow, I'm kind of surprised by this. I'm not a coding guy, but playing T1 for... what... 2 years competitively followed by another 2-3 casually... I could have sworn that T1 did not have a horizontal speed cap.

Sometimes when I'm real high in the air in T:A and I want to just go forward another few meters, I hold "W" and jet. It takes me almost nowhere. I attribute that to the horizontal speed cap, yet in T1 I felt like I could "push forward" using my jets, even going faster than 72km/h.

Perhaps I'm just perceiving it wrong, due to T1's transfer of the vector thrust or whatever you call it.

Mon Apr 09, 2012 9:23 am

Forum rules

please address the many CORE PHYSICS ISSUES ASAP