I should point out that ... Many multihead capable video cards will only do 3D acceleration on the main head. If the instrument panel is placed on the second head, it had better use 2D GL calls. Therefore, the panel has to intrinsically be a 2D database.
2D objects require less textures because you don't have to stack them in front of each other and cover up the joins. That frees up texture space to do more interesting things in the scenery and in the panel itself. If you force panel designers to work in 3D, you will lose much casual work. Fundamentally, most humans can work comfortably with 2D (and paper sketches), but have trouble with 3D even when this is really only a flat structure. Therefore, I recommend having a fully supported 2D panel file format. That doesn't mean that I object to having 3D panel content; we already have the ability to do articulations and stuff in the PLIB infrastructure. I just don't want this to be the only supported mechanism for panels. > Andy Ross writes: > > > This sounds elegant. I'm a little worried about ease of authoring, > > though. Right now, everyone understands what a 2D panel means -- it's > > just flat, and has obvious coordinate conventions. Making everything > > 3D means that panel authors have to worry about a whole new set of > > concerns, like whether their panel "fits" in the cockpit they're > > working on. > > Well, yes, but we can provide a scaling feature easily enough. I > imagine that the 3D aircraft model would provide the panel background > (as we do currently), and that the panel designer would worry only > about instruments. You usually have to fiddle to get the instruments > to fit anyway. > > > Since, in reality, all cockpits are composed of a bunch of flat > > surfaces with instruments on them, I'd argue that the simplest way > > to do this is what we have right now. > > One problem is that we end up with two ways of doing things. Items > like the yoke, rudder pedals, trim wheel, throttle(s), propeller > control(s), mixture control(s), carb heat (where appropriate), trim > wheel(s), parking brake, magento control, and so on, possibly even > down to some radio knobs, will need to be 3D models in any case. > Right now, I have built these right into the C172 3D model, but I'd > prefer to keep them separate and include them in the config file. > > > The addition of scene graph integration and the ability to map > > multiple 2D panel descriptions into the 3D world sounds like the > > simplest way to do things. > > It has the benefit of carrying over more of the work that people have > done on the 2D panels, certainly, but in the long term, I don't know > if two similar-but-not-identical ways of doing the same thing will be > good for FlightGear. > > Note (to others) that I am not suggesting that we dump the 2D panel -- > as Alex has mentioned, it's fine for IFR practice. > > > All the best, > > > David > > -- > David Megginson > [EMAIL PROTECTED] > > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
