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
Manuel Massing writes:
It could be worthwhile looking into if we need to store large images.
The SDK with source code is available at http://www.ermapper.com
The terrain engine also supports the jasper JPEG2000 library. Unfortunately,
the last time I tested, JPEG2000 decoding performed
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
Ampere K. Hardraade wrote:
How about not rendering ground textures at night? Has this been done yet?
I don't think turning off texturing makes any difference on common
hardware (including my O2, it will give me 1fps more). The code to draw
untextured terrain has been removed some time ago.
Erik Hofman wrote:
The code to draw
untextured terrain has been removed some time ago.
Saddly :-(
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman
Sent: Friday, January 28, 2005 3:58 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Runway lighting
Ampere K. Hardraade wrote:
How about not rendering ground
Roman Grigoriev wrote:
Hi guys!
I have too framerate drops when lights are switch on. on my FX5950 ultra and
PIV3500
We don't need to have plib support of shaders.
I use shaders for runway lights. I don't use triangles I use
points(pointsprites). and in shader I use normals to calculate visibility
- Original Message -
From: Erik Hofman [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Friday, January 28, 2005 1:34 AM
Subject: Re: [Flightgear-devel] Runway lighting
Roman Grigoriev wrote:
Hi guys!
I have too framerate drops when
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
Paul Surgeon wrote:
I played around with some runway lighting today to see if textured polygons
are feasible.
Here is what textured, billboard runway lights look like :
http://surgdom.hollosite.com/flightgear/screenshots/index.html
With 6 * 1 ft runways all in view at one time my frame rate
On 27/01/2005 at 12:19 Curtis L. Olson wrote:
snip rwy lights are dropping the frame rate
Any ideas?
Not on the technical side, but one thing we could do now is to ditch the
green taxiway center lights. These aren't specified in the new format apt
data, and the latest build has defaulted
David Luff wrote:
On 27/01/2005 at 12:19 Curtis L. Olson wrote:
snip rwy lights are dropping the frame rate
Any ideas?
Not on the technical side, but one thing we could do now is to ditch the
green taxiway center lights. These aren't specified in the new format apt
data, and the latest
On Thursday, 27 January 2005 20:47, David Luff wrote:
Note that the EGLL poly count is already
hitting my frame rate to begin with - at daytime it's about 60 with view
away from airport, 30 with view including airport. Then 10 with the
lighting added. The frame rate with lighting enabled at
On 28/01/2005 at 00:00 Paul Surgeon wrote:
On Thursday, 27 January 2005 20:47, David Luff wrote:
Note that the EGLL poly count is already
hitting my frame rate to begin with - at daytime it's about 60 with view
away from airport, 30 with view including airport. Then 10 with the
lighting
How about not rendering ground textures at night? Has this been done yet?
Ampere
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Hi,
in real life. Currently the lighting at EGLL or KSFO drops my frame rate
from around 30 to about 10. Based on a rough estimate of light numbers, I
reckon that ditching the green taxiway centerlights might get back 3 - 4
fps, not brilliant but a start. Note that the EGLL poly count is
Curtis L. Olson wrote:
Paul Surgeon wrote:
I played around with some runway lighting today to see if textured
polygons are feasible.
Here is what textured, billboard runway lights look like :
http://surgdom.hollosite.com/flightgear/screenshots/index.html
With 6 * 1 ft runways all in view at
Tiago Gusmão wrote:
Altough the billboard itself always faces the POV, you can still set
the normal the way the real light would be pointing to, them set a
diffuse light on the POV and enable backface culling.
I suppose performance hit should be minimal for TnL hardware.
The normal only affects
On Friday 28 January 2005 02:18, Curtis L. Olson wrote:
Tiago Gusmão wrote:
Altough the billboard itself always faces the POV, you can still set
the normal the way the real light would be pointing to, them set a
diffuse light on the POV and enable backface culling.
I suppose performance
Oliver C. wrote:
What about setting only one point at the beginning of the runway
and then calculating an angel between it and the normal of the billboard.
When the angel is 90° or - 90° the billboard is turned off when it is
90° or -90° then on.
We might need to do something like that.
- Original Message -
From: Curtis L. Olson [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Thursday, January 27, 2005 8:14 PM
Subject: Re: [Flightgear-devel] Runway lighting
Oliver C. wrote:
What about setting only one point
I played around with some runway lighting today to see if textured polygons
are feasible.
Here is what textured, billboard runway lights look like :
http://surgdom.hollosite.com/flightgear/screenshots/index.html
With 6 * 1 ft runways all in view at one time my frame rate dropped from
50
On Friday 18 October 2002 09:17 pm, David Megginson wrote:
John Check writes:
The last time we had KSFO with lights in there it had some problems
too. I think it's worth the tradeoff but if you think it's going
to break anything I can hold off.
I'd prefer to put in a complete rebuild
William L. Riley writes:
unlurk
I have been busy lately (who hasn't?) but can find the time to do a base
Scenery rebuild. What is the status of the lighting? Should I do a rebuild
this weekend? I'll have to check the back messages as I haven't been
following along as closely as I
On Saturday 19 October 2002 03:30 pm, [EMAIL PROTECTED] wrote:
It would be wise to wait a week or two before doing a complete rebuild
of the scenery, in case Curt needs to change anything, but a rebuild
of w130n30 (or at least the area around KSFO) would be very welcome
this weekend.
I am
The base scenery package was rebuilt tonight and is available for download.
http://www.randdtechnologies.com/fgfs/newScenery/
The rebuild went very smoothly so there is probably some huge glaring error
that I missed. ;)
Wm
--
William L. Riley
[EMAIL PROTECTED]
On Saturday 19 October 2002 7:42 pm, William L. Riley wrote:
The base scenery package was rebuilt tonight and is available for download.
http://www.randdtechnologies.com/fgfs/newScenery/
The rebuild went very smoothly so there is probably some huge glaring error
that I missed. ;)
Wm
On Saturday 19 October 2002 7:42 pm, William L. Riley wrote:
The base scenery package was rebuilt tonight and is available for download.
http://www.randdtechnologies.com/fgfs/newScenery/
The rebuild went very smoothly so there is probably some huge glaring error
that I missed. ;)
Wm
Looks
Martin Spott writes:
but in reality not every airport _has_ lightning. Mybe it would be
appropriate to stick to the information on airport lightning that is present
in the airport database,
It's already there.
All the best,
David
--
David Megginson, [EMAIL PROTECTED],
John Check writes:
If you want to fly this yourself, you can grab:
http://www.flightgear.org/tmp/KSFO.btg.gz
Does anybody have a copy or a proper link? it seems to be 404.
My fault, didn't push my change out to the web server ...
Curt.
--
Curtis Olson IVLab / HumanFIRST Program
Martin Spott writes:
Curt,
No one commented on my last runway lights message so I figured I'd
send some more picts of the latest:
Yesterday night it was simply too late to give appropriate comment
I am _really_ amazed. In my eyes this this is the most valuable visual
feature in
Curtis L. Olson writes:
Our world (once I finishe with the other lighting schemes, and once
it's regenerated) will be as close to reality as our database
allows.
Have you patched TerraGear to eliminate runway edge lights for
unlighted runways?
All the best,
David
--
David Megginson,
David Megginson writes:
Curtis L. Olson writes:
Our world (once I finishe with the other lighting schemes, and once
it's regenerated) will be as close to reality as our database
allows.
Have you patched TerraGear to eliminate runway edge lights for
unlighted runways?
Well, patched
Curtis L. Olson [EMAIL PROTECTED] wrote :
David Megginson writes:
Curtis L. Olson writes:
Our world (once I finishe with the other lighting schemes, and once
it's regenerated) will be as close to reality as our database
allows.
Have you patched TerraGear to eliminate runway
Frederic BOUVIER writes:
There are airports that have intermitent, remotely switchable with
onboard radio, lighting. When you arrive in the vicinity of such an
airport, you push (sorry, lack of english vocabulary here) say 7
times in 5 seconds on the radio button to switch it on. It
John Check writes:
On Friday 18 October 2002 8:35 am, Curtis L. Olson wrote:
John Check writes:
If you want to fly this yourself, you can grab:
http://www.flightgear.org/tmp/KSFO.btg.gz
Does anybody have a copy or a proper link? it seems to be 404.
My fault, didn't push
Curtis L. Olson writes:
Yes, we have CAL and CAL-II in the database, but no ARCAL.
ARCAL describes how the lights are activated, not their configuration;
presumably, Calvert I and Calvert II approach lighting systems could
be ARCAL, but since those are used (I think) mainly at military
I would also like to add the ability to turn runway/approach lighting
on/off from the instructor station (i.e. tower control). But that's
step n+1 assuming I'm working on step n right now.
Curt.
David Megginson writes:
Curtis L. Olson writes:
Yes, we have CAL and CAL-II in the database,
John Check writes:
Curt,
What do you think about tossing this in the base package?
Just wondering
That's fine, although it's not elevated and has large gaps where it
meets the surround terrain ...
CUrt.
John:
Are you going to go ahead with this? When it gets in the base package (you
On Friday 18 October 2002 7:13 pm, Jon Berndt wrote:
John Check writes:
Curt,
What do you think about tossing this in the base package?
Just wondering
That's fine, although it's not elevated and has large gaps where it
meets the surround terrain ...
The last time we had KSFO
John Check writes:
The last time we had KSFO with lights in there it had some problems
too. I think it's worth the tradeoff but if you think it's going
to break anything I can hold off.
I'd prefer to put in a complete rebuild from William Riley if he has
time to redo the base package.
No one commented on my last runway lights message so I figured I'd
send some more picts of the latest:
http://www.flightgear.org/tmp/rwy_lights3.jpg
http://www.flightgear.org/tmp/rwy_lights4.jpg
http://www.flightgear.org/tmp/rwy_lights5.jpg
http://www.flightgear.org/tmp/rwy_lights6.jpg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
*drools over keyboard*
Very nice. But can you see the pole and light assemblies at daytime? :-)
Thanks,
David
- --
If you give someone a program, you will frustrate them for a day. If you teach
them how to program, you will frustrate them for a
I've sent mail to Curt about this point already, but while I'm
waiting, I thought I'd throw out the question to the list. I've
patched FlightGear so that (a) runway edge lights are not visible from
improbable distances (like 50km or more), and (b) runway edge lights
are not visible at all while
I'm currently applying a range limit of 12,000m (about 6nm) to the
lights (the range is from the middle of each runway). Personally, I
suspect that that might be far too generous, but I don't want to make
the range too short for very long runways. What does everyone else
think?
All the
On Sun, 7 Jul 2002, David Megginson wrote:
patched FlightGear so that (a) runway edge lights are not visible from
improbable distances (like 50km or more), and (b) runway edge lights
are not visible at all while the sun is above the horizon, but haven't
committed these patches yet.
I think
73 matches
Mail list logo
