The LoD is currently hardcoded to 20km, so if visibility 20km, it
kicks in
before the transparency effect.
I have a good fix that takes into account the current visibility as part
of
the Impostors work, but that won't be available until after the release.
In the meantime, I can
Stuart
On Sun, Dec 4, 2011 at 10:14 PM, Stuart Buchanan wrote:
I've already managed to use a second texture to mask where trees are
placed. The following screenshot shows a golf course where I've used
a mask so that the random trees are only placed in the rough.
Mathias
On Tuesday, December 27, 2011 00:27:41 Stuart Buchanan wrote:
Vivian - are you anticipating the materials-dds.xml file replacing
materials.xml at some point? Any plans for further DDS texture work?
Hmm, regarding dds.
I have to say, that not all OpenGL drivers support texture
Curt:
I would be happy to help, though I don't know of many non-CORINE sceneries
(Helgoland and some photoreal sceneries). I can make a list of the sceneries
I've created and hopefully other scenery developers will come forward?
Oliver:
All the sceneries I've been creating are GPL, with the
On Thu, 2011-12-29 at 14:37 +0100, Erik Hofman wrote:
On Thu, 2011-12-29 at 14:16 +0100, Mathias Fröhlich wrote:
Could we do dds files without compression but with precomputed mipmaps?
So at next, can you try out which combination of compression/provided
mipmaps/forced simgear
Hi Curt!
Curtis Olson curtol...@gmail.com wrote:
Hi Joe, actually the FlightGear scenery is round -- technically oblate
ellipsoid based on a wgs-84 coordinate model. If you stitched enough
tiles together you will see the earth curvature start to form.
I must have missed the implementation
Hi Joe, actually the FlightGear scenery is round -- technically oblate
ellipsoid based on a wgs-84 coordinate model. If you stitched enough tiles
together you will see the earth curvature start to form.
The FlightGear world model lets you fly accurate great circle routes, and
enables all the
On Thu, 29 Dec 2011 10:37:44 +0200 (EET)
thorsten.i.r...@jyu.fi wrote:
http://www.phy.duke.edu/~trenk/pics/local-weather-next05.jpg
Impressive!
Technically, tile generation is tied to actual visibility. The max.
visibility the system generates at high altitude is 140 km or a
Le 29/12/2011 14:16, Mathias Fröhlich a écrit :
Hi Erik,
On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote:
Setting compression to 'none' does speed up texture switching
considerably. Unfortunately there's little difference in switching from
internal to external view for the first
At view distances 100 km it becomes more and more apparent that the
flightgear scenery is flat and not a sphere, doesn't it?
I think a realistic horizon is impossible as long as scenery/world is
a disc.
What's more important from high altitude is what happens beyond view
distance where no
On Thu, Dec 29, 2011 at 8:44 AM,wrote:
I must have missed the implementation of this capability totally. I
assumed a comparatively small cut-out of the ellipsoid was projected on
a plane/disc.
But, hey, thats great news to me! Thanks for clarification!
Each tile is a square shape, and when
Vivian,
There is no intention to migrate as a whole to .dds: it is offered as an
appearance and performance upgrade for those who wish to use it. It is up to
aircraft developers to decide which format they will use. Indeed - they
could provide models with either format so that the user could
On Thu, 2011-12-29 at 17:36 +, Vivian Meazza wrote:
Mathias
I have checked in a change to flightgear to make the use of the compressed
internal formats a starttime configuration option.
I am still interrested if we have that hangs also with texture compression
disabled and without
Stefan
On Thursday 29 December 2011 10:21:11 Vivian Meazza wrote:
That said - why use drivers that cannot handle .dds compression formats?
I
assume closed source drivers are OK?
They simply are not. I currently cannot use FlightGear due to simply
unusable
performance with free
Am 29.12.2011 06:43, schrieb J. Holden:
At the same time I do not support the inclusion of some sceneries
I've created in the main FlightGear repository, as users with
lower-end machines may wish to use the vmap0 scenery over the more
detailed ones - plus there is now a marked difference in
On Thursday 29 December 2011 10:21:11 Vivian Meazza wrote:
That said - why use drivers that cannot handle .dds compression formats? I
assume closed source drivers are OK?
They simply are not. I currently cannot use FlightGear due to simply unusable
performance with free drivers but still,
On Thu, 2011-12-29 at 14:16 +0100, Mathias Fröhlich wrote:
Could we do dds files without compression but with precomputed mipmaps?
So at next, can you try out which combination of compression/provided
mipmaps/forced simgear compression still work fine?
Good Idea, I will try that.
Erik
We should agree on a common place to publish actual surface wind (for
one or many given locations?) in the property tree. /environment/config
is definitely not the best place to use but due to historical reasons,
many objects rely on these properties (windsock, chimneys/smoke, many
more).
Mathias
There is no intention to migrate as a whole to .dds: it is offered as an
appearance and performance upgrade for those who wish to use it. It is
up to
aircraft developers to decide which format they will use. Indeed - they
could provide models with either format so that the user
On Thu, 2011-12-29 at 12:40 +0100, Mathias Fröhlich wrote:
I have checked in a change to flightgear to make the use of the compressed
internal formats a starttime configuration option.
I am still interrested if we have that hangs also with texture compression
disabled and without providing
Hi Erik,
On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote:
Setting compression to 'none' does speed up texture switching
considerably. Unfortunately there's little difference in switching from
internal to external view for the first time.
Thanks.
I do also see an initial frame drop
Vivian,
On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote:
I don't fully understand the point - we're not using .dds, and fancy shaders
as the default option - what else isn't working with open source drivers?
Well, the default f16 does not work anymore for example.
I have also
Well, the scenery structure is dissimilar to the normal structure of patching
git.
A scenery like Washington, DC does not have the same frame rate hit as Juneau
or Innsbruck does.
And as stated there are now sceneries incompatible with older versions of
FlightGear.
The problem is, some new
2011/12/29 Mathias Fröhlich mathias.froehl...@gmx.net:
And this is what I try to do now:
Object against using these patented compression algorithms.
I do not care for the on disk format of any image file we have. But the
problem
is that some kind of precompression that can be stored in
Flightgear-commitlogs wrote:
The branch, master has been updated
- Log -
commit c8d6a0afe0d9f2d35f2da9ce9a23b8974803b731
Author: Gijs de Rooy
Date: Thu Dec 29 17:02:33 2011 +0100
Taxiing tutorial: C172P does not move
Erik,
On Thu, 2011-12-29 at 17:36 +, Vivian Meazza wrote:
Mathias
I have checked in a change to flightgear to make the use of the
compressed
internal formats a starttime configuration option.
I am still interrested if we have that hangs also with texture
compression
Ok.. Then I;m in.. I'd like the idea to maintain openRadar in Java to at
least build a skill set.. and get to know the code and mainly comment
it..andhopefu;;y find some cool future team..
My hidden motivation is to android and devices for purpose eg a TCAS
Android, or a PFD .. live atc chat on
On Fri, 2011-12-30 at 02:50 +, Pedro Morgan wrote:
Ok.. Then I;m in.. I'd like the idea to maintain openRadar in Java
to at least build a skill set.. and get to know the code and mainly
comment it..andhopefu;;y find some cool future team..
I'm a JEE developer, not a Swing developer, so
28 matches
Mail list logo