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 si
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
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 disp
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 came
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
-
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.jp
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 tim
> > 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 tha
> 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.
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 th
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 inclu
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 i
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 poin
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 Na
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
-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 com
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 i
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 wi
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 car
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
--- 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-onl
> 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
* 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
-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
24 matches
Mail list logo