-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roberto Inzerillo wrote: > Martin Spott ha scritto: >> Defining fixed boundaries around airfields is a bad idea in the long >> term. To my understanding FlightGear still focuses on methods that are >> laid out in a forseighted manner and fixed boundaries is definitely not >> a part of this collection. While claiming this I have three reasons in >> mind: ... > >> 3.) It's very likely that people not only want to create a detailed >> arrangement of their local airfield entourage but of other places >> of intersting geography as well. This would mean scattering fixed >> boundaries around numerous places around the world - something that >> definitely will get us into trouble over the time. > > That has been happening since earlier versions of MS-FS and has made a > lot of people happy. People pay a lot of money for custom scenery > addons. Just a few complained about not being able to use the old > scenery addons with the new FS release, they simply buy a new addon > upgrade when available if they want to. Also, if you can imagine FlightGear evolving to to more detailed terrain using modern methods such as LOD and large textures, there has got to be some kind of boundary between terrain / geometry derived semi-automatically from DEMs and rendered using a method suited to huge, detailed terrains, and "things" -- whether its terrain-like geometry or objects -- that are created and managed some other way. I don't know the details, but I understand that MS-FS manages this reasonably well at run time. Is there discussion / work on high-detailed terrain for FlightGear going on anywhere? > > > Another personal note about the impact of high detailed terrain geometry > in performances: that is not a problem! That is a false problem. > I am sorry to hear people saying high resolution has to be avoided > because computer hardware is not powerful enough. That is changing day > by day. We get new and more powerfull hardware every day. I've been fooling around with BuGLe (http://bugle.sourceforge.net/), a neat tool for profiling OpenGL applications without recompiling them. In particular it gives access to the NVidia proprietary performance counters on supported hardware. On my machine -- Turon 64 1.8 Ghz, Nvidia GoForce 7300, the major graphics bottleneck seems to be vertex fetch. Indeed, the average batch size reported by BuGLe is about 12 triangles / batch (with the ufo; default Cessna is much lower). This is quite low by today's standards and could certainly be improved. So yeah, FlightGear can stand a lot more polygons in the scene, but they need to be created intelligently on the modeling side and handled intelligently on the OSG/SimGear/FlightGear side. > The correct approach is to try and find an equilibrium between > performance and quality, it's not "make it low quality just in case > user's computer is not powerfull enough". That's crap. Agreed. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFo2lweDhWHdXrDRURAvh4AJsGfKsm0iGnRLSqTr1W/z/s7KmOOgCg1lPQ 2IZfVfrrk/gJo5U6trkZ3nU= =3g9Q -----END PGP SIGNATURE----- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
