(I want to correct my own post here, because, as this thread has shown, things I
say in the distant past stick around in search engines forever...)
On 9/15/2011 2:33 PM, Paul Martz wrote:
The OpenGL FFP projection matrix transforms from eye coordinates into clip
coordinates. Those two coordinat
> On 09/15/2011 04:33 PM, Paul Martz wrote:
>> You're free to put whatever transform you want in either matrix as long
>> as
>> transform by the two produces clip coords, but for correct FFP lighting
>> computations, your modelview matrix *must* produce eye coordinates.
>> OpenGL FFP
>> lighting is
On 09/15/2011 04:33 PM, Paul Martz wrote:
You're free to put whatever transform you want in either matrix as long as
transform by the two produces clip coords, but for correct FFP lighting
computations, your modelview matrix *must* produce eye coordinates. OpenGL FFP
lighting is computed in eye s
Coming into this thread rather late, and didn't read all the posts, but it's
clear that there's a fundamental misunderstanding of the FFP transform here...
On 9/15/2011 1:25 PM, Jason Daly wrote:
On 09/15/2011 03:01 PM, Mik Wells wrote:
This isn't quite true as the projection matrix (which de
On 09/15/2011 03:59 PM, Mik Wells wrote:
Hi,
It isn't the window system (e.g. Microsoft Windows) which uses the Y coordinate
as the vertical axis of the screen. It's OpenGL. (On my windowing system Y is
down).
That is accounted for in the viewport transform, not inside OpenGL itself.
Worry
Hi,
It isn't the window system (e.g. Microsoft Windows) which uses the Y coordinate
as the vertical axis of the screen. It's OpenGL. (On my windowing system Y is
down).
> Worrying about what OpenGL implicitly calls "up" is not useful
It may not be useful at the app level, but it's essentail if
On 09/15/2011 03:01 PM, Mik Wells wrote:
This isn't quite true as the projection matrix (which determines X-right,
Y-up, Z-out) is non-invertible and so can't be treated as just another transfom
in the stack.
I don't see what that has to do with my statement. My point is that
adding anoth
Hi,
> There's no reason to pay any attention to the "default" orientation, since
> you can change that with a simple transform concatenated into the dozens of
> transforms you're already doing anyway
This isn't quite true as the projection matrix (which determines X-right,
Y-up, Z-out) is non-
On 09/15/2011 01:23 PM, Mik Wells wrote:
Hi,
As far as I know it's not explicitly specified but is implicit in the projection
transforms. Assuming the ModelView matrix is the identity, the matrices generated by the
traditional Ortho/Frustum functions would result in a vertex's Y value determing
Hi,
As far as I know it's not explicitly specified but is implicit in the
projection transforms. Assuming the ModelView matrix is the identity, the
matrices generated by the traditional Ortho/Frustum functions would result in a
vertex's Y value determing its height on the screen. That scenario i
On 09/15/2011 11:03 AM, Mik Wells wrote:
However the Y-up OpenGL default is still relevant.
What page of the OpenGL spec specifies that the default coordinate
system is Y-Up?
--"J"
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http
Paul Martz wrote:
>
> How many first-person rendering systems use the ModelView matrix unmodified?
>
The fact that the ModelView matrix is often modified isn't the correct way to
look at the problem - we need to consider how the system behaves when it is the
identity.
Paul Martz wrote:
>
>
Paul Martz wrote:
All too often, this notion of a "default coordinate system" seems to
restrict our thinking and make us believe that there are limitations on
how we can orient the world. I just want to point out that the idea of a
default coordinate system is really a myth.
There are stil
I think that makes a lot of sense, Paul. After learning about this yesterday,
it took me about a half hour to think it all through, and realize that it's all
pretty much equivalent and boils down to arbitrary choices about how you want
to orient your scene.
Frank
--
Read this t
Frank Sullivan wrote:
> i.e., the identity matrix still has me looking down the -z axis, just
like OpenGL, even though in the osg World, I'm looking downwards.
I don't know whether this will clarify or muddy the concept, but I'll
throw it out anyway.
I've been on somewhat of a crusade to rid
Thanks Thomas,
Yeah, I think you are right. I don't have it all worked out in my head how the
coordinate system switch from osg and OpenGL occur. But I notice, now, that
when I try to get getLookAt() on an identity matrix, I get:
eye: 0, 0, 0
center: 0, 0, -1
up: 0, 1, 0
Instead of what I expe
16 matches
Mail list logo