Re: [Flightgear-devel] upper atmosphere ambient changes
S Andreason wrote 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 The thunmbnail inks don't work here. 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. This is very interesting. Do the new ambient adjustments as of yesterday give the same results? Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] *** SPAM *** Re: upper atmosphere ambient changes
Vivian Meazza wrote: S Andreason wrote 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. Darn :) 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 Ah I see, this turns out to be a bug. All color components of specular and diffuse change to NaN's at some point. I'll look into it. Erik -- ___ 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)
It's not because of the 'misconception' about having to amend/convert existing stuff to use the new data types that I think introducing these new datatypes is a bad idea. It is because: 1. It introduces the scope for errors where currently no scope exists because the identification of each value is only implicit and derived from the ordering of the data within the type. This means it will therefore become possible to specify the data in the incorrect order, whereas with explicitly identified data items this cannot happen. Thus a new scope for errors is introduced where there was none. 2. As Ron mentioned, the property tree currently presents data in a consistent and atomic way but introducing these compound datatypes would break that. I can't go along with your assertion that strings are really just arrays of characters; the data is the string, not the characters that make up the string. You could as easily argue that Int's were arrays of digits and floats/doubles were linked pairs of arrays of digits and then, for example, start specifying a series switch states as '10011010' instead of identifying each one explicitly. Then see point 1. above again. 3. The new compound datatypes are just about how data is represented in the property tree and I can't see how they would make something possible that would otherwise be impossible without them. As such, they just seem like duplication to me. 4. If the new datatypes were to be accepted, and given that they are just another way of representing data, is it intended to prevent people from using them in other areas, such as within model animation files? Will it be possible to use either representation anywhere and if so, how do we choose which representation to use where? What will happen if someone tries to use the wrong representation in the wrong place? Doesn't point 1. above also apply again? No, the issue I have with the new datatypes is not that it would be a lot of work to change existing stuff. It is because it seems like bad design; it doesn't seem to be required to enable an otherwise impossible feature but at the same time introduces the scope for new errors whilst breaking the consistency of the current data atomicity. LeeE On Sunday 05 April 2009, 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? 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 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
Re: [Flightgear-devel] Scene ambient and specularcolor changes
Vivian Meazza wrote: 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. One more thing, the trees are still very dark, especially noticeable in daylight and sunny skies. looking at Models/Trees/deciduous-tree.ac for example, MATERIAL NoName rgb 1 1 0.8 amb 1 1 0.8 emis 0 0 0 spec 0 0 0 shi 2 trans 0 Is the specularity supposed to be zero? I don't think so. All the trees need spec to be set to the rgb or amb color at least. However, after making these changs, I see no difference. So I tried setting the emissions to get glow-in-the-dark trees. Nothing. Is there something causing these values to be ignored? Stewart -- ___ 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
On Mon, Apr 6, 2009 at 11:13 AM, S Andreason wrote: One more thing, the trees are still very dark, especially noticeable in daylight and sunny skies. looking at Models/Trees/deciduous-tree.ac for example, MATERIAL NoName rgb 1 1 0.8 amb 1 1 0.8 emis 0 0 0 spec 0 0 0 shi 2 trans 0 Is the specularity supposed to be zero? I don't think so. All the trees need spec to be set to the rgb or amb color at least. However, after making these changs, I see no difference. So I tried setting the emissions to get glow-in-the-dark trees. Nothing. Is there something causing these values to be ignored? I believe trees are drawn with a shader so perhaps the shader itself needs to be modified to adjust the tree material properties? 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] upper atmosphere ambient changes
Vivian Meazza wrote: The thunmbnail inks don't work here. Oops. Fixed. This is very interesting. Do the new ambient adjustments as of yesterday give the same results? This is as of CVS on 2009.Apr.05 and today's checkout has no changes to source. Stewart -- ___ 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
S Andreason wrote Vivian Meazza wrote: 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. One more thing, the trees are still very dark, especially noticeable in daylight and sunny skies. looking at Models/Trees/deciduous-tree.ac for example, MATERIAL NoName rgb 1 1 0.8 amb 1 1 0.8 emis 0 0 0 spec 0 0 0 shi 2 trans 0 Is the specularity supposed to be zero? I don't think so. All the trees need spec to be set to the rgb or amb color at least. However, after making these changs, I see no difference. So I tried setting the emissions to get glow-in-the-dark trees. Nothing. Is there something causing these values to be ignored? The critical update is in data/Lighting, not source, AM 05/04/2009. Vivian -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] upper atmosphere ambient changes
This should now be fixed in simgear/scene/sky/oursun.cxx Erik -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-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
Hi, Catching up with an already heated up discussion. IMO: Tim should go on and include arrays into the property system. I even believe that aggregates and more sophisticated types will be something good to have. But anyway. Tims change gets my vote. Greetings Mathias -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-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
Hi, I agree with those who are against the proposed new vector format even though I like Tim's basic idea that improves vector calculation performance. As Melchior alrwady said, the new format has nothing to do with what Tim really wants (performance improvement). A node with 3 or 4 float numbers can be converted into a vector class internally in C++ code without the new vector format inside an XML tag. Moreover, the new vector format doesn't improve the usability at all. a user-defined text format inside an XML tag is not recommended since it decreases the readability unless you give a comment, which is way not better than using tags. If we really need more concise format that improves usability, then we need to throw away our current xml files and make new files in our own new format, which I believe is nonsense. The new format also needs a parser, property browser changes, and converter(s) that don't help us improve any usability or performance at runtime, I guess. If such new format gives us some usability or performance improvement, I can accept it even if some extra work is required, but this is not the case. The JSBSim's table format, which I believe, also lacks the readability. It ,however, gives aircraft developers some usability like easier to copy and paste some table data from external tools like javaprop or excel. I know some helper script can create a well- formatted XML tags, but it could be true that many aircraft developers like simple copy-paste things while tweeking prop/engine things tons of times a day. Nevertheless to say, these tables don't need converters or browser changes since these are only read at launch time, and are not readable from the property browser or telnet. So comparing JSBSim table and the vector format doesn't seems fair to me. I hope many people understands what Melchior said on the property system. His going home thing didn't mean that he just wants to hide away unless his opinion is accepted, but he wanted to say the proposed vector format is that bad in terms of software architecture. He might be sometimes brutal in his written words, but I really like his software architecture related comments. These are almost always right, at least to me. I don't say anything on his other comments though :-p Tat p.s. I've moved and my network connection is limit only to iphone until at the end of this month. Sorry for my vry slow response, especially to Mac users. - Tatsuhiro Nishioka On 2009/04/06, at 5:33, Erik Hofman e...@ehofman.com wrote: 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 -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
