Orbiter dynamics news

That last video was cool, with shooting cubes on the moon as well as a carrier airship.

But here's the problem with vessel-vessel collision detection:
Normally in scenario editor, if you wanted a grounded ship to "copy state from" another grounded ship, the two ships would be at the same place and go through each other.

Now what would happen if there was vessel-vessel collision detection? Let's just say that it probably won't end well.
 
That last video was cool, with shooting cubes on the moon as well as a carrier airship.

But here's the problem with vessel-vessel collision detection:
Normally in scenario editor, if you wanted a grounded ship to "copy state from" another grounded ship, the two ships would be at the same place and go through each other.

Now what would happen if there was vessel-vessel collision detection? Let's just say that it probably won't end well.

Just make sure to pause the simulation first so you can move it out of the way. No big deal.
 
It's been a while since I reported on development (or uploaded a beta). Reasons are mainly (a) real life getting in the way, and (b) a complete re-write of the dynamic state propagation model, which turns out to be a bit more work than I had anticipated, and is nowhere near complete.

Anyway, to sweeten the wait a bit, here is a new brief video development update. Vessels can now support a convex hull for ground interaction (rather than the meagre three touchdown points). And before anybody asks: This mechanism currently only works for surface impacts, not for vessel-vessel collisions (for which the convex hull concept would not be sufficient).

 
Edit: Opps NM, seems that the professor answered my question.
 
Last edited:
This should make shuttle landings much more interesting!
 
You will be able to define more than 3 touchdown points, but currently the first 3 points are still special, insofar as they are the only points that can have anisotropic friction behaviour (i.e. landing gear). The other points are currently simply regarded as edges of the hull, with a high isotropic friction coefficient. Making the anisotropic behaviour general for all touchdown points would add complexity, because you would then have to define the "forward" and "lateral" directions for each point. For the first 3 points, these are automatically inferred from their arrangement.
 
Impressive! I wonder though, does vessel still eventually come to 'Landed' state when it's done rolling? Or does it maybe suffer instability when landed and at high time acceleration or wind?
 
The vessel can still still enter a "landed" (idle) state even when it's upside down. I've written support for this only today. Currently, this can't be saved in the scenario, so if you flipped your DG over during landing, saved and reloaded your scenario, it will be back up. I may fix this eventually.

As mentioned earlier in the thread, the entire surface interaction model relies on dynamic state propagation via forces though the gear suspension, which is very unstable at high time accelerations, due to the short interaction times involved. This is partly compensated by new support for state subsampling between video frames, but even that won't work at time accelerations much beyond 100x. For higher accelerations, I am reverting to the old "semi-dynamic" model. Making the transition between the two models seamless wasn't so easy, and is an ongoing issue.
 
Will it be possible to check whether one of the "normal" touchdownpoints or one of the hull edge points is in contact with the ground ? That would be nice for coding damage simulation :)

Thanks again for all your work :hailprobe:
 
Hmm...a vertex-to-touchdown-point utility would be grand right about now :P
 
Hmm...a vertex-to-touchdown-point utility would be grand right about now :P
There's no need for such utility. You can get vertices, their normals, and their triplets (facing direction) from a mesh group at runtime, and the center of reference and vector units are the same for both the mesh and touchdown points.
 
It is also not recommended to copy the mesh vertices directly into the touchdown list for various reasons:
  • The touchdown point list should generally be significantly smaller than the vertex list. Each touchdown point incurs a computational cost for impact testing and force computation, so will have a frame rate effect. For example, the balls in the above video have > 10000 vertices, but 42 touchdown points. The DG has 15 touchdown points.
  • The touchdown points should generally define a convex hull, so only a subset of vertices is usually required (although this is not strictly true, because under compression even points on concave surface patches may get in contact with the ground)
  • Local vertex density of the mesh is generally arbitrary, but touchdown point density has a defined effect on the impact physics. For example, two touchdown points next to each other have essentially the same effect as a single one with twice the spring coefficient. So the placement of touchdown points should be governed by the physics, no visualisation.
 
How about looking for separate msh file with simplified vessel and proper naming convention (eg. deltaglider_dyn.msh). That way you can keep dynamic vertex count low and community will quickly develop "dynamic meshes" as needed.
 
How about looking for separate msh file with simplified vessel and proper naming convention (eg. deltaglider_dyn.msh).
How about using a group in the same mesh file with no-render flag set? I think it's up to developer whether they want touchdown points defined in code or in the mesh (either the same file or another), or in some other data file.
 
Back
Top