Orthographic

Share your ZGE-development tips and techniques here!

Moderator: Moderators

User avatar
Kjell
Posts: 1715
Joined: Sat Feb 23, 2008 11:15 pm

Orthographic

Post by Kjell » Tue May 24, 2011 10:19 am

:arrow:

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
Attachments
Orthographic.zgeproj
(2.89 KiB) Downloaded 588 times
Orthographic.png
Orthographic.png (55.29 KiB) Viewed 13657 times

keymasher
Posts: 39
Joined: Sun Feb 20, 2011 8:54 am

Post by keymasher » Tue May 24, 2011 10:16 pm

Nice work!

Yes we really need a camera component

User avatar
VilleK
Site Admin
Posts: 2025
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Wed May 25, 2011 8:54 am

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.

User avatar
Kjell
Posts: 1715
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Wed May 25, 2011 11:28 am

:roll:

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

User avatar
VilleK
Site Admin
Posts: 2025
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Wed May 25, 2011 11:36 am

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
Posts: 39
Joined: Sun Feb 20, 2011 8:54 am

Post by keymasher » Wed May 25, 2011 10:30 pm

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?

User avatar
VilleK
Site Admin
Posts: 2025
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Sun May 29, 2011 4:49 pm

keymasher wrote: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.

User avatar
Kjell
Posts: 1715
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Sun May 29, 2011 9:58 pm

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

User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski » Mon May 30, 2011 12:33 pm

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

Image

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,. .
iterationGAMES.com

User avatar
Kjell
Posts: 1715
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Mon May 30, 2011 1:34 pm

:?

@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

User avatar
VilleK
Site Admin
Posts: 2025
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Mon May 30, 2011 2:52 pm

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.

User avatar
Kjell
Posts: 1715
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Mon May 30, 2011 3:17 pm

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 :roll:

+ 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

User avatar
VilleK
Site Admin
Posts: 2025
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Mon May 30, 2011 4:27 pm

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.

User avatar
Kjell
Posts: 1715
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell » Mon May 30, 2011 5:17 pm

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 :wink:

K

User avatar
VilleK
Site Admin
Posts: 2025
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK » Mon May 30, 2011 5:38 pm

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.

Post Reply