> From: Melchior FRANZ
>
> * Jim Wilson -- Wednesday 23 March 2005 15:32:
> > I know we discussed this earlier [...]
>
> ... but I haven't read that thread again before implementing it. Was too lazy
> to scroll up.
>
You didn't miss anything. I meant you already sent your proposed layout. I
didn't say
anything you missed.
>
> > but when setting up some configurations on the p51 panel it occured to me
> > that a
> > slightly different xml structure might be better.
>
> Agreed. A deeper hierarchy wouldn't hurt, especially in the case of
> "emission"/"ambient"/etc. But I'm not sure if this isn't giving up usability
> for academic XML-cleanliness.
>
>
>
> > <animation>
> > <type>material</type>
> > <object-name>fuselage</object-name>
> > <global type="bool">true</global>
> > <state>
> > <material-type>emission</material-type>
> > <red>1.0</red>
> > <green>0.8</green>
> > <blue>0.3</blue>
> > <property>/controls/lighting/instruments-norm</property>
> > <offset>0.3</offset>
> > </state>
>
> How does "emission-red-prop" fit into this system? And "emission-factor" would
> also have no place. (Do we even need fixed factors?) Also, I don't like the
> <state> thingy. That's IMHO a bit overdone -- the opposite of the current,
> flat approach. Would then a simple property like "texture" also be a "state"
> of "material-type" "texture"? The "material-" is redunant, anyway. It's
> a material animation, after all.
>
Good points. 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.
Of course there is a little logic to just having support for all such features
(including intervals) in all animations. Just a little though.
> If more depth, then it would IMHO be better to do it like this:
>
> <animation>
> <type>material</type>
> <object-name>fuselage</object-name>
> <global type="bool">true</global>
> <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>
> </emission>
> <ambient>
> ...
> </ambient>
> <texture>
> <property>/foo/bar</property>
> </texture>
> </animation>
>
>
> 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...
>
> The *-prop extension is also (well?) known (-> e.g. "latitude-prop").
> But you are right about the "factor" inconsistency. 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.
>
>
> > This really is a great addition you've made!
>
> Thanks. It's fun to play with live properties at runtime. And a great help
> for tweaking materials under fgfs lighting conditions.
>
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. I haven't
used nasal at all, but I was thinking something that might be a fun view trick
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, pointing toward the aircraft
(like a walk around) and then finally climb through the door into the cockpit.
About a 5 second sequence that did that at start up would look cool! Pure eye
candy :-)
Best regards,
Jim
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
