Curtis Olson wrote:
> On Fri, Mar 20, 2009 at 6:51 PM, Tim Moore <timo...@redhat.com
> <mailto:timo...@redhat.com>> wrote:
>
> Gene Buckle wrote:
> > What benefit does the compound property offer?
> >
> > g.
> >
> More concise syntax for aggregate values like colors, rotations, etc.
>
>
> To me the idea of giving nasal efficient access to vec3 and vec4 types
> for manipulating things like material properties, texture coordinates,
> lighting, and positions seems like the strongest argument "for" this
> proposal.
>
> Reading back through Melchior's original email, perhaps the thing that
> might concern me the most is what happens if we use some random xml tool
> to read in a flightgear xml file, make some manipulation (not
> necessarily touching the proposed new vec3/vec4 types) and the write it
> back out. Will this proposed xml format allow this to happen without
> the random tool corrupting all the vec3/vec4 entries because it didn't
> know how to properly deal with them? What ever we do, I think it's
I don't know what's out there reading / writing property lists. I would hope
that a random XML transformer would treat the vector data as a string and
preserve the type attribute.
> important to have our xml play nice with others. (if a vec3 is
> interpreted as a string by some other tool and written out verbatim,
> that's fine, but if only the first value is interpreted as a number, and
> that's all that is written back out, it would be an easy and subtle way
> to corrupt a flightgear config file.) What other xml tools would
> read/write our files anyway? I don't necessarily know, but maybe an
> external modeler or a plugin to an external modeler that doesn't know
> about our new data types?
>
> JSBSim has a way to input tables and vectors I believe as a single xml
> entry. (The numbers are separated by spaces.) Perhaps we should take a
> peek at how they do things there and what potential implications that
> has or problems it might or might not cause? Maybe there is some
> existing precedence here we can consider.
>
> On the flip side, (just my impression), arguing for this change because
> the alternative is a more verbose xml syntax is maybe the weakest
> argument. xml is already pretty verbose and a percentage difference in
> verbosity isn't much of a big deal I don't think.
I haven't written much in the property list syntax, or in XML for that matter.
I think XML is way too verbose for very little gain over Lisp S-expressions
or C/C++/VRML brace syntax, so I view anything that makes it less verbose as
a win.
>
> Melchior originally wrote:
>
>> What is it about: Currently, if we have data in the tree that belong
>> together, this is done via subnodes under a common property, e.g.:
>>
>> color/
>> |__red (float)
>> |__green (float)
>> |__blue (float)
>>
>> just like it's done in C or C++:
>>
>> struct color {
>> float red;
>> float green;
>> float blue;
>> };
>
> For the types that Tim proposes, they are almost always written as float
> color[4] and accessed with color[0], color[1], color[2], color[3], or
> pos[0], pos[1], pos[2], etc. in C and C++ when you are dealing with
> OpenGL. Anyone who would represent an opengl color in C/C++ the way
> Melchior suggests would have to convert it to a vec3/vec4 before
> actually using it.
>
> Tim, rather than doing specific vec3 and vec4 data types, would it make
> sense to have a generic "array" data type ... perhaps that can be
> float/double/int depending on the get/set methods used? But then it
> would be really nice to use the "vector" type out of the STL instead of
> raw arrays ... and then it doesn't match up as well with native opengl
> types.
That works for me. I toyed with that idea a while, but gave it up in the
face of Melchior's even more violent reaction. It works well with my scheme of
mapping these types to vectors in Nasal.
Tim
------------------------------------------------------------------------------
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
