Three.js: Many examples use a negative value for OrthographicCamera.near

[looeee]

I've just taken a quick look through the examples, and there are a lot of places where the orthographic camera has a negative near value, including CinematicCamera.js, transition.js, misc_exporter_gltf and webgl_postprocessing_advanced.

It's my understanding that the valid values for camera near and far are:

PerspectiveCamera: Infinity > far > near > 0
OrthographicCamera Camera: Infinity > far > near >= 0

It seems to me that this is confusing even for the "experts" who wrote these examples. Since setting camera parameters is unlikely to be a hot code path, perhaps we should consider adding a warning when invalid parameters are set here?

We should also correct all the examples that use negative values here.

[WestLangley]

I believe what is stated in this SO answer is correct.

Although, a negative value for the near plane is OK when post processing, I'd set near to a non-negative value for consistency.

The misc_exporter_gltf example, however, is incorrect and should be changed -- unless the intent was to render objects behind the camera.

I would not bother with a warning. You can make sure the docs are sufficiently informative, though.

[looeee]

@WestLangley from your answer on that SO link, regarding OrthographicCamera

Both near and far should be greater than zero.

Are you saying that 0 is not a valid value?

[WestLangley]

Zero is not a valid value for PerspectiveCamera.near, and positive values that are close to zero should be avoided as they can result in z-fighting problems.

Zero _is_ a valid value for OrthographicCamera.near. Thing is, users often swap cameras, and for simplicity, I think recommending that near be positive is a good idea.

[looeee]

OK, rather than getting sidetracked about docs and parameter checking, I think the most important thing here is to make sure that the examples are correct.

@WestLangley it seems that what you are suggesting is that for best practice and consistency, near should be greater than 0 for both camera types, even though 0 is a valid value for OrthographicCamera.

Is this correct?

[WestLangley]

Yes. Let's keep the frustum in front of the camera.

[WestLangley]

It seems this is resolved.