Martin Spott wrote:
Anyway, even if someone optimizes FlightGear's use of unusual graphics
hardware there will ever be the lack of CPU cycles, as even modern SGI
Workstations run at moderate CPU speed. This gets pretty obvious when
comparing frame rates of FlightGear running LaRCsim or
Christian Mayer wrote:
PS: Is there a way to install FGFS (+SimGear + PLIB + GLUT) on a Indy
w/o root privileges? I'd like to try it at the university.
For source is easy, just place it in you home directory.
For tardist packages:
inst -r ~
this will change the root of the distribution to
Curtis L. Olson wrote:
I'm still not sure what special graphics features sgi provides (that
something like a mid-hi level geforce card doesn't) that we'd be
interested in.
One thing I know of is default support for stereo glasses.
The rest is almost completely implemented in the new (PC)
Alex Perry wrote:
Someone should actually go through all the entries and pick
appropriate non-texture colors for each material. I thought it would
be intresting to taket the average of all the pixels in the texture,
but never got around to seeing how well that would work. But it's
something
Alex Perry wrote:
Alex, what sgi hardware features are you referring to, and are these
available on any of the machines our developers have access to?
I'm still not sure what special graphics features sgi provides (that
something like a mid-hi level geforce card doesn't) that we'd be
Erik Hofman writes:
This aproach gives us a bonus level of detail:
Create a treshold altitude at which all textures are removed (like F9
was pressed) to gain some extra speed (fps).
On some hardware :-) the video card can do all the texture
calculations in parallel with everything else, so
Curtis L. Olson writes:
On some hardware :-) the video card can do all the texture
calculations in parallel with everything else, so there is very
little performance difference with textures off vs on.
Perhaps more usefully, we could replace entire tiles with
appropriately-coloured
David Megginson wrote:
Curtis L. Olson writes:
On some hardware :-) the video card can do all the texture
calculations in parallel with everything else, so there is very
little performance difference with textures off vs on.
Perhaps more usefully, we could replace entire tiles
Erik Hofman writes:
Curtis L. Olson wrote:
Erik Hofman writes:
This aproach gives us a bonus level of detail:
Create a treshold altitude at which all textures are removed (like F9
was pressed) to gain some extra speed (fps).
On some hardware :-) the video card can do all the
David Megginson writes:
Curtis L. Olson writes:
Getting the tile edges to match without gaps is always the challenge
there.
At a sufficient distance, the problem might not be noticable.
What you really are talking about is an LOD scheme. From my
experience, the gaps end up being
Curtis L. Olson writes:
Beyond that, if you are changing LOD of a tile, you have to consider
what to do with all the objects on the surface of that tile. Do you
let objects float or get buried, or do you let them float up and down
as the underlying terrain changes ... none of these are
David Megginson writes:
Curtis L. Olson writes:
Beyond that, if you are changing LOD of a tile, you have to consider
what to do with all the objects on the surface of that tile. Do you
let objects float or get buried, or do you let them float up and down
as the underlying terrain
Martin Spott writes:
To explain what Erik's talking about: You don't get an appropriate video
card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to
upgrade an Octane SSI to MXI cost more than $1000 - and you can't use
FlightGear's textured scenerey without TRAM
Well in
Curtis L. Olson wrote:
Martin Spott writes:
To explain what Erik's talking about: You don't get an appropriate video
card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to
upgrade an Octane SSI to MXI cost more than $1000 - and you can't use
FlightGear's textured scenerey
Erik Hofman wrote:
Curtis L. Olson wrote:
Martin Spott writes:
To explain what Erik's talking about: You don't get an appropriate video
card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to
upgrade an Octane SSI to MXI cost more than $1000 - and you can't use
You don't expect a software rendering 386 to give decent frame rates, do
you?
Haven't tried that yet, because just the FGFS base is 50MB ... and that PC
only has a 100MB HD. My 486 doesn't do very well, due to software 3D.
If I come across an ISA 3D card spare, I try it ... it might be
To explain what Erik's talking about: You don't get an appropriate video
card that you can use in an SGI for just $50. 2x 4 MByte Texture RAM to
upgrade an Octane SSI to MXI cost more than $1000 - and you can't use
FlightGear's textured scenerey without TRAM
In my last job we ran a
Erik,
I want to clarify that I wasn't trying to speak ill of sgi or those
who use sgi computers. I was just responding to Martin Spott's
suggestion that it would cost $1000 to turn an Octane SSI into
something that could reasonably run FlightGear. And then pointing out
that for that $1000 you
Any, my real point here is that I personally do not care to work very
hard to support a non-textured flightgear mode simply for the sake of
old sgi hardware. However, if there are other reasons as well
... supporting notebook (few of which have 3d graphics), or to still
support cards with
Curtis L. Olson wrote:
Erik,
I want to clarify that I wasn't trying to speak ill of sgi or those
who use sgi computers. I was just responding to Martin Spott's
suggestion that it would cost $1000 to turn an Octane SSI into
something that could reasonably run FlightGear. And then
Erik Hofman writes:
Anyway, I've discovered that allmost all of the ambient and diffuse
colors in the materials.xml file hive the same value for r, g an b.
I guess there has gone something wrong in the conversion of the
file.
Ahhh, that actually looks like the source of the problem r = g
* [EMAIL PROTECTED] (Erik Hofman) [2002.01.31 14:14]:
Curtis L. Olson wrote:
Erik,
I want to clarify that I wasn't trying to speak ill of sgi or those
who use sgi computers. I was just responding to Martin Spott's
suggestion that it would cost $1000 to turn an Octane SSI into
something
Erik Hofman writes:
I guess there has gone something wrong in the conversion of the file.
Does anybody have the original still laying around?
The colours in the original were mostly not filled in either,
unfortunately. When you tweak the colours around, do you get anything
useful?
All
* [EMAIL PROTECTED] (David Megginson) [2002.01.31 15:32]:
Cameron Moore writes:
Yes, this is definately wrong. I have a copy, but I'm not sure how old
it is (prolly a couple months). I don't think it has all of the changes
up to when it was removed. Anybody know how to retrieve it
Well, the modern SGIs shouldn't have trouble running a recent version of
FGFS. So we run on a SGI.
Yep, as long as you have lots of CPU cycles. I believe an R10k at 300 MHz is
minimum, also a MaxImpact/MXI graphics subsystem with maximum TRAM should be
recommended.
PS: Is there a way to
Martin Spott wrote:
From: Alex Perry [EMAIL PROTECTED]
It's also worth bearing in mind that
(a) FGFS is currently not taking advantage of some SGI hardware features
Do you believe it might make sense to take these features into account for
FlightGear ? I had the impression that by
David Megginson writes:
Erik Hofman writes:
I guess there has gone something wrong in the conversion of the file.
Does anybody have the original still laying around?
The colours in the original were mostly not filled in either,
unfortunately. When you tweak the colours around, do
Martin Spott writes:
From: Alex Perry [EMAIL PROTECTED]
It's also worth bearing in mind that
(a) FGFS is currently not taking advantage of some SGI hardware
features
Alex, what sgi hardware features are you referring to, and are these
available on any of the machines our developers have
On Thursday 31 January 2002 04:09 pm, you wrote:
* [EMAIL PROTECTED] (Erik Hofman) [2002.01.31 14:14]:
Curtis L. Olson wrote:
Erik,
I want to clarify that I wasn't trying to speak ill of sgi or those
who use sgi computers. I was just responding to Martin Spott's
suggestion that it
Alex, what sgi hardware features are you referring to, and are these
available on any of the machines our developers have access to?
I'm still not sure what special graphics features sgi provides (that
something like a mid-hi level geforce card doesn't) that we'd be
interested in.
I'm
Someone should actually go through all the entries and pick
appropriate non-texture colors for each material. I thought it would
be intresting to taket the average of all the pixels in the texture,
but never got around to seeing how well that would work. But it's
something you could then
Curtis L. Olson wrote:
Now - Feb 8 (this week and next) is the last chance to submit new
features for the 0.7.9 version. Preferably I'd see more bug fixes
than features in this time.
Feb 9 - Feb 15: Everyone should be building from cvs and the trial
tarballs and reporting any
Curtis L. Olson writes:
Uh oh, could this have been introduced when David converted the
materials file to materials.xml? I don't think it's a widely used
feature. I wouldn't be opposed to completely ripping it out. These
days if your video hardware doesn't have reasonable texture you
On Tuesday 29 January 2002 05:08 pm, you wrote:
I really, really, really want to roll out the FlightGear-0.7.9 release
soon. I haven't posted an official release time table yet, but I will
do that in this message.
John Check writes:
For sure. Just make sure you guys don't commit any
34 matches
Mail list logo
