Space Shuttle

[Hooray]

to draw curves instead of line segments, see the APIs available for OpenVG paths (OpenVG being hardware-accelerated vector graphics), as per api.nas:

http://sourceforge.net/p/flightgear/fgd ... as/api.nas

Code: Select all

# Move path cursor
  moveTo: func me.addSegment(me.VG_MOVE_TO_ABS, arg),
  move:   func me.addSegment(me.VG_MOVE_TO_REL, arg),
  # Add a line
  lineTo: func me.addSegment(me.VG_LINE_TO_ABS, arg),
  line:   func me.addSegment(me.VG_LINE_TO_REL, arg),
  # Add a horizontal line
  horizTo: func me.addSegment(me.VG_HLINE_TO_ABS, arg),
  horiz:   func me.addSegment(me.VG_HLINE_TO_REL, arg),
  # Add a vertical line
  vertTo: func me.addSegment(me.VG_VLINE_TO_ABS, arg),
  vert:   func me.addSegment(me.VG_VLINE_TO_REL, arg),
  # Add a quadratic Bézier curve
  quadTo: func me.addSegment(me.VG_QUAD_TO_ABS, arg),
  quad:   func me.addSegment(me.VG_QUAD_TO_REL, arg),
  # Add a cubic Bézier curve
  cubicTo: func me.addSegment(me.VG_CUBIC_TO_ABS, arg),
  cubic:   func me.addSegment(me.VG_CUBIC_TO_REL, arg),
  # Add a smooth quadratic Bézier curve
  squadTo: func me.addSegment(me.VG_SQUAD_TO_ABS, arg),
  squad:   func me.addSegment(me.VG_SQUAD_TO_REL, arg),
  # Add a smooth cubic Bézier curve
  scubicTo: func me.addSegment(me.VG_SCUBIC_TO_ABS, arg),
  scubic:   func me.addSegment(me.VG_SCUBIC_TO_REL, arg),
  # Draw an elliptical arc (shorter counter-clockwise arc)
  arcSmallCCWTo: func me.addSegment(me.VG_SCCWARC_TO_ABS, arg),
  arcSmallCCW:   func me.addSegment(me.VG_SCCWARC_TO_REL, arg),
  # Draw an elliptical arc (shorter clockwise arc)
  arcSmallCWTo: func me.addSegment(me.VG_SCWARC_TO_ABS, arg),
  arcSmallCW:   func me.addSegment(me.VG_SCWARC_TO_REL, arg),
  # Draw an elliptical arc (longer counter-clockwise arc)
  arcLargeCCWTo: func me.addSegment(me.VG_LCCWARC_TO_ABS, arg),
  arcLargeCCW:   func me.addSegment(me.VG_LCCWARC_TO_REL, arg),
  # Draw an elliptical arc (shorter clockwise arc)
  arcLargeCWTo: func me.addSegment(me.VG_LCWARC_TO_ABS, arg),
  arcLargeCW:   func me.addSegment(me.VG_LCWARC_TO_REL, arg),
  # Close the path (implicit lineTo to first point of path)
  close: func me.addSegment(me.VG_CLOSE_PATH),


[Thorsten]

Something visual... the joy of submodels The separation dynamics isn't perfect yet, but perhaps the external force can be applied to simulate the effect of the separation motors pushing the boosters away from the stack.

[Bjoern]

This separation trajectory would have made for a nice explosion in Kerbal Space Program - and a subsequent rescue mission, assuming that the rest of the orbiter had stayed intact and had made it to orbit.

[wkitty42]

Something visual... the joy of submodels The separation dynamics isn't perfect yet, but perhaps the external force can be applied to simulate the effect of the separation motors pushing the boosters away from the stack.

i always thought there was some sort of side rockets that were fired to push the tops of the SRBs out sideways away from the orbiter and tank... something that made them kinda peel off away from the vehicle like drawing the top arcs of a valentine where the vehicle is the center V of the top of the valentine...

i hope that comes across visually as i'm seeing it in my mind's eye...

[Thorsten]

Yes, as I said, I haven't implemented the separation dynamics yet.

[wkitty42]

ahhh, ok... i did see that but didn't realize that this was what you were speaking of

[Thorsten]

Converted the SRBs to slaved ballistic submodels with the flames attached. Upon separation, they're pushed away by 1.2 second burns of the 16 separation motors. Took a while till I found the specs of the separation motors, but okay...

The SRBs continue to burn for a bit without producing much in terms of thrust - they seem to fall here, but they actually don't, it's just that the shuttle accelerates away, if you switch off main engines at separation, you can nicely coast upwards with them.

Getting the directions of the external forces right based on shuttle yaw, pitch and roll frankly is a nightmare in trigonometry - you end up with some asin(cos(rho) / (cos(asin(sin(rho) * cos(theta)))) expressions.





That now looks like the right separation dynamics.

Only problem - the damn submodels flicker occasionally and vanish from view. Anyone who has experience with slaved ballistic objects and can comment?

So I might initialize them as ballistic objects but replace their visuals by a static model during ascent eventually.

[wlbragg]

So I might initialize them as ballistic objects but replace their visuals by a static model during ascent eventually.

I have no comment on why or if there is a fix for the flicker. But I can confirm when I tried to animate an independent AI model in real time alongside a standard model, I had the same problem. If I used a sub-model (without animation) and then a ballistic for the animation, I achieved the desired effect without flicker or teleporting. However the ballistic animation has a mind of its own. I don't think you have much control over its departure.

I'd be real interested if there is a fix for the sub-model real-time animation?

[Hooray]

So I might initialize them as ballistic objects but replace their visuals by a static model during ascent eventually.

I have no comment on why or if there is a fix for the flicker. But I can confirm when I tried to animate an independent AI model in real time alongside a standard model, I had the same problem. If I used a sub-model (without animation) and then a ballistic for the animation, I achieved the desired effect without flicker or teleporting. However the ballistic animation has a mind of its own. I don't think you have much control over its departure.

if that's the case, it must be something that the AI and sub-model code have in common, right ?
flickering and visibility changes could be related to mis-behaving LOD management in the underlying C++ code - but we'd need to look a thorough look at the C++ to see what is going on there.

[wlbragg]

I had this problem before I knew anything about autopilot or property rule. I never tried to apply that, (if you even can), to the animation. Maybe that could do the trick.

[Hooray]

is the animation stuff otherwise handled from Nasal or why do you think that using property rules may be beneficial ?

[wlbragg]

In my case, yes, I was handling it in nasal VS ballistics in XML.

[Hooray]

and did that make a difference WRT flickering ??

[wlbragg]

Now that I think about it, I could never get the AI model to animate from point a to b without teleporting (moving it by updating it in nasal). So I cheated and hid the AI model as soon as I connected to it with the hook or rope and used an AI ballistic sub-model when I needed to transport the cargo container from a to b. So I had to have both the AI container and a ballistic sub-model container. It was difficult to manipulate the physics of the sub-model the way I wanted to for towing it hanging from a rope. But I DIDN'T have flicker or teleporting if I used the ballistic sub-model. When I was ready to drop the container I used ballistics code. As soon as it hit the ground I switched back to the real AI model. It really was seamless looking, it was just disappointing I couldn't move it real time.

[Hooray]

have you tested Red Leader's scripted AI missiles framework (implemented on Nasal, check the wiki) ? I haven't noticed any such restrictions there back when I played with it - but I may have missed something ... the underlying C++ code still is the AI model system.