[Flightgear-devel] Atmospheric Light Scattering

2013-04-23 Thread Renk Thorsten

It occurred to me yesterday that there seems to be a major misunderstanding in 
the way Atmospheric Light Scattering (ALS) is perceived by different people. So 
in order to avoid future misunderstandings, let me try to clarify my side once 
again.

Vivian:

> Do we need to go down this road? We are breaking more and  
> more for minimal gains. Did we ever restore the wake effect on the Carrier  
> with Atmospheric Light Scattering?

Emilian (a while ago):

> I have nothing about the core of the Advanced weather engine, I have an issue 
> of how you interact with it, and how it interacts with other parts of the 
> whole system... and in my view this is broken. 
 
> I also have nothing against the idea of the atmospheric scattering, I have an 
> issue with how it's done, which is suboptimal in my view... and again of how 
> you can interact with it/ how it affects other systems, and how it's affected 
> by 
> other systems.

The common theme here is the perception that something is broken, which is 
naturally not my perception. For instance, the fact that ALS doesn't have a 
wake shader effect indicates its brokenness the same way as the fact that the 
default rendering doesn't have procedural texturing working - which is to say, 
not at all. 

Vivian might correct me, but I think I finally understand where that notion 
comes from. I think it comes from the view that ALS is in essence just another 
way to compute fog and light for what the default rendering scheme does, and 
from this perspective, any effect that doesn't work is indeed broken.

The original plan was indeed to implement things as just different fog and 
light, there is still the parameter 'fog-type' in the effects which would 
support such an implementation, and there was a 6 months window during which 
Emilian and Vivian had the opportunity to implement it that way. As this didn't 
happen (for whatever reason) I decided to ask for some help and Fred kindly 
told me how to implement it as a different rendering framework (i.e. loading a 
whole different effect rather than a different fog shader only).

So, from where I stand, that decision is done and it is now a different 
rendering framework, which means clean slate, all effects have to be written 
from scratch, with all the pros and cons to that (which we might debate 
endlessly). So since this window of opportunity to start from scratch happened, 
I took the opportunity to address a few things I saw as shortcomings in the 
default rendering framework we had. Just to give a few examples:

* Environment interfacing:

Emilian's view that the way ALS and Advanced Weather interact with the rest is 
broken is... bold. Just to give an example for how he addressed the interface, 
for instance the water shader needs to know the amount of reflected light at 
the water surface in order to compute reflection.

Emilian's and Vivian's version of the water sine shader solves this by passing 
the cloud layer configuration settings of Basic Weather to the shader and then 
compute in the fragment shader from that the amount of light. This means that 
a) Advanced Weather has no chance (even conceptually) of ever passing the 
correct information to the shader since it doesn't use the Basic Weather config 
properties to create clouds and my understanding is that it is even impossible 
to write these properties without actually generating visible clouds 
interfering with what Advanced Weather does, and that b) a quantity which 
changes in Basic Weather once a few minutes (when a new METAR comes in) is 
computed about 60 million times each second. I may not be a rendering wizard, 
but this doesn't sound like the way to implement an environment interface to 
me. 

My supposedly broken interface references a single property 'light reaching the 
ground'  for the same purpose. That property isn't native to the weather 
system, it can be set by hand with the browser without affecting anything else 
but the shader or be computed by any weather system currently running, i.e. 
shader control parameters are explicitly and always separated from native 
weather system parameters. This means the computation can be done if and only 
if needed, and the interface doesn't prefer one weather system over the other.

* Consistency

I've witnessed quite a few forum discussions with people complaining that they 
didn't think selecting higher quality shader settings would give them higher 
quality visuals (usually this was about the crop and forest overlay texture 
effects which some like and some don't - I have my opinion which is irrelevant 
here). Likewise, snow and fog were not always consistent across landclasses (I 
believe this is fixed now).

Starting from scratch offered the opportunity to organize quality settings with 
a clear idea in mind, using a consistently selected set of effects. Now, 
consistent doesn't necessarily mean superior, it just says it's all my idea of 
visual quality, not a mixture of different ideas.  B

[Flightgear-devel] Bug in AIAircraft.cxx line 1104

2013-04-23 Thread Nick Vatamaniuc
I think I found a bug in AIAircraft.cxx:

http://gitorious.org/fg/flightgear/blobs/next/src/AIModel/AIAircraft.cxx#line1104

"if (trafficRef)" statement should be using {}, otherwise heading update 
doesn't get executed if trafficRef is NULL.

-Nick


--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Tree issues

2013-04-23 Thread Renk Thorsten
> Actually, I had this working very nicely a couple of months ago - using  
> a sine function on time multiplied by wind factor to shift the top  
> texture coordinates so the top of the trees move.  I even had a nice  
> larger scale effect to produce the sort of wave affect you see across  
> the tree tops
>
> However to be visible at normal ranges (500m+) the wind had to be  
> absolutely howling and shifting the tree tops many meters, so it really  
> didn't seem worth the  minor computational cost.

Oh, do you still have that somewhere? I would love to play with this 
implemented in an optional  high-quality tree shader - I could probably also 
add some grass movement by translating the grain texture or the hires noise 
with time into the wind direction...

* Thorsten
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Tree issues

2013-04-23 Thread Stuart Buchanan
On 23 Apr 2013, at 07:22, Renk Thorsten  wrote:
>> Stuart, is it possible to pass somehow the info what trees are deciduous? 
>> I've done some testing, and I can selectively pick 'green' hue in the shader 
>> and color-rotate these pixels to autumn colors, but this is not sensitive 
>> enough to key on the difference between leaf and needle - if we had that, we 
>> could have autumn colors in addition.

Yes. If we put the deciduous trees at the beginning of the texture strip I can 
pass through information on the fraction of trees that are deciduous as a 
uniform and you can compare the x texture coordinate against that. 

At most a couple of lines of c code. 


> 
>> Then "fall" and "windy" could be combined with particles (?) to simulate  
>> wind blown leaves and dynamically painting the foliage part of the  
>> texture with alpha to make leaves fall off on windy weather..? ;) Kinda  
>> special case and maybe not worth the effort but might be quite awesome  
>> jaw-dropper on the right moment.. ;-)
> 
> Yes, let's forget about spending all the framerate for flight and do 
> realistic vegetation - trees and grass should also move in the wind :-) (I 
> like the idea in principle because it's just mad enough to be charming...) 

Actually, I had this working very nicely a couple of months ago - using a sine 
function on time multiplied by wind factor to shift the top texture coordinates 
so the top of the trees move.  I even had a nice larger scale effect to produce 
the sort of wave affect you see across the tree tops

However to be visible at normal ranges (500m+) the wind had to be absolutely 
howling and shifting the tree tops many meters, so it really didn't seem worth 
the  minor computational cost. 

-Stuart

> 
> * Thorsten
> --
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service 
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel