Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Thorsten » Fri Jun 24, 2016 5:33 am

The way it's written I can just generate the whole data structure and not plot it - no significant performance drain, so the projections, culling etc. in Nasal space is okay. Rendering the structure is not the issue, since I can watch it, but the drain comes only during the display update frame.

I can also look elsewhere and not hence not cause any rendering load - and I see the single frame latency rise whenever the PFD is updated.

I can also compute the whole data structure but write only parts of it, and I see the performance drain creep in proportional to what I write.

So at this point it's academic whether it's the actual property throughput or the step to pick up the properties and render it all as I can't separate these steps conceptually.

I know wiping and re-drawing is bad, but given how visible line segments on a sphere change with rotation, I'm at a loss how to even design a data structure that would just solve it by translating and hiding segments - the computational overhead to manage that is an order of magnitude more than to generate it from scratch.

I've tried a staggered approach in which in each of four successive frames a group is re-drawn, but somewhat puzzling this leads to flickering when groups are updated. My best hypothesis that depth information isn't honored immediately but takes a frame to be picked up by the renderer, but strictly I don't know - I've not found any detailed information how depth is managed by canvas.

In any case, there's now a quality slider for the ADI ball which allows you to change from 'usable' to 'extremely pretty' and I will see whether I can run somewhat more agressive culling to beat the property IO down by writing the minimal number of invisible nodes only.
Thorsten
 
Posts: 11448
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Fri Jun 24, 2016 10:38 pm

IIRC, the depth comment is spot-on - I think I saw a comment in $SG_SRC where Tom specifically mentions this sort of thing, i.e. delayed rendering, skipping a frame or something like that.

Not sure if it's worth the hassle to optimize this in Nasal space - the 3D model approach would be simple in comparison to what you are currently doing, because we'd just be loading a 3D model and animate, transform it according to a handful of properties, and from then on, everything would be in OSG-land
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11584
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sat Jun 25, 2016 5:20 am

the 3D model approach would be simple in comparison to what you are currently doing, because we'd just be loading a 3D model and animate, transform it according to a handful of properties, and from then on, everything would be in OSG-land


It'd however not be consistent with the look of the real display which does not render a real 3d sphere on-screen - Vostok-1 has a 3d ADI ball like that, it looks different. I've thought long and hard about it and then decided to discard the idea.

Anyway, it seems liberal culling can cut processing requirements down by 40%, so with the detail management, this is now in an acceptable state.
Thorsten
 
Posts: 11448
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Jun 25, 2016 7:39 am

[img]the%20real%20display%20which%20does%20not%20render%20a%20real%203d%20sphere%20on-screen[/img]

I think, that's a more recent change (i.e. when CRTs were with LCDs displayed?), but as far as I can tell, the original instruments did indeed contain the equivalent of an actual "ball":

http://www.space1.com/Artifacts/Space_S ... e_adi.html
Image
Image
Image

As far as I can tell, the oribiter folks came up with something texture-based: http://www.orbiter-forum.com/showthread.php?t=18223
Looks 3D, doesn't it? But it's all fake - a flat mesh in a flat panel with no z-coordinates and no lighting.


Note that if we can work out the projection stuff (which you apparently have already), this "fake mesh" could be rendered to a Canvas texture and then simply retrieved procedurally, i.e. by getting a sub-texture (texture map) and transforming that as needed.

I haven't looked at any of their screenshots, but it seems they found a way to make this work efficiently - which your Nasal/Canvas approach may benefit from even more.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11584
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sat Jun 25, 2016 9:41 am

I think, that's a more recent change (i.e. when CRTs were with LCDs displayed?), but as far as I can tell, the original instruments did indeed contain the equivalent of an actual "ball":


The whole cockpit mesh and the avionics present is late-phase Atlantis - before the Shuttles got a glass cockpit they had a physical ADI ball, but the whole cockpit mesh would have to be different to accomodate that instrumentation.

As far as I can tell, the oribiter folks came up with something texture-based


... which doesn't display yaw motion, only pitch and roll, which is the whole point of doing it semi-3d in FG. :-)
Thorsten
 
Posts: 11448
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Jun 25, 2016 9:56 am

I am probably missing something, but regarding the ADI ball: shouldn't it work to project it to a texture using a map projection (if necessary, using different sub-textures for parts that need to be treated separately, you mentioned labels and a few other things), and then only compute a texture map of what should be extracted/visible from that texture, without it ever having to change from then on ?

At that point, any "updates" would merely be fetching the sub-texture from the texture map, and if you need more dynamic elements, that cached texture could be treated as an overlay/background image ?

In other words, the ADI ball/sphere would be rendered in its entirety to a texture of say 512x512 with spherical projection applied, and later on, your Nasal code would retrieve the relevant parts of it to display/transform those (by computing/updating sub-texture coordinates)

If something like this could be made to work, the runtime overhead should be minimal (i.e. the typical time/space tradeoff)

But like I said, I don't actually know anything about the instrument/its requirements, and I also haven't looked at any of your code yet.

However, we were once talking about projecting/unprojecting spherical maps for other purposes - thus, if your code can render a sphere using Canvas, the same code could be modified to render a fully projected sphere to a Canvas texture, so that any future viewpoint-updates should merely be sub-texture lookups ?

Back when we originally came up with the Canvas/SymbolCache framework, we were using a similar, but much simpler, way to pre-compute, and cache, geometry so that it could be later on treated as textured quads retrieved from a texture map.

Even having to use 2-3 textures to serve as some kind of texture atlas, the memory/time tradeoff may be worth it, because the runtime footprint should be significantly lower if Nasal merely updates coordinates for the texture maps to retrieve and treat as overlays, no ?

As a matter of fact, once you begin supporting/displaying multiple instances of such an instrument, the memory/time-tradeoff will definitely be worth it, because multiple instances may be reusing the same cached data, just with different offsets applied (think the same texture map, with different sub-texture coordinates) - and that would even apply if the same instrument would be rendered to a GUI dialog, internally 3+ instances of the same instruments could be using the same cached projected sphere


(feel free to ignore this completely if this is obviously a stupid idea because of something instrument-specific that I am unaware of)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11584
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sat Jun 25, 2016 11:26 am

A texture is a zero curvature object. A sphere has positive curvature, hence there is no flat mapping from a texture to a sphere. However what you get to see of a sphere is a 2d projection with again zero curvature. Even if you do the first projection and have a mapped sphere, you can't use the texture 'as is', you need to do the projection into view space.

That's the 'render a 3d sphere' idea.

Just looking up the texture doesn't do the trick because it misses the second projection.

In other words, the distortion you see of lines on a sphere depends on your perspective and some way or the other needs to re-computed in 3d space every frame because your perspective changes from frame to frame - either by the CPU using the Nasal data structure or by the GPU passing a textured 3d mesh. There's no shortcut with 'just' lookups in the genral case (there is if you eliminate yaw, because then you're essentially transforming the problem from a sphere into a cylinder, and a cylinder is a zero curvature object so a texture lookup works (sort of) without projection.

Edit: The textured 3d sphere idea on the GPU has the issue that it is 'too real' - it would actually project pixels and hence distort everything (including numerals and line widths). That's not what the Shuttle display does - (internally it pretty much does what the Nasal version does) - it just projects coordinates but then draws based on these coordinates in 2d space, so numerals are moved but not distorted themselves.
Last edited by Thorsten on Sat Jun 25, 2016 11:35 am, edited 1 time in total.
Thorsten
 
Posts: 11448
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Jun 25, 2016 11:33 am

I realize that, I think, we were basically having a similar problem with the latitude/longitude grid in the built-in Map dialog, where the current position determines the actual arrangement of the grid

Image

The idea back then, was to memoize a pre-built cache, to avoid the runtime pentalty of doing this repeatedly, but I'd need to find the topic to know for sure.

Anyway, thanks for the explanation
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11584
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Fri Jul 01, 2016 11:47 am

Just back online after a several day internet breakdown... The good news is, I was so frustrated with not being able to do any of my normal activities that I wrote Shuttle autopilots for entry and TAEM - so for the lazy ones, the Shuttle can now be flown without ever touching the stick for almost all mission phases - except final approach and touchdown, that you have to do yourself (just like in reality).

The entry AP is about as good as I am, i.e. it has some deviation around the optimal trajectory, but gets you into a workable TAEM solution. It can do some fancy stuff that looks very sickening (and is hard to do when flying manually) which is alpha modulation - changing AoA during entry by +- 3 degrees corresponds to an instantaneously change of drag by some 10%, which works much faster than changing drag by changing altitude and is used to dampen the oscillations around the guidance target. It also has a low energy mode in which low drag flight rules are used in case you're coming in long. Like the real thing, it does not know about structural limits, aka it will kill you if it decides we need more drag than the Shuttle can take in terms of g-forces - manual take-over is the required procedure.

The TAEM AP can do everything up to the final turn into the approach. It will do S-turns if it thinks we're high on energy and dynamically adapts if you down-mode to a different entry point or HAC procedure. It didn't always deliver me into the optimum approach, but reliably into a flyable approach. Real procedures are taking over by the time the Shuttle goes subsonic by the way - usually that's well before reaching the HAC - so don't complain if it ain't perfect!

Both APs are fuly interfaced to the PFD, so even if you have pitch and/or yaw/roll down-moded to CSS, the error needles on the PFD will be meaningful and will deliver you into the APs preferred solutions if you manually follow them (personally, I find it easier to fly by the 'big picture' from ENTRY TRAJ and VERT SIT than to chase the needles, but to each his own...)

There's a host of new guidance information displayed as well, especially on ENTRY TRAJ - that's moderately meaningful, but you can ignore it if you're not interested in the gory details of what the AP is trying to do.

I've tested a complete TAL scenario from Kennedy to Zaragoza this morning under automatic control, and it worked beautifully. If you're in a hurry, try a time fast-forward by a factor 4-8 - the AP will be stable because all time-critical components run on JSBSim. The resulting motion of the Shuttle during entry looks like a roller-coaster...

Happy flying
Thorsten
 
Posts: 11448
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Fri Jul 01, 2016 12:38 pm

Super cool!!!! Being the laziest within the lazy group I really appreciate it :) For me it's also very important to have the error needles operative for when I'd like to get close and personal with the shuttle, but still without having to attend Orbit Dynamics 101 for getting a proper orbit, and back :)

Regards!!

P.S-> What do you have in mind to do next, Thorsten? The pilot side of the STS looks quite mature now, maybe get more involved into the mission side?
amalahama
 
Posts: 115
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Hooray » Fri Jul 01, 2016 1:01 pm

the wonders of how productive you can be without internet access - oh well, those were the days ...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11584
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Fri Jul 01, 2016 2:21 pm

What do you have in mind to do next, Thorsten?


There's still six DPS pages which seem meaningful to support (PDRS support and the environment system), there's the MEDS config page,... In terms of guidance, the crown jewel of the collection: proper RTLS support (even under AP?), that's a really challenging regime. Some contingency abort guidance. Tank leakage simulation and appropriate procedures.

Not sure what you expect on the mission side. I can't single-handedly replace a community - either people become interested in spaceflight in FG and start developing more infrastructure and model payloads for the Shuttle, a better space station, other spacecraft... etc - or not. It might also be tedious to do a 'real' mission in FG because I couldn't get more than a factor 8 of time fast-forward out of my computer with that amount of systems simulated, so... it means for an eight day mission you're actually going to be busy a full 24 hours. Well, probably the save/resume can be developed to the point that you can split these 24 hours into several chunks.

Once the Shuttle is actually in a presentable state, I guess a well-deserved break to work on rendering again. ALS has been suffering a bit, and there's this plan to wrote a novel terrain engine...
Thorsten
 
Posts: 11448
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Fri Jul 01, 2016 7:11 pm

Not sure what you expect on the mission side. I can't single-handedly replace a community - either people become interested in spaceflight in FG and start developing more infrastructure and model payloads for the Shuttle, a better space station, other spacecraft... etc - or not.


Personally, my preference/suggestion woud be to provide a handful of building blocks (function) that would allow people to create their own missions - e.g. as per the geo.nas and aircraft.nas modules for adding models/aircraft to the scene, obtaining the current position, computing offset positions - just with a focus on spaceflight (think orbital.nas) - I think you have basically begun doing this already, i.e. back when I toyed with visualizing orbital trajectories you mentioned a few APIs that you specifically developed for adding an object to orbit - if this could be refined and extended over time, we could grow a "module" with useful utility functions that could be used by contributors/power users to extend and create "missions" - maybe even in conjunction with the tutorial/missions framework we have already.

Thus, if people are interested in this, my suggestion would be to refactor some utility functions and provide a self-contained Nasal module that we could then document on the wiki, maybe in conjunction with a little tutorial that demonstrates how an object can be added into orbit, even if it's just a satellite or something very simple (think ufo) and how to obtain the data to target that object using a spacecraft like the shuttle.

Anyway, that's just my 2c - and take them with a grain of salt, because it's unlikely that I am going to do anything related anytime soon.

However, referring to your original trajectory map code, I would very much like to resurrect the idea of generalizing that, to support arbitrary objects that can be dynamically added/updated on demand - if your trajectory map could be reworked accordingly and work through something like "orbital.nas", we could even provide a simple UI to add arbitrary 3D models with customizable properties at runtime - which may also be useful for debugging/development purposes.

And like I said originally, I still think that the trajectory map would be useful in and of itself, i.e. without being specific to the shuttle - ideally, it would become a reusable Nasal module, that aircraft/spacecraft developers could load and use for their purposes - and given the way the Canvas system works, it would be really straightforward to make it use a different overlay/background image, or even render to a fictional "instrument" display.

You have already done all the hard work - so if we want to foster development of spaceflight in FlightGear, it would make sense to provide a few utility functions and tools, such as your trajectory map in a generic and reusable fashion - for instance, even just as a standalone Canvas dialog: http://wiki.flightgear.org/Howto:Creati ... ialog_file
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11584
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sat Jul 02, 2016 5:20 am

Personally, my preference/suggestion woud be to provide a handful of building blocks (function) that would allow people to create their own missions


You make that sound more easy than it is because there's significant interaction between 'externals' (payload, satellites, space stations,...) and the Shuttle, most of which is mission-specific and not standardized.

You can grapple some satellites with the RMS arm. You can dock to a station - but only on the docking collars. You can not dock everything to everything as far as I know. ISS can supply power for the Shuttle and the fuel cells can be powered down, Mir can not (or does not). The payload interface to an ISS module is not the same as for the HST.

Think ground observation missions - they'd need some pointing targets for equipment I gather.

The Shuttle needs to be taught these things, so it's very much a question of bouncing things back and forth - someone interested in a mission needs to gather the 3d models and the information. Then where necessary the Shuttle code needs to be adapted to accomodate it. Then it needs to be tested and refined.

We have some of the easy generic building blocks (mission definition files with the ability to place different objects into orbital trajectory simulations, or the ability to define gross properties of payloads...) but if the rest were easy to generalize, I'd have done it by now... but even simulating the ET after disconnecting it is subtly different from simulating the Ku-antenna if you blow it off by pyro charges (while the tank gases out, the pyro charge will induce a slow spin of the antenna).
Thorsten
 
Posts: 11448
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Jul 02, 2016 1:13 pm

Like I said previously, I have no clue about the details - but to be honest, you make it all sound very specific, while I was really thinking in terms of generic building blocks, and certainly not in terms of different docking "ports", payload interfaces etc - it for a reason that I suggested that a library be grown to support adding arbitrary 3D models to an orbit, along with a handful of parameters specifying its details - so that everything else can be added over time.

Referring again to the trajectory map, I don't see any major obstacle to generalize that and allow such objects to be visualized accordingly - everything you said is certainly relevant, but I guess not likely to be a huge factor within the next 2-3 years, unless someone spends a considerable amount of time doing all the R&D - in the meantime, it would seem like a good idea to grow a library with utility functions and tools.

In other words, even exposing what you have already via the UI (think trajectory map) may be helpful to get people going with adding satellites etc - maybe in conjunction with a new folder in $FG_ROOT (think $FG_ROOT/Orbit) from which PropertyList/XML files can be loaded for different orbital objects, which would then be added/updated by a corresponding Nasal module.

Over time, people will add new 3D models and orbital specs to place such objects - and the trajectory map could help with that.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11584
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 1 guest