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.
Most of the discussion is drifting a bit over my head now, but I'm pretty sure
that's not what I am talking about.
I am talking about a situation
Hi,
On Sunday, July 22, 2012 01:17:43 Tim Moore wrote:
That is a big problem, but we also have CPU bottlenecks upstream too.
I agree.
The scenegraph structure is not well suited. But therefore at the first cut I
hope to simply get less tiles and models present by a better lod structure.
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
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
On Thu, Jul 19, 2012 at 6:09 PM, James Turner zakal...@mac.com wrote:
On 19 Jul 2012, at 14:32, Tim Moore wrote:
Do we really not run the terrain fragment shader when the terrain is seen
through the cockpit floor (my system seems to slow down even though no
terrain is seen in the event and
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 test
for the far scene. I believe that the stencil test has been extremely
fast for years.
Oooh, yes - I was
Hi Tim James,
De: James Turner
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
test for the far scene. I believe that the stencil test has been
extremely
On Fri, Jul 20, 2012 at 10:23 AM, Frederic Bouvier fredfgf...@free.fr wrote:
Hi Tim James,
De: James Turner
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
this could be unified with the classical renderer. What do you
think about
that ?
I would probably give more of the range to the far camera e.g.,
[0.1..1.0]. This would probably work best with a floating point depth
buffer, but if you do that, you might be able to go back to using
only
On Thu, 19 Jul 2012 19:43:41 +, Renk wrote in message
e495a106ff5f31448739e79d34138c19196d3...@mbs1.ad.jyu.fi:
In my shading schemes, in-cockpit is much faster because no fogging
is computed at all.
..this means we don't model cockpit or cabin pressurization loss?
Or, that fogging is
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 test
for the far scene. I believe that the
This is an optimization to avoid running really expensive shaders on
geometry that will be hidden from view. The GPU has an early Z
capability and won't run a fragment shader if it knows the result will
be discarded.
But that can't be all that is going on. In this case I'd expect that if I
On Thu, Jul 19, 2012 at 1:16 PM, Renk Thorsten thorsten.i.r...@jyu.fi wrote:
This is an optimization to avoid running really expensive shaders on
geometry that will be hidden from view. The GPU has an early Z
capability and won't run a fragment shader if it knows the result will
be discarded.
On 19 Jul 2012, at 14:32, Tim Moore wrote:
Do we really not run the terrain fragment shader when the terrain is seen
through the cockpit floor (my system seems to slow down even though no
terrain is seen in the event and the framerate responds to my shader quality
settings)?
That would
Which is very unfortunate, since in the common case it would allow a
huge amount of tile/terrain pixels to be dumped. Could we use a buffer
copying to trick to initialise a stencil plane on the far camera based
on the near-camera Z-buffer?
I've no idea what the penalty of a z-buffer
May I ask yet another dumb question?
In the first rendering pass of default terrain rendering, we use default.vert
and terrain-nocolor.frag as shaders. I have so far mindlessly copied the first
pass since I had no real clue as to what it is for. Its purpose seems to be to
establish that
On Wed, Jul 18, 2012 at 8:27 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote:
May I ask yet another dumb question?
Yes, although this isn't a dumb question.
In the first rendering pass of default terrain rendering, we use default.vert
and terrain-nocolor.frag as shaders. I have so far
The main reason to render textures at this stage is that textures with
transparency do change the fragments that are rendered. Calculating
the fog color seems wrong, but I don't have the sources in front of me
and gitorious is acting up.
So since we're not using transparent textures for
So, was there a reason we texture and fog during the first pass and
should I see any unexpected side effects, or can I simply use the
trivial shaders and get my 12% framerate?
The main reason to render textures at this stage is that textures
with transparency do change the fragments that
21 matches
Mail list logo
