Orthographic

[Kjell]

Should have been build-in ( or rather a Camera component ), and could have been a piece-of-cake if doubles were supported ...

In any case, essential for 2D & Isometric games ( and stuff like Paper Mario / Crush / Fez ). Needs to be called from the base-level of the ModelView Matrix, so make sure to pop out of the stack when calling from a Model. Uses the standard Camera properties except from Ratio, and has a added Zoom argument ( instead of FOV ).

Code: Select all

void ortho(float Ratio, float Zoom)
{
  float N, F;

  N = App.ClipNear;
  F = App.ClipFar;

  glMatrixMode(0x1701);
  glLoadIdentity();
  glScalef(Ratio*Zoom,Zoom,-2/(F-N));
  glTranslatef(0,0,0.5*(F+N));

  glMatrixMode(0x1700);
  glLoadIdentity();
  glRotatef(App.CameraRotation.X*360,1,0,0);
  glRotatef(App.CameraRotation.Y*360,0,1,0);
  glRotatef(App.CameraRotation.Z*360,0,0,1);
  glTranslatef(0-App.CameraPosition.X,0-App.CameraPosition.Y,0-App.CameraPosition.Z);
}

Attached is a simple demo using the function.

K

[keymasher]

Nice work!

Yes we really need a camera component

[VilleK]

Maybe then it is finally time to create a camera component . I'm not opposed to it, it is just that I have prioritized other features, and now ever since adding the "remove unused code" we can add components that does not necessarily add to the runtime size when not used.

Did we ever discuss what properties a camera component should have? I can't find it when I search. Please make your suggestions.

[Kjell]

Actually I agree .. a Light component for example should be higher priority then a Camera component.

I posted the Camera properties here ( apart from the obvious position / rotation ), and we briefly discussed this here.

K

[VilleK]

Thanks Kjell, you have better searching skills than me

A light component is slightly more problematic as it would use OpenGL built-in lighting model but this is deprecated as of GL 3+/ES. And I would rather not introduce more deprecated GL-calls until we have decided a path to the newer GL-models.

[keymasher]

For the lighting component, could we not make a generic component (or just use a model component) and pass its vector position to the shader?

[VilleK]

For the lighting component, could we not make a generic component (or just use a model component) and pass its vector position to the shader?

That would work but then a default shader would be needed right? Or just predefined shader variable names "light0, light1" etc that shaders can use. I'm not sure how to design this properly, how do other engines solve this?

Anyway I've started work on the camera-component now and hope to have something working soon.

[Kjell]

Hmm,

Predefined variables ( basically the fixed pipeline reimplemented ) are probably easier / more flexible. Most engines seem to be taking this route some way or another ..

- Three.js "automatically" includes snippets based on flags ( see line 253 ).
- 3DVIA Studio simply provides a bunch of sample / base shaders.
- Unity has Surface Shaders to make it a little easier ( but supports plain shaders as well ).

K

[jph_wacheski]

You may also want to have a look at 3Dlabs GLSL ShaderGen; http://mew.cx/glsl/shadergen/



it generates the shaders for you to work with,. I have not messed with it much yet but it could be helpful in thinking about this, and getting the fixed pipeline re-implemented in GLSL. Looks like it pulls the lighting/fog/texture etc. values from the normal gl setting so these would still need to be added to zge,. .

[Kjell]

@jph - ShaderGen generates shaders which rely on globals that have been depricated since OpenGL 3+ / ES 2+. It was probably made to "assist" developers migrating from OpenGL 1 to 2 .. not from 2 to 3.

@Ville - Perhaps you could add some checkboxes on the Shader component to link certain uniforms you want to include? Doesn't the Texture component do this as well in a way ( too lazy to check the source )? Or like Unity, have a extended Shader component that offers these features and not "pollute" the plain one.

K

[VilleK]

Thanks for the links. Yes, the texture variables in ZGE is predefined to the shader when the shader is attached to a material with textures. We could have App.Lights where you can add Light-components (positions) which then will be predefined in the shader. But first we should perhaps have a general direction what we want to do with GL4 compatibility? It's too early to abandon the fixed GL 1.4 functionality because too many Intel cards only supports this so the best way would be if we could at runtime decide whether to use Fixed or New gl-contexts. In fixed the ZGE Light-component would simply map to the fixed Light-positions, in New context it would map to shader variables. Now ZGE is making GL-calls directly but we would need to make an abstract layer for this instead (similar to what is done for platform-calls).

About the camera, here is the first test version: http://www.zgameeditor.org/files/ZGameEditor_beta.zip

The idea is that you use the new Camera component to set the properties you want and choose between perspective or orthographic view. You can have multiple cameras in your project. Select a camera by assigning the new App.Camera property to the camera you want. You can also do this from code "App.Camera=Camera1;" etc. When App.Camera is not assigned it will use the App.CameraPosition etc properties just like before.

This is hardly tested at all and I do not have a sample project for it so please be prepared it can be buggy.

[Kjell]

Hej Ville,

It's too early to abandon the fixed GL 1.4 functionality because too many Intel cards only supports this so the best way would be if we could at runtime decide whether to use Fixed or New gl-contexts.

Agreed, would be a waste to completely ditch the current renderer, so I'm all for having a separate rendering pipeline to which you can switch.

In fixed the ZGE Light-component would simply map to the fixed Light-positions, in New context it would map to shader variables.

You're planning to have the new pipeline "forward" as well ( opposed to "deferred" )?

By the way, why did you use my hack-a-tron Orthographic function instead of OpenGL's native glOrtho? And perhaps we should advise against using the old App properties from now on, so those can be removed at some point

+ Some bugs ..

- ViewportRatio is pugged into the Ortho scale the wrong way, should be 1/Ratio.
- When previewing App while the application is not running, the old App.Camera properties are used instead of the selected Camera.
- You probably want to set OrthoZoom to 1 by default.

K

[VilleK]

Aha, I did not realize glOrtho used double parameters and that is why you did your own version. I've only used glOrtho with fixed parameters so I thought your way was a good alternative. I'll change it to use glOrtho then instead. Can you please give the full example with the parameters I should use with glOrtho to make it work like you want?

You're planning to have the new pipeline "forward" as well ( opposed to "deferred" )?

Not sure what you mean here: a forward-only GL3 context? Or something to do with deferred lighting?

I'll fix the other items you reported too, thanks for testing.

[Kjell]

Hej,

This appears to be working ( in C++ ).

Code: Select all

double ratio  = 16.0/9.0; // Grab this from Viewport
double zoom   = 2.0; // Inverted Zoom ( 1/OrthoZoom )

double width  = ratio*zoom;
double height = zoom;

glOrtho(-width,width,-height,height,0,100);

And never mind about the deferred question then

K

[VilleK]

Thanks. Updated: http://www.zgameeditor.org/files/ZGameEditor_beta.zip

If we create an abstract layer for different GL-compatibility levels we can support more advanced rendering modes for the higher levels.