N4: Graphics vs. Physics Frame Rate Issue

There is no question that the AI have a tremendous effect on frame rates in N4, just like they do in GPL. This suggests the physics calculations are quite taxing on the CPU. But try sitting in your car and play with the "M" button...turning the mirror on and off and more detail and less detail. Ummm, from what I can tell, the physics of what is happening around your car isn't changing at all, but the frame rate sure is. From my little experiments, the graphics are at least 50% of the FPS equation in N4. Which is good news, because it means there may be room for optimisation. Marc. -- **************************************************************************** Marc Collins [email hidden] Your mouse has moved. Windows must be restarted for the change to take effect. Reboot now? ****************************************************************************

In the sim work I've been doing, the physics code hardly has an effect at all. It used to, back before several hundred Mhz CPU's and 3-D cards, but not so much today, unless you're using the same, complex model for all the cars. Even then, my stuff would be waaaaay below the 50% mark, other's would be even better, I'm sure. My whole physics loop takes about 1/1000th second (running several integration steps in that time frame) on a P-400Mhz. Graphics are really the big hog, I think. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On 15 Feb 2001 06:13:59 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (7 lines)

> In the sim work I've been doing, the physics code hardly has an effect at >all. It used to, back before several hundred Mhz CPU's and 3-D cards, but not >so much today, unless you're using the same, complex model for all the cars. >Even then, my stuff would be waaaaay below the 50% mark, other's would be even >better, I'm sure. My whole physics loop takes about 1/1000th second (running >several integration steps in that time frame) on a P-400Mhz. Graphics are >really the big hog, I think.

What is the rate of the physics model in N4? I know GPL is 288Hz and would expect N4 to be the same (maybe faster, but probably not considering the extra cars to be modeled, 43 vs. 20). Also, with GPL all cars use the same complex model, so I would assume the same is true of N4 (for better or worse). So, 288Hz * 43 cars = 12,384 loops per second. With a 1/1000sec loop time, you're looking at "1238% Processor Occupancy" as the GPx folks would put it. Putt putt... "But in a way, fear is a big part of racing, because if there was nothing to be frightened of, and no limit, any fool could get into a motor car and racing would not exist as a sport." -- Jim Clark

On Thu, 15 Feb 2001 14:28:05 GMT, [email hidden] (Jeff Vincent) wrote:

Quoted text (9 lines)

> What is the rate of the physics model in N4? I know GPL is 288Hz >and would expect N4 to be the same (maybe faster, but probably not >considering the extra cars to be modeled, 43 vs. 20). Also, with GPL >all cars use the same complex model, so I would assume the same is >true of N4 (for better or worse). > > So, 288Hz * 43 cars = 12,384 loops per second. With a 1/1000sec >loop time, you're looking at "1238% Processor Occupancy" as the GPx >folks would put it. Putt putt...

No, the AI uses a simplified model in GPL. I guess the same goes for N4? Andre >"But in a way, fear is a big part of racing, because if there was >nothing to be frightened of, and no limit, any fool could get into >a motor car and racing would not exist as a sport." -- Jim Clark

On Thu, 15 Feb 2001 14:28:05 GMT, [email hidden] (Jeff Vincent) wrote: >On 15 Feb 2001 06:13:59 GMT, [email hidden] (J. Todd Wasson) wrote: > >> In the sim work I've been doing, the physics code hardly has an effect at >>all.... > So, 288Hz * 43 cars = 12,384 loops per second. With a 1/1000sec >loop time, you're looking at "1238% Processor Occupancy" as the GPx >folks would put it. Putt putt... The last release of my sim uses 1000Hz internally (it was a mistake really; I'd go for 250Hz but had it set at 1000Hz accidentally). No-one has complained yet, even though the game grinds to a halt when it can't match the speed. On the SGI O2, the physics take about 15% and 85% goes to the graphics. But its graphics are slow. On the PC, I'd guess the physics take a little more because the graphics are faster, but at 40fps or so, I'm not complaining yet. 12000 loops/second isn't that much for today's CPUs. Yep, it really IS fast, even though Windows seems to get slower and slower. ;-) Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

It would seem to me that the graphics are what take up so much FPS. If it was the physics, my frame rate would go down when an accident took place on the track away from my sight. It only goes down when the graphics have to show me the accident.

I think you are missing how much each part of a program affects the rest of the execution. Sure the frame doesn't take a hit....why? Possibly because like GPL, the AI "FAKE IT" they don't use the same physics model your car does, so until your cpu-cycle-swallowing car gets to the wreck, it doesn't have that great of an impact. Yes the graphics most likely DO affect the Frame Rate, but so do the physics. My experience so far...is that EACH track has a different level of background fps killers. Some tracks I can race at over 10 fps faster than others. dave henrie "Race1530" <[email hidden]> wrote in message news:[email hidden]... > It would seem to me that the graphics are what take up so much FPS. If itwas > the physics, my frame rate would go down when an accident took place onthe > track away from my sight. It only goes down when the graphics have toshow me > the accident.

Dave said << I think you are missing how much each part of a program affects the rest of the execution. Sure the frame doesn't take a hit....why? Possibly because like GPL, the AI "FAKE IT" >> But in Multiplayer, it can't fake it. Wherever there is an accident there is a player there, so it would make sense that if the physics were working on the other end of the track in an accident involving another online player, wouldn't it then create a frame hit on my end? I don't know, just asking. Mike

On 17 Feb 2001 17:12:56 GMT, [email hidden] (Race1530) wrote:

Quoted text (9 lines)

>Dave said ><< I think you are missing how much each part of a program affects the >rest of the execution. Sure the frame doesn't take a hit....why? Possibly >because like GPL, the AI "FAKE IT" >> > >But in Multiplayer, it can't fake it. Wherever there is an accident there is a >player there, so it would make sense that if the physics were working on the >other end of the track in an accident involving another online player, >wouldn't it then create a frame hit on my end? I don't know, just asking.

Collisions don't have to take so much time; 2 OBB's colliding can be done quite fast, and there are only 20 OBBs (except for the wheels) to consider, so in the worst case you get 20*19 checks. You can however get algorithms which start subdividing time when this happens, which may lead to bad performance (in search for the 'perfect' collision time). However, I'd just do a check for a reasonable hit point and sling away the cars to their new direction. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

Quoted text (10 lines)

>What is the rate of the physics model in N4? I know GPL is 288Hz >and would expect N4 to be the same (maybe faster, but probably not >considering the extra cars to be modeled, 43 vs. 20). Also, with GPL >all cars use the same complex model, so I would assume the same is >true of N4 (for better or worse). > > So, 288Hz * 43 cars = 12,384 loops per second. With a 1/1000sec >loop time, you're looking at "1238% Processor Occupancy" as the GPx >folks would put it. Putt putt... >

Not sure what it is. Mine runs at 300Hz and takes 1/1000th second, so multiply that by 43 and you've still got a good framerate. I doubt the player cars use the same physics. It's so hard to program the AI to drive a model like that I can't begin to describe it. Human drivers have problems! Granted, N4's physics are probably a bit more intense than mine, but not *that much!* :0P Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

Quoted text (7 lines)

>Collisions don't have to take so much time; 2 OBB's colliding can be >done quite fast, and there are only 20 OBBs (except for the wheels) to >consider, so in the worst case you get 20*19 checks. >You can however get algorithms which start subdividing time when this >happens, which may lead to bad performance (in search for the >'perfect' collision time). However, I'd just do a check for a >reasonable hit point and sling away the cars to their new direction.

And don't forget to randomly "dynamite" some cars into low Earth orbit from time to time :-) Why don't folks use the relative velocities to calculate collision impulses? Seems like that would make these problems disappear. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

I just finished my first few online efforts, and I'd say I gained at least 10 fps racing online. I looked up and almost crashed when I saw the numbers... dave henrie > N4's physics are probably a bit more intense than mine, but not *thatmuch!* > :0P > Todd Wasson

> I just finished my first few online efforts, and I'd say I gained at least >10 fps racing online. I looked up and almost crashed when I saw the >numbers... Wow, that's a huge improvement. Well, I've been wrong before, so...:-P Perhaps the AI do run the same physics. During the online races, are there AI cars, or are there just player cars? I don't have a copy of N4, so don't know too much about it. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On 17 Feb 2001 21:49:10 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (10 lines)

>>Collisions don't have to take so much time; 2 OBB's colliding can be >>done quite fast, and there are only 20 OBBs (except for the wheels) to >>consider, so in the worst case you get 20*19 checks. >>You can however get algorithms which start subdividing time when this >>happens, which may lead to bad performance (in search for the >>'perfect' collision time). However, I'd just do a check for a >>reasonable hit point and sling away the cars to their new direction. > > And don't forget to randomly "dynamite" some cars into low Earth orbit from >time to time :-)

Ah yes, I've seen that happen, especially with the last version of Racer on the net where the gravity was mistakingly converted to body coordinates twice, resulting in something more like 'Spacer' ;-) (it's fixed now, but still it can jump *higher* when falling to the ground than the jump it originally came from; something with the suspension I guess). > Why don't folks use the relative velocities to calculate >collision impulses? Seems like that would make these problems disappear. Hm, I did a pool program once, and it had (and has) the tendency to have balls stick into eachother, since at the point of collision, the bodies are inside eachother. Then, with some impulses, the balls get a different velocity. But if the velocity is then not enough to untangle the 2 balls, it collides again, and you get whacky planet-moon like effects, with sinoidial effects you didn't remember putting in! ;-) The problem gets worse when 3 cars collide at the same time, I think. They just have to stay away from eachother, somehow. Gosh, hm, collision detection, more to read. PS How's the Straightline Acceleration Simulation sales going? Too bad you don't accept credit cards. Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/

>Ah yes, I've seen that happen, especially with the last version of >Racer on the net where the gravity was mistakingly converted to body >coordinates twice, resulting in something more like 'Spacer' ;-) Hehe! I'd love to try Racer, but my P-60 won't handle it, and I can't currently plug my wheel into my P-400 laptop, so I'm out either way. Unless you can whip up a keyboard steering mode! :-) >(it's fixed now, but still it can jump *higher* when falling to the >ground than the jump it originally came from; something with the >suspension I guess). Mine usually doesn't do that, but then again, as soon as it gets upside down and lands, it'll shoot past the moon in a real hurry! (no collision detection yet) >Hm, I did a pool program once, and it had (and has) the tendency to >have balls stick into eachother, since at the point of collision, the >bodies are inside eachother. Then, with some impulses, the balls get a >different velocity. But if the velocity is then not enough to untangle >the 2 balls, it collides again, and you get whacky planet-moon like >effects, with sinoidial effects you didn't remember putting in! ;-) Hadn't thought of that. I knew it wouldn't be so simple :-) >PS How's the Straightline Acceleration Simulation sales going? Too bad >you don't accept credit cards. > Not too bad. Had a few orders during the two week sale. Only about half of the emailers actually sent checks though! lol I'll reset the price and if there's enough response, get signed up with one of those Delaware based online credit card deals. I must say, version two of the program will be outrageous in comparison, given all I've learned during the past 10 months or so of development with the 3-D dynamics. There aren't a whole lot of competitors that offer spring and damper adjustments and all the other bells and whistles to the drag car predictors. It's pretty cool seeing a 7 second car pull the front wheels in 3-D, with the tires spinning crazily off the line:-) Adjusting the shocks to 90/10 drag types gives the right reaction now too, so perhaps SAS Pro could be in the works soon. Either that or I'll dive back into engine simulation and get something really nice going in that dept. Seems I get more hits from search engines looking for "engine dyno simulators" than "drag simulators" anyway. Decisions, decisions... ;-) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com

On 19 Feb 2001 23:48:46 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (7 lines)

>>Ah yes, I've seen that happen, especially with the last version of >>Racer on the net where the gravity was mistakingly converted to body >>coordinates twice, resulting in something more like 'Spacer' ;-) > > Hehe! I'd love to try Racer, but my P-60 won't handle it, and I can't >currently plug my wheel into my P-400 laptop, so I'm out either way. Unless >you can whip up a keyboard steering mode! :-)

Ouch, hm, so you *do* have an OpenGL capable machine probably? (The P-400). It does need a controller, but not the SGI version, so I might consider doing the mouse version which was in the 1st version (but is awful hehe). Or keyboard, but I don't use DirectInput for that yet (so I get events, not too great for controlling a vehicle).

Quoted text (7 lines)

> >(it's fixed now, but still it can jump *higher* when falling to the >>ground than the jump it originally came from; something with the >>suspension I guess). > > Mine usually doesn't do that, but then again, as soon as it gets upside down >and lands, it'll shoot past the moon in a real hurry! (no collision detection >yet)

Yep, same here. :) I'll have to add some collision points to the roof and the floor. >>PS How's the Straightline Acceleration Simulation sales going? Too bad >>you don't accept credit cards. > > Not too bad. Had a few orders during the two week sale. Only about half of >the emailers actually sent checks though! lol Ouch! What the world is coming to! ;-)

Quoted text (13 lines)

> I'll reset the price and if >there's enough response, get signed up with one of those Delaware based online >credit card deals. I must say, version two of the program will be outrageous >in comparison, given all I've learned during the past 10 months or so of >development with the 3-D dynamics. There aren't a whole lot of competitors >that offer spring and damper adjustments and all the other bells and whistles >to the drag car predictors. It's pretty cool seeing a 7 second car pull the >front wheels in 3-D, with the tires spinning crazily off the line:-) Adjusting >the shocks to 90/10 drag types gives the right reaction now too, so perhaps SAS >Pro could be in the works soon. Either that or I'll dive back into engine >simulation and get something really nice going in that dept. Seems I get more >hits from search engines looking for "engine dyno simulators" than "drag >simulators" anyway. Decisions, decisions... ;-)

Hm, sounds good. Graphics are always nice (although my focus is sometimes too much on that instead of physics). I gotta run, have to get to the studio. Hopefully I won't have to do too much, because I received Genta's book 2 days ago. :) Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Car simulation: http://www.marketgraph.nl/gallery/racer/