David Megginson writes: > > Andy Ross wrote: > > > Honestly, I think you might be fooling yourself on the 2D/3D > > performance issues. There's no secret sauce in ssg that makes it > > faster; my guess is that the existing 3D cockpits are faster than the > > 2D ones because they use fewer and smaller textures, and do less > > animation of the layers. If you were to port the 2D panels to 3D > > model files with a 1:1 mapping, you probably wouldn't see any > > difference. > > Most of the instruments in the PA-28 were ported 1:1, in fact, and initially > I used the much higher resolution textures for the high-res 2D panel rather > than the lower-res textures actually used by the 172p (and I'm still using > bigger textures for things like the panel background). I was astounded at > the framerate difference. My guess is that one or both of the following is > the problem: > > 1. The old panel code triggers some expensive OpenGL rendering calls or > state changes. > > 2. The PLIB FNT library is highly inefficent, since the text instruments are > the only ones not yet ported. > > I can stuff the cockpit with higher-res textures and more detailed geometry > and still get double the framerate on my computer that the old panel code > gave me.
My not so WAG is that the newer code draws MUCH less then the old approach. i.e. All of the 2D Panel was drawn as was all of the scenery that it obscured. In the new approach SSG is clipping those instruments not seen and the occluded scenery is not drawn. Note this includes the scenery occluded by the rest of the planes interior too FWIW That PLib's Font routines are quite efficient is amply demonstrated by the minimal hit drawing the HUD has on the FPS Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
