Re: [Flightgear-devel] *** SPAM *** Re: Scene ambient andspecularcolor changes
Lee Qid wrtote Hi there, let me join this discussion: Very good summary indeed. Pretty much what I was just writing. If you want to get a feel of specular highlights, look at car-paint, and observe what is reflected on the metal that actually causes the highlights. You will find that it is the sun, street-lights or lit billboards. Basically anything emitting a lot of light. As for causastics, I'd say that you add the it to the ambience. You could try and sum up and average the diffuse colours of the scenery tiles every once in a while to get the causastic part for the ambient colour, if you like. You may also want to look at your fog implementation. It may yield a clue on how to determine the amount of light passing through depending on the altitude of the object and density of the fog. You can also try to modify the size and brightness of the highlight, depending on the cloud cover _above_ the object (overcast - clear). What I take from this discussion so far is that the modeller should determine the diffuse colour of a material and its shininess. The modeller should normally set the ambient and specular colours to be the same as the diffuse colour, unless it's an odd material. FlightGear should adjust the ambient, diffuse and specular colours according to the incident light intensity, amount and type of scattering etc. In direct sunlight diffuse colour should be slightly yellow, while ambient colour should be slightly blue. Specular highlights should shade towards the colour of the incident light. Where the lighting is almost all ambient, fog or cloud, there should be no specular reflection, and the ambient colour should be a (light) grey shade. I'm not clear about how much ambient light there should be in any situation, but, to me right now there isn't enough with the default model. The effect of visibility on the diffuse and specular setting looks OK in very low visibility, but at high visibility it looks very odd - far too little ambient, while at medium visibility specular refection is too low. I think that outside the fog situation the visibility should have little or no effect on diffuse or specular values. I look forward to seeing if a log relationship is better. And we need shadows to complete the effect! Vivian -- ___ 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'm not clear about how much ambient light there should be in any situation, but, to me right now there isn't enough with the default model. The effect of visibility on the diffuse and specular setting looks OK in very low visibility, but at high visibility it looks very odd - far too little ambient, while at medium visibility specular refection is too low. I think that outside the fog situation the visibility should have little or no effect on diffuse or specular values. I look forward to seeing if a log relationship is better. After reading the comments I agree with it. I'll take some time to adjust the ambient accordingly. And we need shadows to complete the effect! That would certainly be nice. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] invalid argument to asin() in Instrumentation/navradio.cxx
On Sat, 2009-01-10 at 17:13 +0100, Csaba Halász wrote: #2 0x0080188d in FGNavRadio::update (this=0x98df490, dt=0.058334) at src/Instrumentation/navradio.cxx:613 613 double angle = asin( y / x ) * SGD_RADIANS_TO_DEGREES; (gdb) p x $1 = 3.2580450943147174 (gdb) p y $2 = 3.258443598627875 (gdb) p y / x $3 = 1.0001223139341602 No idea what it is calculating and how to fix. (apart from forcibly clamping y/x to [-1, 1] ...) This bug bit me today. I'm starting this thread from Csaba's first e-mail since the last thread missed the problem. More context code: double x = gs_dist_node-getDoubleValue(); double y = (fgGetDouble(/position/altitude-ft) - nav_elev) * SG_FEET_TO_METER; // cout dist = x height = y endl; double angle = asin( y / x ) * SGD_RADIANS_TO_DEGREES; y is vertical distance, x is distance to the navaid. It appears the original author intended the x distance to be slant range. Hence we have (vertical rise)/(slant range) or rise/hypotenuse. As long as that is true, y/x will never exceed +/- 1 since the vertical rise must always be less than or equal to the slant range. However, I enabled the cout line and discovered x is indeed dropping below y. From observation x is horizontal distance not slant range. I think we need double angle = atan2( y, x ) * SGD_RADIANS_TO_DEGREES; Thanks, Ron Index: src/Instrumentation/navradio.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Instrumentation/navradio.cxx,v retrieving revision 1.31 diff -u -b -r1.31 navradio.cxx --- src/Instrumentation/navradio.cxx 25 Dec 2008 23:11:44 - 1.31 +++ src/Instrumentation/navradio.cxx 2 Apr 2009 14:49:57 - @@ -610,7 +610,7 @@ double y = (fgGetDouble(/position/altitude-ft) - nav_elev) * SG_FEET_TO_METER; // cout dist = x height = y endl; -double angle = asin( y / x ) * SGD_RADIANS_TO_DEGREES; +double angle = atan2( y, x ) * SGD_RADIANS_TO_DEGREES; r = (target_gs - angle) * 5.0; r *= signal_quality_norm; } -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] read sideslip data during replay
I haven't looked carefully at how alpha and beta are dealt with ... perhaps they are computed on the fly from other values and that computation overrides anything you might load from an external file? One possible way around this would be create a copy of the HUD configuration, modify the property name it uses to read beta from the standard name to something you create. Then when you load your data file back in for replay, fill in that new property name rather than the standard one, and your version of the HUD should respond appropriately. Perhaps there would also be some way to override the overridden beta value with a nasal script and then you'd be trading nasal work for HUD work. Regards, Curt. On Tue, Mar 31, 2009 at 8:40 PM, John Waget jwa...@gmail.com wrote: Hi all, I am new to flightgear so please help me out with this. I want to display the side slip data on the Hud during the replay process. During the replay process, fgfs simply read the input file we specified. However, I found out fg won't read the sideslip data from the file, so what should I do to force the fg read the sideslip data?? Thanks, John -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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] jsbsim wind correction in opposite direction
On jeudi 02 avril 2009, gerard robin wrote: On mercredi 01 avril 2009, jean pellotier wrote: Jon S. Berndt a écrit : Yes, the difference stems from the need to know what the wind is bringing, and the vectorial definition of where it's going. The problem was that sometimes we just had a vector where we expected to see North, East, and Down, wind components. Well ... fine, but is that to or from. The convention was unspecified, and that caused confusion. From the FlightGear side, I can see winds being specified either way. In the flight dynamics code, however, I expect to see a wind velocity vector - the direction it's going. The question is, where does the conversion to the wind velocity vector form break? Jon After having seen in some places in last JSBSim code that wind direction is the direction the wind is toward, here's a patch that revert the values used in wind vector for JSBSim, that work for me, wind is now correctly applied. i didn't tested vertical composante . hope that helps jano I don' t exactly understand the problem, with JSBSim aircrafts if we have a cross wind, the direction of the force is correct according to the direction of the wind. I did not noticed any error . ooops, you are right , i mistmatched the aircraft behaviour and the from to wind . -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] invalid argument to asin() in Instrumentation/navradio.cxx
* Ron Jensen -- Thursday 02 April 2009: I think we need double angle = atan2( y, x ) * SGD_RADIANS_TO_DEGREES; Agreed. And that's also done just a few lines later, with the exact same parameters. Comitted, thanks! (I also re-used an already initialized node for altitude-ft.) m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
