Hi, On Monday 23 March 2009 11:29:03 Stuart Buchanan wrote: > I think I've found a regression in the model loading code. > > As part of the Vulcan cockpit , there is a display showing the current > position of the control surfaces and trim settings > (Aircraft/vulcanb2/Models/Instruments/control_pos.xml). It is the oblong > box in the upper center on the Panel. After doing a CVS up and rebuild last > week, it stopped being displayed, with no error message AFAICT even with > log-level=debug. > > The root of the problem (from trial and error) is that the .ac file had an > object "Rudder", which collided with the "Rudder" object of the aircraft > model itself. I suspect the problem is in the .ac loader code rather than > the animation code, as the problem was reproducable even when I removed all > the animations from the object. > > I suspect that this is a new regression, as the object displayed quite > happily on a CVS build from two weeks ago. > > I've corrected it in the CVS Vulcan, by renaming the object in the .ac and > .xml files, but the bug should still be reproducable with a Vulcan > check-out from last week.
I do not know why this did not happen before. So the problem may not be understood too good. But, it is well know to me that the animations are applied to the model and all submodels. This is something I did not like to implement, but that happened for some reason with the plib stuff and that was reimplemented with osg. There is a comment in the model animation code that states that this is something strange to do. But I guess that there are many configurations out there that rely on this property. There are many more surprising things in the xml format that has grown over the years. I do not remember what else, but at the time I implemented that in osg. I hit plenty of strange behaviours that are hard to implement in the animations code, and might be very surprising to model authors if you step on that. I have often thought about introducing a more flexible and consistent xml model format where such surprises do not happen anymore. We could probably produce more tight scenegraphs which would help culling speed. We could stop the need to flip all the ac models to a different axis orientation which will definitely help modelers to animate their models. We could rethink some animations semantics which is sometimes very slightly beyond that what could be implemented efficiently. Often the most interesting use cases would work very good. But due to having that stuff like it is I had to implement something that was not very efficient to do. Greetings Mathias ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
