* Jim Wilson -- Wednesday 23 March 2005 19:06:
> > From: Melchior FRANZ
>  How about something like this:
> 
> <animation>
>   <type>material</type>
>    <object-name>fuselage</object-name>
>    <global type="bool">true</global>
>    <class>
>      <classtype>emission</classtype>
>      <red>1.0</red>
>      <green>0.8</green>
>      <blue>0.3</blue>
>      <property>/controls/lighting/instruments-norm</property>
>      <offset>0.3</offset>
>    </class>
> 
> You could then use "red-prop", "blue-prop", etc.  If we did have it just 
> "factor"
> would be fine.  You know how it is used to scale ranges to 0.0 - 1.0 in the 
> rotation
> animations.  I cannot think of an  application for fixed factors either, so 
> no sense
> in adding support for it until someone needs it.

It's not about "adding". They are already there. The question is, should we 
remove
them again. :-)  One (obscure) use could be to handle some color input source 
that
delivers 0-255 per component, and that could be scaled down to 1/256 via fixed 
factor.
I guess that just leaving it in is less painful than documenting that "factor" 
is the
only component where fixed values aren't allowed ... and repeatedly having to 
remind
people of that fact.  ;-)

But I'm afraid I don't like that version yet. You renamed <state> to <class> and
<material-type> to <classtype>. But I don't want the whole anonymous container
that needs an extra line to define what it is. That is a good thing if one has
lots of equal children, but in this case it's only four color qualities. I 
prefer
just <emission>, <ambient> etc. No need for extra-verbosity for no gain. Or you
could as easily demand that this should be written:

    <class>
      <classtype>emission</classtype>
      <color>
         <colortype>red</colortype>
         <value>0.0</value>
      </color>

I would need a trained monkey to write all the redundant code, and would then 
only
fill in the raw, pure data. The things that matter.  :-)

My current favorite:


  <animation>
      <type>material</type>
      <object-name>fuselage</object-name>
      <global type="bool">true</global>
      <emission>
          <red>1.0</red>
          <green>0.8</green>
          <blue>0.3</blue>
          <factor-prop>/controls/lighting/instruments-norm</factor-prop>
          <offset>0.3</offset>
     </emission>
     <ambient>
          <red-prop>/sim/model/foo/emission/red</red-prop>
          <blue-prop>/sim/model/foo/emission/blue</blue-prop>
          ...
          <factor>...
          <offset-prop>

i.e.: much like it is in cvs, only with <emission> etc. groups. All you need
to remember is that there are four groups (diffuse|ambient|emission|specular),
each with optional members (red|green|blue|factor|offset) or their respective
*-prop variants. No need to mess with classes, classtypes, colortypes and the
like. 



[...]
> >       <emission>
> >          <red>
> >              <property>/sim/model/foo/emission/red</value>
> >          </red>
> >          <green>
> >              <value>0.8</value>
> >          </green>
> >          <blue>
> >              <value>0.3</value>
> >          </blue>
> >          <property>/controls/lighting/instruments-norm</property>
> >          <offset>0.3</offset>
[...]
> > Consistent, but frankly, already a bit verbose and hardly easier to maintain
> > than the current version.  
> 
> That is a little verbose, but I can see where you are going with it.  Hmmmm...

That's the dilemma: should it be deeply structured, "elegant" (really so?) xml
even if that means that editing it becomes a pain because of it's verbosity?
Now that you "allowed" the *-prop extension, I'd rather drop the above idea
(<red><property>...) quickly. (Again: we do already have for each of 
"latitude-deg"
"longitude-deg", "heading-deg", a respective "latitude-deg-prop", etc. This is
IMHO a good thing to do if there's need for several of such twins.



> > What I hate most is the alpha-test anmiation's "alpha-factor" (which isn't
> > multiplied with anything. It's a threshold!)

> Agreed.  That confused me a bit when I first saw it.  Might not be a bad idea
> to fix that before it becomes too popular. 

Or even kill it. The "material" animation can do that, too. It can even
do this at runtime, while "alpha-blend" does it only when intializing the
animation.  :-P



> I can remember the first time I started writing code to do things like that
> with views.  Really points out what a powerful architecture this is.

Yes, indeed. I noticed that (again) when I wrote material.nas, which creates
a dialog. Or the emblem determination code. fgfs may still not be on par with
MSFS when it comes to eye candy, but our architecture can't easily be topped. 
(BTW: I fixed some dialog handling problems today, in case you were p*ssed by
the poor dialog dragging behavior or the material dialog. :-)



> when fgfs first starts up is to start the first frame up in  the tower, fly 
> the
> camera through the air over to where the aircraft is sitting on the threshold.
> Then make the camera loop around the aircraft,[...]

Could sure be nice. And it's easy enough to be turned off for the impatient.
Worth a try. Nasal won't have a problem with that.

m.

_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to