Re: [Flightgear-devel] Terrain self-shading
On Sun, Apr 14, 2013 at 10:41 PM, Stuart Buchanan wrote: As it happens, I'm part way through a change that would allow varying snow- and leaf- cover without having to load different textures, so trees above the snowline could be snow covered while those below are not. This will increase the size of the textures to 512x512, while an individual tree will remain on 128 pixels tall. This is now checked in. Tree foliage is now consistent with the experimental Season slide on the Environment Setting dialog (deciduous trees shed their leaves towards late autumn) and the snow line (trees above the snow-line have a small covering of snow). Of course, we really should only add snow cover to the trees if the snowfall is recent and there isn't much wind, so perhaps we should just have summer/winter variants and no snow-covered... to be discussed. There are changes to both simgear and data for this change. Picking up one or other results in very odd looking trees :). This retires the -summer.[png|dds] and -winter.[png|dds] variants, which have been removed. Those creating tree textures for regional project will now need to follow the new format. I'll update the next newsletter to ensure that this information is distributed. On Tue, Apr 16, 2013 at 7:22 AM, Renk Thorsten wrote: Just to be clear - if we had textures, this is something I would do the work for since I suggested it, I'm not expecting Stuart to do this for me :-) (This is not to imply that I would object against Stuart giving a try, but as long as I can follow up an idea I like myself, I try not to fill someone else's to-do list). That's fine. So I would suggest to implement this as a high-quality option for those who have the hardware to crunch substantial fragment shaders and leave the current implementation as a fallback. That sounds reasonable, though the current implementation has changed in the meantime :). -Stuart -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved Basic Weather integration with Atmospheric Light Scattering
Stuart On Fri, Apr 19, 2013 at 9:18 AM, Vivian Meazza wrote: I still use basic weather with mp so that I get the same clouds in both clients - is this still the case? The clouds are unchanged by this, though I don't think that you will get the same clouds in MP on both clients unless they are started at the same time. The only changes I made with this were to ensure that Basic Weather generates the appropriate properties for the atmospheric shaders. Your most recent change seems to have broken the manual input gui here - sometimes it works, and sometimes the values revert to the default. Hmmm, odd - I made the changes specifically to fix the manual input UI that I thought your Weather UI changes had broken! :) I still have the old version: seems to work fine. But I only moved the way it was accessed - not the gui itself. It might be that we have actually exposed some old bugs of course. I suspect that you and I are using the UI in a different way and there's something broken in the (complex) UI logic. I'll take a look over the weekend - sorry for the inconvenience. If you're able to nail down the specific actions that cause it to fail, vs. the actions that make it work that would be useful. First problem seems to be related to the mouse - here it gets stuck in the coverage field if you enter it (you don't actually need to). You can get out of it by hitting tab and then right mouse click. Second problem is that if you then close the manual entry window and then hit either OK or Apply the weather reverts to the METAR data and the manual entry fields are all set to the default value. Hitting close works OK and the manual data is applied. Third problem is that sometimes when I enter values on a cloud coverage line then move to another line to fill in data there, the first entry line reverts to the default values. I can't reproduce this reliably, nor can I identify any cause. I haven't seen any of these problems before, but I wouldn't claim that they weren't pre-existing: it is entirely possible that I never tested the right combination of entry conditions. They're pretty obvious though when you do encounter them. We seem to have lost the ability to use /NIL as a METAR input - very useful during fdm development to remove weather effects. I'm not sure when this broke, I think it might have been something James did. That shouldn't have been changed by anything I've done recently. No - I think the problem lies elsewhere as I said. Vivian -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
