No need for mentors, the rendering code (Time/light.cxx and Viewer/renderer.cxx) is interesting enough to follow. Some comments are a bit misleading, but the code is written very cleanly. So the bus might be able to run over people, but the clean and functioning code - the bedrock of the project - will remain clean and functional.

It's quite interesting to just dive into the FlightGear renderer code and explore. I know too that I could get my basic questions answered on the devel mailing list, as I'm sure Curt and James knows the overall design of the code. But I find it more fun to just delete or comment out individual parts and see what happens when you start up FG You learn by seeing a lot of funkiness and weirdness. I might consider adding to the wiki, but this seems like a moving target and the wiki article would become out of date quite quickly. For example I might come up with some changes that would disrupt such an article. It'd be of greater benefit to document the code itself using detailed comments. But I'll see what I can do with The_FlightGear_Rendering_Pipeline.

Actually, It hasn't been much of a moving target recently - admittedly, that may change, should Stuart, James & Richard make any significant progress with the whole HLA/FGViewer thing, but apart from that, most of the code still dates back to the Rembrandt (FredB)/CameraGroup (Tim) related commits - and of course the original OSG port (by Mathias).

And given the commit logs, those three would actually seem to be in a much better position to answer any questions related to the rendering/viewer related code, with Zan being another obvious candidate.

The wiki article should be considered a "stub", it mainly consists of stuff taken from the archives - i.e. statements that were often made by Tim, Mathias and others in response to question posed by people like Thorsten.

There by and large hasn't been much need - the effect framework is rather flexible - for a forward renderer at least we can configure many things just from the xml without the need to delve into the code. It's really just a few more exotic tweaks which needed C++ intervention - like the way the forest landclass now declares two effects (one for the terrain itself, one for the trees on it).

Two so far. 1) The moon position, age and phase is now calculated and exposed in the property tree. 2) I have the ALS effects using the moon phase to set the light intensity at night. As Thorsten mentioned, the illumination is not yet correct as I need to apply some functions to make it non-linear. It looks promising, but I might try to come up with a better solution directly within the FlightGear renderer pipeline.

Note that the code needs work. I'm not a C++ programmer, so it's still rough. If you can manually compile your own versions of simgear and flightgear, then the code is in:

MIG29pilot wrote in Thu Dec 17, 2015 6:36 pm:Does that mean it will be kept out of the nightly builds or does that mean it won't be incorporated into the next stable release?

Both. I'll send something in for review only if the experiments work and we end up with something useful. See the above instructions if you'd like to play with ALS and automatic illumination intensity based on the moon's phase.

And it seems that Stuart's recent interest in HLA is also motivated by this whole trend, i.e. 1) splitting off simulation from rendering and 2) supporting different rendering strategies.

As can be seen by quotes from Tim, Mathias and Zan, we would ideally document the whole thing (even if just in terms of better embedded doxygen docs), or make it sufficiently configurable, so that people only needd to dabble with fgdata-level changes to rewire the whole thing, without people having to be proficient C++/OSG developers.

Canvas seems to have succeeded at de-skilling 2D rendering in FlightGear, and the effects/shader framework seems to be halfway there to accomplish the same thing for 3D/scene related code, especially in conjunction with the CameraGroup code.

given that there is so much interest in spacefllight recently, it would be cool to work out what else may end up being useful sooner or later if exposed at the property tree level, i.e. to support earthview-like approaches, without having to re-implement/work around rendering logic that already resides elsewhere - even if that just means making things better configurable (or entirely optional using dedicated draw masks), while providing for a seamless transition between the corresponding approaches -e.g. referring to:

Thorsten wrote:You'd rather re-invent the wheel from scratch because you're so focused on your final goal - which is why you will never go to the moon in FG, whereas I just might.

(in fact, an "architecture astronaut" might end up wondering what would be required to support arbitrary celestial bodies (think Moon, Mars) by exposing those using a property-configurable texture and corresponding parameters for an osg::Shape based array of LOD-enabled spheres )

For instance, imagine a custom PropertyList-XML dialect for instantiating celestial bodies by specifying a position, size, and 3D models/texture sheets for different LODs.

And yes, I would be willing to help work out the SGSubsystem/C++ and OSG magic/patches to make that happen in a generic fashion.

We already have support for adding models procedurally via /models, we can dynamically load/create/modify textures using Canvas, and we do support effects & shaders - so it would mainly seem like a matter of reviewing those features to come up with an interface so that arbitrary celestial bodies can be supported using these existing features.

You got my 'reaching for the stars' reference The code I'm looking at is a few of the key parts of what needs to be adapted for landing on the moon! The ephemeris code, the lighting code, and the osg scene set up in the FG renderer. I was thinking of exactly what needs to be done for a moon landing (or orbit) as I was looking at all of this.

Note that regardless of recent interest in supporting this, this is a really long-standing idea (just search the archives for "moon" or "mars" to see for yourelf).In my opinion it would be a terrific idea to review the corresponding code and see if/what and how things could be adapted to become increasingly configurable - if breakage/backward compatibility should turn out to be problematic, we could introduce a dedicated subsystem - pretty much based on the approach/features that Thorsten is using in Earthview

(without that having to involve any Nasal code necessarily - such a system could be prototyped in Nasal space, but would be straightforward to map to XML/property tree space, analogous to /ai, /models or even /canvas).

The basic idea being to encapsulate a light source, and LOD nodes for different ranges/visibility and texture sheets, in conjunction with effects/shaders that are to be applied.

This would be in line with how many other features in FlightGear started out being hard-coded, were then moved to become property-configurable, and finally become fully instantiable/modifiable at run-time (AI traffic, models, Canvas, camera views)

you can always accelerate simulator time and/or reposition your vehicle at run-time.

Only if your underlying trajectory simulation code is numerically stable enough to do that. Which JSBSim was never tested for if I remember Jon correctly.

And good luck re-positioning a spaceship - you need to get the whole state vector right, not just the position. A percent of velocity might be the difference between orbit and not orbit already. There are libration points in orbital mechanics where the balance is even more fine and a tiny nudge either way will send you either off to the outer planets or back to Earth.