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
11 matches
Mail list logo
