Tatsuhiro Nishioka wrote: > Hi, > > I agree with those who are against the proposed new vector format even > though I like Tim's basic idea that improves vector calculation > performance. > > As Melchior alrwady said, the new format has nothing to do with what > Tim really wants (performance improvement). A node with 3 or 4 float > numbers can be converted into a vector class internally in C++ code > without the new vector format inside an XML tag. I've explained before why this is approach is messy and has performance implications in OSG. If you want to see this strategy in action, look at scene/model/SGMaterialAnimation.cxx and the hundreds of lines of code that are needed to bridge the difference between colors represented as discrete properties and vector colors in OSG. > > Moreover, the new vector format doesn't improve the usability at all. > a user-defined text format inside an XML tag is not recommended since > it decreases the readability unless you give a comment, which is way > not better than using tags. If we really need more concise format that > improves usability, then we need to throw away our current xml files > and make new files in our own new format, which I believe is nonsense. This is the COBOL and Java idea that locally simple, "self documenting" syntax improves readability. I simply don't buy it because the resulting loss of abstraction means that the total amount that a user needs to absorb in order to understand a program increases dramatically. Now, it may be a lost cause to try to improve an XML-based file format, but I feel that it is worthwhile to try.
> > The new format also needs a parser, property browser changes, and > converter(s) that don't help us improve any usability or performance > at runtime, I guess. If such new format gives us some usability or > performance improvement, I can accept it even if some extra work is > required, but this is not the case. These changes are very small, as can be seen in my code. If they weren't, I wouldn't have been tempted to mess with the property system. > > The JSBSim's table format, which I believe, also lacks the > readability. It ,however, gives aircraft developers some usability > like easier to copy and paste some table data from external tools like > javaprop or excel. I know some helper script can create a well- > formatted XML tags, but it could be true that many aircraft developers > like simple copy-paste things while tweeking prop/engine things tons > of times a day. Nevertheless to say, these tables don't need > converters or browser changes since these are only read at launch > time, and are not readable from the property browser or telnet. So > comparing JSBSim table and the vector format doesn't seems fair to me. My proposed usage is just as local, except that eventually I want to change effects properties from Nasal code. > > I hope many people understands what Melchior said on the property > system. His "going home" thing didn't mean that he just wants to hide > away unless his opinion is accepted, but he wanted to say the proposed > vector format is that bad in terms of software architecture. It's not a civil way to participate in a collaborative project. Tim ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
