Hi,
I'm not sure whether emmisive, specular and diffuse lighting might give
a different result here.
Hmm, I don't think things are that dramatic... Admittetly, the following
thoughts apply only to local (per-texel) image differences, but
the big picture shoudln't be worse of.
The specular
On Saturday, 29 January 2005 01:44, Manuel Massing wrote:
The real problem is that it's hard to get detailed textures for the whole
world (and storage hungry!!). What I'd like to experiment with later on is
to let a classifier run over the globally available 28.5m landsat textures,
and use the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel Massing schrieb:
Hello,
I do have a few questions though :
Does the current code that you have handle texture paging?
Yes, textures and geometry are paged and decompressed asynchronously in the
background (seperate thread). The
On Saturday, 29 January 2005 12:54, Christian Mayer wrote:
Manuel Massing schrieb:
Hello,
I do have a few questions though :
Does the current code that you have handle texture paging?
Yes, textures and geometry are paged and decompressed asynchronously in
the background (seperate
On Saturday, 29 January 2005 13:49, Paul Surgeon wrote:
On Saturday, 29 January 2005 12:54, Christian Mayer wrote:
Manuel Massing schrieb:
Hello,
I do have a few questions though :
Does the current code that you have handle texture paging?
Yes, textures and geometry are paged
Hello,
Norman just pointed JPEG 2000 out to me which is open source (and royalty
free for GPL projects) and far better than the standard JPEG most of us
use. It uses state-of-the-art wavelet compression and some of the
comparisons I've seen are incredible. It supports both lossless and lossy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Surgeon schrieb:
On Saturday, 29 January 2005 12:54, Christian Mayer wrote:
Manuel Massing schrieb:
Hello,
I do have a few questions though :
Does the current code that you have handle texture paging?
Yes, textures and geometry are paged
Hi,
For normal photographs that's great - for textures that get scaled,
projected, sheared (sp?), lit, ... the uses assumptions dodn't hold
anymore.
Why should projection, shearing, scaling be a problem? Wouldn't every JPEG
image displayed on your computer screen would look lousy when looking
On Saturday, 29 January 2005 15:10, Christian Mayer wrote:
For normal photographs that's great - for textures that get scaled,
projected, sheared (sp?), lit, ... the uses assumptions dodn't hold
anymore.
An extreme example: when you use a very high compression rate you'll see
the blocking
Paul Surgeon wrote:
I don't see why we have to limit ourselves to *having* to have world coverage
for the engine to be useful.
Yes, could the 10x10 degree sections be a mixture of: most made with the
terragear engine, and some made with other engines?
Perhaps depending on complexity, population
Christian Mayer wrote:
Manual Massing wrote:
Yes, textures and geometry are paged and decompressed
asynchronously in the background (seperate thread). The engine
supports image compression to save IO (and possibly bus)
bandwith, e.g. JPEG and S3TC compression. The first maybe quite
Andy Ross a écrit :
Christian Mayer wrote:
Manual Massing wrote:
Yes, textures and geometry are paged and decompressed
asynchronously in the background (seperate thread). The engine
supports image compression to save IO (and possibly bus)
bandwith, e.g. JPEG and S3TC compression. The first
Frederic Bourvier wrote:
It is still true that JPEG have no alpha channel, so not all
textures could be converted.
Yes. Although the loader could play tricks like storing the
alpha channel in a separate grayscale image. And I believe the
already-mentioned jpeg2000 format does support
Hello Oliver,
There is a trick to create textures with a 15 m resolution based on landsat
data:
http://www.terrainmap.com/rm29.html
yes, fusing the panchromatic channel is a nice option.
Ideally, one should devise an algorithm which can do the fusing at runtime
(e.g. in the pixel shaders), so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andy Ross schrieb:
Christian Mayer wrote:
Manual Massing wrote:
Yes, textures and geometry are paged and decompressed
asynchronously in the background (seperate thread). The engine
supports image compression to save IO (and possibly bus)
bandwith,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Martin schrieb:
On Saturday 29 Jan 2005 17:39, Frederic Bouvier wrote:
Has anyone actually looked at how much of the base package is
taken up by SGI+ format image files? (Which have absolutely
abysmal compression ratios, but that's a
On Saturday, 29 January 2005 19:39, Frederic Bouvier wrote:
It is still true that JPEG have no alpha channel, so not all textures
could be converted.
There is no reason why the alpha channel cannot be shipped in a separate 8 bit
bitmap of some sort with the JPEG just providing the color map.
Christian Mayer wrote:
For our case that compressor must not rely on special optical
tricks (because these get destroyed when they are used as an
texture).
All lossy compressors rely on special optical tricks, that's the
point. If all the data was equally important, you
couldn't lose any of
Andy Ross wrote:
All lossy compressors rely on special optical tricks, that's the
point. If all the data was equally important, you
couldn't lose any of it without damaging the image. This is
where Steve is overgeneralizing. Simply using an image as a
texture (which is just a picture intended
On Friday 28 January 2005 05:14, Curtis L. Olson wrote:
I'm told there is a way to do this with shaders, but plib/ssg doesn't
support shaders. :-(
Curt.
What happended about Manual Massing's new alternative terrain engine?
Oliver C. wrote:
On Friday 28 January 2005 05:14, Curtis L. Olson wrote:
I'm told there is a way to do this with shaders, but plib/ssg doesn't
support shaders. :-(
Curt.
What happended about Manual Massing's new alternative terrain engine?
On Friday 28 January 2005 18:20, Curtis L. Olson wrote:
Oliver C. wrote:
On Friday 28 January 2005 05:14, Curtis L. Olson wrote:
I'm told there is a way to do this with shaders, but plib/ssg doesn't
support shaders. :-(
Curt.
What happended about Manual Massing's new alternative terrain
Oliver C. wrote:
Are there plans or better a planned release date
when the missing features will get added into plib?
You'll have to ask the plib people. Steve is very persnickety about
this section of the code and I suspect he may not allow significant
changes unless he does them himself,
Curtis L. Olson wrote:
If he has all these things, then that's wonderful, he has done an
impressive piece of work. I'm not trying to be critical here, I'm
just pointing out that this is *very* difficult stuff. It's one
thing to do a nice little demo, it's something else entirely to
tackle
Hello,
As with everything, really, the key here is integration. Make it work
with FlightGear so we can test. Saying here is code, can we use it?
just isn't enough. It needs to be here is a patch, try it and tell
me what breaks. Until we get that far, there really isn't much to
argue
On Friday, 28 January 2005 22:14, Manuel Massing wrote:
I completely agree with you on the integration part. I think the engine
is technically adequate for its intended purposes (i.e. satellite-textured
landscapes). If you have any questions concerning the technical side, feel
free to ask.
I
On Friday 28 Jan 2005 21:21, Paul Surgeon wrote:
Yes, I'm sure there are plenty of users who are happy with the current
scenery engine and one of the advantages it has is that there is no paging
of huge textures while flying. This allows for high speed flights without
any pausing and can also
Hello,
I do have a few questions though :
Does the current code that you have handle texture paging?
Yes, textures and geometry are paged and decompressed asynchronously in the
background (seperate thread). The engine supports image compression to save IO
(and possibly bus) bandwith, e.g. JPEG
The real problem is that it's hard to get detailed textures for the whole
world (and storage hungry!!). What I'd like to experiment with later on is
to let a classifier run over the globally available 28.5m landsat textures,
and use the resulting classifications to generate missing detail at
On Friday 28 January 2005 19:44, Curtis L. Olson wrote:
Oliver C. wrote:
Are there plans or better a planned release date
when the missing features will get added into plib?
You'll have to ask the plib people. Steve is very persnickety about
this section of the code and I suspect he may not
30 matches
Mail list logo
