Hi again,
On 2009/04/07, at 21:04, Tim Moore <timo...@redhat.com> wrote:
> Tatsuhiro Nishioka wrote:
>>
>> 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.
What about this way?
Say you have your own material class(e.g.
SGMaterial, or whatever you name it) inherited from osg::Material
class so you may access the protected color vectors like _ambient,
_emission, etc.
SGMaterial has its own vectors (or a float array) for tying 'rgba's in
the property tree (say _ambient_prop, _emission_prop). The class can
also have setters / getters for r,g,b,a, factor and offset if you want
to avoid updating color vectors on every frame.
Separating tying/setters/getters portion of code into another class
(like ColorSpec) may reduce some amount of code since you can reuse
the typing/setter/getter code for different color vectors like ambient
and emission.
As a result, you can save 4 or 5 vector passing into OSG every time
UpdateCallback is called from osg. It also saves several property
references by calling getFloatValue since each element in
_ambient_prop (and so on) is tied to property system. It can't save
the memory for extra vectors (like _ambient_prop) since each color
value is calculated by {r,g,b} * factor + offset, and the rgb value
needs to be tied to the property system.
This way you can improve the performance without making a new vector
format inside XML tag.
# I wish I could send you a code snippet on this but forgive me since
I send this from my iPhone.
>> 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.
Could be, but my way, and some other ways, can be also worthwhile to try.
What I want to say is that changing a text format inside XML is the
last option to take. But boy, your idea saves a lot of CPU time and
memory considering a number of materials in FG. Good indeed.
>> 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.
That's a good news. I'll take a look at your code when I can see it
via a real network.
Or, Is there any URL that I can see your own code in a plain text/html format?
iPhone can access most of web sites but it can't use git to get your files.
> My proposed usage is just as local, except that eventually I want to
> change effects properties from Nasal code.
Then it is not just local, and you need to make colors accessible via
the property tree.
Anyway, I really like your basic idea. And I hope my idea can be a way
to satisfy you both.
Best,
Tat
------------------------------------------------------------------------------
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
