Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


smitty1276

Member Since 17 Jan 2001
Offline Last Active Jul 06 2011 05:37 PM

Topics I've Started

Frustum setup with physical screen coordinates + eye

06 July 2011 - 03:33 PM


(reposted/moved from OpenGL forum... more appropriate here, I think)

Hi everyone, I'm trying to ultimately do something similar to the Johnny Lee headtracking demo, where I want to use the center of the actual screen as the world origin, and I want my "camera" eyepoint to correspond to the user eye position in the real world (in the physical display's coordinate system). Initially, I am just trying to set up a more "traditional" on-axis frustum using eye position and screen dimentions... I am using OGL so this is a right-handed coordinate system looking down neg Z axis...

I setup my projection matrix with a frustum like below

left = -SCREEN_WIDTH_IN_MM / 2.f;
right = SCREEN_WIDTH_IN_MM / 2.f;
bottom = -SCREEN_HEIGHT_IN_MM / 2.f;
top = SCREEN_HEIGHT_IN_MM / 2.f;
near = eyePos.Z - 0.01;
far = eyePos.Z + 1000.f

My view matrix is just translating by -eyePos.

My understanding was that this would provide a view frustum such that anything that sits at z=0.0 (basically, a hair behind the near clip plane) would be displayed in the same position as if I had an ortho view. However, if I move my eyePos backward away from the screen, the geometry is appearing smaller as though it is moving back from the screen. Where is my thinking wrong on this? As the eye moves away from the screen, shouldn't the narrowing frustum exactly offset the greater distance, so that the geometry takes the same space on the screen?

Frustum setup with physical screen coordinates + eye

06 July 2011 - 02:45 PM

Hi everyone, I'm trying to ultimately do something similar to the Johnny Lee headtracking demo, where I want to use the center of the actual screen as the world origin, and I want my "camera" eyepoint to correspond to the user eye position in the real world (in the physical display's coordinate system). Initially, I am just trying to set up a more "traditional" on-axis frustum using eye position and screen dimentions...

I setup my projection matrix with a frustum like below



left = -SCREEN_WIDTH_IN_MM / 2.f;
right = SCREEN_WIDTH_IN_MM / 2.f;
bottom = -SCREEN_HEIGHT_IN_MM / 2.f;
top = SCREEN_HEIGHT_IN_MM / 2.f;
near = eyePos.Z - 0.01;
far = eyePos.Z + 1000.f

My view matrix is just translating by -eyePos.


My understanding was that this would provide a view frustum such that anything that sits at z=0.0 (basically, a hair behind the near clip plane) would be displayed in the same position as if I had an ortho view. However, if I move my eyePos backward away from the screen, the geometry is appearing smaller as though it is moving back from the screen. Where is my thinking wrong on this? As the eye moves away from the screen, shouldn't the narrowing frustum exactly offset the greater distance, so that the geometry takes the same space on the screen?


EDIT: How do I delete posts on the "new" GDnet?

GL ES 2.0: Sharing programs b/t contexts?

23 February 2011 - 06:13 PM

I have a native window context and some pixmap contexts that are "shared" with it. Is it possible to share shaders between contexts or is that sort of thing only limited to textures, buffers, etc.?

GLSL num of uniform variables used in vertex shader

27 January 2011 - 04:16 PM

Setting aside the quality of the code, etc., can anyone explain to me how this vertex shader code would fail to link with the this error? "Error: uniform variables in vertex shader do not fit in 251 vectors."

The excerpt below contains all of the declarations at the top of the source... I'm only counting 120-130 vectors in the worst possible case (depending on how the implementation stores them I guess). What am I missing?

// lights
const int maxLights = 8;


// attributes
attribute vec4 inPosition;
attribute vec4 inDiffuse;
attribute vec2 inTextureCoordinate;
attribute vec3 inNormal;


// uniforms
uniform mat4 ModelViewProjectionMatrix;
uniform mat4 NormalMatrix;
uniform mat4 TextureMatrix;


// the light uniform
uniform float lighting_enable;


struct LightSourceParams {
float light_enable;
vec4 light_ambient;
vec4 light_diffuse;
vec4 light_specular;
vec4 light_position;
vec4 light_spotDirection;
float light_spotExponent;
float light_spotCutoff;
float light_spotCosCutoff; // user must define
float light_constantAttenuation;
float light_linearAttenuation;
float light_quardraticAttenuation;
vec4 light_halfVector; // user must define ... halfVector=Eye-Light [not presicion]
};
uniform LightSourceParams LightSource[maxLights];



// material-uniforms
uniform vec4 material_emmision;
uniform vec4 material_ambient;
uniform vec4 material_diffuse;
uniform vec4 material_specular;
uniform float material_shininess;

// varyings
varying vec4 v_texcoord0;
varying vec4 v_outcolor;



Weird C++ casting problem

24 October 2010 - 02:34 PM

Can anyone shed any light on this? Here is an approximation of what I have:


class A {};
class B : public A {};
class Meh {};

class C : public B, Meh {};

Foo::Foo(A* a)
{
m_pAObject = a;
m_pCObject = reinterpret_cast<C*>(a);
}

void C::SomeMethod()
{
this->DoStuff(); // <-- "this" and m_pCObject above don't match
}





C::C is only invoked once, but when I examine these guys in debugger the pointer assigned to m_pCObject and the this pointer when tracing in C are two different things--specifically, m_pCObject is 64 greater than the this pointer inside of C methods. The objects methods are only invoked as an instance of C from other places, so it hasn't been an issue. I added some methods to C so that Foo could notify it of some state change, and it is behaving as though it is pointing to a different, uninitialized instance.

Is there some behavior around the casting here that I'm not aware of? (I'm not able to use dynamic_cast, but I know that the A object will always be a C object.)

PARTNERS