[Flightgear-devel] Atmospheric Light Scattering
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. But then
Re: [Flightgear-devel] Bug in AIAircraft.cxx line 1104
Hi Nick,
That's correct. It looks like this is actually a leftover from the commented
out debug statement directly below it. Thanks for catching it!
Cheers,
Durk
On 23 Apr 2013, at 15:39, Nick Vatamaniuc wrote:
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
--
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
On Tue, Apr 23, 2013 at 12:38 PM, Renk Thorsten wrote: 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... Fortunately I still have the vertex shader stashed away, but I've lost the effect file. I added additional uniforms to tree.vert: uniform float osg_SimulationTime, WindE, WindN; WindE and WindN are almost certainly /environment/wind-from-[east|north]-fps I think osg_SimulationTime is built in. The actual code to do the translations is this shear code, placed between the rotation and placement in the correct location: // Rotation of the generic quad to specific one for the tree. position.xy = vec2(dot(position.xy, vec2(cr, sr)), dot(position.xy, vec2(-sr, cr))); // Shear by wind. Note that this only applies to the top vertices // [top vert only] [time dependent movement] [seed so trees close together move together] position.x = position.x + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindN; position.y = position.y + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindE; // Move to correct location (stored in gl_Color) position = position + gl_Color.xyz; -- 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] Atmospheric Light Scattering
Le mercredi 24 avril 2013 06:58:41 Renk Thorsten a écrit : 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
[Flightgear-devel] MP Chat text length in FG
Dear List, I noticed a mismatch and want to suggest a fix, or ask for an explanation: In source code I found a max. text length of 256 (bytes) chars in MP server and FG itself. I made some tests and saw that this text length does not work. The text is not being transferred if it gets too long. UDP can transmit 65KB so its out of the game, I think. I have tested with OpenRadar and a FG instance. The max. count of transfered chars is in OR: 128 chars in FG from chat dialog less between 110 and 120. As OR does not care about the chat message length, there seem to be restriction in reception (128 bytes) and sending(~110-120) in FG I know 128 is already a lot if you fly beside typing and reading. But for ATIS messages etc. it is nice, if you don't have to care for some less bytes, which might cause the message is not received. Guess the issue is somewhere in FGs chat message handling... W. -- 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
