Re: [Flightgear-devel] HUD updates

2006-07-16 Thread Mathias Fröhlich

Erik,

On Friday 07 July 2006 23:13, Erik Hofman wrote:
 So, basically, no I won't maintain the ACMS FDM but lets keep it
 available anyhow.
Ack.

   Greetings

   Mathias

-- 
Mathias Fröhlich, email: [EMAIL PROTECTED]


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] RFC: A new sun

2006-07-16 Thread Mark
Hi there!

After some time of coding and restructuring I finally managed to clean 
up the repaint-code using the property-tree as interface for the data 
between fg and sg. Now everything is calculated where it's supposed to 
be: Environmental data in fg's environment, positional data in the 
reposition code and color in repaint. Nice and clean ;-)

I'm using the following property-tree nodes for interaction between the 
sun-code and the environment:

/environment/relative-humidity   // data for repaint
/environment/atmosphere/density-tropo-avg// data for repaint

/environment/atmosphere/altitude-half-to-sun // data for calculating 
avg density
/environment/atmosphere/altitude-troposphere-top   // data for 
calculating avg density

Is the location of the nodes ok, or should I move them somewhere else?

I'm really happy about the solution with the property tree.
Since everything is working fine, I can address the other points in the 
coming days.

Mark

Melchior FRANZ wrote:
 * Melchior FRANZ -- Monday 10 July 2006 20:24:
   
 If you let fgfs tell sg which node to get the density from, and
 make this a node with tied getter function, [...]
 

 Or, illustrated with some code:


 fgfs:

   static double calc_density() {
  // stuff
  return density;
   }

   void Whatever::bind() {
fgTie(/calculate/density, calc_density);
   }

   void Whatever::unbind() {
fgUntie(/calculate/density);
   }


 now you tell sg that it can have the density from /calculate/density,
 and whenever sg or anyone else reads that property, the density is
 calculated freshly (and only then).

 m.


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] A New Sun

2006-07-16 Thread Mark
Hi Curt,

I've been thinking about the idea with the cylinder the last days.
What I like about it is, that this way the fog of the distant objects is 
thicker at ground-level and gets thinner with increasing altitude.
And it's less stress on the hardware than shaders.
The cylinder could be part of the SGSky class, maybe as atmosphere-object.

But I want to get the sun ready before touching anything else.
So if anyone else would like to try out implementing the cylinder, that 
would be great.-)

Bye, Mark

Curtis L. Olson wrote:
 Mark wrote:
   
 Hi Steve,

 which line do you mean? The surface of the earth cutting of the sundisc?
 I agree this looks too sharp but I don't know how this could be improved 
 with standards means.
 At least the sun's halos are blended with the fog already.
   
 

 I've been wondering about placing a short cylinder between the sky dome  
 and the terrain.   This would have fog color at the base and blend to 
 completely transparant at the top.  This would help hide the outer 
 fringe of the tiles in some circumstances, and it would allow things 
 like the sun and moon to blend smoothly into the true horizon.  This 
 could also help with sky dome - earth transition problems in various 
 areas.  We might consider moving this cylinder up and down to match the 
 current view point altitude.  This should be really easy to implement 
 without needing any fancy opengl tricks (maybe make it part of they sky 
 dome model), but I just haven't had time to try it out.

 Curt.

   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] state of heli simulation, bug in Yasim

2006-07-16 Thread Maik Justus
Hi all,

the heli simulation is almost complete for beta testing. Every thing 
except the vortex-state-detection and the interface to the yasim-engines 
is working now (the engine is simulated rather simplified, but is 
working). The feeling is quite different to the old simulation (and I 
hope more realistic). I just have to strip some debug-stuff and to write 
the documentation. Then I will publish the code.

While debugging the downwash effects on stabs I found a bug in yasim 
(and therefore the root cause for the non working stabs). The patch I 
posted some weeks ago was nonsense. The result of this was not a working 
stab, it was such a high parameter for the drag, that the drag of the 
gear rises to a value similar to the total drag of the helicopter. The 
stabs had no effect at all. As a bug in yasim all stabs/wings without 
control-surface-subelements have no aerodynamical effect (not only in 
rotor-simulation. It's the same for fixed wing aircrafts). For every 
stab/wing: the outermost part of the wing up to the first 
control-surface-subelement as well as the innermost part up to the last 
control-surface-subelement is ignored. The bug is in the wing::compile() 
function in wing.cpp. In the boundary collection the tip and the base of 
the wing/stab are missing.
Another problem was, that a stab in stall condition is not producing any 
force perpendicular to the surface (in yasim). I have looked into some 
naca publications where I found, that in stall the lift is reduced to 
about 20..30%, but not to zero. The effect was visible in hover. The 
stabs in the downwash were producing no force. I have coded patches for 
both problems and will publish them with the rotor-code.

@Melchior:
-do you have a sample of the sound, the bo produces when flown through 
narrow turns (I would call this a flapping sound)?. If yes:  the 
simulation generates a property stall for every rotor. Playing this 
sample with a volume generated by this parameter and a sampling rate by 
the rotor-rpm should sound quite realistic.
-it seems, that the rpm-meter is limited to 100%. Due to autorotation, 
the rotor-rpm exceeds this value sometimes.
-the speed-indicator seems to indicate not only the fraction in the 
x-direction. I do not know, how the real thing works, but I assume, that 
it only shows the x-fraction (and only if it is positive).
-I will add an torque-property for the torque-meter (is on my todo-list)

Best regards,
Maik







-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] state of heli simulation, bug in Yasim

2006-07-16 Thread Melchior FRANZ
* Maik Justus -- Sunday 16 July 2006 22:26:
 -do you have a sample of the sound, the bo produces when flown through 
 narrow turns (I would call this a flapping sound)?.

No, but I guess one could fake that by taking the 2blade helicopter
sound and blend it in. I'll try once I know how the stall value
looks like.



 -it seems, that the rpm-meter is limited to 100%. Due to autorotation, 
 the rotor-rpm exceeds this value sometimes.

Yes, turbine and rotor RPM were limited to 100%. Both were faked as
there was no simulated turbine behind it, and the rotor rpm was
constant. I've committed a change that allows 140% for both now,
which is the maximum scale value. The dual-tacho needs to be fixed
anyway. Not only doesn't it have a frame, it also has only two
hands, when there should be three, and thicker ones, too.



 -the speed-indicator seems to indicate not only the fraction in the 
 x-direction.

No, it seems to only show the forward direction. What makes you think
it doesn't? Do you consider wind from ahead?



 I do not know, how the real thing works, but I assume, that  
 it only shows the x-fraction (and only if it is positive).

So do I and so it should work already.



 -I will add an torque-property for the torque-meter (is on my todo-list)

Excellent. That's only faked now, too.

m.


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] state of heli simulation, bug in Yasim

2006-07-16 Thread Maik Justus
Hi Melchior

 * Maik Justus -- Sunday 16 July 2006 22:26:
   
 Yes, turbine and rotor RPM were limited to 100%. Both were faked as
 there was no simulated turbine behind it, and the rotor rpm was
 constant. I've committed a change that allows 140% for both now,
 which is the maximum scale value. The dual-tacho needs to be fixed
 anyway. Not only doesn't it have a frame, it also has only two
 hands, when there should be three, and thicker ones, too.

   
Thanks. The engine  will no exceed 100% now (and in detail, the 
engine-rpm is not simulated now. I have just a limitation of the torque 
the engine can produce depending on actual rotor-rpm and the derivation 
of the rotor-rpm.  It produces no torque on rpm100%
 -the speed-indicator seems to indicate not only the fraction in the 
 x-direction.
 

 No, it seems to only show the forward direction. What makes you think
 it doesn't? Do you consider wind from ahead?
   
In autorotation I was not sure, if the indicated airspeed is correct. 
But probably I think I got confused by the fact, that if I vary the 
inclination of the heli, the speed indicator shows the 
cos(inclination)-fraction of the climb-speed

 I do not know, how the real thing works, but I assume, that  
 it only shows the x-fraction (and only if it is positive).
 

 So do I and so it should work already.

   
When flying backwards it shows a positive speed. I think the real speed 
indicator remains at zero.

Maik


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Texture in the new OV10 linked to the A-10

2006-07-16 Thread Lee Elliott
On Sunday 16 July 2006 00:43, Julien Pierru wrote:
 I don't think we did link, are you talking about the UHF? (we
 made a copy of the texture in the OV10 directory).

 Julien

[EMAIL PROTECTED]:~$ grep -r A-10 FlightGear/Aircraft/OV10/
FlightGear/Aircraft/OV10/Models/USAFE/Instruments/UHF/CVS/Entries:/A-10-radios.rgb/1.1/Sat
 
Jul 15 18:50:53 2006/-kb/
FlightGear/Aircraft/OV10/Models/USAFE/Instruments/UHF/UHF.ac:texture 
A-10-radios.rgb
[EMAIL PROTECTED]:~$ 

LeeE



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] A New Sun

2006-07-16 Thread Lee Elliott
I once tried to do some aurorae using very large 3d objects and 
while I could see them ok I couldn't get any colour in to them - 
they just looked white and the transparency I used in the 
texture was ineffective, so I could see the entire object, sharp 
edges and all  :(

dunno if you might have the same problem with using a 3d object 
for the sun.

Haven't got around to trying it yet but meteors might work ok.

LeeE

On Sunday 16 July 2006 20:14, Mark wrote:
 Hi Curt,

 I've been thinking about the idea with the cylinder the last
 days. What I like about it is, that this way the fog of the
 distant objects is thicker at ground-level and gets thinner
 with increasing altitude. And it's less stress on the hardware
 than shaders.
 The cylinder could be part of the SGSky class, maybe as
 atmosphere-object.

 But I want to get the sun ready before touching anything else.
 So if anyone else would like to try out implementing the
 cylinder, that would be great.-)

 Bye, Mark

 Curtis L. Olson wrote:
  Mark wrote:
  Hi Steve,
 
  which line do you mean? The surface of the earth cutting of
  the sundisc? I agree this looks too sharp but I don't know
  how this could be improved with standards means.
  At least the sun's halos are blended with the fog already.
 
  I've been wondering about placing a short cylinder between
  the sky dome and the terrain.   This would have fog color
  at the base and blend to completely transparant at the top. 
  This would help hide the outer fringe of the tiles in some
  circumstances, and it would allow things like the sun and
  moon to blend smoothly into the true horizon.  This could
  also help with sky dome - earth transition problems in
  various areas.  We might consider moving this cylinder up
  and down to match the current view point altitude.  This
  should be really easy to implement without needing any fancy
  opengl tricks (maybe make it part of they sky dome model),
  but I just haven't had time to try it out.
 
  Curt.

 --
--- Using Tomcat but need to do more? Need to support
 web services, security? Get stuff done quickly with
 pre-integrated technology to make your job easier Download IBM
 WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057;
dat=121642 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel