From: Renk T. <tho...@jy...> - 2012-04-27 06:50:32
|
> 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 |
From: Renk T. <tho...@jy...> - 2012-04-27 07:13:08
|
> 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 |
From: Frederic B. <fre...@fr...> - 2012-04-27 07:17:49
|
> > 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 |
From: Renk T. <tho...@jy...> - 2012-04-27 08:35:00
|
> 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 |
From: Frederic B. <fre...@fr...> - 2012-04-27 09:02:49
|
> > > 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 |
From: Renk T. <tho...@jy...> - 2012-04-27 09:08:58
|
> 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 |
From: Frederic B. <fre...@fr...> - 2012-04-27 09:32:43
|
> > 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 |
From: Renk T. <tho...@jy...> - 2012-04-27 12:02:34
|
> 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 |
From: Frederic B. <fre...@fr...> - 2012-04-27 12:17:05
|
> > 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 |
From: Heiko S. <aei...@ya...> - 2012-04-27 13:52:19
|
> 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 |
From: Renk T. <tho...@jy...> - 2012-04-27 17:30:16
|
> 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 |
From: Chris F. <ch...@ij...> - 2012-04-27 20:46:46
|
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 <tho...@jy...> 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: TDO B. <tdo...@ho...> - 2012-04-27 21:12:57
|
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: ch...@ij... > To: fli...@li... > 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 <tho...@jy...> 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 > > Fli...@li... > > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Vivian M. <viv...@li...> - 2012-04-28 08:16:46
|
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 |
From: Chris F. <ch...@ij...> - 2012-04-28 08:20:02
|
You'll have to elaborate on how 'spin' is special. |
From: Heiko S. <aei...@ya...> - 2012-04-29 11:43:04
|
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 switching advanced weather on and off, switching skydome scattering on and off, playing with the shader settings up to 5.... I don't see any atmosphere effect and skydome scattering when trying different settings, with or without advanced weather. I don't see any effects like we can see here: http://www.flightgear.org/forums/viewtopic.php?f=19&t=9446&start=1230#p156286 And I'm pretty sure, it is not my graphic card! To remember: that how 2.6.0 official release looked: http://www.hoerbird.net/2.6.0.gif What do I miss? Where am I wrong? Do we get something like back with the next release in less than 3 months? Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html |
From: Frederic B. <fre...@fr...> - 2012-04-29 11:51:57
|
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 |
From: Erik H. <er...@eh...> - 2012-04-29 12:54:42
|
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 |
From: Heiko S. <aei...@ya...> - 2012-04-29 12:56:10
|
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 above....and ...and. When I think of our average users about using it....hmmm. 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 |
From: Renk T. <tho...@jy...> - 2012-04-30 09:07:54
|
> 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 above....and > ...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 it....hmmm. 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 |
From: Oliver T. <oli...@go...> - 2012-04-30 09:33:51
|
> 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 |
From: Renk T. <tho...@jy...> - 2012-04-30 11:00:52
|
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 |
From: Heiko S. <aei...@ya...> - 2012-04-30 11:27:00
|
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 |
From: Heiko S. <aei...@ya...> - 2012-04-30 20:48:51
|
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 |
From: Renk T. <tho...@jy...> - 2012-05-01 12:19:38
|
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 |