Board index FlightGear Development Effects and shaders

ALS scope

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

ALS scope

Postby erik » Tue Jul 18, 2017 7:26 pm

I was wondering: is there any known part of FlightGear that doesn't get touched by the ALS shaders?

Yesterday I realized that since ALS does most of the light computations on the GPU it should, in theory, be possible to turn off CPU lighting calculations saving some CPU cycles for low end machines. A quick test did not reveal anything obvious. But I might have missed some exceptions.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2244
Joined: Thu Nov 01, 2007 2:41 pm

Re: ALS scope

Postby Thorsten » Tue Jul 18, 2017 7:37 pm

The particle system, the sun, moon, planets and stars and any surface that has legacy effects like chrome.eff or model-transparent.eff assigned, as well as the non-canvas HUDs.

Not sure the list is complete...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS scope

Postby erik » Tue Jul 18, 2017 8:00 pm

Ok, so basically it's not going to work. That's a pity.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2244
Joined: Thu Nov 01, 2007 2:41 pm

Re: ALS scope

Postby Hooray » Tue Jul 18, 2017 8:40 pm

pretty much most of the hard-coded stuff going on in $FG_SRC/Viewer should be unaffected basically - I ended up adding draw-masks to get rid of some of these things, which may be another option if/when efforts like ALS may want to override/re-implement certain hard-coded functionality:

http://wiki.flightgear.org/Canvas_Troub ... for_Canvas
Image

Looking at the way Rembrandt is integrated, this is in line with Fred's changes basically
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: ALS scope

Postby icecode » Tue Jul 18, 2017 9:12 pm

What about moving the ALS lighting code to C++ space? Instead of doing the same computations for every fragment, we could do them once per frame on the CPU and store them on gl_LightSource.diffuse and .ambient.
icecode
 
Posts: 709
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: ALS scope

Postby Thorsten » Wed Jul 19, 2017 5:48 am

What about moving the ALS lighting code to C++ space? Instead of doing the same computations for every fragment


This defeats the whole point of ALS, because the result of the computation is usually different for every fragment since it's a function of fragment position (or rather then sunlight path through the atmosphere given the position).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS scope

Postby erik » Wed Jul 19, 2017 7:21 am

Besides that, modern hardware alway does the lighting using shaders in the OpenGL driver.

I as thinking, we could disable the geometry code for the sun and the moon in SimGear and make them AC3D objects in FGData. That would make them ALS ready. Stars I'm less worried about. The biggest problem remains the particle system.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2244
Joined: Thu Nov 01, 2007 2:41 pm

Re: ALS scope

Postby Thorsten » Wed Jul 19, 2017 7:55 am

The moon, I think, is a 3d model already. The sun is a textured quad (to get the corona edges), but I think it'd be quite possible to remove their hard-coded effect settings and replace them by xml-configurable effects, at which point ALS could run shader over them.

The lower quality ALS shaders use the default specular light to save GPU work - however this can be changed.

For naturally non-emissive uses of the thruster flame (like vapour trails), I've suggested to use

/rendering/scene/diffuse/red

as base scene brightness (I've used the same trick for the particle system in multiple places) - so there may be breakage caused by removing that in several aircraft which do make use of the same trick.

Nothing here is unsurmountable, it can all be found and fixed (not quite sure about the particle system...) - but... are the classic light computations really that expensive to justify the effort? I mean, creating configurable effects for sun and moon and merging the particle system into the effect framework are worthy goals in themselves because they're enablers for better sun visuals etc. - I'm just wondering whereas the extra work of actually removing the light computations justifies the expected performance gain.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS scope

Postby erik » Wed Jul 19, 2017 8:17 am

Thorsten wrote in Wed Jul 19, 2017 7:55 am:Nothing here is unsurmountable, it can all be found and fixed (not quite sure about the particle system...) - but... are the classic light computations really that expensive to justify the effort? I mean, creating configurable effects for sun and moon and merging the particle system into the effect framework are worthy goals in themselves because they're enablers for better sun visuals etc. - I'm just wondering whereas the extra work of actually removing the light computations justifies the expected performance gain.

For older, single CPU laptops I would think so. The computations do some fairly complex calculations every frame for which CPU cycles could be better spend elsewhere. For higher end systems it's probably unnoticeable.

But the thought about moving the celestial bodies to FGData was triggered by me remembering that you would like to have shader support for the Sun (or in fact have all FlightGear objects subject to shader support). Not so much to be able to safe some CPU cycles.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2244
Joined: Thu Nov 01, 2007 2:41 pm

Re: ALS scope

Postby Hooray » Sat Sep 02, 2017 3:19 pm

Thorsten wrote:
Erik wrote:the thought about moving the celestial bodies to FGData was triggered by me remembering that you would like to have shader support for the Sun (or in fact have all FlightGear objects subject to shader support). Not so much to be able to safe some CPU cycles.

The moon, I think, is a 3d model already. The sun is a textured quad (to get the corona edges), but I think it'd be quite possible to remove their hard-coded effect settings and replace them by xml-configurable effects, at which point ALS could run shader over them.
[...]

Nothing here is unsurmountable, it can all be found and fixed (not quite sure about the particle system...) - but... are the classic light computations really that expensive to justify the effort? I mean, creating configurable effects for sun and moon and merging the particle system into the effect framework are worthy goals in themselves because they're enablers for better sun visuals etc. - I'm just wondering whereas the extra work of actually removing the light computations justifies the expected performance gain.


This is just a heads-up to say that the recent work on coming up with a Canvas::View element to render scenery views to an offscreen texture in conjunction with the orginal Canvas::Model work to load/display and transform arbitrary 3D models could provide the foundation for re-implementing some of these hard-coded features at the fgdata/base package level.

As a matter of fact, we have also tinkered with a more flexible scheme that renders an additional/alternate scenegraph (e.g. elevation/heightmap for starters) to such a Canvas based display, and in conjunction with support for effects/shaders, this could also be the foundation for implementing an experimental scenery/terrain engine, or even an alternate renderer, on top of OSG concepts previously only available in C++ space (think Rembrandt/deferred rendering).

So, this could be relevant to people interested in simulating flight on other planets

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


Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 2 guests