Thorsten, A few thoughts:
I would have guessed that loading these images would be an infrequent hit making file size a relatively small factor, but if the system is continually swapping them out and reloading them for some reason, that might not be so. Where cloud appearance approaches photograph quality, PNG probably won't buy you a lot in terms of file size, though it's worth experimenting. Their size when loaded will be the same regardless of file format (with one exception, which I'll get to in a moment), so I'd expect no gain there. 2048x2048 is getting pretty hefty at nearly 13 MB of memory consumed per image, which I could see being problematic if multiple different images are used to create a scene, especially given all the other textures typically in play at any given time. Would the environment settings give us the option to use textures of different sizes? Some users with high-end rigs might like the 2048 option, though I expect that would murder my system. ;) You might consider the dxt format. dxt needs some additional work to prepare, and has a few caveats to its use, but the dxt format is compressed when loaded into video RAM. The format is often used in gaming, and can do a lot to conserve video memory and possibly improve performance. You might find it worth exploring, especially for this dedicated operation. -Gary aka Buckaroo On Tue, Mar 1, 2011 at 3:00 AM, <[email protected]> wrote: > > After some more grey hair, I believe I talked the Local Weather package > into working with live METAR data such that it is competitive with the > default system. In some areas it performs worse (especially getting denser > coverage of convective clouds right is a bit of a problem, it doesn't do > time interpolation if a METAR station updates), in others better (it has a > vertical model of the visibility and aloft winds, lateral interpolation of > weather parameters, gets closer to the real sky appearance in comparison > with webcam images,...). So - I am working towards a new version v1.0 > soon. > > In that context, I have two questions: > > 1) What is the best texture format for what I want to do? > > I've noticed that hires cloud textures take a long time to load and drain > performance quite a bit. It seems Flightgear is loading a constant rate of > texture pixels / time, which roughly says that I should not migrate to > 2048x2048 cloud textures (although they look *really* impressive in tests) > since the time to load a sky will increase by a factor four. In my current > experience, loading new clouds is already a significant performance issue. > > What I have been wondering is the following: Currently I am using *.rgb > textures. I have noticed that the filesize can be reduced by a factor 2 or > so by going to *.png textures. However, what is the format which would > most efficiently into the scenery? If *.png saves filespace at the expense > of time, then there's no point in converting, but if png also loads a > factor 2 faster, I would convert all texture sheets. > > I could of course run my own performance tests, but maybe someone simply > knows? > > 2) What are the rules for loading live METAR? > > The context of this question is that I have the impression that if I would > fly transatlantic (I have never tried, since I don't like the ocean view > so much...) the METAR string would not change for a long time, and hence > the weather would not change. That's not very realistic. > > On the other hand, I have a rather well-developed and plausible offline > weather system, so I imagine that the controller switches from METAR to > the offline system when the station is too far away and back when another > station comes into range. > > Switching to the offline system while keeping all weather parameters > plausible is not an issue - you just select an appropriate tile when the > last METAR station has reached a distance d. But switching back to live > weather is - because the offline system can't possibly guess correctly > what the weather is on arrival when it switches over the Atlantic - so the > matching has to be done carefully. > > To think this through, I'd like to understand how the weather fetching > works - does it always pick the nearest station, even if that is 3000 > miles away, or is there a distance cut, or some other criterion? > > Any help is appreciated! > > Thanks in advance, > > * Thorsten > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Flightgear-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
