Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 23:47:59 Emilian Huminiuc wrote: Fred, One small question, what's with the multiple passes/ shader overrides and al sort of funky stuff (colour mask O.O) going on in terrain-default.eff. It looks like a real mess. I wanted to clear out the unneeded include_fog.vert that crept back in somehow and found that... Or is this an artefact of a messy git merge? Could you please check, or explain? Cheers, Emilian Nevermind, checked the git history, it's itended to be that way since a while ago :) Sorry for the noise having 2 passes is a kind of optimization if done well : first pass rendered with no fancy stuff initialize the depth buffer so that fancy stuff is only computed on visible fragments, because early z-culling can occur. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Only a win if 1) your draw order wrt depth is chaotic and unfixable, and 2) you are fillrate bound ... -- Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
The runway effect parameters override any parameters it has in common with the terrain-default effect (since it inherits from it), it is not a bug, that's how the system is supposed to work. I don't know, it doesn't strike me as consistent. There are two control structures here: Inheritance allows to replace a generic effect with a particular effect given terrain type, for instance it allows to use some shader for terrain, but a special shader for forest. Technique allows to control overall detail level - earlier (more detailed) techniques take precedence before later (usually less detailed) techniques. The problem at hand is that the parsing creates an inconsistent state - the rule what shader is to be run is determined by technique, but the texture it gets to use is determined by inheritance even if the technique numbering says inheritance doesn't play a role. A higher number technique which is correctly recognized as 'not to be used' still gets to set parameters of the technique which actually is used. Needless to say, this is hellishly difficult to figure out (it took me four hours to understand) because there is nothing wrong at all with the structure of terrain-default.eff and yet things don't work. So, for me the expected behaviour would be that technique beats inheritance - special effects can override generic effects for certain landclasses if their technique is lower, but all their information is discarded if the technique is not lower. Forgot to mention the fact that runways have the runway effect applied to them from materials.xml, hence they obey that one and not terrain-default. That's where you are wrong - technique actually beats inheritance for everything except texture unit number (which is what causes the problems) - runways are shaded with what is specified in terrain-default.eff when it comes with a lower technique number than what is specified in runway.eff (that is the case here). The system correctly uses terrain-haze-detailed.* to shade the runway, just the snow texture gets overrideen by what is specified in runway.eff. This is fixable by changing the snow texture unit number in the terrain default, so it doesn't get overridden by the runway settings, or by changing the runway effect itself, and adding another texture unit there for the snow, and an altered technique 4 that caters for the differing texture unit numbers. I know how to fix it, but I don't know how to prevent the next person adding effects to screw it up all over again. The problem is finding an unused texture unit which nobody will overwrite anywhere in any effect file down the line. My favoured solution would be to make the parsing consistent so that shader to be used and texture to be used are taken from the same technique, but if that can't be done or should not be done for some reason I don't yet understand, maybe we can come up with general guidelines about what texture units are assigned for what (basic texture, noise, normal map, alternative textures, snow,...) so that, say, texture unit 5 is always snow and then there's no problem either. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Thus if runway inherits from terrain the actual runway effect as seen by flightgear gets a technique 4 of its own (inherited from the terrain effect). So when the skydome shader is active, it's the technique 4 in this runway effect that is active, which then uses the textures specified in the runway effect, as it's supposed to. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Yes, but what's wrong with making that conditional based on technique number? What functionality would this destroy? Or what is the use of the current setup in which higher techniques overwrite lower techniques? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 07:55:19 Renk Thorsten wrote: No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Yes, but what's wrong with making that conditional based on technique number? What functionality would this destroy? Or what is the use of the current setup in which higher techniques overwrite lower techniques? * Thorsten Every other effect written so far. Better explanation: Think of the parent and the child effect as two property trees. At runtime they get merged, with any paths in the child effect overwriting the same paths in the parent, all under the heading of the child effect. The lower techniques override higher techniques. The functionality is to enable you to use different options in specific conditions that are present in the predicate section of each technique. As you are using them in the terrain effect. It's not the effects that change at runtime between those specific conditions, it's a different technique of the same effect that's used. The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Say you have shaders active, the default effect has a technique that specifies some default shaders to be used. Now you make your own effect, but you want to use different shaders in the same situation; in that case you add a lower numbered technique in your new effect, that by the order of precedence (lower numbers before higher numbers) trumps the technique used in the default, and this new technique specifies the different set of shaders that you want. By putting the sky-dome technique in a low enough place, you ensure that your new technique will not be overwritten and will be lower placed than any other in the child effects' trees, ensuring that those shaders are activated when the sky-dome is active, and that they take precedence over less strict conditions that would activate some other set of shaders/options in one of the other effects. Keep in mind though, that they will then use the merged parameters as they're specified in the child effect (this includes textures). Important note: the *texture n=x* numbers in the parameters section can be as high as you need them, but the *texture-unitunity/unit* numbers in the technique section should be kept =7 as those are the actual texture units as seen by the shader, and some impplementations oanly have 8 texture units available. *y* and *x* don't have to match. In fact you can get very creative and have 3 different *texture n=x1*, *texture n=x2*, *texture n=x3* in the parameters section that are assigned to the same *unity/unit*, each in a different technique, according to different predicates. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Actualy this should read: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same or any stricter condition. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Actualy this should read: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same or any stricter condition. But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 10:53:31 Frederic Bouvier wrote: On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Actualy this should read: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same or any stricter condition. But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers Regards, -Fred I would say it's intended and it's very powerful. We only need to be careful with technique numbers. Take a look at how I worked around the binormal/tangent generator crashing for objects that are not textured in the model-combined effect: by enabling the generator for that technique only in child effects that are supposedly applied *only* to textured objects. All these with only a couple of xml entries, and not requiring a different complete effect. (Ref: Docs/model-combined.eff/)-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wed, May 2, 2012 at 9:53 AM, Frederic Bouvier wrote: But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers In fact, I used just this ability last night to modify the model-default.eff techniques to add an emissive layer for the random buildings. See Effects/buildings.eff -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wed, May 2, 2012 at 9:53 AM, Frederic Bouvier wrote: But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers In fact, I used just this ability last night to modify the model-default.eff techniques to add an emissive layer for the random buildings. See Effects/buildings.eff I hope you added a comment saying that you rely on the numbering of some other technique. I see the maintenance nightmare coming very soon. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 23:47:59 Emilian Huminiuc wrote: Fred, One small question, what's with the multiple passes/ shader overrides and al sort of funky stuff (colour mask O.O) going on in terrain-default.eff. It looks like a real mess. I wanted to clear out the unneeded include_fog.vert that crept back in somehow and found that... Or is this an artefact of a messy git merge? Could you please check, or explain? Cheers, Emilian Nevermind, checked the git history, it's itended to be that way since a while ago :) Sorry for the noise Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hi Heiko, Okay, so cloud and terrain shaders on both detail levels perform okay, but the skydome shader doesn't come on - one can see the mismatch between terrain and sky in the distance, and there's no scattering effect at all in the sky. Which means we need to find the reason why, and that's going to be tricky. Absolutly nothing- no error messages, just the usual .dds-warnings Bugger, I was kind of hoping for that. What was the last version of the skydome shader which did work for you? The one shipped with 2.6? Or anything later? If no one else has a better idea what could be the cause, I would probably send you a skydome.frag in which I comment out several designated blocks which hopefully works - you'd have to activate them one by one and see at which point the shader ceases to work. Interesting Bug I found: http://www.hoerbird.net/LightfieldshaderBug.png Yes, saw it yesterday as well - I know what the cause is. Question to Fred (and other Effect people) - is this a bug or am I misusing the system? What happens is as follows: * the code finds a runway and looks first through terrain-default.eff to see what it should do. It finds, if skydome shader is on and landmass is above 4, a technique 4 telling it to render the runway with terrain-haze-detailed.* * in that technique, it gets the advice to use texture unit 6 for snow * however, parsing further, the code finds an effect with a higher technique declared for runway as well (the rain reflection). In spite of this being not executed because a technique with a lower number is used, this overwrites the texture associated with texture unit 6. * as a result, rainbows instead of snow appear In my naive opinion, that looks a bit like a bug, because a technique with a larger number which isn't used shouldn't be parsed or be able to set textures for what actually is used. But maybe I misunderstand how the system is intended to work. The dull color at ground I mentioned: http://www.hoerbird.net/LightfieldDull.png That's actually a feature you're just not used to - if you have clouds as in your shot, they shade the terrain underneath, which means that the light gets dimmer, desaturates and rotates to a more blue hue. For low sun and clouds drawn to small range, this sometimes looks a bit unrealistic because you can see the sun shining underneath the layer in your shot whereas the shader assumes that the cloud cover you see extends all the way to the horizon. For clear sky or above the clouds, the dull colors go away. The difference is quite a lot - look here for a comparison: http://wiki.flightgear.org/Atmospheric_light_scattering#Light_scattering_during_the_day Hope that helps a bit. I'll get back to you with a skydome test version over the next few days. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Tuesday 01 May 2012 12:19:27 Renk Thorsten wrote: Question to Fred (and other Effect people) - is this a bug or am I misusing the system? What happens is as follows: * the code finds a runway and looks first through terrain-default.eff to see what it should do. It finds, if skydome shader is on and landmass is above 4, a technique 4 telling it to render the runway with terrain-haze-detailed.* * in that technique, it gets the advice to use texture unit 6 for snow * however, parsing further, the code finds an effect with a higher technique declared for runway as well (the rain reflection). In spite of this being not executed because a technique with a lower number is used, this overwrites the texture associated with texture unit 6. * as a result, rainbows instead of snow appear In my naive opinion, that looks a bit like a bug, because a technique with a larger number which isn't used shouldn't be parsed or be able to set textures for what actually is used. But maybe I misunderstand how the system is intended to work. The runway effect parameters override any parameters it has in common with the terrain-default effect (since it inherits from it), it is not a bug, that's how the system is supposed to work. This is fixable by changing the snow texture unit number in the terrain default, so it doesn't get overridden by the runway settings, or by changing the runway effect itself, and adding another texture unit there for the snow, and an altered technique 4 that caters for the differing texture unit numbers. HTH, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Tuesday 01 May 2012 15:33:36 Emilian Huminiuc wrote: The runway effect parameters override any parameters it has in common with the terrain-default effect (since it inherits from it), it is not a bug, that's how the system is supposed to work. This is fixable by changing the snow texture unit number in the terrain default, so it doesn't get overridden by the runway settings, or by changing the runway effect itself, and adding another texture unit there for the snow, and an altered technique 4 that caters for the differing texture unit numbers. HTH, Emilian Forgot to mention the fact that runways have the runway effect applied to them from materials.xml, hence they obey that one and not terrain-default. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
I did try that- after some more tryings with different settings I found out that I didn't know yet that it only works with advanced weather AND at high altitudes (above 10.000ft!!) Agreeing somewhat with Fred, the screenshots don't make it easy to see what is going on, as there is neither strong haze nor low sun where the differences to default are most pronounced. Having said that: To the best of my ability to determine from the screenshots, the skydome shader doesn't work for you (for some yet to be determined reason). As a result, you can see no haze and no change in the sky when on the ground, because the haze from that position would affect mainly the skydome. Since we're looking at close hills and buildings in your shots, the differences in fog for the terrain are not really apparent. As you go to high altitude (and presumably good visibility), more and more of the haze you see is created by the terrain shader rather than the skydome shader, which is why I'm guessing you see better results at high altitude (but then, there should actually be a visible mismatch between sky and terrain if I am correct). And that the shader custom slider has to be set to 4 and aboveand ...and. Actually, no. All that needs to be on is the skydome shader button, no matter altitude or shader settings. When you move water or landmass above 4, the detailed version of the shaders come on. It is possible that the non-detailed version of the shader doesn't run for you either (Emilian told me yesterday of some implementation-specific things which my nVidia unfortunately tolerates without complaint). So my second guess is that you don't have an nVidia card. When I think of our average users about using ithmmm. The GUI is actually rather fool-proof - it switches almost everything which is not compatible with the scheme off no matter where the sliders are and parses only the sliders which are implemented. Your problem is not GUI related. As I've said a few times on this list already, the scheme runs with basic weather in principle, but the default settings may not be appropriate for the actual weather conditions. It's no technical difficulty to change these, but this requires decisions which I don't want to make without any feedback from the maintainers of Basic Weather. Sorry when it does sounded like ranting, but I think there are some other things as well to consider: Not all pilots are flying in such high altitudes- what's about the typically VFR-flyers? And I'm sure that not all pilots here are flying at dusk or dawn. I've done by now about 100 hours of flight in the scheme at pretty much all possible times, weather conditions and altitudes ranging from zero to 150 km. When working correctly, it is probably the most seamless scheme Flightgear ever had (the default scheme doesn't do suborbital flight correctly). For me, at other times and on ground, the colors looks pretty the same like in older FGFS versions before shaders. Not what I expected after read Thorsten's description about his work. Right. We have this in GIT so that others can test and we can sort system-specific issues out. So what I would like you to do is: a) watch the console for any error message from shaders trying to compile but not succeeding b) get me a screenshot from ~20.000 ft with good visibility over land facing the rising sun at dawn with skydome shader on and landmass shader on 3 c) do the same exercise with landmass slider set to 4 Cheers, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Actually, no. All that needs to be on is the skydome shader button, no matter altitude or shader settings. When you move water or landmass above 4, the detailed version of the shaders come on. It is possible that the non-detailed version of the shader doesn't run for you either (Emilian told me yesterday of some implementation-specific things which my nVidia unfortunately tolerates without complaint). So my second guess is that you don't have an nVidia card. I tested last night with win7 and xp using ATI cards (winXP - hd3850, win7 64bit hd5870 tested with all ATI drivers since 11.4 beside the latest) and the skydome shader is crashing fgfs. The crash looks like the crash that occours if i enable the generic shader. No console output. Besides that the fps are better then with the standard weather. This is even more noticeable with bad weater (standard 20fps / advanced 55fps). Oliver -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
I tested last night with win7 and xp using ATI cards (winXP - hd3850, win7 64bit hd5870 tested with all ATI drivers since 11.4 beside the latest) and the skydome shader is crashing fgfs. The crash looks like the crash that occours if i enable the generic shader. No console output. Well, the generic shader code is run in almost any other shader of the scheme, so if that doesn't run, the others won't as well. No idea what could be causing that though - the generic shader code looks really harmless. Besides that the fps are better then with the standard weather. This is even more noticeable with bad weater (standard 20fps / advanced 55fps). Please don't confuse the things - Terrain Haze is quite independent of the Advanced Weather package - you can run one without the other, although I am tuning the interplay between the two quite a bit. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hello Thorsten, First again sorry when it sounded like rant. But I must admit I was dissapointed seeing the results on my system here. Having said that: To the best of my ability to determine from the screenshots, the skydome shader doesn't work for you (for some yet to be determined reason). As a result, you can see no haze and no change in the sky when on the ground, because the haze from that position would affect mainly the skydome. Since we're looking at close hills and buildings in your shots, the differences in fog for the terrain are not really apparent. As you go to high altitude (and presumably good visibility), more and more of the haze you see is created by the terrain shader rather than the skydome shader, which is why I'm guessing you see better results at high altitude (but then, there should actually be a visible mismatch between sky and terrain if I am correct). Thanks for that detailed explanation! I didn't see any error messages in the console so I guessed there shoulden't be any shader-problem, but good to know that there should be a change to see from the ground. Actually, no. All that needs to be on is the skydome shader button, no matter altitude or shader settings. When you move water or landmass above 4, the detailed version of the shaders come on. It is possible that the non-detailed version of the shader doesn't run for you either (Emilian told me yesterday of some implementation-specific things which my nVidia unfortunately tolerates without complaint). So my second guess is that you don't have an nVidia card. I actually have a new nVidia Geforce GTX460 with 1GB RAM. So that should be not the problem. I have tried with the skydome shader button on, and the effect was even worse. All colors went dull. So indeed for any reasons the shader seems not to work here. The GUI is actually rather fool-proof - it switches almost everything which is not compatible with the scheme off no matter where the sliders are and parses only the sliders which are implemented. Your problem is not GUI related. After your description it seems indeed so. As I've said a few times on this list already, the scheme runs with basic weather in principle, but the default settings may not be appropriate for the actual weather conditions. It's no technical difficulty to change these, but this requires decisions which I don't want to make without any feedback from the maintainers of Basic Weather. Which should be no problem, as from reading here on the list from time to time I can see that it is even wished to make this work available for Default Weather as well. Not all people can run Advanced Weather without having a bigger unusuable fps impact; on my system here (DualCore 2,6Ghz with 4 GB RA) framerates are now worse than with Default Weather. (That was different to last autumn...) I've done by now about 100 hours of flight in the scheme at pretty much all possible times, weather conditions and altitudes ranging from zero to 150 km. When working correctly, it is probably the most seamless scheme Flightgear ever had (the default scheme doesn't do suborbital flight correctly). I can still remember my first and second flight as pax in a glider 15 years ago. The scattering effect was even visible from 1000-1500ft AGL, visibility wasn't that great as you show in your screenshots. (less than 100km visibility) I actually had the impression from the various sceenshots and my own experience that it only works in higher altitudes. Sorry for misinterpreting. So what I would like you to do is: a) watch the console for any error message from shaders trying to compile but not succeeding b) get me a screenshot from ~20.000 ft with good visibility over land facing the rising sun at dawn with skydome shader on and landmass shader on 3 c) do the same exercise with landmass slider set to 4 Good, I will provide this this evening/ tomorrow, as I'm probably not at the computer until later evening today. Cheers Heiko -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hello Thorsten, a) watch the console for any error message from shaders trying to compile but not succeeding Absolutly nothing- no error messages, just the usual .dds-warnings b) get me a screenshot from ~20.000 ft with good visibility over land facing the rising sun at dawn with skydome shader on and landmass shader on 3 http://www.hoerbird.net/Lightfieldshader1.png c) do the same exercise with landmass slider set to 4 http://www.hoerbird.net/Lightfieldshader2.png Interesting Bug I found: http://www.hoerbird.net/LightfieldshaderBug.png The dull color at ground I mentioned: http://www.hoerbird.net/LightfieldDull.png All with a clear checkout, Hudson Build #447, TerraSync-scenery, default values I hope this is helpfull Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hi Heiko, What do I miss? Where am I wrong? Do we get something like back with the next release in less than 3 months? In case you didn't notice, Thorsten screenshots are from altitude, not from the ground, with more clouds on screen, and at dusk or dawn. Put yourself in the same conditions to do the comparison Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Sun, 2012-04-29 at 12:42 +0100, Heiko Schulz wrote: Hello, I updated data today with the latest Hudson Build. Regarding the Terrain Haze v1.3. Lightfield I must admit, I'm really dissapointed. Somehow I don't get the images presented on the forum. Or am I wrong, and all this only works with 2.6.0 instead of current GIT? That how it looks here: http://www.hoerbird.net/2.7.0Lightfield.gif http://www.hoerbird.net/2.7.0Lightfield2.gif You can see a clear difference (albeit subtle) in the clouds but the sky dome scattering itself doesn't seem to work on your system. Erik -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hello Fred, In case you didn't notice, Thorsten screenshots are from altitude, not from the ground, with more clouds on screen, and at dusk or dawn. Put yourself in the same conditions to do the comparison I did try that- after some more tryings with different settings I found out that I didn't know yet that it only works with advanced weather AND at high altitudes (above 10.000ft!!) And that the shader custom slider has to be set to 4 and aboveand ...and. When I think of our average users about using ithmmm. Sorry when it does sounded like ranting, but I think there are some other things as well to consider: Not all pilots are flying in such high altitudes- what's about the typically VFR-flyers? And I'm sure that not all pilots here are flying at dusk or dawn. For me, at other times and on ground, the colors looks pretty the same like in older FGFS versions before shaders. Not what I expected after read Thorsten's description about his work. Sorry for complaining Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Chris It would be interesting to use skeletal animation to get rid of some of the batch spam with complex multipart models. It wouldn't even necessarily require reworking the model data -- we could initially do the merge and bone attachment when a model is loaded. What are the animation cases? So far I have: - Things move or rotate - Things get removed completely Both of these are representable easily in a matrix palette (removal via w=0); Anything else? I've been waiting for this for years. I animated a couple of pilots way back using the available animations, but haven't done any since - just too much like hard work! Additional animation - spin (special case of rotate) Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
You'll have to elaborate on how 'spin' is special. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
The direct link to the merge request is usually handy. Will do next time. Effects/terrain-default.eff has two techniques number 4. They seem similar Could you check ? Aarg... GIT strikes again. The two blocks with technique 4 are identical copies - one of them can go. Must be my screwup in merging the file... One short comment on the shaders, texture lookups inside branches gives undefined results, so any texture2D() call should be pulled outside the branches. (http://hacksoflife.blogspot.com/2011/01/derivatives-ii-conditional- texture.html) Thank you for the info - that's good to know (although admittedly I have to do some reading trying to understand what 'that' precisely is - the linked article is a bit opaque for me). Seems there's a lot to learn about the hidden secrets of GLSL... Since this doesn't look like a crippling issue (it seems to work on my card just fine, it potentially affects only higher detail settings,...) I would like to take the time and understand what is going on before making any changes. The reason is that things end up in conditionals usually because I tested them to have better performance, so just pulling them out would degrade performance again. The article seems to suggest a different syntax to do conditional texture lookup inside an if clause, so I would like to look into that and compare performance in some benchmarks. I would also be intersted if anyone is actually seeing any texturing artefacts (should be mainly the snow effect) caused by the issue, so that I can see if I implemented a fix correctly, because on my system it's running fine as it is. Thanks, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Thorsten, One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. I usually commit Thorsten's work. Will have a look in the next days. The direct link to the merge request is usually handy. Effects/terrain-default.eff has two techniques number 4. They seem similar Could you check ? It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif Regards -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif The only place models get the effect is if they go via Effects/model-default.eff if they're using their own effect file they are not in the scheme. In addition, neither the random buildings nor the random vegetation in the screenshot are currently implemented in the scheme - that makes it a bit hard to see if there's something going wrong in the screenshot, random buildings and static buildings should have different lighting to dome degree. Do they respond to fog (ground haze slider in Advanced Weather)? Also, what if you simply use Effects/model-default.eff as currently on master (shouldn't really be much of a difference)? I have observed once that models came out very dark, that was fixed by switching the shader on and off, apparently some glitch which I could never reproduce. Spending 3 minutes with Effects/model-default.eff in the merge request branch doesn't reveal anything odd. So, I'm a bit at a loss. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Thorsten, One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. I usually commit Thorsten's work. Will have a look in the next days. The direct link to the merge request is usually handy. Effects/terrain-default.eff has two techniques number 4. They seem similar Could you check ? It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif That problem goes away if landmass shader is disabled. The strange thing is that when set to some value, the problem appears but as soon as you click on the landmass slider, without changing the value, the problem goes away too. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif The only place models get the effect is if they go via Effects/model-default.eff if they're using their own effect file they are not in the scheme. I was speaking about the terminal, not the random buildings. But you already saw my previous message :) -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Presumably all these effects could actually be done as one screenspace pass? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Presumably all these effects could actually be done as one screenspace pass? Please elaborate -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
I usually commit Thorsten's work. Will have a look in the next days. This is in git now, with the duplicated technique removed -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Friday 27 April 2012 06:50:22 Renk Thorsten wrote: Thank you for the info - that's good to know (although admittedly I have to do some reading trying to understand what 'that' precisely is - the linked article is a bit opaque for me). Seems there's a lot to learn about the hidden secrets of GLSL... Since this doesn't look like a crippling issue (it seems to work on my card just fine, it potentially affects only higher detail settings,...) I would like to take the time and understand what is going on before making any changes. The reason is that things end up in conditionals usually because I tested them to have better performance, so just pulling them out would degrade performance again. The article seems to suggest a different syntax to do conditional texture lookup inside an if clause, so I would like to look into that and compare performance in some benchmarks. I would also be intersted if anyone is actually seeing any texturing artefacts (should be mainly the snow effect) caused by the issue, so that I can see if I implemented a fix correctly, because on my system it's running fine as it is. Thanks, * Thorsten Found the original article describing the issue http://www.opengl.org/img/uploads/pipeline/pipeline_001.pdf page 3, New Texture Functions with Awkward Names to Avoid Ugly Artifacts The new functions require the extensions present, and a port of the shader to glsl 1.40. And even then they may or may not be properly supported by different cards. So the simple solution is to pull them out of the conditional. I have hit this with the transition shader, it worked fine on different cards, but it blew up the mipmap lookup on a card similar to mine: http://flightgear.org/forums/viewtopic.php?f=5t=13513hilit=dds+textures#p136566 check the cornrows in the distance on the forest areas. The usage of custom miplevels made it more obvious and easy to spot, but the effects of these can range from a small discontinuity in the features to the shader eroring on some other implementations. Regards Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
That problem goes away if landmass shader is disabled. The strange thing is that when set to some value, the problem appears but as soon as you click on the landmass slider, without changing the value, the problem goes away too. Is this anything I could have caused? Because I have no idea where to look for a potential fix. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
That problem goes away if landmass shader is disabled. The strange thing is that when set to some value, the problem appears but as soon as you click on the landmass slider, without changing the value, the problem goes away too. Is this anything I could have caused? Because I have no idea where to look for a potential fix. I have no idea too. It looks like an uninitialized value that get one when we click on the slider. Do you reproduce the problem I see ? What I did was : 1. open the shader custom configuration and put the landmass slider to the right. 2. stop FG with the quit menu to record my settings, 3. restart at KSFO and see the maintenance and terminal buildings with weird lighting. 4. open the shader dialog and click on the landmass slider thumb: the lighting comes back. That doesn't happen if the slider in in the left position. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
I have no idea too. It looks like an uninitialized value that get one when we click on the slider. Do you reproduce the problem I see ? For some (yet to be determined) reason the shader settings are not archived on Flightgear exit in my local devel branch since my next-to-last update three weeks ago. That could explain why I never really saw the problem, because I start with landmass slider initialized to 3 and always shift it to 4 by hand - so I always touched it in my tests before the shader came on. I'll try later today to set the shader quality via commandline and see what happens then (I'm at the wrong computer to try at the moment...) * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
I have no idea too. It looks like an uninitialized value that get one when we click on the slider. Do you reproduce the problem I see ? For some (yet to be determined) reason the shader settings are not archived on Flightgear exit in my local devel branch since my next-to-last update three weeks ago. That could explain why I never really saw the problem, because I start with landmass slider initialized to 3 and always shift it to 4 by hand - so I always touched it in my tests before the shader came on. I'll try later today to set the shader quality via commandline and see what happens then (I'm at the wrong computer to try at the moment...) Maybe you already know that, but closing the window using the windows manager close decoration bypass setting saving here. The default value in preferences.xml is 1, so if you start at 3, either you changes preferences.xml locally, or you have your private settings loaded. Maybe they are now read-only. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Do you reproduce the problem I see ? Okay, found the problem with userarchive and eliminated it Now I see the same thing you describe, the model shader doesn't start up correctly, but all goes well once one just clicks the slider. The model shader doesn't seem to be doing anything at all, I can't fog the buildings either. I wonder why the terrain shading starts up the right way though - if any parameters passed to the shader would not be ready, then the terrain should show the same problem, but that isn't happening. Btw - with the recent GIT, I now get Rembrandt working with --prop:/sim/rendering/no-16bit-buffer=true in the commandline and a shadow map no larger than 4096x4096. I'm getting ~9-10 fps out at KSFO, about 14 in low vertex count situations like TNCM or a carrier - is that in the expected range? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Do you reproduce the problem I see ? Okay, found the problem with userarchive and eliminated it Now I see the same thing you describe, the model shader doesn't start up correctly, but all goes well once one just clicks the slider. The model shader doesn't seem to be doing anything at all, I can't fog the buildings either. I wonder why the terrain shading starts up the right way though - if any parameters passed to the shader would not be ready, then the terrain should show the same problem, but that isn't happening. This doesn't happen when you click on another slider or when we start at 1. Should be something specific to landmass. Btw - with the recent GIT, I now get Rembrandt working with --prop:/sim/rendering/no-16bit-buffer=true in the commandline and a shadow map no larger than 4096x4096. I'm getting ~9-10 fps out at KSFO, about 14 in low vertex count situations like TNCM or a carrier - is that in the expected range? Yes. You can disable shadows and see what is the delta in fps. Usually I get 5 more. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Btw - with the recent GIT, I now get Rembrandt working with --prop:/sim/ rendering/no-16bit-buffer=true in the commandline and a shadow map no larger than 4096x4096. I'm getting ~9-10 fps out at KSFO, about 14 in low vertex count situations like TNCM or a carrier - is that in the expected range? Let me correct you: not the vertice count is the bottleneck in Rembrandt and FlightGear- but objects number! Test it yourself: - create a simple cube in Blender (8 vertices) - duplicate in Object mode several times ( I did it around 1000x times!) So we have a model containing a large number of objects and 8000 vertices all about. - save it as .ac - used the ufo and replaced the UFO-model with the new object, and start FlightGear in Rembrandt mode Then I used the same model, but joined all 1000 objects together, so got a model with just one object but still 8000 vertices. I started at Kufstein/ LOIK with the CustomScenery provided by Christian Schmidt, detailed scenery but away from LOWI. The One-Object-model gave me full framerate of 60fps, the 1000 Objects model gave me about 20 and less And thats one reason why LOWI or other aircraft are quite difficult for some. They contain a lot of models. But each model is splitted up into several objects. Some are need for animation, but a lot not. Especially aircraft with complex cockpits and detailed instruments, especially digital displays not made using 2d-layers, naturally uses a lot of objects, which will then slow down. Of course such instruments doesn't need to cast shadows. So there will be another speed up when Fred is able to get back the no shadows-tag. And there is something else which can help: Fred made the shadows-cascade configurable at runtime. Not only you can improve the shadow quality with (smaller edges so it looks quite sharp)at close distance, you can also set the overall distance of the shadows with. I'm sure Fred can tell us a bit more about, but I found it already very helpfull! Cheers Heiko P.S. Sorry, the no subject posting by me was made accidently- to quick hitting the button. still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
This doesn't happen when you click on another slider or when we start at 1. Should be something specific to landmass. Tenuous, but: Terrain and models are sent to the same shader code (terrain-haze.*) by the effect file technique 5. To switch the detailed terrain rendering on, I used the landmass slider (since I remember snow first being available under landmass) - so that decides if terrain and models use the same or different shaders - if quality is 4, then terrain-haze-detaild.* is used for terrain but still terrain-haze.* by models (which shouldn't get snow, are not large enough for structured fog and might be dust-free). That makes the landmass slider special. What I don't understand is why this should fail specifically for models and work for terrain and why it should fail specifically at startup but not when you touch the slider. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
It would be interesting to use skeletal animation to get rid of some of the batch spam with complex multipart models. It wouldn't even necessarily require reworking the model data -- we could initially do the merge and bone attachment when a model is loaded. What are the animation cases? So far I have: - Things move or rotate - Things get removed completely Both of these are representable easily in a matrix palette (removal via w=0); Anything else? -- Chris On Sat, Apr 28, 2012 at 5:30 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: This doesn't happen when you click on another slider or when we start at 1. Should be something specific to landmass. Tenuous, but: Terrain and models are sent to the same shader code (terrain-haze.*) by the effect file technique 5. To switch the detailed terrain rendering on, I used the landmass slider (since I remember snow first being available under landmass) - so that decides if terrain and models use the same or different shaders - if quality is 4, then terrain-haze-detaild.* is used for terrain but still terrain-haze.* by models (which shouldn't get snow, are not large enough for structured fog and might be dust-free). That makes the landmass slider special. What I don't understand is why this should fail specifically for models and work for terrain and why it should fail specifically at startup but not when you touch the slider. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Well, if you introduce skeletal animation, I'd add: things flex (wings on a glider, but also the arms of a pilot) things scale and morph (drag chutes. Morph targets might work better?) and perhaps in the future, things link two objects with a flexible chain, like the aerotow. but that is wishful thinking Date: Sat, 28 Apr 2012 08:46:37 +1200 From: chr...@ijw.co.nz To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Terrain Haze v1.3 It would be interesting to use skeletal animation to get rid of some of the batch spam with complex multipart models. It wouldn't even necessarily require reworking the model data -- we could initially do the merge and bone attachment when a model is loaded. What are the animation cases? So far I have: - Things move or rotate - Things get removed completely Both of these are representable easily in a matrix palette (removal via w=0); Anything else? -- Chris On Sat, Apr 28, 2012 at 5:30 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: This doesn't happen when you click on another slider or when we start at 1. Should be something specific to landmass. Tenuous, but: Terrain and models are sent to the same shader code (terrain-haze.*) by the effect file technique 5. To switch the detailed terrain rendering on, I used the landmass slider (since I remember snow first being available under landmass) - so that decides if terrain and models use the same or different shaders - if quality is 4, then terrain-haze-detaild.* is used for terrain but still terrain-haze.* by models (which shouldn't get snow, are not large enough for structured fog and might be dust-free). That makes the landmass slider special. What I don't understand is why this should fail specifically for models and work for terrain and why it should fail specifically at startup but not when you touch the slider. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terrain Haze v1.3
I've just created a merge request containing the recent work I've done for the haze shaders (haze in water shader, dust effect, Mie scattering on clouds, ...). The procedure described in the wiki to create a merge request did not work for me, I could not push a local branch containing my changes to remote, it just pushed master to master, but I don't want to make any commits to my local master branch. Hooray helped me find the command to create a remote branch containing my changes, so I used that for the merge request. Maybe someone who knows these things properly can have a look at the wiki? (Also, please don't kill me if there's something wrong - I'm trying to learn how to do this). Thanks, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On 26 Apr 2012, at 13:20, Renk Thorsten wrote: I've just created a merge request containing the recent work I've done for the haze shaders (haze in water shader, dust effect, Mie scattering on clouds, ...). The procedure described in the wiki to create a merge request did not work for me, I could not push a local branch containing my changes to remote, it just pushed master to master, but I don't want to make any commits to my local master branch. Hooray helped me find the command to create a remote branch containing my changes, so I used that for the merge request. Maybe someone who knows these things properly can have a look at the wiki? (Also, please don't kill me if there's something wrong - I'm trying to learn how to do this). One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. I usually commit Thorsten's work. Will have a look in the next days. The direct link to the merge request is usually handy. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Thursday 26 April 2012 12:20:36 Renk Thorsten wrote: I've just created a merge request containing the recent work I've done for the haze shaders (haze in water shader, dust effect, Mie scattering on clouds, ...). The procedure described in the wiki to create a merge request did not work for me, I could not push a local branch containing my changes to remote, it just pushed master to master, but I don't want to make any commits to my local master branch. Hooray helped me find the command to create a remote branch containing my changes, so I used that for the merge request. Maybe someone who knows these things properly can have a look at the wiki? (Also, please don't kill me if there's something wrong - I'm trying to learn how to do this). Thanks, * Thorsten One short comment on the shaders, texture lookups inside branches gives undefined results, so any texture2D() call should be pulled outside the branches. (http://hacksoflife.blogspot.com/2011/01/derivatives-ii-conditional- texture.html)-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Thorsten, One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. I usually commit Thorsten's work. Will have a look in the next days. The direct link to the merge request is usually handy. Effects/terrain-default.eff has two techniques number 4. They seem similar Could you check ? Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
