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.
Theref
>>> 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 sit
On Sat, Jul 21, 2012 at 10:42 AM, Mathias Fröhlich
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 suspected for ye
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 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 t
> De: "Tim Moore"
>
> On Fri, Jul 20, 2012 at 9:59 AM, James Turner
> 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
On Fri, Jul 20, 2012 at 9:59 AM, James Turner 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 stencil tes
On Thu, 19 Jul 2012 19:43:41 +, Renk wrote in message
:
> 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 triggered by the pressure loss like in RL?
--
..med ve
> > 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 u
On Fri, Jul 20, 2012 at 10:23 AM, Frederic Bouvier 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
>>
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
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 for
On Thu, Jul 19, 2012 at 6:09 PM, James Turner 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 the
> 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-buff
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)?
>
> T
On Thu, Jul 19, 2012 at 1:16 PM, Renk Thorsten 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.
>
> But that
> 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
> > 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 fragme
> 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 te
On Wed, Jul 18, 2012 at 8:27 AM, Renk Thorsten 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 mindlessly copied the
>
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 farawa
21 matches
Mail list logo
