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 can
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 - but once you
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
camera
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
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
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
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 for
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
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 you'd
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
A
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
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 vector
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
--
Thanks for writing this up. I have a couple of comments, nitpicks really.
On Mon, Oct 15, 2012 at 9:43 AM, Renk Thorsten thorsten.i.r...@jyu.fi 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
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 number
On Tue, Oct 16, 2012 at 12:05 PM, Renk Thorsten thorsten.i.r...@jyu.fi 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
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
On Tue, Oct 16, 2012 at 2:54 PM, James Turner zakal...@mac.com 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
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 because that
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
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
or I can find out what the pitfalls are.
Basically this is about reducing the number of varyings, which is desirable for
at least two
21 matches
Mail list logo
