If you want to know the altitude, you need to have the matrix that
transforms
from the current view position/orientation to the earths center. And you
need
to transform from cartesian space into the earth ellipsoid. The best you
can
do is to do this per vertex. And even that is way too much
Which motor aircraft do you use for towing ? Given the above figures I
suspect you're using the Piper Cub, right ? Did you ever try the Grob
G115 ? I've never flown that one, neither in RL nor in FG, but I
*guess* it's probably the closest in performance and FDM credibiliy to
commonly used
On Wed, Jan 11, 2012 at 8:09 AM, Thorsten Renk wrote:
I have now a scheme that does seem to do the trick - high stuff and stuff
towards the sun glows properly before lower stuff and stuff away from the
sun.
http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=15#p147240
Very
Rather than passing in the eye position as a uniform, why not
pass in the cloud altitude instead? Is this simply to avoid
needing to modify the C++ code?
I thought uniforms are things which are per frame constant in the scene
and apply to all objects the same way - i.e. I pass light
On Wed, Jan 11, 2012 at 9:16 AM, Thorsten Renk wrote:
Rather than passing in the eye position as a uniform, why not
pass in the cloud altitude instead? Is this simply to avoid
needing to modify the C++ code?
I thought uniforms are things which are per frame constant in the scene
and apply to
On 11/01/2012 10:08, flightgear-devel-requ...@lists.sourceforge.net wrote:
I tried it today and as far as I can tell from a simple setup with
mouse-control only I'd say the G115 behaves sufficiently reasonable.
BUT I'm_very_ surprised: Don't these birds have neither a speed
indicator nor
Hi all,
I had the same issue. It's quite odd. Git status was showing my tree as
unmodified but I had to do the same thing (clone a new copy) with
simgear otherwise it was not finding OSG in /usr/include. I think it was
only looking in /usr/local/include for some reason.
Cheers,
Vik
On
On Wednesday 11 January 2012 13:27:04 Viktor Radnai wrote:
I had the same issue. It's quite odd. Git status was showing my tree as
unmodified but I had to do the same thing (clone a new copy) with
simgear otherwise it was not finding OSG in /usr/include. I think it was
only looking in
Thanks for that. One of these days I'll actually learn git I promise :)
Unfortunately I already nuked the old tree so I can't figure out what
was left over that was causing the error.
Cheers,
Vik
On 01/11/2012 01:50 PM, Stefan Seifert wrote:
On Wednesday 11 January 2012 13:27:04 Viktor Radnai
Just created a merge request #130 for fgdata.
Eric
On 01/10/2012 06:23 PM, Stuart Buchanan wrote:
On Tue, Jan 10, 2012 at 5:14 PM, Eric van den Berg wrote:
Is indeed JSBSIM and that did the trick. Engine running!
Great. Will you be committing a fix to fgdata, or do you need
Hi,
On Sunday, January 01, 2012 11:41:22 Mathias Fröhlich wrote:
I think then, computing mipmaps for any texture file on the CPU in the
loader thread should globally improove the situation.
Also avoiding the compression already in the files should help every use
case. Except that the on disk
Hi everybody,
in less than one week we will pass the outer marker for our release of
FlightGear 2.6.0: the creation of the release branches in our git
repositories. A good time to read the final checklist:
* All features work as desired?
* All major bugs fixed?
Hi,
does anybody have the same problem?
Several Messages:
Unknown Chunk: ***UNKNOWN*** (0xA08A)
in fgfs output. Seems to be a diagnostic from the 3DS loader within OSG.
I get this (and messy views) with current OSG, fgfs, fgdata choosing for
instance aircraft MD11 or airport EHAM .
On 11.01.2012 23:15, Olaf Flebbe wrote:
Hi,
does anybody have the same problem?
Several Messages:
Unknown Chunk: ***UNKNOWN*** (0xA08A)
in fgfs output. Seems to be a diagnostic from the 3DS loader within
OSG.
I get this (and messy views) with current OSG, fgfs, fgdata choosing
for
14 matches
Mail list logo
