On Fri, Mar 20, 2009 at 6:51 PM, Tim Moore <timo...@redhat.com> wrote:

> Gene Buckle wrote:
> >>
> >> In my opinion this planned change would be an incredibly bad
> >> move, and would almost have to be seen as the destruction of
> >> the property system. So let me repeat: I strongly object.
> >>
> >
> > I guess it boils down to whether or not the benefit gained outweighs the
> > down side.
> >
> > 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 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.

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.

Regards,

Curt.
-- 
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
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

Reply via email to