GLSL ES shader based camera question

DividedByZero · 2016-01-31T06:02:35

Hi Guys, I am in the process of trying to make a GLSL ES based camera system but have run in to a little snag (coming from a basic HLSL background). This is what I have so far. It is incomplete as I haven't accounted for View and Projection yet (that will come when I get past this hiccup). The problem that I am having is that the return type of gl_Position (as required in GameMaker) is a type of vec4 but the matrices I am using are of mat4 type. Thus, resulting in a compilation error. attribute vec3 in_Position; // Vertex position in its own local space uniform float xx; uniform float yy; uniform float zz; void main() { mat4 identity; mat4 world; mat4 view; mat4 projection; identity = mat4( 1.0, 0.0, 0.0, 0.0, // first column (not row!) 0.0, 1.0, 0.0, 0.0, // second column 0.0, 0.0, 1.0, 0.0, // third column 0.0, 0.0, 0.0, 1.0 // third column ); // Translation matrix (world matrix) world = mat4( 1.0, 0.0, 0.0, in_Position.x + xx, 0.0, 1.0, 0.0, in_Position.y + yy, 0.0, 0.0, 1.0, in_Position.z + zz, 0.0, 0.0, 0.0, 1.0 ); gl_Position = identity * world; // This results in an error of vec4 not being compatible with mat4 (which is fair enough) //gl_Position = vec4(identity * world); // This results in a hang eventually resulting in a generic error - with no other explanation } Could you please advise if I am on the right track? And any help is always greatly appreciated. Thanks in advance

Graphics and GPU Programming Programming

Started by DividedByZero January 29, 2016 07:19 AM

10 comments, last by DividedByZero 8 years, 2 months ago

swiftcoder

18,997

January 30, 2016 04:31 PM

I expect what is going on is that the shader has decided to compile the entire expression (identity * world * view * projection), and all of the calculations that go into it, into a single constant matrix.

This is a pretty normal compiler optimisation, since all of your inputs are constant at that point. And then the rest of the shader boils down to a single matrix<->vector multiply, and storing a couple of values.

I wouldn't rely on every shader compiler to get this right, and if you make any of those input non-constant (say, to move the camera around), then you will see a massive performance hit.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

DividedByZero

1,261

Author

January 31, 2016 06:02 AM

I expect what is going on is that the shader has decided to compile the entire expression (identity * world * view * projection), and all of the calculations that go into it, into a single constant matrix.

This is a pretty normal compiler optimisation, since all of your inputs are constant at that point. And then the rest of the shader boils down to a single matrix<->vector multiply, and storing a couple of values.

I wouldn't rely on every shader compiler to get this right, and if you make any of those input non-constant (say, to move the camera around), then you will see a massive performance hit.

It is interesting, because I am now moving the object (120K poly) and camera around via their own uniforms and the performance is still the same.

Having said that, the camera system isn't complete yet (fixed look at, no rotations etc..). So, maybe the performance will dive when it becomes more functional.

GLSL ES shader based camera question

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

GLSL ES shader based camera question

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines