Currently, the 2D panel displayed in the 3D model is a kludge. It works enough of the time that you can fly, but some strange things happen from time to time:
1. The 2D panel instruments show through any 3D objects that should obstruct them, such as the yoke. 2. The 2D panel does not move with the eyepoint location, so if you provide x/y/z offsets for the pilot view, the gauges follow you. 3. Some of the 2D instruments look stupid when not viewed straight-on. 4. The instruments are not clickable. For #3, we will obviously need to mix 3D objects with 2D instruments, as I already have in the C172 by providing a 3D throttle and mixture control; for #4 and #2, Andy can add another transformation into his code for the view offsets; and for #1, we can SSG-ify the panel and add it to the 3D model's scene graph. HOWEVER ... I'm starting to wonder if the panel should be a special case at all in the 3D model. The currently-available model animations already cover all of the movements of the instruments except for text displays, so the instruments could simply be part of the 3D model and then animated like everything else (with appropriate LOD so that they disappear not far outside the cockpit). The simplest approach would be for me to add the instruments to the model in Blender and then animate the parts, but that will make it hard to design custom panels. Another, nicely general approach would be to allow XML wrappers for 3D models to include other 3D submodels in their scene graphs. That way, we could have <model> <path>Aircraft/c172/Panels3D/c172-panel.xml</path> <x-offset-m>...</x-offset-m> <y-offset-m>...</y-offset-m> <z-offset-m>...</z-offset-m> <roll-offset-deg>...</roll-offset-deg> <pitch-offset-deg>...</pitch-offset-deg> <heading-offset-deg>...</heading-offset-deg> </model> Then, inside c172-panel.xml, we could have a series of inclusions for the instruments, like these <model> <path>Aircraft/Instruments3D/airspeed.xml</path> <!-- offsets as before --> </model> In this case, the offsets would be relative to the panel, not to the aircraft as a whole. More complex aircraft, like the DC-3, might include several panels this way. On the leaf level, we would, of course, allow any arbitrary 3D model. It might also be nice to provide an ability to define simple models inline in XML, as we currently do with the 2D panel. Instead of hotspots, we'd add actions to models the same way we add animations to them. We would need code to detect the object in the aircraft scene graph under a screen position (i.e. a mouse click), then would walk up the tree from that object until we found an object with an action attached or the ssgRoot (in which case we'd fail). Comments? I realize that this will lead to a split between the 2D and 3D panels, but it seems much more flexible on the 3D side, and many (or most) of the 2D instrument textures -- which are the hardest part -- could be reused on the 3D side. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
