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
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
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
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.
-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
-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
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),
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 different argument.) I
> >wrote a quick script at one point to recursi
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 4-chann
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
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 quit
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 de
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 blocki
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 looki
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 per
-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, textu
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 los
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
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 backgroun
-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).
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
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
> 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 a
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. JPE
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 a
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.
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
> ar
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
> tack
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, es
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 al
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?
http://www.mail-archive.com/flightgear-devel@flight
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?
http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29
- Original Message -
From: "Erik Hofman" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions"
Sent: Friday, January 28, 2005 1:34 AM
Subject: Re: [Flightgear-devel] Runway lighting
> Roman Grigoriev wrote:
>
> > Hi guys!
> > I have t
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: [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. Hardraa
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
2f585eeea02e
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
- Original Message -
From: "Curtis L. Olson" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions"
Sent: Thursday, January 27, 2005 8:14 PM
Subject: Re: [Flightgear-devel] Runway lighting
> Oliver C. wrote:
>
> >What about setting only on
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
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 perfo
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
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 o
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 i
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
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
>> lig
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
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 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 defa
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 d
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
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 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
William L. Riley writes:
>
> 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 would
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
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.
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 t
> 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 p
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 databas
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
install
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.
> >
>
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
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 t
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?
Wel
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
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
> feat
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
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], http://w
-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 l
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 th
> 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 th
71 matches
Mail list logo
