James Turner wrote: > On 16 Sep 2008, at 07:05, Erik Hofman wrote: > >>> ALPHA_TEST is slow on modern hardware, which is why I was hoping to >>> not have it >>> be on by default in the scene graph. Oh well. I'll leave this >>> reverted for now >>> and think about turning it on only for states with transparent >>> textures. >>> >>> >> I had no problems like this with my f-16 probably because I decided >> not >> to add transparent glasses to the instruments. >> One way I could think of is to change the alpha-test animation to turn >> in on for that particular model. It has been used for the plib branch >> for quite some time and is unused for the osg version as far as I >> know. > > As I understand it, alpha-testing is slow(er, than it was on say SGI > hardware) because the (vastly) preferred solution is collect the > transparent geometry and render it back-to-front after the opaque > geometry - usually with Z-tests enabled but Z-writes disabled. This Alpha testing is slow because it disables the "early z" optimization in modern cards, which can avoid processing a fragment altogether if it's known that the fragment won't pass the depth test. In our case this is probably a micro-optimization and I should get over it :) > assumes transparent materials (StatesSets) can be pulled out and re- > ordered, but I'd sort of guessed OSG could do this already using a > RenderBin. OSG (and FlightGear) does do this, of course, but with Z writes enabled. When alpha testing is enabled, the Z buffer won't be written if the test fails (i.e., the fragment is transparent), whereas if it is disabled the blended fragment will be written with the new depth. This is the cause of the pa24-250 problems. > > Or is there some fundamental / awkward reason why FG can't use this > approach? You're seeing it in the pa24-250. The depth sort can go awry with nearly-coplanar polygons. Furthermore, it's too expensive to sort every polygon, so the sort is based on sets of polygons which just make the sorting ambiguity worse. The plib version doesn't sort at all, AFAIK, but draws polygons in the order in which they appear in the .ac files. This doesn't work in general but does work well for views from a fixed position, like the cockpit, so aircraft designers carefully arranged their transparent polys with this in mind. The OSG version does sort, causing rendering artifacts with some models.
Tim ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
