Board index FlightGear Development Effects and shaders

Implementing moonlight (or not)

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Implementing moonlight (or not)

Postby bugman » Thu Dec 17, 2015 6:50 pm

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.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Implementing moonlight (or not)

Postby legoboyvdlp » Thu Dec 17, 2015 6:52 pm

Interesting stuff :)
:D :D
Have you managed any breakthroughs?
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Implementing moonlight (or not)

Postby Hooray » Thu Dec 17, 2015 7:25 pm

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.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Implementing moonlight (or not)

Postby Thorsten » Thu Dec 17, 2015 7:28 pm

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).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Implementing moonlight (or not)

Postby bugman » Thu Dec 17, 2015 7:35 pm

legoboyvdlp wrote in Thu Dec 17, 2015 6:52 pm:Have you managed any breakthroughs?


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:


These can be directly checked out with git using the instructions there, or set up as remotes, for example for a pre-existing flightgear git repository:

Code: Select all
$ git remote add -t directional_moonlight_2015-12-17 moonlight http://git.code.sf.net/u/edauvergne/flightgear
$ git fetch moonlight
$ git checkout -t moonlight/directional_moonlight_2015-12-17


The current changes will not be sent for inclusion into FlightGear, as this is all experimental. The more interesting effects are yet to come, but the basic infrastructure is in place now.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Implementing moonlight (or not)

Postby MIG29pilot » Thu Dec 17, 2015 7: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?
User avatar
MIG29pilot
 
Posts: 1465
Joined: Tue May 19, 2015 5:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 2020.1.3
OS: Windows 10

Re: Implementing moonlight (or not)

Postby bugman » Thu Dec 17, 2015 7:39 pm

MIG29pilot wrote in Thu Dec 17, 2015 7: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.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Hooray » Thu Dec 17, 2015 7:40 pm

There by and large hasn't been much need

Well, I don't know, but given statements made by James, Mathias and others, people are hoping to split up the whole thing anyway, specifically to support different renderers: http://wiki.flightgear.org/Supporting_m ... _renderers

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.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Implementing moonlight (or not)

Postby legoboyvdlp » Thu Dec 17, 2015 8:13 pm

bugman wrote in Thu Dec 17, 2015 7:35 pm:
legoboyvdlp wrote in Thu Dec 17, 2015 6:52 pm:Have you managed any breakthroughs?


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.


Very good. Too bad it won't be in the nightlies, as the latter is a very nice touch. Nevertheless, nice work :)
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Implementing moonlight (or not)

Postby Hooray » Thu Dec 17, 2015 8:57 pm

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:

Subject: Su-15
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 :D )

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.

(note that this seems to be how celestial bodies in Orbiter are structured: http://www.orbiterwiki.org/wiki/Category:Add-ons )
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Implementing moonlight (or not)

Postby bugman » Thu Dec 17, 2015 9:14 pm

You got my 'reaching for the stars' reference :D 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.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Implementing moonlight (or not)

Postby Hooray » Thu Dec 17, 2015 9:31 pm

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).

And even the sphere could be created/textured procedurally using osg::Sphere: http://trac.openscenegraph.org/document ... gShape.htm

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)
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Implementing moonlight (or not)

Postby legoboyvdlp » Thu Dec 17, 2015 9:32 pm

Anyway, if it ever happens, could there be a 'portal' to go to the Moon or Mars, since not many have a couple of days to spare flying a spaceship to the moon? :)
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Implementing moonlight (or not)

Postby Hooray » Thu Dec 17, 2015 9:36 pm

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

Also see the "planets" discussion here, including the links to related devel list postings: viewtopic.php?f=5&t=26785
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Implementing moonlight (or not)

Postby Thorsten » Fri Dec 18, 2015 8:38 am

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.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 2 guests