Hi Vivian,

> ALS is very impressive work, but things broken? Have you forgotten the  
> flag shader (now fixed), wake effect and rainbow effect? I don't have a
> particular problem with these and hope that they will be fixed  
> eventually, although I note that do you seem to have raced on to other things 
> while
> leaving the wake effect unfixed for some time. I rather fear that that's
> just going to get lost in the noise and general excitement over the  
> latest bit of eye-candy.

That is what I tried to explain in length. My definition of broken is 'used to 
work, there was a change, now doesn't work'. What is yours?

The wake effect used to work in default, and now still does. The wake effect 
never worked in ALS and now still doesn't. There's nothing broken here, you are 
talking about non-existing features and a feature request to implement them. 
Which is very different from breaking existing things.

To give you the reverse example - procedural texturing works in ALS but not in 
Rembrandt  - so does this imply it's broken in Rembrandt? Cloud shadows don't 
work in either Rembrandt or ALS - does that imply we've broken them? Nope - 
they never existed, and you can make a feature request to implement them.

In the event, your feature request for the wake effect is noted, but not my top 
priority - I prefer to race on to the next bit of eye candy (as you put it) 
because the wake effect is a very localized effect, whereas I want to address 
some world-wide stuff which affects a few billion pixels more first. You're 
welcome to implement it yourself, and I'll be happy to assist you if that is 
needed.

To call a non-existing feature with a feature request attached 'broken' 
generates a completely wrong impression and a sense of urgency which really 
isn't there.

> I think a more general concern would be that we seem to be developing 3  
> or 4
> different Flightgears, in which different things work or not as the case
> might be:
>
>       Rembrandt
>
>       Basic weather/Advanced Weather
>
>       Atmospheric  Light Scattering (ALS)

This may be a question of philosophy, but I don't think OpenSource fares badly 
with this approach in general. As a Linux user I get a choice between Gnome, 
KDE and a host of other desktop environments - and I rather like that, I can 
pick what suits me best. As an aircraft developer, I can pick JSBSim or YaSim, 
whatever suits me best.  So why should we not offer different rendering 
approaches dependent on what the user wants to burn the framerate for? I don't 
see this at all as a problem, I rather see it as a huge opportunity. We can 
ship one rendering approach for the low end graphics cards and are then not 
restricted in what we offer for the high end. How exactly is that a bad thing? 

> As a developer I have only just finished making my models Rembrandt
> compatible, and I don't know if I will ever be able to actually make use
> Rembrandt facilities in all of them.

You'll have noticed that the ALS ubershader (short of inserting the tangent, 
normal and binormal attribute for normal maps which I understand really _must_ 
be airplane-side) works out of the box without any action required in ALS. So 
there is no need to make your models ALS compatible, this is not a real 
problem, but a hypothetical one. The worst case by the way is not that the 
aircraft can't be flown as in Rembrandt, because you can't see out of the 
cockpit, the worst case is that your normal map doesn't work.

> As I understand it, ALS will include modelling facilities which will not
> work in the other flavours of FG. How is this meant to be used? 

Optionally. 

*sigh* When you and Emilian wrote the default ubershader, it provided new 
features. These were offered to the airplane developers as options - it was 
their choice to make use of them or not. Now ALS offers an ubershader which 
might get additional features. There are offered to airplane modellers as 
options. Just why is it okay if you do it, but problematic if I do it?

Yes, they may not work in Rembrandt - and Rembrandt has AO, and bloom, and real 
internal light sources which do not work in other frameworks. So not every 
framework has the same visuals. Why is this a problem?

> In an ideal world everything would work and be
> compatible with everything else.

I don't see how any progress could be made that way. I don't see how Rembrandt 
could have been made requiring that it must be completely compatible with 
existing technology and aircraft definitions. We used to characterize the 
atmosphere by a fog density and a fog color. It's beyond me how one could make 
ALS by requiring the same thing. JSBSIm has updates, they break some aircraft, 
developers fix it - somehow I miss all the complaints about this (and JSBSim 
updates actually have the potential to break aircraft in the sense of rendering 
them non-functional, not in the sense of bumpmapping not working).

Just imagine computers were required to be able to run DOS nowadays... Just 
imagine modern Windows software were required to be able to run on DOS...


> What are aircraft developers and/or users meant to make of this ?

As I said above, that's a hypothetical issue. In reality, the aircraft and 
models rendered with the ubershader just work with ALS because the shader uses 
exactly the same configuration, so there's that. Aircraft not using the 
ubershader do not get nice effects, but then again, Emilian when he still was 
active in the forum was busy telling people that older effects are deprecated 
and they should be using the ubershader - so when exactly did this 
recommendation become bad?

> As to Emilian's concerns, I don't really understand the technical  
> details,  but I do know that he felt that his advice and expertise was being  
> ignored  with the result that FG was headed in the wrong direction

Well, there it goes again. The 'wrong direction' - what is that? Who gets to 
decide it? How can an optional feature push something into the wrong direction? 
What is the concrete problem we're talking about? You don't understand 
exactly... But somehow, there must be something to it, right? And so, a vague 
impression remains and we're back to rumormongering.

> Perhaps you received contrary advice, or
> considered that his advice wasn't of value, but we never had that debate
> IIRC. 

The concrete advice I received from Emilian I usually followed up - either by 
following it and implementing it, or by doing some background reading, 
implementation testing and discarding it when I made up my mind that he wasn't 
right. The objections in the end seemed to be rather unspecified and general 
though - the 'wrong way' as you put it.

> Oh - and btw the ALS still shows up a tear in the skydome that we have  
> had right from the beginning.

Yes - it's not in the shader as far as I can test, which means I can't fix it. 
I suspect it's in the geometry, which is generated god knows where, I've posted 
two analyses here and in the forum, people know about it - so that's the limit 
of my expertise, sorry. I recognize that a fix is needed, but I'm unable to do 
it.

> I thought perhaps it would be helpful if a native English speaker tried  
> to put things in perspective

Yes - as I suspected, it's about (from my view) unrealistic expectations. 
You're somehow fine with the fact that we have JSBSim and YaSim (and possibly 
UIUC - does this still work?) to drive FDMs - so it's okay that FG is open 
here. So why are openness and choice suddenly bad when we come to rendering? 
Why do you expect that ALS must support the effects which default supports, but 
not that Rembrandt must support what ALS does? I don't see you arguing with 
Fred that Rembrandt broke procedural texturing - why's that? I didn't see you 
arguing with Fred that you had to make aircraft Rembrandt-compatible - now 
you're arguing with me that you might have to make aircraft ALS compatible 
despite the fact that you actually don't have to?  I'm not getting this, it's 
not a consistent position.

* 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

Reply via email to