Re: [Flightgear-devel] [RFC] ac3d and materials
Hi, On Thursday 19 March 2009 12:57:17 gerard robin wrote: Since i have not followed that topic may be a stupid question: will that animation longer working typematerial/type emission factor-propcontrols/lighting/instruments-norm/factor-prop red0.60/red green0.30/green blue0.20/blue /emission diffuse red1/red green1/green blue1/blue /diffuse ambient red1/red green1/green blue1/blue /ambient specular red0/red green0/green blue0/blue /specular shininess4/shininess I am using it, to light the instruments XML model changes are not affected by the code change. So, only material properties that are in the ac file are *no* *longer* changed by the loading process. So, now you get in flightgear what you have in the ac file. Before, you got in flightgear, what flightgear changed in the ac file. Greetings Mathias -- 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
Re: [Flightgear-devel] [RFC] ac3d and materials
Hi Heiko, On Thursday 19 March 2009 14:11:30 Heiko Schulz wrote: what does that mean in future for me as 3d-modeller? What I have to change when using Blender? Since I do not know blender too much, I cannot give blender specific hints. But in general, I would say: Just go on like you are used to. You have just more control over the material properties of the models. What might happen, is that your modelers default viewer light settings have very different lighting components from the one you might find at different day times/light conditions in flightear. So you may need to play with different light settings in the viewer. Greetings Mathias -- 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
Re: [Flightgear-devel] [RFC] ac3d and materials
Am Donnerstag, den 19.03.2009, 13:11 + schrieb Heiko Schulz: Hello, what does that mean in future for me as 3d-modeller? What I have to change when using Blender? To get the same results as before you just need to change the Ambient Value to 1.0. You find it in the Material Buttons Shaders menu Slider Amb). However I think a setting of 0.75 gives a more realistic metal look, especially in the morning or evening hours. Of course for less reflecting materials like fabric or wood this is different. You may want to play with the Reflective settings (in Shaders Menu Ref too. I have commited some changes to the F4U and Beaufighter yesterday. You may want to look at that. Overall I like the new Look very much, the Modeller has better control over the Materials now. Thanks a lot Mathias! Rgards HHS Hi, Given this thread. I have checked in the change to simgear. I have also updated the default c172 and selectively those submodels that I thought need some update. And I have updated all the ac models in the AI and the Models subdirectory. For the specific aircraft models, I do not want to just overwrite what the author might have done on purpose but what was not yet honoured by flightgear. So, if there are very dark models, the attached script to do the change on the model level might be a good starting point for further development. Greetings Mathias -- 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 -- Detlef Faber http://www.sol2500.net/flightgear -- 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
[Flightgear-devel] 787 disappeared from download page
Hi all, I'm new to devel mailing list. After 1.9.0 released, some users in FlightGear forum reported that 787 aircraft disappeared from download page. For more detail, please refer to my post in the forum. http://www.flightgear.org/forums/viewtopic.php?f=2t=3242#p29432 I guess either of CVS files need to be modified to fix this problem: - admin/make-aircraft-pkgs.pl - admin/make-aircraft-html.pl - data/Aircraft/787/787-set.xml But I don't know which file should be modified. I hope someone can correct this issue and comit to CVS. One more thing that I want to request is to include ATC aircraft, which is excluded to be packaged by make-aircraft-pkgs.pl. At the mean time, users who want to obtain ATC aircraft should use CVS client, or obtain CVS snapshot from git repository browser at http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=tree;f=Aircraft/ATC;hb=HEAD. You can see many users are in trouble to obtain ATC aircraft: http://www.flightgear.org/forums/viewtopic.php?f=11t=3179. If we can obtain ATC aircraft from aircraft download page in next release, I'm happy. Cheers, Toshi -- 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
Re: [Flightgear-devel] [RFC] ac3d and materials
Hi, yes, it seems to me, that time was passing real fast since the old plib-days! I have to wait until I have a new binary, then I will change my models. Thanks for the helpfull answers Regards HHS Hello, what does that mean in future for me as 3d-modeller? What I have to change when using Blender? To get the same results as before you just need to change the Ambient Value to 1.0. You find it in the Material Buttons Shaders menu Slider Amb). However I think a setting of 0.75 gives a more realistic metal look, especially in the morning or evening hours. Of course for less reflecting materials like fabric or wood this is different. You may want to play with the Reflective settings (in Shaders Menu Ref too. I have commited some changes to the F4U and Beaufighter yesterday. You may want to look at that. Overall I like the new Look very much, the Modeller has better control over the Materials now. Thanks a lot Mathias! Rgards HHS Hi, Given this thread. I have checked in the change to simgear. I have also updated the default c172 and selectively those submodels that I thought need some update. And I have updated all the ac models in the AI and the Models subdirectory. For the specific aircraft models, I do not want to just overwrite what the author might have done on purpose but what was not yet honoured by flightgear. So, if there are very dark models, the attached script to do the change on the model level might be a good starting point for further development. Greetings Mathias -- 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 -- Detlef Faber http://www.sol2500.net/flightgear -- 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 -- 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
Re: [Flightgear-devel] Atmosphere temperature model
You could have saved yourself a lot of work by posting a question before writing all this code. I don't mind that, because it was just fun to do that. And I wasn't going to do a temperature model in the first place, but somehow ended up doing that :) The code to do all this has existed for years. A nice table-driven implementation. It does this and more (notably linking the _pressure_ versus height dependence to the temperature). Pressure is kinda important for realistic altimetry, engine performance, et cetera. Let me know if you are interested in this. If you mean the table at the top of environment.cxx, yeah I noticed it. And I use it like before up to 35000ft. I don't know what was the reason to not use it over that altitude for temperature, it seems to be quite nice up to 10ft. See http://users.tkk.fi/~lapelto2/fgfs_temp_graph.jpg . I also notice that it is used to model pressure at all altitudes. Or do you have some other table system than that? I was mostly doing this to add the latitude dependency to the temperature curves. I'm sure no one would notice that when flying, but it seemed like a nice thing to do. In any case, the current -56 degC at altitudes over 38000 is horrible, and we should either model using the table or something similar to my system, depending on the accuracy wanted. I don't know if any aircraft can/should fly in those high altitudes, and if their modeling takes temperature into account. Lauri -- Lauri Peltonen lauri.pelto...@gmail.com -- 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
Re: [Flightgear-devel] data/tanker.nas
SNIP - vary callsign TACAN id - support more than just KC135 and KA6 tanker - support helicopter refueling (i.e. configurable airspeed) - fly refueling pattern(?) - avoid collisions with mountains m. The Handley Page Victor K2 is not too far from completion. It already has the ability to act as Multiplayer tanker Alex E-mail message checked by Spyware Doctor (6.0.0.386) Database version: 5.11910 http://www.pctools.com/uk/spyware-doctor-antivirus/ -- 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
Re: [Flightgear-devel] data/tanker.nas
alex wrote: - vary callsign TACAN id - support more than just KC135 and KA6 tanker - support helicopter refueling (i.e. configurable airspeed) - fly refueling pattern(?) - avoid collisions with mountains m. The Handley Page Victor K2 is not too far from completion. It already has the ability to act as Multiplayer tanker That's great news. I'm really looking forward to seeing it. It might be worthwhile creating a low-poly model for use as an AI tanker. -Stuart -- 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
Re: [Flightgear-devel] data/tanker.nas
* alex -- Friday 20 March 2009: * * Melchior FRANZ -- Monday 16 March 2009: - vary callsign TACAN id That's done. (Even a bit overengineered. ;-) - support more than just KC135 and KA6 tanker - support helicopter refueling (i.e. configurable airspeed) or generally: - allow aircraft to define ideal type/model/speed/altitude, so that tanker.nas could find one in its built-in properties list - fly refueling pattern(?) - avoid collisions with mountains More TODOs: - react to turbulences - avoid cloud layers The Handley Page Victor K2 is not too far from completion. It already has the ability to act as Multiplayer tanker Wonderful. As Stuart mentiond, a stripped down AI for tanking purposes might be a good idea, one that is guaranteed to exist, which the full model isn't. In any case, I could check for that, and the user could set this in his/her preferences: prefer full (or AI) model if available. m. -- 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
[Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
This will probably become a flame-war, but I see no way to avoid
it. Tim plans to extend the property system with compound data
types, such as VEC3, VEC4, or COLOR. We've discussed this three times
in IRC, and I've always pointed out why this is IMHO a *BAD* thing,
and why I strongly object. But now he has implemented it in his
source, and made that the base of further (desirable!) features.
I don't want a flame war with Tim, but this needs to be decided
*now*. Otherwise we might end up having to decide whether we want
the (IMHO) evil property change *and* the nice features, or
neither. And that's not how a decision about one of our foundations
should be made!
(To Tim's defense, he had planned to write an RFC to the devel list
about it, though he also intended to commit parts of the change before
that. And to my defense: I have told him that if he doesn't write the
RFC *soon*, then I will bring it up on the list!)
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;
};
That is: each component is a basic standad type and can be accessed
as such, but the whole structure can be passed as one, too. The
property system contains the standard types from C++: BOOL, INT, LONG,
FLOAT, DOUBLE, STRING (= char*), as well as UNSPECIFIED and NONE.
Subsystems publish values in these basic types and access data from
other subsystems. This is done from within C and C++, from Nasal,
via property browser, property display (on screen), and remote
access is possible via telnet/socket, http, protocols, or properties
are just loaded from XML files directly into the tree.
All data types can be read as any other datatype (except the special
ones UNSPECIFIED and NONE), in which case the data are converted
appropriately and as one would expect. It's possible to read a BOOL
into a double, and to write a double to a LONG. The property system
is one of the foundations of FlightGear and has worked very well for
a long time.
Tim's planned patch will IMHO degrade the system and remove essential
properties. How should such a VEC3 property be displayed in the
property browser? In one line, separated by semicolons? Will everyone
who reads the data have to write parsers for the compound type?
How will one attach a GUI slider to the red property, if it doesn't
have its own property path, but is thrown together with other
properties?
What happens if I write a bool value to a VEC3 property? Will it set
all three values to 0 or 1, or only the first? Or will it return an
error? What will I get if I call getIntValue() on a VEC3 property?
What happens when I read out a color via telnet? Will I get
0.123;0.5;0.6667? Will people have to learn that the first of
them is red, the second blue, and the third green?
Will input fields in remote applications (instructor) have to write
special validators for VEC3 properties, rather than just having
three fields that accept a number?
How will a VEC3 property be written in an XML file? As
foo type=vec3123;341;123/foo? Will then every application
which reads such a file have to have its own (sub)parser for
certain fields, in addition to using an XML parser?
Or will the compound properties no longer be public at all, but be
kept secret, with no way for the user to inspect and change them?
Or will the whole throwing-together of properties only happen
internally, while they are still presented as separate data
types to the world? But what's the whole point of it, then?
We already have that, as separate properties can already be
loaded into an SGVec class!
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.
Please no knee-jerk reactions about whether I am in the position
to strongly object or not, no discussions about whether Tim is
an important project member and core developer who has contributed
significant improvements and features to fgfs -- of course he is
and has, and no discussions about whether we want effects, shadows,
and landing lights -- of course we do. This is about the property
system and compound property types.
m.
--
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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
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. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. OpenQM - A Multi-Value database for the masses, not the classes. http://gpl.openqm.com - Get it _today_! -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Melchior FRANZ wrote: How will a VEC3 property be written in an XML file? As foo type=vec3123;341;123/foo? Will then every application which reads such a file have to have its own (sub)parser for certain fields, in addition to using an XML parser? This is my strongest point to be against it. The property tree is there for easy xml file loading and saving. I can see no obvious way to save those VEC properties to an xml file in a way that is supported by the xml specification. It is impossible at this time to say whether or not that is desirable at all in the future so this option should be left open. Aside from that is see no reason to add them in the first place. Erik -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
I don't know much about C++, but in Python people can custom a data type, it has its own method to be bound with operator. Like str(), the function a translate an object to a string, str(theObj) is actually theObj._str() This might also applied in tim's types such as VEC3. And it could have its own validator function, let OO solve problems! IMO, if these compound types are unavoidable, then just also wrap the primitive types up! --Buganini -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
* Buganini -- Friday 20 March 2009: IMO, if these compound types are unavoidable, [...] They are very much avoidable. We've had colors and coordinates since *ages*. And what next? If we have VEC3, then what about POSITION, which contains latitude/longitude/altitude, and ORIENTATION with heading, pitch, roll, and FONT with name, size, slant, and ... Once we give up atomicity and start throwing things together, there's no logical end to it. And no, that change is *not* needed. m. -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Melchior FRANZ wrote: This will probably become a flame-war, but I see no way to avoid it. Tim plans to extend the property system with compound data types, such as VEC3, VEC4, or COLOR. We've discussed this three times in IRC, and I've always pointed out why this is IMHO a *BAD* thing, and why I strongly object. But now he has implemented it in his source, and made that the base of further (desirable!) features. I don't want a flame war with Tim, but this needs to be decided *now*. Otherwise we might end up having to decide whether we want the (IMHO) evil property change *and* the nice features, or neither. And that's not how a decision about one of our foundations should be made! (To Tim's defense, he had planned to write an RFC to the devel list about it, though he also intended to commit parts of the change before that. And to my defense: I have told him that if he doesn't write the RFC *soon*, then I will bring it up on the list!) I don't see any reason for this to become a flame-war. I think it would be good for Tim to explain why more complex types are required, as I'm sure he will do shortly :) My immediate thought is that one could write some fairly straightforward code to interpret a given property node with 3 child values as a Vec3. Could we subvert the property attributes to indicate that a given nodes contains a Vect3. That way internal code could interpret it as a Vec3, while external interfaces would be preserved. Like Erik, I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. -Stuart -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
* Stuart Buchanan -- Friday 20 March 2009: I don't see any reason for this to become a flame-war. Umm, because some people seem to have an auto-responder that launches a hate-mail every time an email contains my name and object? :-] m. -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
* Melchior FRANZ -- Friday 20 March 2009: * Stuart Buchanan -- Friday 20 March 2009: I don't see any reason for this to become a flame-war. Umm, because [...] Arghh ... and that should have been a private mail to Stuart, with tongue in cheek. And now it looks as if *I* am the one who wants to turn up the heat. It's hot enough already. :-) Sorry for that. m. -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Sorry for that. But thanks for the cool idea anyway - let's see how to set it up ;-) Back to topic - you have strong points against it. Let's wait and see what Tim has to say. I am sure he has some good pros. Torsten -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
On Fri, Mar 20, 2009 at 10:22 AM, Stuart Buchanan wrote: Melchior FRANZ wrote: This will probably become a flame-war, but I see no way to avoid it. I think you laid out your position in a very well thought out and fair manner, backed up with many reasonable points and/or questions. If the replies to this thread have a similar tone and include any thought and insight, we shouldn't have a problem. :-) I can imagine an alternate perspective so I'm looking forward to hearing that too. Tim plans to extend the property system with compound data types, such as VEC3, VEC4, or COLOR. We've discussed this three times in IRC, and I've always pointed out why this is IMHO a *BAD* thing, and why I strongly object. But now he has implemented it in his source, and made that the base of further (desirable!) features. I don't want a flame war with Tim, but this needs to be decided *now*. Otherwise we might end up having to decide whether we want the (IMHO) evil property change *and* the nice features, or neither. And that's not how a decision about one of our foundations should be made! (To Tim's defense, he had planned to write an RFC to the devel list about it, though he also intended to commit parts of the change before that. And to my defense: I have told him that if he doesn't write the RFC *soon*, then I will bring it up on the list!) I think it would be good for Tim to explain why more complex types are required, as I'm sure he will do shortly :) Our current property system seems to match up well with C's view of data types. As Melchior points out, we have always represented records/structs as a subtree of properties hanging off a node. Arrays have been represented using numbered nodes as in ... pos/vec[0], pos/vec[1], pos/vec[2] or pos vec1.1/vec vec0.5/vec vec-0.2/vec pos or more verbosely: pos vec n=01.1/vec vec n=10.5/vec vec n=2-0.2/vec pos The main argument I can anticipate for adhoc aggregate types would perhaps be some sort of performance/space argument. If you want to store and retrieve a boatload of vectors in the property system, having a child node for each array element of each vector consumes extra space, and you burn extra time accessing the individual elements. And an aggregate type could be setup to have a better direct mapping to the required OSG/OpenGL form of the data which would eliminate the need to convert the value each time it is accessed. But as Melchior points out, doing this sort of thing could open up a big can of worms, and if space and access time is a key consideration, then is the property system the best place for that sort of data? If we start doing aggregate types, do we jump in with an adhoc approach and create a few things here and a few things there as needed? This seems to me to have the potential to explode in to a mess of accessor fuctions and near-duplicate code that would be required for each new type or variant. Perhaps *if* we want to extend the supported property types, we should think *very* carefully about the overall design of the property system. Do we add support for arrays? Could that be done in a reasonable manner, and could that be leveraged for Tim's needs? Most of the key opengl data types are things like float or int arrays. My immediate thought is that one could write some fairly straightforward code to interpret a given property node with 3 child values as a Vec3. Could we subvert the property attributes to indicate that a given nodes contains a Vect3. That way internal code could interpret it as a Vec3, while external interfaces would be preserved. I like this approach. We could easily write some helper functions that would deal with aggregate types at a higher level. Internally, they are still represented with the current property system, but a helper function could collect all the children values of a node and present them as an array of floats for instance. This would have a time/space overhead, but again, if that's a problem, then that might be a sign that the property system isn't the best place to store that data. Like Erik, I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. If we do move towards aggregate types, would we take a more object oriented approach to data representation? It would be nice to have the flexibility to then represent arbitrary collections of data like a C++ class. But if we do that, we really should support the concept of inheritant, and what about attaching functionality/classes to the data. But I'd still be interested in hearing Tim's perspective so I don't have to guess at what that might be. :-) Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and
[Flightgear-devel] DEM data
I just wanted to check on this before I muck it up, now that I finally seem to have terragear compiled. I've got a couple of 1201X1201 grid cells of raster data, covering a total of 0.5 deg X 0.5 deg. The extension on the files is .dem, and according to the details that come with it, the data format is CDED ASCII. Do I need to re-process and format this before I can start running demchop on it to cut the squares to the right size? (provided I'm correctly understanding what it its that demshop does). I know that DEM-30 data needs to be changed, but I think this is more similar to DEM-3 data. Thanks gang! -cullam -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Hi, I hear that for the first time. On Friday 20 March 2009 16:06:51 Gene Buckle wrote: I guess it boils down to whether or not the benefit gained outweighs the down side. What benefit does the compound property offer? * You can modify properties in a atomic way. * We use the property tree as a reflection framework to reflect object state into other areas of the application. So you can reflect more complex properties directly. * The same benefit why you write a struct/class in C/C++/whatever high level language in contrast to the was FORTRAN does where everything is a scalar like our current property tree. Greetings Mathias -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Hi, On Friday 20 March 2009 16:07:57 Erik Hofman wrote: This is my strongest point to be against it. The property tree is there for easy xml file loading and saving. I can see no obvious way to save those VEC properties to an xml file in a way that is supported by the xml specification. Ok. But from my point of view the property tree is also used as a reflection framework to reflect objects state into the models/scripting/whatever. From my point of view, the serialization of the objects into xml is just a special case of that reflection stuff. Given that, you might consequently want to reflect more complex types by the properties. Greetings Mathias -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
2009/3/20 Mathias Fröhlich mathias.froehl...@gmx.net: From my point of view, the serialization of the objects into xml is just a special case of that reflection stuff. Not just the xml, there is MP, the generic i/o stuff and the telnet/http interface too. -- Csaba/Jester -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Mathias Fröhlich wrote: But from my point of view the property tree is also used as a reflection framework to reflect objects state into the models/scripting/whatever. From my point of view, the serialization of the objects into xml is just a special case of that reflection stuff. Given that, you might consequently want to reflect more complex types by the properties. Allright but how would you acces /model/skin/color/red in the new case then? Erik -- 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
Re: [Flightgear-devel] c172p-dual-pilot broken
On Fri, 20 Mar 2009, Torsten Dreyer wrote: I followed your advice and didn't rush ;-) No problem with the nasal wrapper for the animations. Do you have a generic interface for the properties for the remote aircraft? Are they transmitted via the generic multiplayer values? Hi, They are packed into a set of generic MP properties for transmission using a set utility components (in ZLT-NT/DualControl/pilot-dual-control.nas). The best structure I currently have is that the instrument's nasal module provides functions that return the configuration pieces needed to configure such utility components for the instrument (which is done at the per-aircraft level). E.g. the aircraft might use a MP property to encode 32 switches/buttons - that encoder component would be configured with to handle switches from from several instruments. It should be cool to have a single instrument to be used for both of the dual-control aircraft. Hmm, I suppose you mean for both the normal and the dual control aircraft? To make an instrument dual control enabled one does not, at least in principle, need to modify the instrument 3d object at all, and the XML model file only if the pick animations isn't already going through Nasal wrappers. So what is needed is a modified Nasal module for the instrument but (except for the code bloat) it would work fine also for the single user case (since it anyway has to work when there isn't any copilot around). However, in practice I ended up forking the 3d objects too for quite a few instruments since I wanted to use a different pick animation style (I don't fancy the hotspot rectangles :) (But OTOH my input style is not friendly to people without a mouse wheel and/or MMB.) Speaking of that, maybe we should try to figure out a common style or best practice for pick animations? I like the point at the control, LMB inc, MMB dec and mouse wheel inc/dec style, but it isn't too friendly to people without a fully featured :) pointing device. I'm not too fond of the flat hotspot like rectangles since they end up in non obvious places when the instrument is far away on the other side of the cockpit. I am very much interested in this feature to implement it into the SenecaII, but I feared so far, that I have to double all instruments. I haven't spent to much time yet to understand how dual control works, though. Gearing up the SenecaII for dual control will be a handful, yes :) But I think you can do it with it without changing your 3d objects - only XML and Nasal work needed. Look in Aircraft/ZLT-NT/Systems/ZLT-NT-dual-control.nas to get some idea of the per-aircraft configuration. Aircraft/ZLT-NT/DualControl/Instruments/VHF-22/ctl22.nas is an example of a dual control instrument. One could imagine splitting such a instrument module into the basic single user instrument and a module that (when needed) can wrap around it and add the dual control parts while still using the original module for the actual operations of the instrument. Hmm, that's yet another item on my TODO list :) Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
2009/3/20 Mathias Fröhlich wrote:
Ok.
But from my point of view the property tree is also used as a reflection
framework to reflect objects state into the models/scripting/whatever. From
my
point of view, the serialization of the objects into xml is just a special
case of that reflection stuff. Given that, you might consequently want to
reflect
more complex types by the properties.
The aggregate types are all constructed as combinations of our simpler
types. I think what I would propose is we could add an API layer which
could read or write a node as an aggregate type, but internally it would map
these complex types to a parent node with several children. So our current
xml tools and property tree manipulation tools would all continue to work as
before, but an additional higher level function call would make the node and
it's children optionally appear as a more complicated aggregate type. For
instance, considure the following property tree entries:
/engines/engine[0]/rpm-history-arr/value[0] = 2200;
/engines/engine[0]/rpm-history-arr/value[0] = 2201;
/engines/engine[0]/rpm-history-arr/value[0] = 2201;
/engines/engine[0]/rpm-history-arr/value[0] = 2200;
.
.
.
/engines/engine[0]/rpm-history-arr/value[999] = 2198;
We could access this with a new convenience aggregate accessor (untested)
:-) The accessor functions would use some simple conventions to assemble
and return an aggregate structure based on the simpler property tree
represenation:
vectordouble rpm =
fgGetDoubleVector(/engines/engine[0]/rpm-history-arr);
vectordouble rps;
for ( unsigned int i = 0; i x.size(); i++ ) {
rps[i] = rpm[i] / 60.0;
}
fgSetDoubleVector( rps );
In this case, fgGetDoubleVector() would traverse the
/engines/engine[0]/rpm-history-arr parent node and find any children called
value. It would take their individual values and copy them into a
vectordouble and return that to the calling layer.
Similarly, fgSetDoubleVector() would traverse the provided vectordouble
and write each subsequent value as a child called value[n] underneath the
specifed node.
Because we haven't changed the property system, this same example could also
be written using the current API like this (untested pseudo code):
rpm_node = fgGetNode(/engines/engine[0]/rpm-history-arr);
rps_node = fgGetNode(/engines/engine[0]/rps-history-arr);
unsigned int size = rpm_node.num_children();
for ( unsigned int i = 0; i size; i++ ) {
tmp = rpm_node.get_child(i).getDoubleValue();
rps_node.get_child(i).setDoubleValue( tmp / 60.0 );
}
Nothing in the core/underlying property system would need to change, we
could just add some additional convenience functions that would map more
complex structures back and forth to a traditional property tree
representation. It's nothing that individual functions couldn't already do
themselves, so I don't see a problem with adding some additional API calls
if this is a convenience that could be used throughout the application.
My only additional comment is that if this approach is objectionable due to
performance or space considerations, then perhaps the property tree is not
the best place to be storing this data in the first place.
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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Hi, Stuart Buchanan schrieb am 20.03.2009 16:22: My immediate thought is that one could write some fairly straightforward code to interpret a given property node with 3 child values as a Vec3. Could we subvert the property attributes to indicate that a given nodes contains a Vect3. That way internal code could interpret it as a Vec3, while external interfaces would be preserved. Or we do it vice versa. We store the vec3 directly in the property tree, e.g.. surface/color, but you can access any components over the property tree in the approved way. (surface/color/red, curface/color/blue, ...). From telnet, MP, property-browser, etc. everything keep unchanged, but from c++ you can directly access the vec3. We even can allow to store any (?) class directly in the property tree. The class must present functions to map it's components to the property tree in the common way. The nodes and actual basic datatypes would be just classes as any other class in the property tree. We even can take care, that a cast from and to the basic datatypes must be present. By mapping of all class members to the property tree in the approved way, we are able to ex- and import the property tree via xml. Best regards, Maik -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Maik Justus wrote: Hi, Or we do it vice versa. We store the vec3 directly in the property tree, e.g.. surface/color, but you can access any components over the property tree in the approved way. (surface/color/red, curface/color/blue, ...). From telnet, MP, property-browser, etc. everything keep unchanged, but from c++ you can directly access the vec3. We even can allow to store any (?) class directly in the property tree. The class must present functions to map it's components to the property tree in the common way. The nodes and actual basic datatypes would be just classes as any other class in the property tree. We even can take care, that a cast from and to the basic datatypes must be present. By mapping of all class members to the property tree in the approved way, we are able to ex- and import the property tree via xml. I have the feeling this will become a developers nightmare, give the number of possibilities to access the property tree.. But if anyone feels brave enough, be my guest. Erik -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
I have the feeling this will become a developers nightmare, give the number of possibilities to access the property tree.. But if anyone feels brave enough, be my guest. Erik I've thought, from time to time, about a units extension to the property system. I've also thought at times that it would be nice to be able to handle vectors. I always came back to the conclusion that this would be a really bad idea. And it still is. If anyone feels that this is something worth looking into, it needs to be done separately from the FlightGear development tree, perhaps as a proof of concept in a smaller project. Then, let people loose on it and see how they use it (and break it). There is a beauty in the simplicity of the way things are done, now. It can be clunky in some cases, but the alternative is mass confusion. I'd very strongly advise against this idea. Jon -- 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
[Flightgear-devel] RFC: vector types in the property system
RFC: Vector Types in the Property System Proposal: Allow vector types as properties in property list XML files and as properties in the runtime property system. The syntax in an XML file would look like: parameters material diffuse type=vec4d .2 .4 .6 1.0 /diffuse specular type=vec4d .4 .5 .7 1.0 /specular uniform namesky-direction/name value type=vec3d0 0 1/value /uniform /material /parameters Existing 3D XML file formats, like Collada, support this syntax for vector values such colors. Rationale: Without these types, the XML syntax is much more verbose: parameters material diffuse r.2/r g.4/g b.6/b a1.0/a /diffuse specular r.4/r g.5/g b.7/b a1.0/a /specular uniform namesky-direction/name value x0/x y0/y z1/z /value /uniform /material /parameters Furthermore, C++ code that reads and writes the color values has to process the child properties, looking them up by name and traversing children. Whether or not this costly, it is much more straightforward to fetch all values at once from a property node. It is irritating to code around the mini-tree of values at each aggregate property, especially when the value is immediately written into an Open Scene Graph object. API: The vector properties are represented in C++ as Open Scene Graph Vec3d and Vec4d objects. SGPropertyNode has two new template member functions: templatetypename T T SGPropertyNode::getValue() const; templatetypename T bool SGPropertyNode::setValue(const T val); These work like the existing property node getter and setter functions, e.g. getFloatValue() and setFloatValue(), for either the basic atomic types or Vec3d or Vec4d. If the actual type of the property node is STRING or UNSPECIFIED, the value is read from the string. If the type T in the template and the property type are not the same but are basic types, the existing conversion rules are used. Otherwise, a default value , typically 0, is returned. In Nasal code, getValue() returns a vector of length 3 or 4 for vector valued properties. setValue() can be passed a vector argument which will be passed as a Vec3d or Vec4d to SGPropertyNode::setValue. Implementation: The SGRawValue classes are changed to return type information. A new class, SGRawExtended, is added that can store the value of a property node in allocated storage outside of the node. The type is also stored in the SGRawExtended object. The changes are available in git://repo.or.cz/simgear/timoore.git and git://repo.or.cz/flightgear/timoore.git in the topic/property branch. Discussion: The property system is very useful and I want to use it for implementing effects. However, I find the syntax way too verbose for simple aggregate properties like colors. With the proposed changes effect files can be property lists, and effects values can easily be represented as property trees, while still preserving a concise syntax. I'm not proposing to change any existing property to an extended property. -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
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. Tim -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Erik Hofman wrote: Melchior FRANZ wrote: How will a VEC3 property be written in an XML file? As foo type=vec3123;341;123/foo? Will then every application which reads such a file have to have its own (sub)parser for certain fields, in addition to using an XML parser? This is my strongest point to be against it. The property tree is there for easy xml file loading and saving. I can see no obvious way to save those VEC properties to an xml file in a way that is supported by the xml specification. What do you mean by that? Other XML file formats with strict DTDs support similar notes of aggregate properties. If your application is smart enough to write out red.../redgreen.../green then it can surely handle writing out a vector type. It is impossible at this time to say whether or not that is desirable at all in the future so this option should be left open. Aside from that is see no reason to add them in the first place. I hope my RFC makes the motivation clear. Tim -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Melchior FRANZ wrote: * Buganini -- Friday 20 March 2009: IMO, if these compound types are unavoidable, [...] They are very much avoidable. We've had colors and coordinates since *ages*. And what next? If we have VEC3, then what about POSITION, which contains latitude/longitude/altitude, and ORIENTATION with heading, pitch, roll, Those are all... Vec3d or Vec4d. That's no coincidence; these are useful types that can represent a lot of different kinds of values. and FONT with name, size, slant, and ... Most of those attributes seem optional, whereas there aren't really optional parts of a color or orientation. Once we give up atomicity and start throwing things together, there's no logical end to it. And no, that change is *not* needed. I'm not impressed by the slippery slope argument. Good programming style always requires good taste. Tim -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Stuart Buchanan wrote: I think it would be good for Tim to explain why more complex types are required, as I'm sure he will do shortly :) My immediate thought is that one could write some fairly straightforward code to interpret a given property node with 3 child values as a Vec3. Could we subvert the property attributes to indicate that a given nodes contains a Vect3. That way internal code could interpret it as a Vec3, while external interfaces would be preserved. Like Erik, I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. I'm just trying to make the surface syntax for some types more clear. Tim -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Melchior FRANZ wrote:
This will probably become a flame-war, but I see no way to avoid
it. Tim plans to extend the property system with compound data
types, such as VEC3, VEC4, or COLOR. We've discussed this three times
in IRC, and I've always pointed out why this is IMHO a *BAD* thing,
and why I strongly object. But now he has implemented it in his
source, and made that the base of further (desirable!) features.
I don't want a flame war with Tim, but this needs to be decided
*now*. Otherwise we might end up having to decide whether we want
the (IMHO) evil property change *and* the nice features, or
neither. And that's not how a decision about one of our foundations
should be made!
(To Tim's defense, he had planned to write an RFC to the devel list
about it, though he also intended to commit parts of the change before
that. And to my defense: I have told him that if he doesn't write the
RFC *soon*, then I will bring it up on the list!)
I'll get my flaming out of the way first off. I'm very disappointed that
you launched the discussion in this way. I explained to you in private
email why it was inconvenient for me to write an RFC right at this time,
promised not to check any major changes to the property system in until
there had been a discussion and favorable consensus, and pushed my code
to a public Git repo for you to examine. Now there are 18 emails on the
list responding to your channeling of... a mixture of our IRC discussions
and the code, I guess.
I am only proposing to add Vec3d and Vec4d properties, not COLOR or POSITION
or whatever. However, I wouldn't be opposed to other multi-value types such
as Matrix4x4.
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;
};
Actually, in C++ it's often accessed using array accessor syntax, like
color[0], or you refer to the whole color as color.
That is: each component is a basic standad type and can be accessed
as such, but the whole structure can be passed as one, too. The
property system contains the standard types from C++: BOOL, INT, LONG,
FLOAT, DOUBLE, STRING (= char*), as well as UNSPECIFIED and NONE.
Subsystems publish values in these basic types and access data from
other subsystems. This is done from within C and C++, from Nasal,
via property browser, property display (on screen), and remote
access is possible via telnet/socket, http, protocols, or properties
are just loaded from XML files directly into the tree.
All data types can be read as any other datatype (except the special
ones UNSPECIFIED and NONE), in which case the data are converted
appropriately and as one would expect. It's possible to read a BOOL
into a double, and to write a double to a LONG. The property system
is one of the foundations of FlightGear and has worked very well for
a long time.
I agree with the importance of the property system, but automatic
conversion is mostly a crock. What's the boolean value of .01? Of
.1? Of -.1? Actual types matter, even if there are
default conversions.
Tim's planned patch will IMHO degrade the system and remove essential
properties. How should such a VEC3 property be displayed in the
property browser? In one line, separated by semicolons? Will everyone
who reads the data have to write parsers for the compound type?
The RFC describes how these vector types are written: with spaces between
the values. Maybe I'm showing my naivete, but who's writing parsers that
isn't using libsgprops?
But this last objection, and many that follow, assume that, wholesale,
properties up and down the property tree will be changed to use this
new feature. I'm not proposing that. If the vector properties are so
viral, perhaps that's a good problem to have.
How will one attach a GUI slider to the red property, if it doesn't
have its own property path, but is thrown together with other
properties?
Can you point me to an example of this? Otherwise I'd say write some
Nasal.
What happens if I write a bool value to a VEC3 property? Will it set
all three values to 0 or 1, or only the first? Or will it return an
error? What will I get if I call getIntValue() on a VEC3 property?
It's well defined; basically 0 is the result. But I can't believe that
writing a bool to the red child of a color gives you a sensible result,
even though it's defined to be the value 1. If you're writing a bool
to a color component, shouldn't you fix your buggy code?
What happens when I read out a color via telnet? Will I get
0.123;0.5;0.6667? Will people have to learn that the first of
them is red, the second blue, and the third green?
Is this serious?
Will input fields in remote applications (instructor) have to write
special
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Curtis Olson wrote: On Fri, Mar 20, 2009 at 10:22 AM, Stuart Buchanan wrote: Melchior FRANZ wrote: This will probably become a flame-war, but I see no way to avoid it. I think you laid out your position in a very well thought out and fair manner, backed up with many reasonable points and/or questions. If the replies to this thread have a similar tone and include any thought and insight, we shouldn't have a problem. :-) I can imagine an alternate perspective so I'm looking forward to hearing that too. It's customary to wait for an RFC before arguing against it :) Our current property system seems to match up well with C's view of data types. Yes, but less well with a C++ world of more complex types. I know there's a tension when deciding what members of an aggregate to treat as naturally grouped and which to make accessible, but the current property system doesn't leave any choice. As Melchior points out, we have always represented records/structs as a subtree of properties hanging off a node. Arrays have been represented using numbered nodes as in ... pos/vec[0], pos/vec[1], pos/vec[2] or pos vec1.1/vec vec0.5/vec vec-0.2/vec pos or more verbosely: pos vec n=01.1/vec vec n=10.5/vec vec n=2-0.2/vec pos The main argument I can anticipate for adhoc aggregate types would perhaps be some sort of performance/space argument. If you want to store and retrieve a boatload of vectors in the property system, having a child node for each array element of each vector consumes extra space, and you burn extra time accessing the individual elements. And an aggregate type could be setup to have a better direct mapping to the required OSG/OpenGL form of the data which would eliminate the need to convert the value each time it is accessed. This is true, but I'm mostly concerned with surface syntax. But as Melchior points out, doing this sort of thing could open up a big can of worms, and if space and access time is a key consideration, then is the property system the best place for that sort of data? I don't see why not. The property system is a wonderful blackboard where all parts of fg communicate. I think we should be doing more to make it faster, multi-thread safe, reflect it across machines, etc. If we start doing aggregate types, do we jump in with an adhoc approach and create a few things here and a few things there as needed? This seems to me to have the potential to explode in to a mess of accessor fuctions and near-duplicate code that would be required for each new type or variant. Perhaps *if* we want to extend the supported property types, we should think *very* carefully about the overall design of the property system. Do we add support for arrays? Could that be done in a reasonable manner, and could that be leveraged for Tim's needs? Most of the key opengl data types are things like float or int arrays. My immediate thought is that one could write some fairly straightforward code to interpret a given property node with 3 child values as a Vec3. Could we subvert the property attributes to indicate that a given nodes contains a Vect3. That way internal code could interpret it as a Vec3, while external interfaces would be preserved. I like this approach. We could easily write some helper functions that would deal with aggregate types at a higher level. Internally, they are still represented with the current property system, but a helper function could collect all the children values of a node and present them as an array of floats for instance. This would have a time/space overhead, but again, if that's a problem, then that might be a sign that the property system isn't the best place to store that data. I'll do this if the RFC is shot down, but it doesn't solve the problem of ugly surface syntax. Also, I think the property system is a great place to dump data :) Like Erik, I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. If we do move towards aggregate types, would we take a more object oriented approach to data representation? It would be nice to have the flexibility to then represent arbitrary collections of data like a C++ class. But if we do that, we really should support the concept of inheritant, and what about attaching functionality/classes to the data. I haven't really thought about that yet. But I'd still be interested in hearing Tim's perspective so I don't have to guess at what that might be. :-) Tim -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Erik Hofman wrote: Mathias Fröhlich wrote: But from my point of view the property tree is also used as a reflection framework to reflect objects state into the models/scripting/whatever. From my point of view, the serialization of the objects into xml is just a special case of that reflection stuff. Given that, you might consequently want to reflect more complex types by the properties. Allright but how would you acces /model/skin/color/red in the new case then? What do you mean by access? In C++ or Nasal within fg, or in the XML parse within another app? Why would you want red without green and blue and maybe alpha? Tim -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Curtis Olson wrote: 2009/3/20 Mathias Fröhlich wrote: Ok. But from my point of view the property tree is also used as a reflection framework to reflect objects state into the models/scripting/whatever. From my point of view, the serialization of the objects into xml is just a special case of that reflection stuff. Given that, you might consequently want to reflect more complex types by the properties. The aggregate types are all constructed as combinations of our simpler types. I think what I would propose is we could add an API layer which could read or write a node as an aggregate type, but internally it would map these complex types to a parent node with several children. So our I'll repeat that the code to translate back and forth between our current property node aggregates and aggregate C++ types is not a real problem coding-wise. I just don't like the current XML syntax. Tim -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Jon S. Berndt wrote: I have the feeling this will become a developers nightmare, give the number of possibilities to access the property tree.. But if anyone feels brave enough, be my guest. Erik I've thought, from time to time, about a units extension to the property system. I've also thought at times that it would be nice to be able to handle vectors. I always came back to the conclusion that this would be a really bad idea. And it still is. If anyone feels that this is something worth looking into, it needs to be done separately from the FlightGear development tree, perhaps as a proof of concept in a smaller project. Then, let people loose on it and see how they use it (and break it). There is a beauty in the simplicity of the way things are done, now. It can be clunky in some cases, but the alternative is mass confusion. I'd very strongly advise against this idea. If you have a different response to the actual RFC, I'd like to see it. Tim -- 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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
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
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
On Sat, Mar 21, 2009 at 1:49 AM, Curtis Olson curtol...@gmail.com wrote: 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. I share this opinion. In fact, I like that the color components are written out, less possibility for confusion (RGBA? ARGB? BGRA?) At my workplace we use lot of xml files and we avoid parsing text content wherever possible. We mostly use generated xmls, though, so I can accept that if somebody is creating xmls by hand it might be more convenient to just dump all 4 values into a single tag. Having a specialized color type instead of vec3d/vec4d seems a better idea to me (if all we are talking about is color). Note also, we *do* write x-m0/x-my-m0/y-mz-m0/z-m for position vectors too and nobody died yet :) On the C++ side, I don't object that strongly to adding vector or color types, but adding support for arbitrary types would be more difficult. To bring up MP as an example, we now handle the serialization in the MP code, and not in the property code. For arbitrary types, this would have to change. For the suggested vector types we could still extend the MP code in place, although maintaining backward compatibility might be tricky. I also wonder if property change listeners should get an additional argument, giving the index of the changed item. But of course the change would need to be detected first, which basically means we can not directly expose a writable vec3d/4d contained in the property. (I apologize for not having looked at the code in git yet, feel free to ignore any part of the above that is already addressed by the code) What other xml tools would read/write our files anyway? TeXnicer on the IRC channel has been working on xsl stylesheets for (at least) joystick configuration files, see here for an sample: http://141.76.121.6/~lego/projects/flightgear/X52/demo/Joysticks/Saitek/Jester.xml. I imagine parsing text content from xsl could easily prove a nightmare. Not that I know a sensible application for that right now. -- Csaba/Jester -- 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
