Happy new year!
Vivian,
On Friday, December 30, 2011 10:48:40 Vivian Meazza wrote:
The hangs are caused by mipmap generation on the fly by OSG?
The hangs are caused by mipmap generation by the driver which happens on forst
use of a texture.
The old texture files are static and I would
Am Freitag, den 30.12.2011, 00:09 +0100 schrieb Csaba Halász:
I wonder if there is an open standard counterpart that can do the same
as the dds compression? Or is the whole idea patented? (Eww, too broad
software patents are the work of the devil).
As far as i know, FXT1 a texture
On Fri, 2011-12-30 at 00:07 +, Vivian Meazza wrote:
The F16 is just excellent here. I get a slight pause on first switching
from an internal to external view, but I expect that is the texture loading
for the first time. Thereafter it is as near instantaneous as you could
wish. Likewise
-Original Message-
From: Mathias Fröhlich [mailto:mathias.froehl...@gmx.net]
Sent: 29 December 2011 20:04
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Improving random trees buildings
Vivian,
On Thursday, December 29, 2011 17:36:24 Vivian Meazza
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
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
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
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
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
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
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
Hi,
On Tuesday, December 27, 2011 10:49:07 Erik Hofman wrote:
Actually for the F-16 I did not switch because of compression but
because livery switching is almost instant while the previous textures
is took about 10 seconds to switch from internal view to external for
the first time.
That's
On Tue, 2011-12-27 at 09:53 +0100, Mathias Fröhlich wrote:
Sorry to step in this so late - probably way too late - but is there a reason
that the on disk format must be compressed?
The previous strategy to have on disk an format that everybody can read and
to
make the driver compress them
Hi,
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 compression,
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.
Am Montag, den 05.12.2011, 11:02 + schrieb Martin Spott:
kreuzritter2000 wrote:
When we're talking about MSFS and terrain i also want to mention, that
their regular grid allowed them to use textures that allowed a seamless
crossover on their borders. So with the right textures
Am Montag, den 05.12.2011, 16:16 + schrieb lists:
On Sun, 4 Dec 2011 22:14:18 +, Stuart Buchanan wrote:
Rather than using the same texture, we can simply have a separate
texture for object type and rotation.
It's simple enough to place objects along a linear feature (like a
Am Sonntag, den 04.12.2011, 22:14 + schrieb Stuart Buchanan:
On Sun, Dec 4, 2011 at 1:08 PM, kreuzritter2000wrote:
We could do the same, but i don't know, if this works with an irregular
grid, flighgear uses.
This is a very interesting idea indeed. I hadn't realized that is how they
On Mon, 2011-12-05 at 10:55 +0100, kreuzritter2000 wrote:
I wonder how X-Plane solved that, they're using an irregular grid too,
but the texture borders look rather seamless which makes the visual
quality very realistic.
kreuzritter2000 wrote:
When we're talking about MSFS and terrain i also want to mention, that
their regular grid allowed them to use textures that allowed a seamless
crossover on their borders. So with the right textures choosen, the
textures matched on the borders.
Ah, well, but, as I
On Sun, 4 Dec 2011 22:14:18 +, Stuart Buchanan wrote:
Rather than using the same texture, we can simply have a separate
texture for object type and rotation.
It's simple enough to place objects along a linear feature (like a
road):
I think X-Plane is using texture splatting.
Please read this blog post from Ben Supnik (X-Plane scenery developer) that
I read a few years ago:
http://www.x-plane.com/blog/2008/12/dealing-with-repetition/
It deals not exactly with the smooth transition problem, but this technique
could be applied
Am Mittwoch, den 30.11.2011, 14:07 + schrieb Stuart Buchanan:
Hi All,
Having seen some recent screenshots from X-Plane 10, I've been
thinking about ways to improve our random scenery, in particular
buildings.
At present, we have random building scattered over the scenery, based
on
On 30 Nov 2011, at 14:07, Stuart Buchanan wrote:
I'm interested in peoples opinions on this, and in particular what
their view is of the current forest and urban shader performance. It
may be that my system is unique in that one is cheap and the other
expensive, and this is all pointless!
2011/11/30 Stuart Buchanan stuar...@gmail.com:
At the same time, I'm anticipating aligning the buildings with the
texture, and probably using a second texture as a mask to indicate
where buildings may, or may not, be placed.
Can you use low-bit gray (or index) mask, to indicate not only
On Thu, Dec 1, 2011 at 8:07 AM, James Turner wrote:
- I don't think you need to worry about a cuboid per floor - only define
some (irregular) trapezoids for the floor plans, and simply extrude them to a
height - with suitable random generation of the heights.
I was thinking I'd need a
Hi All,
Having seen some recent screenshots from X-Plane 10, I've been
thinking about ways to improve our random scenery, in particular
buildings.
At present, we have random building scattered over the scenery, based
on .ac models, plus the Urban shader.
The former are limited in that
Stuart
Hi All,
Having seen some recent screenshots from X-Plane 10, I've been
thinking about ways to improve our random scenery, in particular
buildings.
At present, we have random building scattered over the scenery, based
on .ac models, plus the Urban shader.
The former are
35 matches
Mail list logo
