-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Curtis Olson wrote:
Hi Tim,
I took a peek at the diffs and had a couple questions. Originally the
idea of the fg_os files was to have a single interface within the
flightgear code so that the details could be hidden in fg_os.[ch]xx, but
I see
* Tim Moore -- 5/18/2007 9:20 AM:
renderer.cxx already contains a lot of OSG specific code; in fact it
would be fair to say that is all OSG specific code.
I agree. Main/fg_os*.cxx are there to handle the operating system dependent
interfaces for window management/keyboard/mouse: glut and later
Martin Spott wrote:
gh.robin wrote:
With FlightGear-0.9.11-pre1 it is something strange
we have Flying Carriers.
The carrier is correct - sea level is wrong :-))
Wait for the tide to come in.
Jon
I presume this is to do with the fact that the sea is modelled as a
--- Martin Spott wrote:
Stuart Buchanan wrote:
I have a patch available for the flash2a, so it works on the plib
branch.
Available here:
http://www.nanjika.co.uk/flightgear/flash2a.diff.bz2
Is the patch meant for PLIB only or for OSG as well ?
The fix is plib-only, and removes
On Thu 17 May 2007 18:19, Vivian Meazza wrote:
It's not a bug it's a feature! The carrier operates in the same frame of
reference as aircraft - it has to otherwise you couldn't catch wires
correctly. Unfortunately, the sea surface does not - elsewhere on the sea
surface you will see the
Hi Stuart,
Stuart Buchanan wrote:
--- Martin Spott wrote:
Stuart Buchanan wrote:
I have a patch available for the flash2a, so it works on the plib
branch.
Available here:
http://www.nanjika.co.uk/flightgear/flash2a.diff.bz2
Is the patch meant for PLIB only or for OSG as
On Thu 17 May 2007 22:28, Tim Moore wrote:
SNIP
It's hard to assign a meaning to these times in isolation, except to
note that 16 milliseconds total is the magic number that gives you a
frame rate of 60hz. The large cull time indicates poor scene graph
layout; possibly there's a problem with
On Thu 17 May 2007 22:28, Tim Moore wrote:
SNIP
The Cull is basically very high compared to the other values but when
i fly over the sea (without tiles as i said in an other topic).
What is exactly the meaning of the Cull value ?
It's hard to assign a meaning to these times in isolation,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Bytheway wrote:
Martin Spott wrote:
gh.robin wrote:
With FlightGear-0.9.11-pre1 it is something strange
we have Flying Carriers.
The carrier is correct - sea level is wrong :-))
Wait for the tide to come in.
Jon
I
Martin Spott wrote:
Curtis Olson wrote:
Double check there isn't any x-plane 8.50 bezier stuff in the version we use
since we really aren't setup to use the new file format features yet.
Done, no v8.50 style runway definitions in the new file.
Well, Robin currently does not have a v8.50
Hi Jon,
Jon Stockill wrote:
Any plans to update nav.dat too? If so I'll update the navaid models in
the scenery database.
Please see the respective changelog notice. I've been updating all four
files that FlightGear picks from Robin's package. These include
Airports/apt.dat.gz as well as
I noticed the 737's wheels were floating above the ground and decided
to tweak it. In the process, I discovered that the gear, engines, CG,
etc were all defined to be about 9 meters behind the 3D model.
The linked patch adds a 9.04 meter offset on X in Models/737-300.xml and
adds contact
That should not be necessary. The aircraft configuration file only needs
to be consistent within itself. The structural frame is used for the
location of engines, landing gear, empty-weight CG, etc. There is also
a point called the visial reference point (typically the nose of the
aircraft) that
Martin Spott wrote:
Hi Jon,
Jon Stockill wrote:
Any plans to update nav.dat too? If so I'll update the navaid models in
the scenery database.
Please see the respective changelog notice. I've been updating all four
files that FlightGear picks from Robin's package. These include
Berndt, Jon S wrote:
That should not be necessary. The aircraft configuration file only needs
to be consistent within itself. The structural frame is used for the
location of engines, landing gear, empty-weight CG, etc. There is also
a point called the visial reference point (typically the
I'm not in a position at this time to check whether Z pos'n in the
FDM/configuration file was wrong or the Z offset in the Model file
was wrong;
Unless the one that's in the FlightGear distribution is different from the
one that's been in JSBSim CVS for years, it isn't the FDM that's wrong.
I'm not in a position at this time to check whether Z pos'n in the
FDM/configuration file was wrong or the Z offset in the Model file
was wrong;
Unless the one that's in the FlightGear distribution is different from the
one that's been in JSBSim CVS for years, it isn't the FDM that's
On Tuesday 15 May 2007, Tim Moore wrote:
Howdy,
This patch implements the option of using OpenSceneGraph's osgViewer
instead of SDL or glut. The major user visible difference is the
availability of OSG statistics, as seen in
http://www.bricoworks.com/moore/osgstats.png, which show the time
On Tuesday 15 May 2007, gh.robin wrote:
Hello,
The generic tiles over the sea is/are missing.
Tested with last cvs SG/FG built with last svn OSG
and with last cvs SG/FG built with older svn OSG (10-April 2007)
here snapshot
http://perso.orange.fr/GRTux/FG_OSG_Generic-Tile.jpg
Hmm,
On Friday 18 May 2007 23:47, Jon S. Berndt wrote:
737 drawing:
http://hawker.smugmug.com/gallery/92076/1/3226720#3226720-O-LB
JB
http://boeing.com/commercial/airports/3_view.html
More accurate. :)
Also:
http://boeing.com/commercial/airports/737.htm
Ampere
Hi,
On Friday 18 May 2007, Tim Moore wrote:
renderer.cxx already contains a lot of OSG specific code; in fact it
would be fair to say that is all OSG specific code. I did add some
osgViewer specific code to renderer.cxx because the details of accessing
the scene root, controlling the camera,
Hi Harald,
On Tuesday 08 May 2007, Harald JOHNSEN wrote:
To recap we have (or should have in the future) :
- one drawable per model / part of model
Not sure what this means, the Drawable's are the leaf nodes in osg. They can
have StateSet's attached to it. With one Drawable there is one
On Tuesday 08 May 2007, Harald JOHNSEN wrote:
Yes by states I was thinking of statesets. Anyway I looked again the
geode and drawable definitions and now
I'm confused, I thought the states were tied to the geodes but they are
tied to the drawable. I really don't
understand how we can have one
Tim,
On Tuesday 08 May 2007, Tim Moore wrote:
There is also a second assumption in the animation system: The textures
for the liveries are expected not to be in the osg::Drawables. That is
not always true and is especially no longer true with the ac loader
update in osg svn since a few
24 matches
Mail list logo
