speed limits

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
Post Reply
Errol_Summerlin
Merchant
Merchant
Posts: 46
Joined: Thu Mar 11, 2010 4:10 am

speed limits

Post by Errol_Summerlin »

This is my first time starting a new topic, so let me just first say that I really like the idea of creating a generic space simulator that can accomodate a nearly infinite variety of user created universes and scenarios. The creation of an MMORPG that isn't mind bogglingly boring (EVE comes to mind) and uses real physics is very appearling to me.

In fact, I am seriously considering volunteering to join the development team part time (if they will have me). I have a good deal of non-graphics related programming and I am a physicist by trade. I would be most happy doing back end development of the physics engine to create weaponry and pilot assist commands that make newtonian physics based combat intuitive (which it isn't naturally) and entertaining (which is the common complaint of the x-wing style "space" sim advocates).

However, I wanted to make sure that the game is actually using newtonian physics. There are two aspects of the game that I have discovered so far that suggest this may not be the case.

1. flight mode top speeds for ships are different. If flight mode is supposed to be truly newtonian physics, the only limting speed should be c unless you are in a dense nebula or a planetary atmosphere where drag is not negligible. I understand that the developers might choose to avoid the complications of relativity by limiting ship speeds to perhaps c/100. It is also perfectly reasonable to place a speed cap due to radiation hazard. At speeds close to the speed of light, the ambient hydrogen in the interplanetary medium is traveling towards the ship at nearly the speed of light. While the drag created by these ions is not very large due to their low density, each individual ion has sufficient energy(relative to the spacecraft) to penetrate a large amount of hull plating a deliver a lethal radiation dose to any organic beings as well as damage internal ship systems. However, in either of the above cases for keeping the speed limit <c, every ship should still have the same artificial imposed speed cap(well, in the radiation hazard limit, heavily armored ships might be able to get higher top speeds than less heavily armored ships, but that is obviously not the way the current game does this). To do otherwise is to impose a non-physical artificial difference between ships. I am presuming that the flight mode top speed is a property of the individual space craft and not hard coded so that, if I wrote a mod using this engine, I would be able to make my ships all have the same top speed, but I want to make sure this is the case. I also wanted to convey my "feature request" that all spacecraft have the same top speed that is at least c/100. Immersion is really big for me in space sims, and games with non-physical speed limits just ruin the immersion for me.

2. The governor sets a requested velocity vector in the direction your ship is facing and a magnitude given by your "combat top speed". But why is this magnitude different for different ships and furthermore, why can you not select its value to be any thing you want (less than the absolute top speed of the ship obviously...discussed above). Sure, if you select too high a combat speed maximum, you may end up having a little trouble turning on a dime, but you also dont want to be stuck puttering along unable to catch your quarry because they went to flight mode and ran away. I know that there are challenges to making newtonian space combat work, but I feel that the underlying engine being created here should provide players and future modders with options in this regard rather than limiting the governor to only work at a set speed for each spacecraft. Maximum velocities sans drag (governed or not) should not be related to the ship's acceleration and should be, for the most part, the same(baring the armor argument above). Never-the-less, it may be a good idea to have space stations look out for themselves by warning craft that are traveling too fast and could potentially damage the station. Maybe they should even shoot the potential kamikazes down to avoid getting rammed at nearly light speed. Bottom line: I want to select the magnitude of the velocity vector my governor seeks to achieve rather than being told what my "combat speed" is. My combat speed is whatever I decide is the right speed cap for the situation at hand. When docking, I may want to set my speed cap to something very small. When fighting in an asteroid field, I may want it low so that my inertia doesn't carry me into an asteroid, but quick enough that I am not standing still. In open space, I may have long range weapons and desire that my ship have 0 velocity relative to my target.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: speed limits

Post by Deus Siddis »

The governor presets are just recommendations for maneuvering in close quarters, either in combat or docking situations. They can be defeated using Y (flight mode) or Tab (afterburner, manual forward accelerate). You can set your speed to anything you like. I believe there is a command for turning off the flight computer entirely (except for maybe the rotation governor-- don't want any centrifugal deaths). Either way the game does use Newtonian physics, all these issues are just a matter of the flight interface / simulated guidance computer.

The hard limits for top speed are whatever computing limitations current hardware running VS might be (think high speed collision detection). Plus however fast you are going when your engines run out of reaction mass, which doesn't seem like it has been fully implemented yet.

The speed of light isn't supposed to be reachable under normal circumstances. SPEC travel (VS' flavor of FTL) is allowing you to travel at C relative to the normal physical universe around you, but you're interactions with it are not normal. It is mostly effected by some combination of mass and proximity. Maybe gravity. So if you approach a large object, your SPEC ability will falloff at a good distance away. If your approach a small object, your SPEC ability will falloff at a very short distance. But you might very well be unaffected by direct, would-be collisions with little particles like you described. They might pass right through you or get pulled around your "bubble" of warped space.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: speed limits

Post by klauss »

Deus Siddis wrote:The hard limits for top speed are whatever computing limitations current hardware running VS might be (think high speed collision detection). Plus however fast you are going when your engines run out of reaction mass, which doesn't seem like it has been fully implemented yet.
It has, only fuel efficiency is ridiculously high ATM.
There was a time when it was a lot lower, and it kind of defeated gameplay a bit.
But I certainly would expect it to eventually reach a balanced, elite-ish state.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: speed limits

Post by Deus Siddis »

klauss wrote:
Deus Siddis wrote:The hard limits for top speed are whatever computing limitations current hardware running VS might be (think high speed collision detection). Plus however fast you are going when your engines run out of reaction mass, which doesn't seem like it has been fully implemented yet.
It has, only fuel efficiency is ridiculously high ATM.
There was a time when it was a lot lower, and it kind of defeated gameplay a bit.
But I certainly would expect it to eventually reach a balanced, elite-ish state.
I tested it and it took ~20 minutes of constant forward thrust to expend all fuel. If acceleration rates weren't so insane wouldn't that be a reasonable efficiency?

The problem is my ship could still accelerate at the same rate as before it ran out of fuel. Only the capacitors wouldn't recharge. So it doesn't seem like fuel represents reaction mass at all- it's just reactor fuel, and your engines never run out of juice. Strangely enough, your engines do drain fuel more than anything else it seems-- they effect it but aren't affected by it.

So however you slice it, it is a broken feature at present.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: speed limits

Post by klauss »

IIRC, thruster efficiency when out of fuel is configurable.

Killing your engines when you're out of fuel would be... harsh. It would kill the fun almost every time. Rather, once someone decided, it would kill weapons and shields (everything needing energy to recharge) but leave you able to reach a base and refuel.

Granted, acceleration could be degraded, at least it would let you feel the fuel shortage. Also, a nice "BINGO" banner would be nice ;)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: speed limits

Post by chuck_starchaser »

Errol_Summerlin wrote:However, I wanted to make sure that the game is actually using newtonian physics.
It IS newtonian, but the simulation is choppy and using Euler, instead of RK4.
Can you code an RK4 physics engine? I got a link for you I'll post in a minute.

EDIT:
Here we go:
http://gafferongames.com/game-physics/i ... on-basics/

And if you're a physicist and a programmer, you're probably familiar with the problem of aliasing in simulation.
Proper simulation needs two instances that alternate roles: One holds the "current" state and is read-only,
while the other holds "previous" and/or "next" as the physics engine iterates through it; then, when the
iteration is done, and the writeable instance is all "next", it becomes current; and the current becomes
pervious.
Well, we're not doing that yet; we only have one instance of everything; and if A and B are on a head-on collision
course, whether the collision happens closer to A or closer to B depends on the order in which they are updated.
So, we need to implement RK4 and proper simulation, if you're up to it.
Errol_Summerlin
Merchant
Merchant
Posts: 46
Joined: Thu Mar 11, 2010 4:10 am

Re: speed limits

Post by Errol_Summerlin »

So, I can make my governor do any velocity I want as my "desired vector?" Could I make it a vector different from the direction I am facing? I haven't figured out all the controls yet...too much time posting..not enough time playing :P

As for top speeds, I understand that comutational limitations might limit the speed, but why are the top speeds different for different ships? The computational top speed issue should again, be something that is independent of the particular ship.

There should probably be some clarity of terms regarding energy production and thrust. Reaction mass is somewhat ambiguous. It could refer to the reactants that generate the energy or the propellant that is actually expelled from the thrusters. See my post in the consumable fuel thread. Some propulsion mechanisms use the reaction products AS the fuel, but this is not terribly efficient for high speed products as the power to thrust ratio is low. Thus, it makes more sense to have reactants (such as electrons and positrons for anti-matter fuel or any of the fusion options) as "fuel" that provides energy and then a propellant that is heated by this energy and expelled to produce thrust. If your power output is fixed, using lower exhaust velocity gives better thrust(proportional to P/v, power over exhaust velocity), but uses much more mass per second(dm/dt proportional to P/v^2). Higher exhaust velocity gives less thrust but uses much less mass per second as well. It seems to me that making your primary energy production last a really long time is in the interest of game mechanics so that people are not stranded in space, but the propellant could be more limited with players usually taking only enough to get them where they need to go (don't want to weigh down your ship with propellant that you are not going to use). It would also be very cool if you could actually adjust the exhaust velocity/ dm/dt in flight. It would make propellant conservation a tactical consideration in a dog fight.

I don't worry so much about FTL travel radiation issues. This is where we have to just make up physics anyway in order to facilitate game play. I am not spending 3 days (real time) traveling to the next planet in the system. That just ain't happening :). However, I will point out the only ftl travel scenario that is actually grounded in real physics (albeit highly theoretical with no idea how to actually achieve such a thing, but at least it uses general relativity). http://en.wikipedia.org/wiki/Alcubierre_drive

@deus...as long as the balanced elitish state is based on real physics (not necessarily stuff we can do right now, but stuff that we, theoretically, could eventually do), I will be cappy hamper

@klauss...anti-matter equivalent to 1% of your ship's mass could achieve .25g acceleration (pretty low, but allows you to limp back to base) for 320 hours by utilizing the reaction products(gamma-rays) directly as thrust. Adding a mass of propellant heated by the reaction products (instead of harnessing them directly for thrust) could increase the thrust by varying amounts (discussed above) depending on how fast you want to expel your propellant. The propellant would then be your fuel with expelling the reaction products directly a last resort for when you run out of fuel. I am perhaps harping at this point, but it seems ideal to the multiple considerations involved A) not stranding people in space B) a booster option C) a finite plausible fuel supply. I have also been thinking about this for far too long designing a game like this in my head.

@I haven't used rk4 since computational physics class, but I am familiar with its implementation. I wrote a gravitational N-body simulation of the formation of the Heliosphere using it. (The simulation I work on now is actually semi-analytical. It solves a transcendental equation of motion using a bi-section technique if you want to know). I am just not sure it is a good choice. My experience with rk4 is that it is VERY slow. And, unless I am missing something in the details, a simple Euler's method with deltat of around .05 seconds or less would have no noticeable impact for players and be far less expensive computationally. Sure, it isn't exact, but this isn't a simulation for science purposes, it is a simulation meant to LOOK and feel like reality as far as a human can tell. For this purpose, Rk4 seems over kill computationally. I suspect though that I don't understand the problem with high velocities. With an Euler type simulation, during each individual time step, the velocity of the ship is constant. The acceleration during this time step changes the velocity for the next time step. So, with a constant velocity, It is trivial to interpolate the trajectories since they are just straight lines. Then, if the ships have nice un-complicated bounding boxes, the program can either calculate mathematically if a collision occurred (easy for two spheres, very hard for any other shapes) or step through the trajectory on a smaller time step (still at constant velocity though) looking for collisions just like you would at lower velocities(taking the time step down again if it is still inefficient). Of course, you don't want to do this every time step if the ship's are not anywhere near each other, but a set of booleans are probably already in place to check if a collision is even possible so that CPU cycles are not wasted doing all the collision determination when the ships are on opposite sides of the system. Rk4 is a fine algorithm, but I am not seeing the benefit of adding the extra computational time unless it provides some hidden benefit like allowing larger time steps than are currently being used which makes it actually faster? I don't do computer game programming usually, but I figured that the time step for computing new position and velocities of everything would be at least as small as 0.05 so that the human eye won't see the discrete changes in position at 20fps. Maybe there is a trick to this where the server can use a larger time steps and have player machines interpolate the trajectories client-side at whatever their computer's fps is to provide smooth trajectories. Perhaps I am just showing my ignorance of computer game programming here, but hopefully my mathematical and physics programming experience will let me catch on once i figure out the basics.

However, I do see the need for keeping the different states. Right now, you just cycle through each object and change its position and velocity accordingly one at a time? I can see how that would be a problem for collision detection. If you can point me in the right direction in the code, I will be happy to lend what skills I have and learn what skills I don't. I am at work right now, but I will read the link you provided tonight when I get home.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: speed limits

Post by chuck_starchaser »

Errol_Summerlin wrote:@I haven't used rk4 since computational physics class, but I am familiar with its implementation. I wrote a gravitational N-body simulation of the formation of the Heliosphere using it. (The simulation I work on now is actually semi-analytical. It solves a transcendental equation of motion using a bi-section technique if you want to know). I am just not sure it is a good choice. My experience with rk4 is that it is VERY slow. And, unless I am missing something in the details, a simple Euler's method with deltat of around .05 seconds or less would have no noticeable impact for players and be far less expensive computationally. Sure, it isn't exact, but this isn't a simulation for science purposes, it is a simulation meant to LOOK and feel like reality as far as a human can tell. For this purpose, Rk4 seems over kill computationally. I suspect though that I don't understand the problem with high velocities. With an Euler type simulation, during each individual time step, the velocity of the ship is constant. The acceleration during this time step changes the velocity for the next time step. So, with a constant velocity, It is trivial to interpolate the trajectories since they are just straight lines. Then, if the ships have nice un-complicated bounding boxes, the program can either calculate mathematically if a collision occurred (easy for two spheres, very hard for any other shapes) or step through the trajectory on a smaller time step (still at constant velocity though) looking for collisions just like you would at lower velocities(taking the time step down again if it is still inefficient). Of course, you don't want to do this every time step if the ship's are not anywhere near each other, but a set of booleans are probably already in place to check if a collision is even possible so that CPU cycles are not wasted doing all the collision determination when the ships are on opposite sides of the system. Rk4 is a fine algorithm, but I am not seeing the benefit of adding the extra computational time unless it provides some hidden benefit like allowing larger time steps than are currently being used which makes it actually faster? I don't do computer game programming usually, but I figured that the time step for computing new position and velocities of everything would be at least as small as 0.05 so that the human eye won't see the discrete changes in position at 20fps. Maybe there is a trick to this where the server can use a larger time steps and have player machines interpolate the trajectories client-side at whatever their computer's fps is to provide smooth trajectories. Perhaps I am just showing my ignorance of computer game programming here, but hopefully my mathematical and physics programming experience will let me catch on once i figure out the basics.

However, I do see the need for keeping the different states. Right now, you just cycle through each object and change its position and velocity accordingly one at a time? I can see how that would be a problem for collision detection. If you can point me in the right direction in the code, I will be happy to lend what skills I have and learn what skills I don't. I am at work right now, but I will read the link you provided tonight when I get home.
I passed you a link, but you obviously didn't look at it.

http://gafferongames.com/game-physics/i ... on-basics/
Quoting from it:
Glenn wrote:If you use Euler then you are a bloody idiot
You get far more precision by going rk4 than by decreasing time step in euler. Vegastrike used to have gravity, but it was removed due to precision problems causing drift when you're trying to dock with an orbiting space station.
Right now we don't have springs; but we will, in the future.
And please don't confuse vegastrike the game, and the engine. The engine should serve the needs of all mods that may use it, present and future.
Finally, the code right now sucks; got nothing to show you. If you can code a phyisics library, just do it; make it generic;
assume it's a library for the world; not for vegastrike. I'll soon be starting on a refactoring of the Unit hierarchy, and I could use having
a physics library with a clean inteface to plug into.
There's no per-unit tensors of inertia, presently; but we can add them to units.csv.

EDIT:
Force and acceleration can be float; but momentum/speed and position need to be double precision.
Errol_Summerlin
Merchant
Merchant
Posts: 46
Joined: Thu Mar 11, 2010 4:10 am

Re: speed limits

Post by Errol_Summerlin »

I read the article, but I don't take that fellow's word as gospel. Depending upon the precision required and the computational limitations, Euler can, in some cases, be better than rk4. Rk4 involves more flops than Euler and can slow the simulation down. Generally, you can compensate for these extra flops by increasing your deltat making the simulation both faster and more accurate. However, for a game, your maximum time step is fixed at around 20hz. If you go any higher than that, your simulation will look choppy no matter what algorithm you use because your system updates are coming slow enough that the human eye can detect the jerkiness of the motion. So, if you are already operating at 20 hz, Rk4 buys precision at the expense of computational resources making it a tradeoff rather than a clear-cut improvement. However, you mentioned the drift in gravitational fields. Yes, if you want planetary gravity, Euler won't cut it. It is terrible with orbits because it doesn't conserve energy. However, for ship thrust, explosions, and weapon recoil, Euler would work fine and it wouldn't be worth it. Anyway, that was the point I was trying to make.

As for the code, I looked at physics.cpp. I am not entirely sure what you would want in a library(what you would be passing it, what it would need to pass out, etc.). If you give me a .h file with the function placeholders, I can fill in the code to produce the desired output. Or I could just re-write the functions in physics.cpp to implement the runge-kutte technique for now (and clean up the variable names a bit...they are confusing at the moment) and move on to other aspects later. My biggest concern though is that if we try to include too much of the physics, we end up with an N-body simulation that will run too slow for a game. That aspect though, doesn't appear to be part of physics.cpp. It would be in the decision of which forces to add to list and which ones to ignore to save on computation time. Anyway, let me know which of the above options you would prefer or what 3rd option you would like me to pursue. I am just not clear on how to write a "generic" library since the physics engine already has a particular architecture that anything I write needs to fit into.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: speed limits

Post by Deus Siddis »

klauss wrote: Killing your engines when you're out of fuel would be... harsh. It would kill the fun almost every time. Rather, once someone decided, it would kill weapons and shields (everything needing energy to recharge) but leave you able to reach a base and refuel.
That's kind of pointless, because without SPEC you can get just as marooned and very easily. Escape pods are pointless for the same reason (no SPEC).
Granted, acceleration could be degraded, at least it would let you feel the fuel shortage. Also, a nice "BINGO" banner would be nice ;)
That would be way better in every way. Then you can still limp along, with SPEC, to get back to a port in a realistic time-frame. And it makes realistic sense because reaction mass should run out way before your power output does, otherwise you run into the infamous waste heat issues.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: speed limits

Post by chuck_starchaser »

Errol_Summerlin wrote:I read the article, but I don't take that fellow's word as gospel. Depending upon the precision required and the computational limitations, Euler can, in some cases, be better than rk4. Rk4 involves more flops than Euler and can slow the simulation down. Generally, you can compensate for these extra flops by increasing your deltat making the simulation both faster and more accurate. However, for a game, your maximum time step is fixed at around 20hz.
Physics currently runs at 14 Hz for the smallest steps, and gets longer (step time is dynamic); but for the graphics there's interpolation going on, so it looks less choppy.
If you go any higher than that, your simulation will look choppy no matter what algorithm you use because your system updates are coming slow enough that the human eye can detect the jerkiness of the motion. So, if you are already operating at 20 hz, Rk4 buys precision at the expense of computational resources making it a tradeoff rather than a clear-cut improvement.
Thing is, you have to look at the over-all profiling of the engine; and physics right now takes much less time than collisions, which in turn takes pretty little time. We have other bottlenecks. The AI code is horrendous, for instance; AI routines are pages and pages long, full of switch statements and branches.
And the dynamic physics step part of the code is clunky and sub-optimal; I have a good idea how to rewrite it.
However, you mentioned the drift in gravitational fields. Yes, if you want planetary gravity, Euler won't cut it. It is terrible with orbits because it doesn't conserve energy.
Exactly. Plus, once we have springs, Euler is highly unstable; so we're going to have to switch to RK4 sooner or later; might as well get it done now.
However, for ship thrust, explosions, and weapon recoil, Euler would work fine and it wouldn't be worth it. Anyway, that was the point I was trying to make.
This I agree; and there's no reason why we can't have Euler for some things and RK4 for others.
As for the code, I looked at physics.cpp. I am not entirely sure what you would want in a library(what you would be passing it, what it would need to pass out, etc.). If you give me a .h file with the function placeholders, I can fill in the code to produce the desired output.
Ok, I'll try to come up with something.
Or I could just re-write the functions in physics.cpp to implement the runge-kutte technique for now (and clean up the variable names a bit...they are confusing at the moment) and move on to other aspects later.
If you want, go ahead; but frankly I think we need to completely reorganize the physics, starting with the dynamic time-step stuff.
My biggest concern though is that if we try to include too much of the physics, we end up with an N-body simulation that will run too slow for a game. That aspect though, doesn't appear to be part of physics.cpp.
No; no N-body. My idea as of about a week ago, and I posted it somewhere, was that we'd keep all gravitational attractors (stars, planets and moons) in circular orbits, --no simulation--, until we approach a station for docking. As soon as we hit D to request docking, we switch from circular orbit to simulated orbit, so that we can maneuver to a docking with matching physics. Once docked, the station's simulation is discarded and it goes back to a circular orbit.
It would be in the decision of which forces to add to list and which ones to ignore to save on computation time. Anyway, let me know which of the above options you would prefer or what 3rd option you would like me to pursue. I am just not clear on how to write a "generic" library since the physics engine already has a particular architecture that anything I write needs to fit into.
No; no need to fit into anything. Like I said, I'm going to refactor the Unit hierarchy, and I can make it fit your simulation interface. I was going to do the physics too, before you showed up.
My biggest worry is variable simulation steps. I don't like at all the way it is done now; all that SIMULATION_ATOM stuff. Too messy, IMO.
My plan is to have staggered simulation runs on power of two time steps, as follows:

Code: Select all

t00 (16 Hz items )
    t01 (8 Hz items )
t02
        t03 (4 Hz items)
t04
    t05
t06
            t07 (2 Hz items)
t08
    t09
t0A
        t0B
t0C
    t0D
t0E
                t0F (1 Hz items)
t10
    t11
t12
        t13
t14
    t15
t16
            t17
t18
    t19
t1A
        t1B
t1C
    t1D
t1E
                    t1F (0.5 Hz items)
... ... ... ... ... ... ...
Here the vertical axis is time, and each hexadecimally numbered item is a simulation job, involving an iteration through a container of units.
I've changed the number of physics frames per second from 14 to 16, for simplicity. Rather 32.
So, the left column events come 16 times per second (every other sim frame) and at each event we iterate and update the units that need faster updates (due to being near the player, or whatever).
The second column events come at 8 times per second, and they trigger an iteration/update of second priority units in a "second_rung" container.
And so on.
IOW, at t00, t02, t04, ... we iterate through Objects_16_00_Hz_Container.
at t01, t05, t09, ... we iterate through Objects_8_00_Hz_Container.
at t03, t0B, ... we iterate through Objects_4_00_Hz_Container.
at t07, t17, ... we iterate through Objects_2_00_Hz_Container.
at t0F, t2F, t4F we iterate through Objects_1_00_Hz_Container.
at t1F, t5F, t9F... we iterate through Objects_0_50_Hz_Container.
and so on.
This organization will allow us to spread the simulation load pretty evenly in time. All we have to do is make sure we balance
the sizes of the containers dynamically. So, if we have too many units in the fastest update container, we change our criteria thresholds so that some of them migrate to the slower update, 8 Hz container, and so on.
This will also increase cache coherence, because at each simulation frame we iterate linearly through a small container, rather than iterate through all units, checking their "SIMULATION_ATOM"'s.
AND we get a great deal more collisions coherence; because right now the physics update for any unit can happen any time; so the only way to do collisions is by using interpolated data.

But once we combine this with having two simulation buffers (current and prev/next), it's going to get a bit complicated.
Another complication is when we move units from one container (simulation frequency) to another, we have to deal with a transient odd time step.
So, the idea is to do very clean programming, with clear separations of concerns.

EDIT:
As for interfaces, the thing is, class PhysicalObject or RigidBody or whatever, is higher in the hierarchy than almost anything else; so my (refactored) Unit class will inherit YOUR physics class; not the other way around.
AND, you don't need to worry about forces, either. Why? Separation of concerns. The function to add all forces will probably be in a derived class; and what your class will get is a single resultant force.
So what your class needs to have is the basic stuff: mass, force, momentum, velocity, acceleration, position... all the rotational counterparts, auto-flipping current and prev/next buffers, and a do_it() function, or better yet, a void operator()(), easy to call in a forall sweep.
For the force you could provide a setForce( Force const & f ) function.
Tensors of inertia we don't have data for yet, so I'd suggest an overloaded function:
void setTensorOfInertia( TensorOfInertia const & toi ); and
void setTensorOfInertia() { compute_default_TOI(); }

EDIT2:
About the current and prev/next buffers, this can be tricky: If you don't want to have two blocks of code and a boolean switch, I'd suggest using a pair of pointers:

Code: Select all

class PhysicsObject
{
    PhysicsBuffer a, b, *pCurent, *pPrevNext;
    void flip( bool toggler )
    {
        if( toggler )
        {
            pCurrent = &a;
            pPrevNext = &b;
        }
        else
        {
            pCurrent = &b;
            pPrevNext = &a;
        }
    }
    void RK4_step();
    getNewForceAndTorque(); //yeah, I think you'd better pull them in, rather than Unit push them
public:
    void operator()()
    {
        Time time = ::getTime();
        getNewForceAndTorque(time);
        RK4_step(time);
    }
    Position getCurrentPosition() const { return pCurrent->getPosition(); }
    PhysicsBuffer const * getPointerToCurrentBuffer() const { return pCurrent; }
    //etceteras...
};
where...

Code: Select all

class PhysicsBuffer
{
    BOOST_STRONG_TYPEDEF( size_t, Time ); //milliseconds
    BOOST_STRONG_TYPEDEF( double, InverseMass );
    //etceteras
    Time timeStamp;
    Time timeDelta;
    InverseMass inverseMass;
    Force force; //vec3<double>
    Momentum momentum; //vec3<double>
    Velocity velocity; //vec3<double>
    Position position; //vec3<double>
    //etceteras...
};
so, at each tXX simulation run with a std::unordered_map<PhysicsObject> FreqXXHzObjects,
we'd iterate through all calling operator()(), then iterate through all again calling flip( toggler ),
and semaphore users (collision, AI, graphics) that a new frame is ready.
((Actually, no need for semaphores; but the iteration calling flip() should be atomic.))
Errol_Summerlin
Merchant
Merchant
Posts: 46
Joined: Thu Mar 11, 2010 4:10 am

Re: speed limits

Post by Errol_Summerlin »

okie dokie. I didn't understand all of that, but I will start studying what I didn't understand. But basically, I can assume a fixed time step and should make all my functions allow for a 2 state system. I don't think we can mix Euler and rk4 steps. I just can't see how that would work since the acceleration is the sum of ALL the forces divided by the mass and not just the ones that are Euler friendly. So, I will just do rk4 steps and assume that I have access to the current net force and net torque on the ship. I will send you some stuff(via private message?) soon(tomorrow if I can find some free time, but my wife keeps me busy on the weekend) so you can look it over and let me know how to make it fit in the class structure (I code mostly in C and haven't used Java in 10 years, so it will take me a bit to figure out how classes work in cpp) and what additional functions I should add.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: speed limits

Post by chuck_starchaser »

Errol_Summerlin wrote:okie dokie. I didn't understand all of that, but I will start studying what I didn't understand.
Start with that link I gave you; like read all the pages that follow that first one, to get the feel for the whole thing.
But basically, I can assume a fixed time step
Nope; you can't. Right now the time-step is continuously variable; and with my plan it will vary by powers of two; but although a unit will seldom change update frequency slots, it WILL happen.
and should make all my functions allow for a 2 state system.
Yep.
I don't think we can mix Euler and rk4 steps. I just can't see how that would work since the acceleration is the sum of ALL the forces divided by the mass and not just the ones that are Euler friendly.
What I meant is that we can apply RK4 to some units and Euler to others. Example: Capital ship using Euler; torpedo hits; capship explodes, and now there's all kinds of debris hurling away. The pieces of debris could use Euler. Same for particles; they aren't important.
So, I will just do rk4 steps and assume that I have access to the current net force and net torque on the ship.
Exactly.
I will send you some stuff(via private message?) soon(tomorrow if I can find some free time, but my wife keeps me busy on the weekend) so you can look it over and let me know how to make it fit in the class structure
That's the best way to work; short cycles of review/feedback; and no hurry; this won't be going into the upcoming release, AFAIK; probably the next after.
(I code mostly in C and haven't used Java in 10 years, so it will take me a bit to figure out how classes work in cpp) and what additional functions I should add.
Don't worry; I can clean it up, as far as C++ishness is concerned.
Errol_Summerlin
Merchant
Merchant
Posts: 46
Joined: Thu Mar 11, 2010 4:10 am

Re: speed limits

Post by Errol_Summerlin »

one last question, should I make the equations relativistic?

I CAN do it, but it will require more flops, and more coding...and will create the potential for time dilation which won't work very well in a multi-player game.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: speed limits

Post by chuck_starchaser »

Better not. There's relativity in the code right now; but turned off; not used. Thing is, our spec speed limit right now is 97c, --which is still too low for inter-stellar travel without jumps--, and mass can get tricky above c; and we don't care to have the player meet his grand-grand children, anyways :D
Shark
Confed Special Operative
Confed Special Operative
Posts: 360
Joined: Tue Mar 02, 2004 9:34 am
Contact:

Re: speed limits

Post by Shark »

klauss wrote:Killing your engines when you're out of fuel would be... harsh. It would kill the fun almost every time. Rather, once someone decided, it would kill weapons and shields (everything needing energy to recharge) but leave you able to reach a base and refuel.
So, fuel in VS is a type of substance that needs to be refilled at a station when depleted? Not convinced this concession to "realism" mixes well with the other, mostly "sci-fi" mechanics. For mods that need it maybe, but that's it. Would rather see it based just on reactor output and capacitor capacity. I.e. you can run out of juice, but if you lay off the throttle and guns for a while the energy will be recharged slowly.
TBeholder
Elite Venturer
Elite Venturer
Posts: 753
Joined: Sat Apr 15, 2006 2:40 am
Location: chthonic safety

Re: speed limits

Post by TBeholder »

Since the questions are here...
Deus Siddis wrote: I tested it and it took ~20 minutes of constant forward thrust to expend all fuel. If acceleration rates weren't so insane wouldn't that be a reasonable efficiency?
On Dostoevsky with reactor 8 and shields 8 it's quicker than this. Two or three in-system bounty missions, and it's half empty. Then again, Dostoevsky carries 3.5 tons of fuel and Llama 25 tons.
klauss wrote: Killing your engines when you're out of fuel would be... harsh. It would kill the fun almost every time. Rather, once someone decided, it would kill weapons and shields (everything needing energy to recharge) but leave you able to reach a base and refuel.
As is, it would be the end. If the ship could be refueled using launched ships and/or contact someone and ask to deliver (for a price), though...
Errol_Summerlin wrote:So, I can make my governor do any velocity I want as my "desired vector?" Could I make it a vector different from the direction I am facing?
Via governor, no... but side-thrusters are bindable. On fighters and Rlaan ships it's must-have, IMHO.

edit:link
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
Post Reply