Re: [Flightgear-devel] Snow line based on METAR
Is it possible to automatically set the turbulence based on METAR? Does METAR contain this information? -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!
But this is definitely some food for the brain. Here is what they write: So, how do we render these clouds in x-plane 10? the answer is levels of detail, which is a display of resolutions of buckets. (...) AGAIN! NO MATTER HOW BIG THE SKY, EACH LEVEL OF DETAIL ONLY COSTS US 1,000 PUFFS! Cutting through all the excitement of the blog writer - we've been discussing this previously, and (at last I) disregarded it for the following reasons: 1) Using many small 'puffs' (or 'sprites' in Stuart's terminology, or 'cloudlets' in mine) are a nice way to render diffuse shapeless clouds, but to arrange them in such a way that you get the correct shape of a well-defined Cumulus cloud is near impossible (which is way we use not so many larger full-cloud image textures). 2) Setting up 'puffs' of different size dependent on distance in a static setup is all nice and crispy, but unfortunately the darn airplanes *move*, so you need some algorithm which replaces a collection of small puffs by a single large puff - and this transition shouldn't actually be visible. If you code it for just a few configurations, it can be done, but then your clouds lack variety. 3) The problem that follows from the above two is that you must make a transition from a Cu cloud composed of 100 small puffs to one which is a single large puff, but the cloud shouldn't change visibly while you do so - which is tricky because Cu clouds have a lot of structure. 4) The problem is worsened by the fact that Cu clouds are not exactly self-similar across too large distance scales - a single puff which works well to represent a cloud from the distance isn't represented well by 10 smaller versions of the same puff - the shape gets wrong. Instead, you'd need a mixture of different smaller puff types dependent on where in the cloud you are. 5) Talking about km-sized puffs at distance is all nice, but the cloud layer may just be 100 m thick, so you can't represent it by 1000 m scale puffs without making it thicker than it really is. Again, with shapeless clouds you can use z-rescaling to deal with the problem, but with structured clouds, that shows up in a very pronounced way. My guess is that X-plane with this approach invites trouble with representing cloud structures, but fares better with very featureless clouds. Also, shape variation of clouds might be an issue, dependent on how this is coded in detail. It's not a bad idea, but the devil is in the detail, and a dynamical way of doing a reduction of complexity at distance (= the imposters) seems a better way to me. Anyway, it's hardly like this writer invented the wheel... Cheers, * Thorsten -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Snow line based on METAR
On 2011-12-07 09.02, Robert wrote: Does METAR contain this information? Not directly. METAR may contain information about gusty winds which is an indication of turbulence. Jari -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak in latest sound code?
On Tue, 2011-12-06 at 20:05 +0100, Durk Talsma wrote: Hi All, Using the following command line options, I am seeing a dramatic increase in memory consumption, in just a few seconds, up to the point where flightgear becomes unusable (top reporting that flightgear uses more than 85% of memory on a 4 GiG linux box): fgfs --timeofday=dawn --airport=SAVE --aircraft=dc-3 Running a comparable session using the fokker50 instead of the dc-3 shows a stable memory footprint of about 25% (as reported by the linux top command). While running the dc-3 I see many warnings printed that stereo sound files are not supported, and after disabling the master sound channel (GUI: File-Sound-uncheck master sound), the memory footprint becomes stable again. Given that I don't see this behavior using the fokker50, makes me suspect it's something specific to the dc-3, and probably related to the erroneous stereo file. Is this possible? OK, this is fixed in simgear. I also adjusted the code to show the message only once. Erik -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak in latest sound code?
OK, this is fixed in simgear. I also adjusted the code to show the message only once. Thanks Erik! I'll give it a go tonight. d. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trying to get more performance out of the 3D clouds!
2011/12/6 Mathias Fröhlich wrote: As usual, I did not take the time to really look into the code. So please excuse more or less obvious questions about the current implementation. The relevant code is newcloud.[c|h]xx and CloudShaderGeometry.[c|h]xx in simgear/scene/sky/ It's entirely possible that there are some inefficiencies there. The only people who have done anything with it are Tim and myself, and I'm certainly not a good graphics programmer. I assume that you have a few textures that is used very often? Or do these textures really have a different content? For the global clouds we typically use a single texture for all the clouds in the layer, and there are usually between 1 and 3 layers. If they are the same content wise, you can help at first osg and then also the GL driver if these are also the same on osg level. That means the osg::Texture* state attribute must be the same for all uses of the same texture picture. May be you already know this, but the description pretty much sounds like an effect originating from this. We use the Effects code to pick up the Texture (see newcloud.cxx line 108). I guess it's possible that is not doing the right thing. snip Really what matters much more are state changes and geometry setup. I still assume that you have very small bunches of geometry that the clouds are made of. This really hurts both osg and the driver. Sure to get transparency right they must be distinct. But I guess the problem to be solved is how to get maximum sized bunches of geometry with as little state changes as possible ahd still have the transparency right ... For osg this means that there must be relatively huge atomic Geometry/PrimitiveSets that are probably pre sorted to order the draw in the depth. Probably an octree like structure holding the cloud subscene helps here. We sort all the sprites within a cloud to minimize the state changes, and then use heuristics to minimize the amount of re-sorting (see CloudShaderGeometry.cxx line 97 Is that what you mean? There is also a technicque called 'pre integration' available for clouds. I'll look into this. Together I still think that the amount of draws and state changes must be cut down. In terms of state changes, an exact depth sorted draw order causes may be a huge amount of texture state changes. May be it is possible to collapse the different textures into one and pick out the appropriate subrange of the texture? May be an array texture, may be a 3d texture with different layers in each discrete z dimension? We already use array textures so we have multiple different textures in a single image file. Is that what you mean? Thanks very much for the explanations - very useful as always. If you have the time to take a look at the code and see if there are any really obvious mistakes, I would be very grateful. -Stuart -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
