Three.js: Proposed New OrthographicCamera API

[WestLangley]

The PerspectiveCamera API looks like this:

PerspectiveCamera( fov, aspect, near, far )

fov is the vertical field-of-view in degrees, aspect is the aspect ratio, and near and far are the distances to the near and far clip-planes, respectively.

I propose that the OrthographicCamera API be changed to:

OrthographicCamera( height, aspect, near, far )

height is the vertical height of the orthographic frustum in world units, and the remaining parameters are the same as those for the PerspectiveCamera.

An alternate API is:

OrthographicCamera( width, height, near, far )

Either of these API changes imply that the orthographic frustum is symmetric around the z-axis. I do not believe this is a limiting constraint, but I am open to being convinced otherwise.

[erichlof]

@WestLangley
+1 for one of these options to replace the current ortho constructor. Sorry I didn't respond sooner WestLangley, something came up.

Anyway, I kind of prefer the second option, the one with ( width, height, near, far ). If that is all three.js needs to construct an ortho camera, then this is very intuitive and almost self-explanatory. I will be glad to update the docs if one of these changes gets implemented. Also, as discussed in #4880 , I will include an additional sentence or two right below the example code snippet, explaining the correct way to think about and use the ortho camera constructor.

[gero3]

+1 I agree.
It simplifies the orthographic camera.
I would also deprecate the old version for 2 revisions.

There are problems here tough:
https://github.com/mrdoob/three.js/blob/master/examples/webgl_animation_skinning_morph.html#L122-L123 -> The directional light uses a orthographic camera for shadows.
https://github.com/mrdoob/three.js/blob/master/examples/webgl_materials_cubemap_dynamic.html#L599-L603

And the loaders also need to changed.

[mrdoob]

Sounds good to me.
The second one seems simpler.

[looeee]

@mrdoob @WestLangley it's been a couple of years since this was opened, is it still being considered?

[mrdoob]

Yep. I can't think of a way of doing this change in a robust way with no breakage though...

[WestLangley]

Also, the current API supports an asymmetric orthographic frustum, and the proposal here does not, so I am going to close this.