On Tuesday 02 December 2003 02:31, Curtis L. Olson wrote:
My understanding of systems that impliment these basic ideas is that
step 1) is to give up the idea of seamless, non-blurry textures in the
distance. Every system I have seen blurs the textures excessively as
you go further in the
[EMAIL PROTECTED] writes:
On Tuesday 02 December 2003 02:31, Curtis L. Olson wrote:
My understanding of systems that impliment these basic ideas is that
step 1) is to give up the idea of seamless, non-blurry textures in the
distance. Every system I have seen blurs the textures
Paul Surgeon wrote:
Yeah that's because the scenery is pre-rendered. Who said we have to
pre-render the scenery? :)
Rendering in real time would only require a library of geodata which would be
similar in size to the current FG scenery.
In that case, it wouldn't look like TerraScene scenery --
Curtis L. Olson writes:
Andy Ross writes:
That was my thinking when I started, too. But your math is a little
off. Getting to a worst case resolution of 1 texel per screen-space
pixel with unique texturing requires *vast* amounts of memory.
Yup, I doubt if we get to the 1 texel -
On Tuesday 02 December 2003 13:57, Curtis L. Olson wrote:
[EMAIL PROTECTED] writes:
Couldn't we load the whole data into RAM before?
1 GB Ram are cheap today.
1. Threre is a big difference between having texture data loaded into
main RAM vs. having the texture data loaded into your
Oliver C. wrote:
Couldn't we load the whole data into RAM before?
1 GB Ram are cheap today.
It's not nearly that simple. If you want to draw something on the
screen, it has to get into the video card's memory at some point
during the frame. Even 256MB Übercards are going to thrash* with a
1GB
[EMAIL PROTECTED] writes:
1. Threre is a big difference between having texture data loaded into
main RAM vs. having the texture data loaded into your cards video
RAM. (There are probably a few exceptions, the only one I can
think of at the moment is the sgi O2 which has a
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
would make life easier for you guys. Why not just dump it for a scene
graph library that does the job you need it to
Gene Buckle writes:
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
would make life easier for you guys. Why not just dump it for a scene
graph library that
On Tuesday 02 December 2003 16:56, Curtis L. Olson wrote:
Gene Buckle writes:
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
would make life easier for you
Gene Buckle writes:
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
would make life easier for you guys. Why not just dump it for a scene
graph
Oliver C. wrote:
Does dumping plib mean that we can choose something like the SDL
library for the OpenGL initialization?
No, that means dumping glut. Earlier plib versions had a glut
dependency, but I believe that has been removed from current versions.
We can keep the plib parts that we use
On 09:56 Tue 02 Dec , Curtis L. Olson wrote:
This is something that has been considered, but it will be a massive
amount of work to do this and preserve all the existing functionality.
Massive might be slightly overstated, but it probably means tearing
everything down and rebuilding it
Gene Buckle writes:
I can imagine this would be a complex undertaking, but wouldn't it be the
best solution in the long run?
Sure, and it's on the todo list (or to investigate list) somewhere.
However, there is always a significant time shortage.
If it would be easier, why not just fork plib
On Tuesday 02 December 2003 16:21, Curtis L. Olson wrote:
But when the data is allready in the RAM we wouldn't need
to load the data from the slow hard drive.
Right, but sending that much data across the AGP bus isn't fast
either, especially when you want/need to draw at 60hz. Sure,
[EMAIL PROTECTED] writes:
On Tuesday 02 December 2003 16:56, Curtis L. Olson wrote:
Gene Buckle writes:
Unfortunately, plib (our scene graph engine) doesn't support
multitexturing at this point in life. :-(
From what I've read, this isn't the only thing it doesn't support that
[EMAIL PROTECTED] writes:
On Tuesday 02 December 2003 16:21, Curtis L. Olson wrote:
But when the data is allready in the RAM we wouldn't need
to load the data from the slow hard drive.
Right, but sending that much data across the AGP bus isn't fast
either, especially when you
On Tuesday 02 December 2003 18:15, Curtis L. Olson wrote:
Ok, do you know any good documentation and information about this
particular real time rendering topic. That doesn't mean that i will
write such an engine, but i just want to read the basic stuff so
that i know what i am talking
On Tuesday, 2 December 2003 19:15, Curtis L. Olson wrote:
If a person is working on some feature that won't be finished for 2
years, then I think it is reasonable to try to predict card
performance that far out and write to future hardware. In large part,
that is what we did when we started
Curtis L. Olson wrote:
I would recommend doing a net search for CLOD (continuous level of
detail) and ROAM (I forget what that stands for.)
Real-time Optimally Adapting Meshes.
--
Russ
Conway's Law: The structure of a system tends to mirror the
structure of the group producing it.
-- Mel
[Heh, this turned out longer than I expected when I started writing...]
Curtis L. Olson wrote:
I would recommend doing a net search for CLOD (continuous level of
detail) and ROAM (I forget what that stands for.) There are a lot of
spiffy demos out there. However, there are some non-trivial
Andy Ross [EMAIL PROTECTED] wrote:
Oliver C. wrote:
Does dumping plib mean that we can choose something like the SDL
library for the OpenGL initialization?
No, that means dumping glut. Earlier plib versions had a glut
dependency, but I believe that has been removed from current versions.
Paul Surgeon wrote:
A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
would require about 311 GB of storage space using S3TC compression with a
texture resolution of 1 meter/pixel.
Probably half, that, actually, since a lot of the trip is over ocean.
All the best,
A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
would require about 311 GB of storage space using S3TC compression with a
texture resolution of 1 meter/pixel.
You can buy 320MB of hard disk space for a mere USD 275 (GBP 160) if you shop
around. What sounds OTT
David Megginson writes:
Paul Surgeon wrote:
A corridor 100 km wide between Chicago (Illinois) and London (UK) (6378 km)
would require about 311 GB of storage space using S3TC compression with a
texture resolution of 1 meter/pixel.
Probably half, that, actually, since a lot of the
I made a tilable grass texture today.
If anyone likes it and wants to use for some part of FG then let me know and
I'll e-mail it to you. 1024x1024 RGB - 3MB
I made it quite light to reflect the type of grass in my part of the world so
if someone wants darker greens let me know and I'll tweak
Paul Surgeon writes:
Now if I can just figure out how to change the mip mapping to not be so
aggressive. It kills the texture detail far too close to the viewer and makes
the screenshots look bad.
The best thing I've seen for this is to enable anisotropic texture
filtering for your card. On
Paul Surgeon schrieb:
I made a tilable grass texture today.
It looks great
If anyone likes it and wants to use for some part of FG then let me know and
I'll e-mail it to you. 1024x1024 RGB - 3MB
1024x1024 is *extremly* big for such a texture!
We should try to render our terrain with
If you could define N multiple textures overtextures, you would get N^2
possible textures, which would really break up the patterns for a small
memory cost.
And while you're on the subject of We should try, I've always wondered
about using multitextures with the top one off the ground. You
Josh Babcock writes:
If you could define N multiple textures overtextures, you would get N^2
possible textures, which would really break up the patterns for a small
memory cost.
And while you're on the subject of We should try, I've always wondered
about using multitextures with the top
Paul Surgeon wrote:
I'm sure there will be protesters but this polygonal looking scenery is not
very nice in my opinion. Yes it works but it doesn't even begin to resemble
real life scenery.
Out of curiosity has anyone ever used TerraScene?
(synthetic scenery generation app for Fly! and Fly!2)
Paul Surgeon wrote:
Detail textures help but I they are not the answer.
What is needed is new terrain rendering engine. :D
I'm sure there will be protesters but this polygonal looking
scenery is not very nice in my opinion. Yes it works but it doesn't
even begin to resemble real life
On Tuesday, 2 December 2003 00:12, David Megginson wrote:
Yes, I did use it -- it was a very well-thought out little program, but it
had some pretty disasterous problems:
1. The generated scenery was enormous: we couldn't dream of making
worldwide scenery available online (TerraScene scenery
On Tuesday, 2 December 2003 00:16, Andy Ross wrote:
But the answer can't possibly be to blow 4MB of card memory per
texture. There are dozens of terrain types. Even a 256MB megacard is
going to run short when you spend your VRAM like that that.
It would not work for the way the current
Paul Surgeon wrote:
Think along the lines of about 57MB for 400 km2 with the terrain
directly under the aircraft at 1 meter/pixel resolution and then
gradually tappering off to 8 meters/pixel in 5 steps to a distance
of 10 km in all directions from the aircraft.
That was my thinking when I
Could it be possible to create a rendering engine that allows
us to fly from the ground up into space seamlessly?
Many flight simulators have their limits at around 5 feet altitude
so it would be great if we are able to fly higher in flightgear.
This would be desirable for something like
Andy Ross writes:
That was my thinking when I started, too. But your math is a little
off. Getting to a worst case resolution of 1 texel per screen-space
pixel with unique texturing requires *vast* amounts of memory. The
anisotropy kills you; far-away texels might typically be rendered at
37 matches
Mail list logo
