> I haven't fully tested all the options, but in general the frame rate > cost seems very heavy.
> Regarding frame-rates: yes, the Local-Weather implementation kills > non-high-end systems (mine, too). I'm getting slightly frustrated here. I've spent months to improve performance, and I feel by now that I at least deserve a fair judgement for my effords, i.e. an apples-to-apples comparison rather than a highly skewed comparison. The default for the standard 3d clouds is about 16 km visibility of the terrain and clouds are visible out to 20 km, clouds do not drift in the wind. The default comparable local weather call, high pressure, has about 35 km visibility (that's a factor 4 more terrain to render), clouds are visible out to 30 km (that's a factor 2 more area to cover) and clouds do drift in the wind. If you want to compare apples to apples, then you have to level the field. I've just tested 'fair weather' conditions seen from the same location (above KLSV), no cloud movement, same altitude of cloud layers and same visibility of terrain (35 km) and clouds (20 km). Under these conditions I get 80 fps with the standard 3d clouds and 75 fps with local weather. Yes, it's a bit slower under equal conditions. But hardly dramatically so. The reason why it appears slower should now be obvious - it attempts to do more. If you want to render multiple overcast layers and clouds which drift in the wind and flow in a semi-realistic way obstacles in the terrain, then yes, that costs framerate. But if you compare the default settings, then this is like flying the Cessna over Munich and the Piper Seneca over the Paris scenery, and conclude that the Seneca is really slow. > It has not been commited to the repository and I would not recommend > doing so. We should stick to implementing algorithms and systems in the > C++ core and use Nasal for prototyping or aircraft supporting logic. The > terrainsampler is a good example, after being prototyped in Nasal, it's > now a C++ coded subsystem configurable through the property-tree. I beg to disagree here. The terrain presampler is a highly specialized tool, which is best for what it is supposed to do. A fast vector-method to retrieve terrain elevations is a good multi-purpose tool quite independent of terrain presampling. * weather could use it to model the deflection of the wind around major obstacles * any ground radar mode could use it to get a picture of the terrain * low-flying AI planes could use it to navigate around obstacles for which some more global picture of the terrain is needed * ... All this could be done faster having a fast vector method to get elevations in Nasal, and unless you want to hard-code everything, Nasal would probably be the platform of choice. What you want to include in GIT and what not is of course not my business, but I'd certainly have use for the vector elevation sampling beyond the terrain presampling. Best, * Thorsten ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
