Orbiter dynamics news

[martins]

Just in case you were concerned that it has got a bit quiet on the development front recently: I am in the middle of entirely rewriting the dynamic state propagation code. This was initially sparked by this issue, but has gotten a bit out of hand. Essentially, the problem was caused by some hacks in the ground impact model that I had introduced in order to keep impacts stable at higher time accelerations.

I've now decided that it's time to revise this strategy and instead write a proper dynamics model for ground impacts. This will allow much more realistic effects at real-time and low accelerations, but will need some consideration for high time accelerations (where the entire ground interaction may occupy only a fraction of a single frame. In order to accomodate this, I have now rewritten the time integration routines to allow subsampling, essentially splitting a single video frame into multiple state updates. Since dynamic updates are much faster than frame rendering, a fair number of subsamples can be fitted into a video frame without too much performance impact.

Additionally, ground impact forces are no longer considered constant over an update frame. High-order integrators (RK and SY) which evaluate the states at intermediate times, will now receive interpolated ground impact forces.

One result of this new model is that linear and angular states must now always be updated in sync, so it will no longer be possible to select different integrators for the linear and angular states (since the evaluation of intermediate states requires information about position, velocity, orientation and angular velocity).

It's going to be a while before the new model is stable enough to justify a new beta (I also want to give aerodynamic forces a similar treatment). Also, I may need to fall back to the old behaviour at very large time accelerations, where even subsampling won't be sufficient for impact modelling. Some changes to the API may also be required, with the usual concerns about backward compatibility.

Anyway, in the meantime here is a little demo to whet your appetite:

 

[Arrowstar]

Excellent! It looks quite nice. :thumbup:

In the first segment of the video, am I seeing the DG landing gear compress, or are they clipping the surface of the runway?

 

[Napalm42]

Oh wow, that looks great Dr. Schweiger.

 

[Cras]

Excellent stuff!

 

[martins]

In the first segment of the video, am I seeing the DG landing gear compress, or are they clipping the surface of the runway?

It isn't actually visually compressing, although this could be done in the vessel code (by checking how far below the surface each of the touchdown points is located, and driving the compression animation accordingly). It is however behaving as if it was compressing, and that is all that counts, after all. The rest is just eye candy ...

By changing the compression stiffness and damping factors, you can get pretty interesting effects. Also, I noticed that it is now nearly impossible to land on the moon runway-style (i.e. with significant horizontal velocity) without flipping over, in particular if you engage the wheel brakes.

Also, I may have to replace the familiar 3 "touchdown points" with a "touchdown convex hull", because at the moment the spacecraft will sink below the surface if you land upside down.

 

[mojoey]

Who exactly wants to land upside down? seems a bit damaging to the spacecraft. Eye candy is ALWAYS good. As long as it doesnt interfere with the realism (physics wise) it shall be welcome on my hard drive :thumbup: great job!

 

[Artlav]

Looks great.
While you're at it, can you also leave a hook for altitude?
That is, instead of comparing the altitude with the planet, or collision against the planet's sphere, leave an option to have a module that would provide that altitude/collision structure for such point on such planet instead.
That could simplify the long-awaited business for making collidable terrain and building meshes into a few lines of add-on code.

About subsampling - do you aim at a specific step length, breaking up whatever frame_time into a set of it (plus remainder), or something else?

The former is prone to runaways - if the rendering lags and the amount of time to fill up the steps exceeds the time to render the next frame then the next frame would take more time to render, needing even more steps, and so on.

Assuming the state update would take negligible time can backfire too - someone may want to make a replicating vessel, running the vessel count into thousands -

 

[RisingFury]

(I also want to give aerodynamic forces a similar treatment)

Will that prevent the crazy shaking of certain objects at high dynamic pressure?

---------- Post added at 08:57 ---------- Previous post was at 08:53 ----------

Also, I may have to replace the familiar 3 "touchdown points" with a "touchdown convex hull", because at the moment the spacecraft will sink below the surface if you land upside down.

Could you describe the "touchdown convex hull" a bit more, please.

Also, what about a way that allows addon devs to define more than 3 touchdown points?

 

[N_Molson]

Thanks for this update, I was feeling the vessel-to-ground interface as one of the "oldest parts" of Orbiter code. :thumbup:

And hopefully this could help to develop 3D terrain with collision detection, as stated above :yes:

 

[Spacethingy]

Wonderful! I never liked that "snapping to the ground" look very much. Thanks!

 

[jangofett287]

So when I crash, I will now actually, well, crash! Awesome!

 

[Donamy]

Could this be used to make splashdowns and water movement ?

 

[RisingFury]

One more thing I suppose I should mention here...

When vessels roll along the runway, they actually jump a little bit. UCGO cars routinely become airborn while driving along. Not actually an issue the average Orbinaut would care about, but I thought I'd point it out here.


I'm really excited about the new landing gear compression! It'll add an extra challenge to landings!

 

[Grover]

B-E-A-utiful, that is spectacular coding, but i have one question:

will there be an upepr limit, defined in a vessel's code for how far the gear can compress? because in the video it showed the belly of the DG going below the surface of the earth, when a DG would really have only 150mm of compression at a maximum (due to the little landing gear struts)

this also leads onto another point: if the calculated compression would exceed the given upper limit for compression, vessel damage could be implicated, starting at just the wheels (increased rolling resistance), then to landing gear in general (further increase in rolling resistance, and possibly failed retraction) then to other parts, which can result in broken elevons, reduced lift, increased drag etc

ok, now i see why your project got out of hand... did orbiter just start as a simple orbital calculator... then evolve into the sim we see today?

 

[tl8]

One more thing I suppose I should mention here...

When vessels roll along the runway, they actually jump a little bit. UCGO cars routinely become airborn while driving along. Not actually an issue the average Orbinaut would care about, but I thought I'd point it out here.


I'm really excited about the new landing gear compression! It'll add an extra challenge to landings!

They do? This is good

My tug has the same problem. It was quite bad before, but it is a lot better now (< 2 degrees). It depends on the the touchdown points and the location of the thruster/force.

I must say, this has perked my interest, though like you I am not sure what effect it will have.

 

[RisingFury]

They do? This is good

My tug has the same problem. It was quite bad before, but it is a lot better now (< 2 degrees). It depends on the the touchdown points and the location of the thruster/force.

I must say, this has perked my interest, though like you I am not sure what effect it will have.

I only noticed it when creating the ground missile guidance for the OBSP. The ground missile will only track the target if it's actually marked as touching the ground by Orbiter. If it takes off, the missile will lose track and self destruct. I noticed the jumping for rolling vessels when most of the missiles I fired detonated in mid air...

The jumping only occurs for a few frames at a time, so the solution is to check if the vessel is airborne for several consecutive frames, or for a certain amount of time.

 

[martins]

Looks great.
While you're at it, can you also leave a hook for altitude?
That is, instead of comparing the altitude with the planet, or collision against the planet's sphere, leave an option to have a module that would provide that altitude/collision structure for such point on such planet instead.
That could simplify the long-awaited business for making collidable terrain and building meshes into a few lines of add-on code.

Yes, I was thinking about this. Essentially, there are two possible approaches:

• Requesting the altitude at each of the touchdown points
• Requesting the altitude at a single point, and the associated gradient

The first method is a bit more versatile, because it would also accommodate impact with structures such as buildings, while the second method is more suitable for smoothly varying surfaces. Also, if I do implement the touchdown convex hull idea with potentially hundreds of touchdown points, the first method may become inefficient. What do you think?

About subsampling - do you aim at a specific step length, breaking up whatever frame_time into a set of it (plus remainder), or something else?

The former is prone to runaways - if the rendering lags and the amount of time to fill up the steps exceeds the time to render the next frame then the next frame would take more time to render, needing even more steps, and so on.

Assuming the state update would take negligible time can backfire too - someone may want to make a replicating vessel, running the vessel count into thousands

Subsampling will be decided on a per-vessel basis, not for the entire simulation. Only vessels in critical situations (collisions) will usually subsample their update steps, so hopefully the impact won't significantly increase for densely populated scenarios. There will be an upper limit to the number of subsamples, so this should keep runaway effects in check. Also, I am trying to clean up the dynamic update code to the point where vessels can update themselves independently from each other, so can use multiple threads, except in docking/attachment/collision configurations.

 

[jedidia]

Also, if I do implement the touchdown convex hull idea with potentially hundreds of touchdown points, the first method may become inefficient. What do you think?

Maybe this is a silly question, but I can't help it: Why not just use collision meshes and finally support full-out collision detection?

 

[Artlav]

Yes, I was thinking about this. Essentially, there are two possible approaches:

• Requesting the altitude at each of the touchdown points
• Requesting the altitude at a single point, and the associated gradient

The first method is a bit more versatile, because it would also accommodate impact with structures such as buildings, while the second method is more suitable for smoothly varying surfaces.

When in doubt, leave options?

The second seems to be an extension on the first - you can get gradients by checking the nearby points.
But what if the vessel sits on a ledge? It would roll down like if it was on a hillside. Only the module can decide which is the case.

Maybe cluster the points together?
Pass on an array to be filled up - a structure with coordinates written in it and places for altitudes provided. Then, the module is free to fill them all up separately or interpolated, and the core would use them as separate ones.
There is likely to be two kinds of modules - for the whole planet terrain, and for a specific base or place, and both would like to have different functionality.

And a simple second function for a single point requests - given a VECTOR3 somewhere near a planet, provide altitude. Usable for instrumentation.
Some kind of throttling and buffering is in order - like if an addon would like to request the altitude a dozen times in a loop, the core should call the terrain once and store the result.
It may also have to be exported as get_elevation_by_coords kind of call, for example so that autopilots could scan the terrain ahead. And hope the developers would use it wisely.

Also, if I do implement the touchdown convex hull idea with potentially hundreds of touchdown points, the first method may become inefficient. What do you think?

Convex hull of hundreds of points just for touchdown sounds a bit over the top.
In Meshland i define collisions by an array of points, and only 9 of then are enough to make a nice handling of a Deltaglider - gears, wingtips, nose and top.
Here it is in action from a few years ago:

[ame="http://www.youtube.com/watch?v=1gZN-5hl428"]Visosad 070426 vessel-vessel collision detection demo - YouTube[/ame]

 

[Robsoie]

the collision modelling with the terrain looks like a very impressive change in the video from the first post. I will have to land more correctly now