David Megginson wrote:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Navaids
In directory seneca:/tmp/cvs-serv23071/src/Navaids
Modified Files:
fix.hxx ils.hxx nav.hxx
Log Message:
Mac OS X patches from Jonathan Polley.
*** 37,41
#elif defined(
Erik Hofman wrote:
David Megginson wrote:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Navaids
In directory seneca:/tmp/cvs-serv23071/src/Navaids
Modified Files:
fix.hxx ils.hxx nav.hxx
Log Message:
Mac OS X patches from Jonathan Polley.
*** 37,41
#elif
Jim Wilson writes:
- add animations for the model as a whole
- add submodels
- add billboards
- add UV animations
Billboards-? you mean like those big signs they allow in other states? Is
animation for blinking aircraft lights included in the above?
No -- I
Hmmm, The bigger airports tend to use the same frequency for each end
of their runways. So this change will probably break half the
approaches at the major airports (KLAX, KMSP, KORD, KDFW, etc.)
I made a change to return the matching station that points most
directly at us. This should be the
Are you using scenery_center or next_scenery_center? It's been so
long I don't recall all the resoning, but next_scenery_center was made
available to the view manager so it can get the view position correct
even when we cross a tile boundary and the offsets change.
Regards,
Curt.
Jim Wilson
Curtis L. Olson [EMAIL PROTECTED] said:
Are you using scenery_center or next_scenery_center? It's been so
long I don't recall all the resoning, but next_scenery_center was made
available to the view manager so it can get the view position correct
even when we cross a tile boundary and the
David,
It sounds like you are bypassing SG_LOG() because it isn't doing what
you want. This seems like a bandaid solution at best. Perhaps we
should put these messages back in as SG_LOG( SG_ALERT ) and then
default 'release' builds to a minimum logging level of SG_ALERT rather
than collapsing
Curtis L. Olson writes:
It sounds like you are bypassing SG_LOG() because it isn't doing what
you want. This seems like a bandaid solution at best. Perhaps we
should put these messages back in as SG_LOG( SG_ALERT ) and then
default 'release' builds to a minimum logging level of
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision 1.37
diff -C2 -r1.36 -r1.37
Cameron Moore wrote:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision
--- David Megginson [EMAIL PROTECTED] wrote:
Tony Peden writes:
Restoring a flight is not
working in a running FlightGear session because
of
JSBSim trim-routine
problems,
What is it doing (or not, as the case may be)?
It's not setting body velocities from the save
--- David Megginson [EMAIL PROTECTED] wrote:
Tony Peden writes:
Restoring a flight is not
working in a running FlightGear session because
of
JSBSim trim-routine
problems,
What is it doing (or not, as the case may be)?
It's not setting body velocities from the save
Bernie Bright wrote:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit
In directory seneca:/tmp/cvs-serv20681
Modified Files:
panel_io.cxx
Log Message:
Sgi doesn't define the != operator for string != char[] so we need to cast
the char array into a
David,
This is going to mess up rendering of distant mountains for people
with voodoo cards (i.e. 16 bit buffers).
Depth buffer precision is *very* sensitive to the near clip plane
distance:
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
I'm really nervous about forcing this
David Megginson writes:
Changed the near clip plane to 0.1f regardless. Previously, it jumped
to 10m after takeoff, but that doesn't really make sense any more,
especially if models are going to have interior views. Is there any
real saving in pushing the near plane out anyway?
On 5 Mar 2002, at 8:40, Curtis L. Olson wrote:
David,
This is going to mess up rendering of distant mountains for people
with voodoo cards (i.e. 16 bit buffers).
And not just 16 bit cards - I get flashing polygons in the sky with
two different 32 bit cards at 0.5, progressively cured by
Alex Perry writes:
and for the latter you're in ground haze in any case.
You Californians speak for yourselves!
:-)
Cheers - Dave
--
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Curtis L. Olson wrote:
I'm really nervous about forcing this down to 0.1 for all cases. This
will mess things up for people with voodoo cards.
Can we change this back?
Perhaps we need to do a separate pass for rendering the 3d model and
change the near clip plane just for that
Curt wrote:
Perhaps we need to do a separate pass for rendering the 3d model and
change the near clip plane just for that portion of the rendering.
Yes. That should be easy to do. BoB does it as well, they even have 3
or 4 different parts of the geometry that they render with 3 or 4
Alex Perry writes:
Putting the clip plane at 0.1 is an easy way to stop me doing demos of FGFS.
I don't _have_ a machine with better than 16 bit depth buffering, and the
notebook that I do most of the demos with cannot of course be upgraded.
I understand. How does everything look with
Andy Ross writes:
Or just turn the depth buffer off for the cockpit and sort the
geometry; for most cockpit layouts, this should be pretty feasible.
It won't work if the cockpit has moving parts (yokes or whatnot) that
obscure other pieces.
I don't think this is an easy option, at least
David Megginson [EMAIL PROTECTED] said:
I don't think this is an easy option, at least not with a true 3D
model wrapped around the viewer. We'll have to find a more robust
solution. To start, I can make the depth buffer 0.1 only when the
interior model view is enabled, so no one loses
Curtis L. Olson [EMAIL PROTECTED] said:
David,
Assuming all of this is being drawn via plib/ssg then you could put
all the geometry in a separate ssgRoot node and call ssgCullandDraw()
on this root after everything else has been rendered. We have a
couple ssgRoot's already so we can
Jim Wilson wrote:
Ummm...why not clear the z-buffer and use a seperate scene graph?
Note that there are *lots* of people using pre-geforce generation
hardware. Probably more than not.
Actually, it's those folks who are at risk. Clearing the whole z
buffer soaks up big chunks of
Or just turn the depth buffer off for the cockpit and sort the
geometry; for most cockpit layouts, this should be pretty feasible.
It won't work if the cockpit has moving parts (yokes or whatnot) that
obscure other pieces.
Even if they obscure, it is only a problem if they swap places so
David Luff writes:
Alex Perry writes:
and for the latter you're in ground haze in any case.
You Californians speak for yourselves!
[EMAIL PROTECTED]
Ya see, here the temperature is _above_ freezing and _not_ raining
at the same time 8-). I'll take poor visibility over days of drizzle...
Jim Wilson writes:
Ummm...why not clear the z-buffer and use a seperate scene graph? Note that
there are *lots* of people using pre-geforce generation hardware. Probably
more than not.
Time -- I don't know if I'll have time to figure all that out this
week.
All the best,
David
--
Alex,
Try doing a make clean inside JSBSim and then rebuild everything.
Curt.
Alex Perry writes:
You likely don't notice any of this if you
are running a card with a 32bit depth buffer (i.e. geforce.)
Don't worry Curt, leave the change in, I don't see the problem on 16 bit ...
You likely don't notice any of this if you
are running a card with a 32bit depth buffer (i.e. geforce.)
Don't worry Curt, leave the change in, I don't see the problem on 16 bit
...
Loading tile /usr/local/lib/FlightGear/Scenery/w120n30/w118n32/1023667
ESC[1mESC[4mJSBSim Flight
13971 Segmentation fault
[you *are* joking, aren't you?!?!]
Err, no. Sorry. Curt suggest I recompile ... in progress ...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.01.17 09:25]:
! echo -n Running automake
! if [ $OSTYPE = IRIX -o $OSTYPE = IRIX64 ]; then
! echo --add-missing --include-deps
! automake --add-missing --include-deps
! else
! echo --add-missing
! automake --add-missing
! fi
Ok, thanks, this should now be installed for FlightGear and SimGear.
I'll work on TerraGear at some future time when I get a chance.
Curt.
Ross Golder writes:
This is how it appears to be set up for me:
In CVSROOT/loginfo, add the line :
DEFAULT $CVSROOT/CVSROOT/syncmail %{sVv}
[EMAIL
On Thu, 2001-12-13 at 03:48, David Megginson wrote:
Date: Wednesday December 12, 19101 @ 21:48
Author: david
Wow! What're things like in the year 19101, David? Has FlightGear 1.0
been release yet :o) ?
--
Ross
___
Flightgear-devel
Ross,
I believe what David was doing was adding the autogenerated files to
the .cvsignore files ... (threw me at first too.)
Curt.
Ross Golder writes:
Why add auto-generated files to the CVS repository?
I think it is generally considered (by other open source projects
anyway) a bad idea
Ross Golder writes:
Why add auto-generated files to the CVS repository?
I didn't -- I added config.h to .cvsignore, so that cvs won't complain
about an unknown file.
Modified Files:
.cvsignore
Log Message:
Added config.h, which is autogenerated.
All the best,
David
--
Phew! :-)
Did we get anywhere with adding cvs diff output to the cvslogs messages,
as per SourceForge? That would have made it a bit more obvious.
--
Ross
On Tue, 2001-12-11 at 21:43, Curtis L. Olson wrote:
Ross,
I believe what David was doing was adding the autogenerated files to
the
Ross Golder writes:
Did we get anywhere with adding cvs diff output to the cvslogs messages,
as per SourceForge? That would have made it a bit more obvious.
I think I'm losing email over the side of the bucket ... can someone
send a proper script to me directly?
Thanks,
Curt.
--
Curtis
501 - 537 of 537 matches
Mail list logo
