Hi Stuart,
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be even faster than the variant you tried since it avoids the
extra computations/allocations
Instead there are two shadings taking place:
1) Shading based on distance of the sprite to the sun. Effectively
we compare a vector from the center of the cloud to the sprite location
with the light normal.
2) Shading based on the vertical placement of the sprite in the cloud, so
lower
2011/8/7 Mathias Fröhlich:
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be even faster than the variant you tried since it avoids the
extra
On Sat, 6 Aug 2011 23:09:44 -0400, Derrick wrote in message
CAF74wjbov8xiA26W3_n2EA6HX04B2_8+U6mPn=9votkv8hu...@mail.gmail.com:
OK so I found a solution, I think, I changed the COM port number to
COM3. That seems to work but now FLIGHTGEAR will not accept inputs
for some reason, when I set as
On Sun, Aug 7, 2011 at 11:24 AM, Thorsten Renk wrote:
Upon further reflection - could it be the problem that I'm trying to
assemble a layer rather than fill a volume?
The bottom shading in 3dcloud.vert is controlled by a combination of
'shade' and 'cloud_height'. Your Nasal interface doesn't
I think the problem is that you are expecting the cloud height to
indicate the location
of sprite centers, wherease the code is expecting it to be the height
of the actual
cloud.
The code actually _subtracts_ the minimum texture height from the cloud
height to determine where to place
On Thu, Aug 4, 2011 at 12:51 PM, Thorsten Renk wrote:
We should change the maximum to whatever you feel is sensible
(40km?), and leave the default as it is (20km).
I think my current maximum is 45 km, and for much more one needs a
different tile structure anyway, so if we could get 45 km
Hi,
On Sunday, August 07, 2011 12:32:36 Stuart Buchanan wrote:
2011/8/7 Mathias Fröhlich:
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be
2011/8/7 Mathias Fröhlich wrote:
I have now seen that this has overlapped a question from yours form yesterday
evening. I just got up today morning, took a look outside - still no summer in
mid europe - and decided to hack something. Then I just thought that this
change might be good to
Inputs: what inputs are you sending? Are they getting overwritten by
internal processing? If you are inputting position and orientation (for
instance) you need to turn off the internal flight dynamics engine
(--fdm=null) If you are inputting control surface positions, you probably
don't want a
? wrote:
I am using the FG as simulator with HUD, but if I start the program like
Cessna 172P, here is the view of 3D cockpit, how can I turn off the 3D
cockpit when I use multi-screen?
The 3D cockpit of our default Cessna is an integral part of the entire
airframe 3D model. In order
On Sat, 6 Aug 2011, Derrick Washington wrote:
OK, has anyone actually attempted this method, and got it too work, lol bcus
I just tried it got the bluescreen of death twice. The syntax definitely
does something but it also take the computer down, any suggestions?
Typically when a BSOD
Gene,
Unless you've got 26 other serial ports on that machine, I'd strongly
suggest researching what caused Windows to assign COM27 to your device.
It's NOT typical behavior.
You can assign any number you want to a COM port when it is driven by
a USB-to-COM or Ethernet-to-COM adapter. Simply
On Sun, 7 Aug 2011, Frederic Bouvier wrote:
Gene,
Unless you've got 26 other serial ports on that machine, I'd strongly
suggest researching what caused Windows to assign COM27 to your device.
It's NOT typical behavior.
You can assign any number you want to a COM port when it is driven by
2011/8/7 Mathias Fröhlich wrote:
Hi Stuart,
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be even faster than the variant you tried since it
Curt...
I believe I'm just inputting control surface positions, however but I did
have the remote plugged in, I'll make sure to unplug it on my next try.
On Sun, Aug 7, 2011 at 11:10 AM, Curtis Olson curtol...@gmail.com wrote:
Inputs: what inputs are you sending? Are they getting
OK
So I believe I've got it to work on COM27 by using the \\.\COM27 syntax.
I still have a problem sending and receiving at the same time, FG will not
allow me to open up multiple generic serial protocols to the same COM port
for in and out, only one at a time and bi directional doesn't seem to
Hi
I need to know if the inputs coming from FG, while using a generic
protocol having binary mode set to true, are coming in as integers that need
to be converted to floating point or is FG actually sending in a floating
point word, a byte at a time? So my code to receive FG data looks
Does Flightgear have any view like that? I have reference some one press c
to turn off the panel, but it is not effect in default cessna
-邮件原件-
发件人: Martin Spott [mailto:martin.sp...@mgras.net]
发送时间: 2011年8月8日 0:07
收件人: flightgear-devel@lists.sourceforge.net
主题: Re: [Flightgear-devel]
Hi,
On Sunday, August 07, 2011 20:46:46 Stuart Buchanan wrote:
I think this may have broken YASim aircraft. I've tried a selection (dc3,
dc-3, a4f) and they all start at 36,000ft altitude with 0 IAS.
I suspect it might be an initialization order issue,
I've raised it as bug 397
Set /sim/allow-toggle-cockpit to 'true' , then press 'c'
2011/8/7 金承德 jinchen...@gmail.com:
Does Flightgear have any view like that? I have reference some one press c
to turn off the panel, but it is not effect in default cessna
-邮件原件-
发件人: Martin Spott
21 matches
Mail list logo
