Re: [Flightgear-devel] RFC: graphics effects files
Hi Melchior, Melchior FRANZ wrote: * Curtis Olson -- Sunday 05 April 2009: Without seeing anything so far that I would consider a compelling argument against, I vote for giving Tim the green light here. Developer convenience has almost always been a good enough reason in the past. OK. Unfortunately, this is a route that I can't go with the project. I better watch that from outside. I still claim ownership of the bo105 and will probably continue maintaining it after a longer pause (if I can keep my commit rights until then). All other areas that I maintained are free for adoption (gui, fg/nasal, new hud, voice, input). I'm very sorry you feel that this is such a critical issue that you wish to stop making your contributions to the project. You obviously feel very strongly about this issue, otherwise you wouldn't be considering such a drastic step. While I'm not convinced by Tim's arguments, I accept Curt's comment that this is new function that won't break anything that already exists. I'm prepared to wait and see what this means in terms of actual code, XML and properties. We already have some XML files that aren't completely part of the property system (IIRC, AI traffic, JSBSim configuration, materials.xml), and this is at least going to be part of that. Plus, it is a significant step forward from our current shader support, where the shaders are hardcoded into the source code, and difficult to use (which is at least partly my fault!). Finally, FG will always be a work in progress, and this decision isn't set in stone. If we find that we really need to split up these RGB value, I'm sure someone will be able to produce a patch. Therefore I'm not going to get too worked up about it - there are plenty of other things for me to worry about. FlightGear is, of course, a collaborative project and that means giving up some control in return for the benefits that it brings. Inevitably sometimes the project will go in directions you don't agree with. Personally, I feel that the benefits far outweigh the disadvantages. Feel free to respond to this on- or off-list. Best regards, -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Heiko Schulz wrote: Hi, Well, for someone who don't have any ideas or knowledge about shaders, it looks really complicated at the first sight. On the other site, it looks a bit like the .osg-files, and with a bit diggin in, it would be understandable for me at least. I'm sorry that there isn't any documentation for the graphics portion of these files. The example is intended only to motivate the property list discussion. Tim I guess it is a bump map for the towns and cities, right? I would really know from the developers who are against this style of code are, what are the issues with this? Where are the main problems and what would be alternatives? Shader support would be a great step forward! Regards HHS-- PropertyList effect namedefault-effect/name !-- inherits-fromanother-effect/inherits-from -- parameters material ambient type=vec4d 0.0 0.0 0.0 1.0 /ambient diffuse type=vec4d .5 .5 .5 1.0 /diffuse specular type=vec4d 0.3 0.3 0.3 1.0 /specular emissive type=vec4d variance=dynamic 0.0 0.0 0.0 1.0 /emissive shininess1.2/shininess /material texture0 texture2d imagecity.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture0 texture1 texture2d imagedetail.png/image filterlinear-mipmap-linear/filter !-- also repeat -- wrap-sclamp/wrap-s wrap-tclamp-to-edge/wrap-t !-- wrap-rclamp-to-border/wrap-r -- !-- float, signed-integer, integer -- internal-formatnormalized/internal-format /texture2d /texture1 bump-height type=double.05/bump-height pattern-rotation type=vec4d0 0 1 1.5708/pattern-rotation /parameters technique predicate or less-equal value2.0/value glversion/ /less-equal and extension-supportedGL_ARB_shader_objects/extension-supported extension-supportedGL_ARB_shading_language_100/extension-supported extension-supportedGL_ARB_vertex_shader/extension-supported extension-supportedGL_ARB_fragment_shader/extension-supported /and /or /predicate pass lightingtrue/lighting material ambientusematerial/ambient/use/ambient diffuseusematerial/diffuse/use/diffuse specularusematerial/specular/use/specular shininessusematerial/shininess/use/shininess /material texture-unit texture2dusetexture0/texture2d/use/texture2d /texture-unit texture-unit texture2dusetexture1/texture2d/use/texture2d /texture-unit shader-program uniform namebumpHeight/name typefloat/type usebump-height/use /uniform uniform namepatternRotation/name typevec4d/type usepattern-rotation/use /uniform vertex-shader Shaders/util.vert /vertex-shader vertex-shader Shaders/foo.vert /vertex-shader fragment-shader Shaders/foo.frag /fragment-shader /shader-program /pass /technique technique pass lightingtrue/lighting material ambientusematerial/ambient/use/ambient diffuseusematerial/diffuse/use/diffuse specularusematerial/specular/use/specular /material texture-unit texture2dusetexture0/texture2d/use/texture2d /texture-unit /pass /technique /effect /PropertyList Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Curtis Olson wrote: I don't have time to follow along with IRC so I can only see what is posted to the mailing list, so I very well could be missing key parts of this discussion. But honestly, I am really having trouble understanding the objection here. The biggest problem that I would have is that initially it sounded that the red, geen and blue properties would be *replaced* with a vector based one. I don't like that principle as a modeller. Therefore I've asked Tim if that's the case.And if it is I still object. Adding shader support using xml files is not something I would object to. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Sat, 2009-04-04 at 20:54 -0500, Curtis Olson wrote: Since the beginning of time, computers have included the concept of arrays. Since the birth of the property system in FlightGear, it has supported booleans, integer, floating point, and double floating point types. The property system has also always supported character arrays. To claim the property system supports character arrays is wrong, and somewhat disingenuous. The property system supports strings as atomic units. You can not access the nth character of a string nor can you change only the nth character of a string like you could if it were an array. The property system serves as a human interface as well as interfacing between subsystems. Melchior expressed his very deep, very real, very valid concerns better than I can in his initial e-mail http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21558.html I have heard nothing to address his vital questions. How should such a property be displayed in the property browser? Or the web interface? Or the telnet interface? 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 we input VEC3 properties via the property browser? As he is currently the primary coder in the GUI and interface department he is in the best position to foresee problems. I urge you to trust his judgment. The property system supports implicit conversions between types if that is asked for, and always makes it's best attempt. But if you ask for something nonsensical or poorly defined, you will get something back based on the rules of the system, but it may not make a lot of sense. If you try to extract the floating point value of a string (aka character array) you get something back based on the rules of the system, but what if you try to retrieve the floating point value of abcdefg. It doesn't make sense, you probably won't get a useful answer although you will get something. It's up to the calling routine to make sensible requests. It's always been that way, it will always be that way. Now, the message I am getting here is that some people think it's unacceptable to also support double or float arrays within the property system. Count me in as some people From the e-mail traffic on this list, some people also include some very talented developers: Jon Berndt: I always came back to the conclusion that (vectors) would be a really bad idea. And it still is. Erik Hofman: I have the feeling this will become a developers nightmare LeeE: This strikes me as an extremely bad idea. Stuart Buchanan: 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. Csaba Halász: I like that the color components are written out, less possibility for confusion (RGBA? ARGB? BGRA?) It can't be because arrays are messy because we already support character arrays. It can't be because some conversions wouldn't make sense, because we already have that situation. It can't be because it makes the property subsystem too complex, because Melchior, to be fair, you are the king of creating very complicated systems (with correspondingly high functionality.) I don't mean that as a diss ... I'm just observing that you have put together some highly complex systems full of subtle nuance within the flightgear code base. Melchoir has done much to enhance the usability and elegance of most of our systems. Initially I was not a fan of all the nasal code, but I have come to greatly appreciate its functionality and power. I don't have time to follow along with IRC so I can only see what is posted to the mailing list, so I very well could be missing key parts of this discussion. But honestly, I am really having trouble understanding the objection here. I fail to see what is going to break, what is going to end, what harm is going to be done. Is there a direct conflict in logic? Is there a non-othogonality in design? Is there some behind the scenes fued going on that I'm (thankfully) unaware of ... in that case I'll quit trying to draw out logical reasons for your objections? I'm married so I'm continually caught trying to find logical explanations where there are none. :-) I'm not suggesting that's the case here, but if it is, we might as well say it clearly so I don't have to waste my time trying to understand what's going on. I asked Tim if it would make sense to just support generic double or float arrays in the property system ... just like we support character arrays. However, he replied that you were even more opposed to that than specific color or position array types. Again, I fail to understand why. I could be easily missing something here, I'm not claiming I have an all seeing eye. But
Re: [Flightgear-devel] RFC: graphics effects files
Ron Jensen wrote On Sat, 2009-04-04 at 20:54 -0500, Curtis Olson wrote: Since the beginning of time, computers have included the concept of arrays. Since the birth of the property system in FlightGear, it has supported booleans, integer, floating point, and double floating point types. The property system has also always supported character arrays. To claim the property system supports character arrays is wrong, and somewhat disingenuous. The property system supports strings as atomic units. You can not access the nth character of a string nor can you change only the nth character of a string like you could if it were an array. The property system serves as a human interface as well as interfacing between subsystems. Melchior expressed his very deep, very real, very valid concerns better than I can in his initial e-mail http://www.mail-archive.com/flightgear- de...@lists.sourceforge.net/msg21558.html I have heard nothing to address his vital questions. How should such a property be displayed in the property browser? Or the web interface? Or the telnet interface? 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 we input VEC3 properties via the property browser? As he is currently the primary coder in the GUI and interface department he is in the best position to foresee problems. I urge you to trust his judgment. The property system supports implicit conversions between types if that is asked for, and always makes it's best attempt. But if you ask for something nonsensical or poorly defined, you will get something back based on the rules of the system, but it may not make a lot of sense. If you try to extract the floating point value of a string (aka character array) you get something back based on the rules of the system, but what if you try to retrieve the floating point value of abcdefg. It doesn't make sense, you probably won't get a useful answer although you will get something. It's up to the calling routine to make sensible requests. It's always been that way, it will always be that way. Now, the message I am getting here is that some people think it's unacceptable to also support double or float arrays within the property system. Count me in as some people From the e-mail traffic on this list, some people also include some very talented developers: Jon Berndt: I always came back to the conclusion that (vectors) would be a really bad idea. And it still is. Erik Hofman: I have the feeling this will become a developers nightmare LeeE: This strikes me as an extremely bad idea. Stuart Buchanan: 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. Csaba Halász: I like that the color components are written out, less possibility for confusion (RGBA? ARGB? BGRA?) It can't be because arrays are messy because we already support character arrays. It can't be because some conversions wouldn't make sense, because we already have that situation. It can't be because it makes the property subsystem too complex, because Melchior, to be fair, you are the king of creating very complicated systems (with correspondingly high functionality.) I don't mean that as a diss ... I'm just observing that you have put together some highly complex systems full of subtle nuance within the flightgear code base. Melchoir has done much to enhance the usability and elegance of most of our systems. Initially I was not a fan of all the nasal code, but I have come to greatly appreciate its functionality and power. I don't have time to follow along with IRC so I can only see what is posted to the mailing list, so I very well could be missing key parts of this discussion. But honestly, I am really having trouble understanding the objection here. I fail to see what is going to break, what is going to end, what harm is going to be done. Is there a direct conflict in logic? Is there a non-othogonality in design? Is there some behind the scenes fued going on that I'm (thankfully) unaware of ... in that case I'll quit trying to draw out logical reasons for your objections? I'm married so I'm continually caught trying to find logical explanations where there are none. :-) I'm not suggesting that's the case here, but if it is, we might as well say it clearly so I don't have to waste my time trying to understand what's going on. I asked Tim if it would make sense to just support generic double or float arrays in the property system ... just like we support character arrays. However, he replied that you were even more opposed to that than specific color or position array types. Again, I
Re: [Flightgear-devel] Scene ambient and specularcolor changes
Melchior FRANZ wrote: * Vivian Meazza -- Saturday 04 April 2009: This is how I think it should look, Does indeed look much better here (on my *still* quite bad monitor ;-). Alright I've updated the ambient table (multiplied all values by 2.5) Let me know what you all think with the CVS version of src/Time/light.cxx The default values might well have been modeled after a lightbulb in a room instead of the sun in a skydome environment. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
Erik wrote Vivian Meazza wrote: I'm doing a small adjustment in light.cxx - seems to work: float ambient = _ambient_tbl-interpolate( deg ) + (0.25 + 0.75 * visibility_inv/10); Not sure that I fancy tinkering around in Data/Lighting/ambient - someone has obviously taken a lot of care to craft that one. Well you *are* since you are adding 0.25 to ambient. In fact this changes [0.04 - 0.2] to [0.254 - 0.45] It's easier to test that way! And haven't I also reduced the effect of visibility by a small amount? I've now amended the table to reflect the static offset, and I'm happy with the result. Do you want proceed with this, or just drop it? Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Erik Hofman wrote: Tim Moore wrote: If people really don't like the effects syntax, I might be willing to hold my nose and use the existing property implementation. I'm also not committed to having the effects properties be of class SGPropertyNode; they might be a subtype. I have two questions after reading this: 1. Will ambient/r, ambient/g and ambient/b still be supported in other locations besides xml embedded effects en techniques? That's my plan. 2. As I see this now this is a way to define custom (not hardcoded) effects. This means only a small number of these configuration files will be created and probably only by developers who know what they are doing. Am I right? That's hard to predict. We'll probably have a set of standard effects that modelers will use most often, but if someone wants to write their own shader program, they would write an effects file too. I hope that, because of effects file inheritance, most files will be shorter than this example. Tim If both answers are 'yes' then I see no problem with adding it, otherwise there's still gonna be a bit of discussion I guess. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
Vivian Meazza wrote: I've now amended the table to reflect the static offset, and I'm happy with the result. Even at midnight? I was worried the ambient might be too light with a static offset. Do you want proceed with this, or just drop it? Lets get it right this time. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
Erik Melchior FRANZ wrote: * Vivian Meazza -- Saturday 04 April 2009: This is how I think it should look, Does indeed look much better here (on my *still* quite bad monitor ;-). Alright I've updated the ambient table (multiplied all values by 2.5) Let me know what you all think with the CVS version of src/Time/light.cxx Looks nice here, I hope others will agree. The default values might well have been modeled after a lightbulb in a room instead of the sun in a skydome environment. That seems entirely possible. Lovely weather at KSFO for testing atm, and lovely weather outside here for observing and comparing light and shadows. Now for shadows, shaders, and we will be motoring. Sorry, our posts crossed Thanks Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Timothy Moore wrote: Erik Hofman wrote: 1. Will ambient/r, ambient/g and ambient/b still be supported in other locations besides xml embedded effects en techniques? That's my plan. Ok, that's good to hear. I think this will eliminate many of the objections. Except for a few inconsistencies in xml style that already have been mentioned I think it's worth adding it then. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
Erik wrote Vivian Meazza wrote: I've now amended the table to reflect the static offset, and I'm happy with the result. Even at midnight? I was worried the ambient might be too light with a static offset. Do you want proceed with this, or just drop it? Lets get it right this time. I think it's as right as we are going to get it, given all the unknowns about the objects and the scattering particles in the environment at any time or place. I think the purists would argue that we ought to adjust the ambient values for altitude as well. There is much less ambient light once you leave the atmosphere. Perhaps we can do that at a later date, when we have an external model for the Shuttle. (This is also known as hitting the problem into the long grass :-) ). Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Erik Hofman wrote: Heiko Schulz wrote: Hi, Well, for someone who don't have any ideas or knowledge about shaders, it looks really complicated at the first sight. On the other site, it looks a bit like the .osg-files, and with a bit diggin in, it would be understandable for me at least. I guess it is a bump map for the towns and cities, right? I would really know from the developers who are against this style of code are, what are the issues with this? Where are the main problems and what would be alternatives? Shader support would be a great step forward! True, but there are tow ways of doing it; * hardcode the effects that are needed * add the ability to make custom, configurable effects files. To be honnest, I don't expect that many custom effects files will be created and the ones that are created are going the be used by almost all modellers. This sounds like hardcoded will be just fine. I don't think so. Artists and modelers like to play with shaders, even if initially they might not understand the programming behind him (the shader might come from a shader generation tool, for example). Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Good morning, this is yet another mail in support of rethinking the current proposal: All the mentioned features regarding XML based shaders support are indeed very much desirable in FlightGear, but the proposed changes and approach, as well as the posted snippet of XML effects in particular, just don't seem in line with long-standing and proven FlightGear conventions or the modular design and implementation of the original property tree code in the first place. This applies in particular because all of the desirable functionality can apparently be implemented by using existing infrastructure and conventions, as has been demonstrated by various postings illustrating viable alternative and even better approaches using the existing API and conventions. But also because this proposal doesn't seem to really directly improve or benefit any other FlightGear components, which raises the question if implementing support for new primitive types in the global, system-wide property tree really is a good solution in this case? This also seems questionable because it introduces changes (namely new primitive types) to the property tree system that appear highly subsystem-specific, and irrelevant to or even incompatible/unsupported with the rest of FlightGear? Wouldn't these properties be highly specific to just one component and use in FlightGear (unlike any other feature of the property tree)? Wouldn't this create additional baggage in the property tree code that is not even remotely useful in other areas of FlightGear? Wouldn't they create yet another way of doing things [no matter how concise]? So it really appears to boil down to enhancing a proven and central FlightGear component with support for new types in order to accommodate the needs of one particular FlightGear system. The most often cited reasons I could find were: I find the sytntax way too verbose for simple aggregate properties like colors. More concise syntax for aggregate values I think XML is way too verbose I just want to evolve the very useful property system to support the syntax I like It seems, all previously posted technical arguments (atomicity of updates and performance considerations) were shown to be addressable by using a more conventional approach, using listeners and tied memory? So is this really not just about syntactical sugar? What real technical advantages are there (apart from the more concise syntax), advantages that are not just specific to one specific feature or component and that are not addressed by any of the previously suggested alternatives? regards -hfitz -- Get even more from your private email hosting service. Visit the pages of Zoner Software and download your free copy of the Zoner Photo Studio 11 program today! Learn more - www.zoner.com. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Count me in as some people From the e-mail traffic on this list, some people also include some very talented developers: ?Jon Berndt: I always came back to the conclusion that (vectors) would be a really bad idea. And it still is. The more information I get about the proposal to support vectors as stated, the less concerned I am. FlightGear uses properties pretty much for data input as far as I can tell. JSBSim does that, but also generates properties on the fly and connects them up at runtime and performs specified function operations (of any complexity) on them. Having to handle type checking on anything other than the double which is assumed might complicate things. If the new changes are backwards compatible in code, then it may not end up being a problem. JSBSim uses some elements of simgear (properties and xml handling), and if the props.[ch]xx code (for instance) gets changed a lot, I'm concerned that it may negatively impact our operations. I understand that it should not impact us, and that we should be OK. But, sometimes in coding there are side effects and unintended consequences, and given the magnitude of the proposed change, I'm sure we'll proceed with due diligence. JB -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Second Class Properties (was: Re: RFC: graphics effects files)
Except for a few inconsistencies in xml style that already have been mentioned I think it's worth adding it then. Maybe I am misunderstanding this issue, but I have been involved in using FlightGear at work for a number of simulation related projects during the last couple of years, and to me some things are still unclear: Personally, my understanding of the property tree is that of an IPC enabling mechanism, that ties together all FlightGear subsystems and often also many non-FlightGear related tools/software even outside its own address space. So from my point of view, it is seems important to keep in mind that the property tree is not only about global variable storage but that it's also FlightGear's one and only standardized IPC mechanism, all subsystems and many FlightGear related tools that work outside the fgfs process space communicate with each other using the property tree and its natively supported types. With this in mind, it really seems of paramount importance that all property tree users (fgfs subsystems or external tools) have a concept and way of dealing with the native data types represented in the property tree. This exactly is it what makes the property tree, and more generally, FlightGear so intuitive, unobfuscated, powerful and easy to extend. This has been my experience when interfacing FlightGear to other software. Enhancing the property tree to support new component-specific native types that cannot be directly accessed, manipulated or processed by all or at least many other FlightGear related subsystems and tools seems like a troubling idea to me, in particular when it's not even foreseeable that other subsystems are going to develop a demand to also benefit from such a change eventually (just because they can already do all of this simply by using a more verbose, user-friendly and self-explanatory format that's been in use for years). Just think about some of the more complex systems that depend on having a full understanding of all property tree data and types, such as Nasal, the XML protocol system, the telnet interface to the property tree or the multiplayer system, all of which depend on working with arbitrary native property types. In its current form the property tree and its potential is virtually unrestricted and many new features were and still can be implemented on top of this very genericity without requiring modifications to the core implementation of the property tree. The natural tree-structure of XML and the natively supported data types allow users to emulate even complex data structures just by using the existing -admittedly verbose- syntax. But that's simply the cost of directly mapping XML to the key/value format used by the property tree. So the question really appears to be if FlightGear wants to end up with property types that are so purpose- and system-specific that only certain subsystems really know how to deal with them, essentially resulting in second class properties that cannot be processed by much of the currently existing FlightGear infrastructure? Basically, this is introducing a form of forced encapsulation into the property tree. I am not trying to dramatize this issue, this is just my current understanding of the likely repercussions. For the time being, the property tree system doesn't have a single feature (to my knowledge) that is really specific to just one single FlightGear component or purpose - the property tree code has been so well generalized that it can be equally used by all components, without restrictions. It just consists of primitives, building blocks that can be used to model more complex data structures on top of it. Changing this would probably not only result in second class properties but eventually also in second class subsystems and after some time also in second class software interfaces and tools, because not every property tree user may be able to deal with all of FlightGear's internals represented by such non-POD types. According to my understanding of the situation, this would be a very unfortunate situation. It seems logical and plausible from that from this point of view, this proposal would actually contribute to obfuscating FlightGear and degrading the current property tree system, which really is currently fully self-documenting and 100% open and accessible to all components. So adding new non-POD types raises not only the issue of inter-type conversions for such non-POD types, but also the issue of serialization for persistence/network transfer purposes (i.e. custom protocols, multiplayer). It seems to me, such additions may cause a whole new dimension of potential issues. It's obvious and understandable that, in the light of Tim Moore's very significant and highly appreciated contributions to FlightGear, it is very easy to overlook the potential architectural implications and ramifications in this proposal. Even if this is ultimately
Re: [Flightgear-devel] RFC: graphics effects files
Anders Gidenstam wrote:
On Sat, 4 Apr 2009, Tim Moore wrote:
1) Write the full vector every time a component is changed. This means
potentially 4 times the memory traffic to change a color, and leaves the
values stored in OSG in an inconsistent state for a time.
If efficiency is of the outermost concern you could tie each of the
components of a double vec[4] to properties, e.g.
color/{red,green,blue,alpha}. That would make it possible for the internal
C++ code to use the vector representation while still preserving a nicely
structured and typed property tree for external access.
The relevant values in OSG are protected members, accessed through getters and
setters, so you can't tie the value to be set directly. Uing a tie like this
just pushes
the problem downstream a bit; one would still need to jump through the hoops I
detailed
before in terms of pushing the new value(s) to OSG.
Tim
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Melchior FRANZ wrote: * Vivian Meazza -- Saturday 04 April 2009: less-equal? texture0, texture1. ? ambientusematerial/ambient/use/ambient ? I did't even look at that. The vector properties (that have already been rejected before) were enough for me to reject the whole second attempt to get this in. But I agree with all your points. That's fair, I've been disregarding pretty much everything you've said in this discussion ;) This does also not make sense to me: vertex-shader Shaders/util.vert /vertex-shader Why should any part of fgfs (or external apps) have to deal with stripping quotes around strings? Should be: vertex-shaderShaders/util.vert/vertex-shader or probably even better vertex-shader-path. Yep, that's a bug; quotes shouldn't be part of the syntax. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Melchior FRANZ wrote:
* Heiko Schulz -- Saturday 04 April 2009:
How would it be better, and would all what Tim wants to do,
be still possible?
The features that Tim is talking about (effects and stuff), and
the XML and property tree representation do IMHO not have much
to do with each other.
How can separate values be stored without vector property type:
Just like now. Every property (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the dynamic attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
I can't really imagine all possible uses, but people are clever
with animations, and one could imagine a fair number being changed
every frame.
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent color, and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. Of course, triggering the parent
would have to be done manually in the property browser or via
telnet, but that's certainly not the main use case and is IMHO
acceptable.
No intrusive changes with multiple bad side effects needed.
Sounds like a very brittle hack to me when the update would
just happen if the property were a vector.
Tim
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Sun, 5 Apr 2009, Melchior FRANZ wrote: * Curtis Olson -- Sunday 05 April 2009: Without seeing anything so far that I would consider a compelling argument against, I vote for giving Tim the green light here. Developer convenience has almost always been a good enough reason in the past. OK. Unfortunately, this is a route that I can't go with the project. I better watch that from outside. I still claim ownership of the bo105 and will probably continue maintaining it after a longer pause (if I can keep my commit rights until then). All other areas that I maintained are free for adoption (gui, fg/nasal, new hud, voice, input). So essentially since you may not get your way, you're going to take your ball and go home? WTF? 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_! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Gene Buckle -- Sunday 05 April 2009: So essentially since you may not get your way, you're going to take your ball and go home? You don't seem to understand this comparison. It's about taking something away so that others can't continue enjoying the game, only because one doesn't have his way. I am not taking anything with me. I'm just going home, because the others have changed the game from football to throwing in windows. And that's not what I want to take part in. All you need for that is a spine. Nothing evil. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] upper atmosphere ambient changes Was:Scene ambient and specularcolor changes
Hi Vivian, Why wait for a NASA Shuttle? There already exist several models to see the /interesting/ effects at altitude, some which have changed with the new ambient values. One of said aircraft _is_ in CVS. I am getting requests to make spaceships for Flightgear, faster than I can possibly make them. Since helijah is so prolific at making new aircraft, perhaps we should ask him to help out in this, maybe with a real NASA Space Shuttle in our aircraft hanger, we could get upper atmosphere flights to be more realistic. I keep telling people, Flightgear is for flying near the ground, so adding starships to my lineup is not a priority. I think this says something about what some are expecting Flightgear to become, or deliver. Stewart -- Keep up with the lastest changes to Bluebird, runabout and shuttlecraft at http://seahorseCorral.org/flightgear_aircraft.html Vivian Meazza wrote: I think the purists would argue that we ought to adjust the ambient values for altitude as well. There is much less ambient light once you leave the atmosphere. Perhaps we can do that at a later date, when we have an external model for the Shuttle. (This is also known as hitting the problem into the long grass :-) ). -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
Vivian Meazza wrote: Melchior FRANZ wrote: Alright I've updated the ambient table (multiplied all values by 2.5) Let me know what you all think with the CVS version of src/Time/light.cxx Looks nice here, I hope others will agree. I agree. Looks _very_ good now. Is there any property I can query? to determine at runtime if my model is running under the old ambient value, or the new one? I would hate to have to have separate releases for my interior lighting code. Stewart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Sorry- no one yet has thrown in any windows. And I don't see that Tim want's to do that. Yes, maybe it could be problematic what he wants to introduce- but is far away from destroying several things as I can understand here! You don't seem to understand this comparison. It's about taking something away so that others can't continue enjoying the game, only because one doesn't have his way. I am not taking anything with me. I'm just going home, because the others have changed the game from football to throwing in windows. And that's not what I want to take part in. All you need for that is a spine. Nothing evil. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] upper atmosphere ambient changes
S Andreason wrote: Hi Vivian, Why wait for a NASA Shuttle? There already exist several models to see the /interesting/ effects at altitude, some which have changed with the new ambient values. For good or for bad? (and if for bad what exactly, or as precise as possible). One problem with higher altitudes is that it's not as easy to model as lower altitude coloring. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Sun, Apr 5, 2009 at 2:44 AM, Ron Jensen w...@jentronics.com wrote: To claim the property system supports character arrays is wrong, and somewhat disingenuous. The property system supports strings as atomic units. You can not access the nth character of a string nor can you change only the nth character of a string like you could if it were an array. I'm not sure I agree there ... while the facts you state are true, it is also true that the property system can be used to store arrays of characters. Is Tim's proposal to add arrays of float's along with a full set of operations on the individual elements? The property system serves as a human interface as well as interfacing between subsystems. Melchior expressed his very deep, very real, very valid concerns better than I can in his initial e-mail http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21558.html I have heard nothing to address his vital questions. How should such a property be displayed in the property browser? Or the web interface? Or the telnet interface? Let me say a couple things here. How is floating point input handled right now? All these interfaces input the new value as a character array and then based on previous knowledge of the data type, convert that string to the appropriate type. If there's no other indication of the data type, the value is left in the form of a character array. How would it be any different in this case? We would need some code to parse the string into the appropriate data type if the property has been typed as a float array. Likewise, the telnet/web interface need to convert the numeric values to strings before outputting them. Again, in the case of a floating point array, how would this be any different? Slightly more complex, but if some conventions are chosen (like putting a space between the numbers as Tim has proposed, then this can be done unambiguously and consistently.) I don't want to be dismissive of this concern, but it seems pretty minor to me? Am I missing something here? Can you suggest a case where this would be confusing or would break something? 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 we input VEC3 properties via the property browser? By Tim's proposal you would do this like this: 0.1 2.4 -3.0 1.0 As he is currently the primary coder in the GUI and interface department he is in the best position to foresee problems. I urge you to trust his judgment. A big problem here (in my view) is that neither side is being as clear as they need to be with this discussion. We can't just assert there will be a problem and leave it at that. I'm still hoping someone can list a specific example of how these interfaces will break. Or am I the only one in the room who doesn't see the obvious cases? Count me in as some people From the e-mail traffic on this list, some people also include some very talented developers: Jon Berndt: I always came back to the conclusion that (vectors) would be a really bad idea. And it still is. I hate to put words in people's mouths, but let me try to do this fairly The primary reason I heard from Jon, is that he was thinking this will require a huge expansion in creating operators that manipulate these vectors ... and do all the different vector math operations. I think that's a misconception, but maybe I missed something in Tim's proposal? If true, then I agree with Jon's conclusion, but I think this is a misconception with the proposal. Erik Hofman: I have the feeling this will become a developers nightmare LeeE: This strikes me as an extremely bad idea. Stuart Buchanan: 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 these folks are speaking from a modeler's perspective and expecting that this proposal will require them to redo all the color and vector properties in all their modeling work, along with rewriting all the corresponding nasal code, then yes, this would be a horribly unnecessary thing to force on the FlightGear community. But again, I hope Tim can respond when he has a chance, because I think this is a misconception with Tim's proposal. If these modelers have correctly interpreted Tim's proposal, then I'd side with the modelers, but I suspect this is a misinterpretation of the proposal. Csaba Halász: I like that the color components are written out, less possibility for confusion (RGBA? ARGB? BGRA?) Can anyone point to any place within the FlightGear project where we don't use RGBA? And if so, why does the code need to do it differently? If we write out the color components in random orders and inconsistenly throughout the code, then this could be a point, but I can't think of one
Re: [Flightgear-devel] RFC: graphics effects files
The part that I was unsure about was to what extent FlightGear used relationships between and amongst properties (operations). If properties are used on the FlightGear side for input/storage only, then I’m OK with it as long as the code remains backwards compatible – which, I’m sure, is a given. Jon From: Curtis Olson [mailto:curtol...@gmail.com] Sent: Sunday, April 05, 2009 1:47 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] RFC: graphics effects files Jon Berndt: I always came back to the conclusion that (vectors) would be a really bad idea. And it still is. I hate to put words in people's mouths, but let me try to do this fairly The primary reason I heard from Jon, is that he was thinking this will require a huge expansion in creating operators that manipulate these vectors ... and do all the different vector math operations. I think that's a misconception, but maybe I missed something in Tim's proposal? If true, then I agree with Jon's conclusion, but I think this is a misconception with the proposal. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Sun, Apr 5, 2009 at 2:21 PM, Jon S. Berndt wrote: The part that I was unsure about was to what extent FlightGear used relationships between and amongst properties (operations). If properties are used on the FlightGear side for input/storage only, then I’m OK with it as long as the code remains backwards compatible – which, I’m sure, is a given. It can be useful to look at past history as precedence to give some context when evaluating some new situation. In light of that we should notice that JSBSim supports arbitrary vectors and tables of floating point data within it's xml file syntax and has done so since it's very earliest days. This is only part of the picture because as far as I know they don't have a way to store these tables in their property system, but it's interesting to observe that JSBSim has gone partway already in doing something similar to what Tim is proposing. This isn't an argument for or against Tim's proposal in and of itself, but it's at least interesting to observe other real world cases that are at least partially similar. Has JSBSim run into any problems with it's journey down this path? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Curtis Olson wrote: This isn't an argument for or against Tim's proposal in and of itself, but it's at least interesting to observe other real world cases that are at least partially similar. Has JSBSim run into any problems with it's journey down this path? This has been one reason why I have been cautious about including it, this setup does tend to result more errors than laying it down is separate xml nodes. Also, the JSBSim configuration files are often generated by a script (aeromatic in this case) first and then altered. This minimizes human error. That said, it looks to me the best way to eliminate all concerns is to make sure that subsystems that are going to use array-properties use a detached property tree (not attached to the root tree as shown in the property manager). It looks to me that would be no problem for the shader subsystem since it (like JSBSim) only uses the property tree to read the configuration file. After it has been read there would probable little or no need to adjust the individual properties using the property manager, or to send them over the network, anyhow. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Wildfire integration for the PBY Catalina
Anders Gidenstam wrote: Hi, This small patch makes water dropped from Gerard's nice PBY Catalina extinguish wildfires. http://www.gidenstam.org/FlightGear/misc/WildFire/PBY-Catalina.diff Committed, thanks. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Second Class Properties (was: Re: RFC: graphics effects files)
Curtis Olson wrote: I agree that the property system is for generic data ... so adding color_vectors or position_vectors is really out of the scope of what it should be intended for. This is too specific and I agree that it creates a mess and there's then no good place to draw the line when the next person comes along and wants to add some other specific aggregate structure. However, if the proposal is to add support for storing generic float (or double, or int) arrays in the property system, then I think that could be supported. Again we already support character arrays (although as has been pointed out, without an interface to be able to access individual elements of the array.) Two misconceptions I am hearing, and maybe Tim can respond to these: 1. Adding float arrays to the property system for the purpose of representing colors and vectors will require all modelers to convert all their existing models, structures, and code to the new system. There seems to be a lot of push back from modelers based on this fear, and I wonder if this is going to be the case? If so, then they have a point. Is this a misconception of Tim's proposal or not? It's certainly not a part of my proposal. I don't intend for a single line of XML in any model file to change. Eventually there may be a need to directly set effects properties from Nasal code included in models or have properties that connect to effect properties, but that is certainly way down the line. 2. Adding float/double arrays to the property system will also require adding a myriad of operations on those arrays ... do we need to now implement a full suite of vector and matrix math operations inside the property system. I don't see why that would be necessary. I just want to keep the discussion clear and make sure that we are all on the same page with what we are talking about here. I sense that a large amount of negative imagination is creeping into the discussion, so let's clarify if these fears are founded or not? Regards, Curt. On Sun, Apr 5, 2009 at 9:19 AM, wrote: Except for a few inconsistencies in xml style that already have been mentioned I think it's worth adding it then. Maybe I am misunderstanding this issue, but I have been involved in using FlightGear at work for a number of simulation related projects during the last couple of years, and to me some things are still unclear: Personally, my understanding of the property tree is that of an IPC enabling mechanism, that ties together all FlightGear subsystems and often also many non-FlightGear related tools/software even outside its own address space. So from my point of view, it is seems important to keep in mind that the property tree is not only about global variable storage but that it's also FlightGear's one and only standardized IPC mechanism, all subsystems and many FlightGear related tools that work outside the fgfs process space communicate with each other using the property tree and its natively supported types. With this in mind, it really seems of paramount importance that all property tree users (fgfs subsystems or external tools) have a concept and way of dealing with the native data types represented in the property tree. This exactly is it what makes the property tree, and more generally, FlightGear so intuitive, unobfuscated, powerful and easy to extend. This has been my experience when interfacing FlightGear to other software. Enhancing the property tree to support new component-specific native types that cannot be directly accessed, manipulated or processed by all or at least many other FlightGear related subsystems and tools seems like a troubling idea to me, in particular when it's not even foreseeable that other subsystems are going to develop a demand to also benefit from such a change eventually (just because they can already do all of this simply by using a more verbose, user-friendly and self-explanatory format that's been in use for years). Just think about some of the more complex systems that depend on having a full understanding of all property tree data and types, such as Nasal, the XML protocol system, the telnet interface to the property tree or the multiplayer system, all of which depend on working with arbitrary native property types. In its current form the property tree and its potential is virtually unrestricted and many new features were and still can be implemented on top of this very genericity without requiring modifications to the core implementation of the property tree. The natural tree-structure of XML and the natively supported data types allow users to emulate even complex data structures just by using the existing -admittedly verbose- syntax. But that's simply
Re: [Flightgear-devel] Second Class Properties (was: Re: RFC: graphics effects files)
Curtis Olson wrote: I agree that the property system is for generic data ... so adding color_vectors or position_vectors is really out of the scope of what it should be intended for. This is too specific and I agree that it creates a mess and there's then no good place to draw the line when the next person comes along and wants to add some other specific aggregate structure. However, if the proposal is to add support for storing generic float (or double, or int) arrays in the property system, then I think that could be supported. Again we already support character arrays (although as has been pointed out, without an interface to be able to access individual elements of the array.) Two misconceptions I am hearing, and maybe Tim can respond to these: 1. Adding float arrays to the property system for the purpose of representing colors and vectors will require all modelers to convert all their existing models, structures, and code to the new system. There seems to be a lot of push back from modelers based on this fear, and I wonder if this is going to be the case? If so, then they have a point. Is this a misconception of Tim's proposal or not? It's certainly not a part of my proposal. I don't intend for a single line of XML in any model file to change. Eventually there may be a need to directly set effects properties from Nasal code included in models or have properties that connect to effect properties, but that is certainly way down the line. 2. Adding float/double arrays to the property system will also require adding a myriad of operations on those arrays ... do we need to now implement a full suite of vector and matrix math operations inside the property system. I don't see why that would be necessary. I just want to keep the discussion clear and make sure that we are all on the same page with what we are talking about here. I sense that a large amount of negative imagination is creeping into the discussion, so let's clarify if these fears are founded or not? Regards, Curt. On Sun, Apr 5, 2009 at 9:19 AM, wrote: Except for a few inconsistencies in xml style that already have been mentioned I think it's worth adding it then. Maybe I am misunderstanding this issue, but I have been involved in using FlightGear at work for a number of simulation related projects during the last couple of years, and to me some things are still unclear: Personally, my understanding of the property tree is that of an IPC enabling mechanism, that ties together all FlightGear subsystems and often also many non-FlightGear related tools/software even outside its own address space. So from my point of view, it is seems important to keep in mind that the property tree is not only about global variable storage but that it's also FlightGear's one and only standardized IPC mechanism, all subsystems and many FlightGear related tools that work outside the fgfs process space communicate with each other using the property tree and its natively supported types. With this in mind, it really seems of paramount importance that all property tree users (fgfs subsystems or external tools) have a concept and way of dealing with the native data types represented in the property tree. This exactly is it what makes the property tree, and more generally, FlightGear so intuitive, unobfuscated, powerful and easy to extend. This has been my experience when interfacing FlightGear to other software. Enhancing the property tree to support new component-specific native types that cannot be directly accessed, manipulated or processed by all or at least many other FlightGear related subsystems and tools seems like a troubling idea to me, in particular when it's not even foreseeable that other subsystems are going to develop a demand to also benefit from such a change eventually (just because they can already do all of this simply by using a more verbose, user-friendly and self-explanatory format that's been in use for years). Just think about some of the more complex systems that depend on having a full understanding of all property tree data and types, such as Nasal, the XML protocol system, the telnet interface to the property tree or the multiplayer system, all of which depend on working with arbitrary native property types. In its current form the property tree and its potential is virtually unrestricted and many new features were and still can be implemented on top of this very genericity without requiring modifications to the core implementation of the property tree. The natural tree-structure of XML and the natively supported data types allow users to emulate even complex data structures just by using the existing -admittedly verbose- syntax. But that's simply
Re: [Flightgear-devel] Second Class Properties (was: Re: RFC: graphics effects files)
hf...@inmail24.com wrote: Except for a few inconsistencies in xml style that already have been mentioned I think it's worth adding it then. Maybe I am misunderstanding this issue, but I have been involved in using FlightGear at work for a number of simulation related projects during the last couple of years, and to me some things are still unclear: Personally, my understanding of the property tree is that of an IPC enabling mechanism, that ties together all FlightGear subsystems and often also many non-FlightGear related tools/software even outside its own address space. So from my point of view, it is seems important to keep in mind that the property tree is not only about global variable storage but that it's also FlightGear's one and only standardized IPC mechanism, all subsystems and many FlightGear related tools that work outside the fgfs process space communicate with each other using the property tree and its natively supported types. I agree that the property tree system performs this IPC role well. The effects properties don't live in the global property tree and so won't introduce any confusion in this area. With this in mind, it really seems of paramount importance that all property tree users (fgfs subsystems or external tools) have a concept and way of dealing with the native data types represented in the property tree. This exactly is it what makes the property tree, and more generally, FlightGear so intuitive, unobfuscated, powerful and easy to extend. This has been my experience when interfacing FlightGear to other software. Enhancing the property tree to support new component-specific native types that cannot be directly accessed, manipulated or processed by all or at least many other FlightGear related subsystems and tools seems like a troubling idea to me, in particular when it's not even foreseeable that other subsystems are going to develop a demand to also benefit from such a change eventually (just because they can already do all of this simply by using a more verbose, user-friendly and self-explanatory format that's been in use for years). If a subsystem can't parse a property, chances are good it doesn't need to worry about it... Unless you are talking about systems that deal with properties in a generic way, which you list below. Just think about some of the more complex systems that depend on having a full understanding of all property tree data and types, such as Nasal, the XML protocol system, the telnet interface to the property tree or the multiplayer system, all of which depend on working with arbitrary native property types. These are complex systems? My proposal addresses how Nasal can deal with the new properties -- as arrays -- and my initial code implements that. My initial code has modified the XML property reader and writer. Not a big deal. I admit that I haven't looked at the telnet interface yet, but I don't think it's too different from the property browser, which I have changed in my code. The multiplayer code does not depend on arbitrary property types; the properties and their types are all hard-coded. In its current form the property tree and its potential is virtually unrestricted and many new features were and still can be implemented on top of this very genericity without requiring modifications to the core implementation of the property tree. The natural tree-structure of XML and the natively supported data types allow users to emulate even complex data structures just by using the existing -admittedly verbose- syntax. But that's simply the cost of directly mapping XML to the key/value format used by the property tree. So the question really appears to be if FlightGear wants to end up with property types that are so purpose- and system-specific that only certain subsystems really know how to deal with them, essentially resulting in second class properties that cannot be processed by much of the currently existing FlightGear infrastructure? Basically, this is introducing a form of forced encapsulation into the property tree. I am not trying to dramatize this issue, this is just my current understanding of the likely repercussions. I'm not proposing to introduce my new types into the global property tree or change any existing properties. However, if the new types prove useful, they will hardly be second-class. For the time being, the property tree system doesn't have a single feature (to my knowledge) that is really specific to just one single FlightGear component or purpose - the property tree code has been so well generalized that it can be equally used by all components, without restrictions. It just consists of primitives, building blocks that can be used to model more complex data structures on top of it. I wasn't around for the birth of the property system, but I would imagine that it has evolved to meet new needs... Changing this would probably not only result
Re: [Flightgear-devel] upper atmosphere ambient changes
Erik Hofman wrote: Why wait for a NASA Shuttle? There already exist several models to see the /interesting/ effects at altitude, some which have changed with the new ambient values. For good or for bad? (and if for bad what exactly, or as precise as possible). Bad, of course. Oh yes, I can be precise. :D I made a web page of thumbnail screenshots (enlargable), along with narrative at http://seahorseCorral.org/fgfs-bug-report.html To summarize: I previously reported the white-out bug on IRC on 2008.Dec.16 saying, /I was flying at 39,000 asl and the white-out bug returned. This is lower altitude than last seen. I discovered the threshold was changing with sun-angle, so mapped the threshold. It occurs down to 36,400 when sun-angle is 1.56/ A combination of sun-angle and altitude defines the threshold for where this occurs. As the sun-angle decreases, or the sun gets higher in the sky, the altitude at which this occurs gets higher. Also, at lower altitudes, the problem seems to occur when the sun is on the horizon, perhaps the specular effects at sunrise are the problem? Because continuing into night from day, the white-out disappears at sun-angle 1.65 It also becomes apparant, this white-out causes material-only surfaces to turn completely white, while textured surfaces lose their ambient and diffuse values, and then look like the plain texture-image file. One problem with higher altitudes is that it's not as easy to model as lower altitude coloring. I don't think the atmosphere darkening to black is bad at all. In fact, except for the lack of Earth along the true horizon, it looks quite nice. Stewart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
