> I'm talking about the ep ... which is done for each vertex, everytime
... and the relevance of that observation to the ongoing discussion is...?
It's needed among other things to construct a sun/horizon coordinate system for
the lighting computations, so the ep has to be computed regardle
On Thursday, October 18, 2012 09:31:27 Renk Thorsten wrote:
> > And the matrix transform is for free...?
> > Oh, I forgot, a "useless" matrix transform is ok to be run on milions of
> > vertices, but one that actualy has a use, and runs on tens or maybe
> > hundreds at most, is killing performance
> And the matrix transform is for free...?
> Oh, I forgot, a "useless" matrix transform is ok to be run on milions of
> vertices, but one that actualy has a use, and runs on tens or maybe
> hundreds at most, is killing performance
A uniform float doesn't have a matrix transform. I thought y
On Thursday, October 18, 2012 08:58:43 Renk Thorsten wrote:
>
> In any case, since the 'additional computations' are subtracting one number
> from another number, I can just about live with the performance degradation
> caused by the operation, given that it provides backwards compatibility to
> e
> Maybe it would be better next time to ping some more people and notify
> them
> about problems in the scenery toolchain.
> Emilian did it
> (http://code.google.com/p/flightgear-bugs/issues/detail?id=888)
> and we fixed the bug, which means that your additional calculations are
> unnecessary now
Hi Thorsten,
Renk Thorsten wrote:
> FYI, I fixed the snowline problem for custom terrain half a year ago by
> passing camera altitude as uniform and computing absolute vertex altitude
> from camera altitude and the vertical difference. :-) The current point
> seemed to be that Mathias says we _sho
> Hint... I already knew that
In which case I'm puzzled by your remark that I wouldn't be interested in
supporting custom scenery anyway when you know that I've cooked up a scheme
which does just that. But maybe I'm simply too tired.
* Thorsten
--
On Thursday, October 18, 2012 07:58:14 Renk Thorsten wrote:
> > Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude.
> > There are some issues with that one, but only in custom terrain generated
> > after 2009, which you're not interested in supporting anyway.
>
> FYI, I fixed the
> Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude.
> There are some issues with that one, but only in custom terrain generated
> after 2009, which you're not interested in supporting anyway.
FYI, I fixed the snowline problem for custom terrain half a year ago by passing
camer
On Thursday, October 18, 2012 06:43:32 Renk Thorsten wrote:
> >> Speaking of which - it'd be nice to have local north as well defined
> >> direction as well - that would allow for things like the snowline
> >> being higher on south slopes ...
> >
> > In the Northern hemisphere ;-)
>
> Quite so -
>> Speaking of which - it'd be nice to have local north as well defined
>> direction as well - that would allow for things like the snowline
>> being higher on south slopes ...
>
> In the Northern hemisphere ;-)
Quite so - but once you have a north-pointing vector, the rest is trivial
because you
> Speaking of which - it'd be nice to have local north as well defined
> direction as well - that would allow for things like the snowline
> being higher on south slopes ...
In the Northern hemisphere ;-)
Regards,
-Fred
> Even the oldest hardware that
> supports OpenGL programmable shaders implements vector operations, and
> a vector multiply-add has, as far as I know, the same cost as a scalar
> operation. On the other hand, the shader compiler might be able to
> combine multiple scalar interpolations into vecto
Hi,
On Tuesday, October 16, 2012 15:17:04 Tim Moore wrote:
> I don't have access to a local copy of the tree at the mo', but I
> remember that this was introduced by Mathias when he added BVH.
Yes. That is to align the bounding volumes boxes as well as the drawables
bounding boxes to the earths
> De: "James Turner"
>
> On 16 Oct 2012, at 13:38, Tim Moore wrote:
>
> > The tile data on disk is actually stored in a
> > coordinate system that is aligned with the earth-centric system, so
> > Z
> > points to the north pole. We rotate the coordinates back to a local
> > coordinate system becau
On Tue, Oct 16, 2012 at 2:54 PM, James Turner wrote:
>
> On 16 Oct 2012, at 13:38, Tim Moore wrote:
>
>> The tile data on disk is actually stored in a
>> coordinate system that is aligned with the earth-centric system, so Z
>> points to the north pole. We rotate the coordinates back to a local
>>
On 16 Oct 2012, at 13:38, Tim Moore wrote:
> The tile data on disk is actually stored in a
> coordinate system that is aligned with the earth-centric system, so Z
> points to the north pole. We rotate the coordinates back to a local
> coordinate system because that provides a much more useful bou
On Tue, Oct 16, 2012 at 12:05 PM, Renk Thorsten wrote:
>> One can assume that
>> a vec4 varying is no more expensive than a vec3.
> (...)
>> I'm not sure it's useful to think of each component of a varying
>> vector as a "varying" i.e., three vec3 varying values use up three
>> varying "slots," an
> One can assume that
> a vec4 varying is no more expensive than a vec3.
(...)
> I'm not sure it's useful to think of each component of a varying
> vector as a "varying" i.e., three vec3 varying values use up three
> varying "slots," and so do 3 float varying values
I dunno...
Just counting the
Thanks for writing this up. I have a couple of comments, nitpicks really.
On Mon, Oct 15, 2012 at 9:43 AM, Renk Thorsten wrote:
>
> I thought it might be a good idea to write up a few things I've tried
> recently and not seen in widespread use - so that either others know about
> them as well o
20 matches
Mail list logo
