Norman Vine <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
>
> > In the
> >end I believe that we will have to reserve the seperate scene graph for
> >interior view only and integrate all other models into the main ssg.
>
> FWIW AFAIK This is what has been envisioned all along.
> But it is rathe
Jim Wilson writes:
> In the
>end I believe that we will have to reserve the seperate scene graph for
>interior view only and integrate all other models into the main ssg.
FWIW AFAIK This is what has been envisioned all along.
But it is rather interesting watching the path 'newcomers'
take to ar
At 4/12/02, you wrote:
>Can we check the bounding sphere of the model and, if the viewpoint is
>outside it, use the nearest point of the sphere as a candidate for the
>clip plane ? Doesn't help for pilot viewpoint, but should for trailing.
I don't know if this is related. I have a R/C glider m
Norman Vine
>
>Following 'untested code'
Ooops after testing here is a minor fix
< moved the get_position() to follow the getMatrixCall()
so as to pick up the 'updated' location
This seems to work and should be fast enough for LOTS
of static models :-)
Cheers
Norman
void
FG3DModel::updat
Norman Vine <[EMAIL PROTECTED]> said:
> David Megginson writes:
> >
> >Christian Mayer writes:
> >
> > > So it'll be quite hard to solve in a general way. Drawing the plane last
> > > in it's own z-buffer range (IIRC we are doing that now with the normal
> > > 3D panel) won't work generally, as t
At 4/12/02, you wrote:
>Michael Selig
>
> >With this version day does turn to night, after a short period of
> >flying. I know this is being discussed in another thread.
>
>FYI
>speeding time up momentarily will turn the lights on to
>
>'t' key followed by 'T' key
>
>A real fix is in the pipe.
>
Michael Selig
>With this version day does turn to night, after a short period of
>flying. I know this is being discussed in another thread.
FYI
speeding time up momentarily will turn the lights on to
't' key followed by 'T' key
A real fix is in the pipe.
Norman
__
David Megginson writes:
>
>Christian Mayer writes:
>
> > So it'll be quite hard to solve in a general way. Drawing the plane last
> > in it's own z-buffer range (IIRC we are doing that now with the normal
> > 3D panel) won't work generally, as there might be other objects 'in the
> > way' (i.e. be
Here is a c172 model file that I've adjusted and seems to look much better
in terms of the "z fighting". It won't be going into cvs since it was done to
a converted copy, not the original blender file.
http://www.spiderbark.com/fgfs/c172-dpm.ac.gz
As I experimented with this model what I found
At 4/12/02, you wrote:
>Michael Selig writes:
>
> > When I start up I see this:
> > http://amber.aae.uiuc.edu/~m-selig/tmp/beech.gif
>
>Yes, it looks like your gear code isn't holding the plane above the
>ground, so it's resting at its origin. When I try
>
> fgfs --aircraft=c172-uiuc
>
>using
Jim Wilson writes:
>
>Norman Vine <[EMAIL PROTECTED]> said:
>
>> Jim Wilson writes:
>> >
>> >David Megginson <[EMAIL PROTECTED]> said:
>> >
>> >> As of this morning, FlightGear has a new infrastructure for
>> >> incorporating moving, animated 3D models besides the aircraft model.
>> >> This is not
> The sock itself is rigid rather than collapsible, and it simply
> rotates with the wind direction and tilts from 75deg down for no wind
> to straight out for 15kt. That's not right -- at 6kt, it should be
> inclined only 30deg down for a standard windsock -- but at least it's
> something.
You
Can we check the bounding sphere of the model and, if the viewpoint is
outside it, use the nearest point of the sphere as a candidate for the
clip plane ? Doesn't help for pilot viewpoint, but should for trailing.
> David Megginson <[EMAIL PROTECTED]> said:
>
> > Curtis L. Olson writes:
> >
>
On Fri, 2002-04-12 at 12:08, Michael Selig wrote:
> At 4/12/02, you wrote:
> >Michael Selig writes:
> >
> > > OK, I think I am just getting confused trying to decipher *all* parts of
> > > what you are doing in those files. It's like a puzzle to me.
> >
> >The JSBSim files can be overwhelming -
David Megginson <[EMAIL PROTECTED]> said:
> Curtis L. Olson writes:
>
> > Could the interior be marked as a separate branch of the scene graph
> > and then somehow skipped when viewed from an external view?
>
> We wouldn't want to do that in general -- it would be OK for the 3D
> instruments
At 4/12/02, you wrote:
>Michael Selig writes:
>
> > When I start up I see this:
> > http://amber.aae.uiuc.edu/~m-selig/tmp/beech.gif
>
>Yes, it looks like your gear code isn't holding the plane above the
>ground, so it's resting at its origin. When I try
>
> fgfs --aircraft=c172-uiuc
>
>using
David Megginson wrote:
> I think we've always used +z up. YASim uses +z down internally, if
> I recall correctly, but that shouldn't affect anything else.
Heh, actually... YASim is +z up too.
For the record, the YASim internal aircraft coordinate frame:
+ Take your right hand.
+ Point your
On Fri, 12 Apr 2002 14:08:00 -0500
Michael Selig <[EMAIL PROTECTED]> wrote:
>Ah ... thank you ... I see it now. The fact that
>"CLadot" gets included on the fly is pretty neat. As our
We wanted the ability to add whatever we wanted to for
aero coefficients. One could do lateral or long
Michael Selig writes:
> When I start up I see this:
> http://amber.aae.uiuc.edu/~m-selig/tmp/beech.gif
Yes, it looks like your gear code isn't holding the plane above the
ground, so it's resting at its origin. When I try
fgfs --aircraft=c172-uiuc
using the UIUC files currently in the base
Michael Selig writes:
> The point - are plans underway to have JSBSim include nonlinear
> aero data via path/filename, rather than including all that
> nonlinear data in the single xml file?
Jon is still waiting on me to put together a thin (but conformant) XML
parser for JSBSim, probably a s
--- Michael Selig <[EMAIL PROTECTED]> wrote:
> At 4/12/02, you wrote:
> >Michael Selig writes:
> >
> > > OK, I think I am just getting confused trying
> to decipher *all* parts of
> > > what you are doing in those files. It's like a
> puzzle to me.
> >
> >The JSBSim files can be overwhelming -
At 4/12/02, you wrote:
>Michael Selig writes:
> > Using our FGFS CVS checkout (Simgear, flightsim, fgfsbase) from 4/7/02 +
> > our own uiuc mods, I just remade/installed Simgear and remade fgfs, and I
> > still get this problem.
> >
> > Besides Norman and all of us at UIUC, are other people seeing
Curtis L. Olson writes:
> At one point I had set up a key binding that would dump the current
> lat/lon/ground elev to the console so you could taxi to where you
> wanted to place an object, press a key, and get the exact values
> dumped to console where you could then copy/paste them somepla
At 4/12/02, you wrote:
>Michael Selig writes:
>
> > OK, I think I am just getting confused trying to decipher *all* parts of
> > what you are doing in those files. It's like a puzzle to me.
>
>The JSBSim files can be overwhelming -- they were far worse for me,
>with no background in aerodynamic
Curtis L. Olson writes:
> Could the interior be marked as a separate branch of the scene graph
> and then somehow skipped when viewed from an external view?
We wouldn't want to do that in general -- it would be OK for the 3D
instruments and controls, but if we killed the cockpit interior walls
Michael Selig writes:
> Using our FGFS CVS checkout (Simgear, flightsim, fgfsbase) from 4/7/02 +
> our own uiuc mods, I just remade/installed Simgear and remade fgfs, and I
> still get this problem.
>
> Besides Norman and all of us at UIUC, are other people seeing UIUC and
> LaRCsim models bel
You are right, LOD is a better solution.
Curt.
Christian Mayer writes:
> "Curtis L. Olson" wrote:
> >
> > Jim Wilson writes:
> > > I'm wondering if we can cull the interior surfaces and fix this (not just the
> > > seats, but the inside surfaces of the aircraft).
> >
> > Could the interior be
At 4/12/02, you wrote:
>David Megginson writes:
> >
> >Michael Selig writes:
> >
> > > ... while all these wonderful *uiuc-set.xml airplanes are now being
> > > buried alive, I have a few simple questions (multiple choice):
> >
> >I cannot reproduce your problem -- with yesterday evening's CVS, I
David Megginson wrote:
>
> Christian Mayer writes:
>
> > So it'll be quite hard to solve in a general way. Drawing the plane last
> > in it's own z-buffer range (IIRC we are doing that now with the normal
> > 3D panel) won't work generally, as there might be other objects 'in the
> > way' (i
"Curtis L. Olson" wrote:
>
> Jim Wilson writes:
> > I'm wondering if we can cull the interior surfaces and fix this (not just the
> > seats, but the inside surfaces of the aircraft).
>
> Could the interior be marked as a separate branch of the scene graph
> and then somehow skipped when viewed f
At one point I had set up a key binding that would dump the current
lat/lon/ground elev to the console so you could taxi to where you
wanted to place an object, press a key, and get the exact values
dumped to console where you could then copy/paste them someplace else.
That was really useful when
Jim Wilson writes:
> I'm wondering if we can cull the interior surfaces and fix this (not just the
> seats, but the inside surfaces of the aircraft).
Could the interior be marked as a separate branch of the scene graph
and then somehow skipped when viewed from an external view?
Curt.
--
Curtis
Jim Wilson writes:
> I'm wondering if we can cull the interior surfaces and fix this
> (not just the seats, but the inside surfaces of the aircraft).
Yes, we should be able to. I'd like to add an LOD animation to
model.cxx when I have a chance, and kill the interior at, say, >20m.
All the b
Christian Mayer writes:
> So it'll be quite hard to solve in a general way. Drawing the plane last
> in it's own z-buffer range (IIRC we are doing that now with the normal
> 3D panel) won't work generally, as there might be other objects 'in the
> way' (i.e. between the tower and the plane)
Christian Mayer <[EMAIL PROTECTED]> said:
> Well, I didn'T compile or run FGFS for quite a while, but
>
> Erik Hofman wrote:
> >
> > * When zooming in, form tower view, the structure of the plane gets
> > unstable and starts showing parts of the interior.
>
> I think that's caused by z-buffer
Erik Hofman <[EMAIL PROTECTED]> said:
> Hi,
>
> After not being able to compile FLightGear for about a week, I must say
> FlightGear isn't improving.
>
As for the view and viewmgr parts that I'm working on, it is still in a
state of flux. I sent a few patches to David and Curt last night, b
Well, I didn'T compile or run FGFS for quite a while, but
Erik Hofman wrote:
>
> * When zooming in, form tower view, the structure of the plane gets
> unstable and starts showing parts of the interior.
I think that's caused by z-buffer fighting.
So it'll be quite hard to solve in a general way
The most important non-aircraft object for flying is the windsock, so
I've made an extremely simplistic one and put it in
$FG_ROOT/Models/Airport. You can place one (or more) at your
favourite airport like this:
Windsock
Models/Airport/windsock.xml
-75.686
45.332
300
The so
Norman Vine writes:
> Also IMHO I don't see anything wrong with letting a user's Model
> cancel out ours, we aren't trying to be dictatorial or we wouldn't
> be going to pains to make the SIM configurable.
That's not what I mean. If we put the KSFO terminal building as
model[0], and the us
Hi,
After not being able to compile FLightGear for about a week, I must say
FlightGear isn't improving.
I noticed several bugs/problems/annoyances:
* The scenery starts up in grayscale, and after a while turns to a
complete daylight situation. Just after e few seconds the scenery
returns t
David Megginson writes:
>
>Michael Selig writes:
>
> > ... while all these wonderful *uiuc-set.xml airplanes are now being
> > buried alive, I have a few simple questions (multiple choice):
>
>I cannot reproduce your problem -- with yesterday evening's CVS, I see
>a C172 sitting nicely on top of t
David Megginson writes:
> We'd also need to
>avoid letting any user-supplied models cancel ours out;
>we could
>either put the user's models in a separate subtree or start the
>built-in ones at a high index (like 9).
Setting up and walking a SceneGraph although relatively cheap
is not a
Jim Wilson writes:
> The tile solution is interesting and I need to know more about it
> before commenting on how to do it. Basically I like the idea of
> specifying the model position and orientation in xml (of course
> that could just be my lack of understanding). What might be
> interes
Alexander Kappes <[EMAIL PROTECTED]> said:
> I had the same problem when I thought about how to get all (approach)
> stations <100 miles around the player's plane. In the end I assigned to
> each station the appropriate tile number (bucket) and sorted the stations
> according to this number. As t
Norman Vine <[EMAIL PROTECTED]> said:
> Jim Wilson writes:
> >
> >David Megginson <[EMAIL PROTECTED]> said:
> >
> >> As of this morning, FlightGear has a new infrastructure for
> >> incorporating moving, animated 3D models besides the aircraft model.
> >> This is not intended to be a general solu
I had the same problem when I thought about how to get all (approach)
stations <100 miles around the player's plane. In the end I assigned to
each station the appropriate tile number (bucket) and sorted the stations
according to this number. As the buckets are of course smaller than 100
miles I ha
Erik Hofman writes:
> I've worked on changing the sound code to use the FGCondition code, but
> I noticed the /surface-positions/flap-pos-norm propertie diesn;t get
> updated (JSBSim latest base c172).
No, I'm noticing the same problem. I'm not sure what broke.
All the best,
David
--
Jim Wilson writes:
>
>David Megginson <[EMAIL PROTECTED]> said:
>
>> As of this morning, FlightGear has a new infrastructure for
>> incorporating moving, animated 3D models besides the aircraft model.
>> This is not intended to be a general solution for adding thousands of
>> bridges, buildings, e
Hi,
I've worked on changing the sound code to use the FGCondition code, but
I noticed the /surface-positions/flap-pos-norm propertie diesn;t get
updated (JSBSim latest base c172).
Am I the only one?
Erik
___
Flightgear-devel mailing list
[EMAIL
Jim Wilson writes:
> > As of this morning, FlightGear has a new infrastructure for
> > incorporating moving, animated 3D models besides the aircraft
> > model. This is not intended to be a general solution for adding
> > thousands of bridges, buildings, etc. to the scenery
>
> Why not? I
David Megginson <[EMAIL PROTECTED]> said:
> As of this morning, FlightGear has a new infrastructure for
> incorporating moving, animated 3D models besides the aircraft model.
> This is not intended to be a general solution for adding thousands of
> bridges, buildings, etc. to the scenery
Why not
As of this morning, FlightGear has a new infrastructure for
incorporating moving, animated 3D models besides the aircraft model.
This is not intended to be a general solution for adding thousands of
bridges, buildings, etc. to the scenery -- for that, we need some kind
of tiled solution. With my
John Wojnaroski wrote:
> Commercial off the shelf or unique single point design?
> Are the head tracker and glasses independent systems?
We're using two separate off the shelf systems, namely the i-O Display Systems
i-glasses SVGA, and a head tracker called "Virtua-Track" that I'm guessing is V
* D Luff -- Wednesday 03 April 2002 01:27:
> [...] especially since they fix only valgrind/compiler warnings rather
> than user-visible bugs.
Err ... I'm actually also trying to fix other problems than those reported
by valgrind. :->
* D Luff -- Wednesday 03 April 2002 02:21:
> However, defau
Michael Selig writes:
> OK, I think I am just getting confused trying to decipher *all* parts of
> what you are doing in those files. It's like a puzzle to me.
The JSBSim files can be overwhelming -- they were far worse for me,
with no background in aerodynamics (or even physics, for that ma
Michael Selig writes:
> ... while all these wonderful *uiuc-set.xml airplanes are now being
> buried alive, I have a few simple questions (multiple choice):
I cannot reproduce your problem -- with yesterday evening's CVS, I see
a C172 sitting nicely on top of the runway with any of the followi
Bruce Finney writes:
> The convention for moving models for flight simulation visual system
> is for the origin to be at the CG location for aircraft models.
That would be problematic, since (as Jon and others have pointed out)
the CG isn't fixed. In JSBSim, we take any arbitrary reference po
57 matches
Mail list logo
