* 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 Flightgearfirstname.lastname@example.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d