De: Tim Moore timoor...@gmail.com
On Fri, Jul 20, 2012 at 9:59 AM, James Turner zakal...@mac.com
wrote:
On 20 Jul 2012, at 07:22, Tim Moore wrote:
We could use the stencil buffer without copying anything: render
the near scene first, setting stencil bits, then enable the stencil
Hi,
On Thursday, July 19, 2012 17:09:09 James Turner wrote:
I have some plans in that direction post 2.8, especially to flatten the LOD
quadtrees and transforms of the tiles. Each tile will get some top-level
LOD groups for all objects (shared and static). I'm hoping in combination
with the
Hi,
On Thursday, July 19, 2012 15:32:01 Tim Moore wrote:
The depth-pass-only pass is a well known optimization, but the fact it
is not helping implies that our bottleneck is not in fragment
processing. I've suspected for years that it lies on the CPU, and have
been trying to optimize our
Hi,
On Monday, July 16, 2012 07:20:32 Chris Forbes wrote:
If DDS is not politically acceptable, there should be an alternative
way of providing premipped textures.
Mipmap generation is a *significant* portion of the load time,
particularly on the nicer aircraft with large textures.
Even
Hi,
On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote:
I can see a number of options to resolve this (and I'm sure there are more):
The 4. Method that I can imagine is to precompute the mipmaps in the loader.
IIRC tests with some of the guys suffering from this problem, providing
Hi,
On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote:
I can see a number of options to resolve this (and I'm sure there are more):
Oh, I forgot in the previous mail:
There is a 5. Solution:
Provide premipmapped uncompressed dds files and compress them with something
like gzip. Osg can
Mathias Fröhlich a écrit :
...
But that means we could at the point where the warning happens compute
the mipmap levels on the cpu in the loader thread. osg::gluScaleImage
could be used to do this I think (or something similar not requireing
a context). This one is an imported version
Hi,
On Saturday, July 21, 2012 11:56:39 Harald Johnsen wrote:
gluScaleImage does the usual job of blurring the texture to compute the
mipmaps. The advantage of pre computed mipmaps (inside .dds or not) is
that we can use better algorithms
(http://en.wikipedia.org/wiki/Bicubic_interpolation
Am 21.07.2012 um 11:56 schrieb Harald Johnsen hjohn...@evc.net:
Mathias Fröhlich a écrit :
...
But that means we could at the point where the warning happens compute the
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be
used to do this I think (or
Am 20.07.2012 11:10, schrieb Anders Gidenstam:
Given that there is some risk that the behaviour of carefully tuned flight
models change I'd suggest we only update 2.9.0 and do not update 2.8.0 as
it is late in its release cycle.
Valid point. Can someone with more insight into the patch
Hi all!
Let me quickly introduce myself, I'm a dutch software engineering
student who has been lurking on this list for an embarrassingly long
time (think pre FG 1.0...). Anyway, I'd like to get actively involved
in FlightGear core development.
It's obviously a long time wish to get rid of the
On Sat, Jul 21, 2012 at 10:42 AM, Mathias Fröhlich
mathias.froehl...@gmx.net wrote:
Hi,
On Thursday, July 19, 2012 15:32:01 Tim Moore wrote:
The depth-pass-only pass is a well known optimization, but the fact it
is not helping implies that our bottleneck is not in fragment
processing. I've
12 matches
Mail list logo
