Well if you make a sphere with a radius of 3.75 the clipping plane starts to cut it away in top, front, side views.

so in the Houdini world everything must be smaller then 3 3/4 units or your bigger then the visible universe apparently.
Is there some way to scale the orthographic camera rig to infinity as it should naturally be, thanks (dev team)?

(Also note that my more or less state of the art NVidia Graphics Card only works on GL 2.1 or lines draw with randomly located points.)
:roll: ops: :wink:

1. Display options/clipping/“Homing Auto Adjusts” == Near & Far Clip Planes

2. Select sphere

3. space-h

MartybNz
1. Display options/clipping/“Homing Auto Adjusts” == Near & Far Clip Planes

Yeah, but GottaGetmedat raises a good point that it doesn't make any sense to have near/far clipping in the orthographic viewports. (It doesn't really make sense in the other viewports either, but that's a separate gripe of mine.) I don't know if there's a good solution, though, because graphics cards still require near and far planes, because they decided to handle z-buffering using low-bit-count integers instead of floating-point numbers. :roll:

How do you depth sort without clipping planes?

MartybNz
How do you depth sort without clipping planes?

Huh? You depth sort by sorting by the depth; it has nothing to do with clipping. The depth starts as a 32-bit floating-point number, and if you just remove negative values, it can go from zero to FLT_MAX, (or even infinite, but that's another matter), which is on the order of 10^38, so you effectively have a plane at depth 10^38 beyond which everything will be at the same distance.

There's no need to arbitrarily limit depths, unless you're changing the depth to be a linear (or 1/linear) integer, which is what graphics cards do, so that's why they need near/far clipping planes. If you instead either keep the floating-point number or pretend the floating-point number's bits are an integer, you can sort on either of those without any clipping planes, (the pretend integer version only works for all positive integers or all negative integers, but that's what we have).

Hey that sounds very interesting. Do you have an example of a non-clipped orthographic/perspective 3d viewer?

MartybNz
Hey that sounds very interesting. Do you have an example of a non-clipped orthographic/perspective 3d viewer?

Sadly, no, because pretty much everything these days uses the graphics card for viewing. I think even CPU renderers like Mantra have near/far clipping planes, albeit probably for different reasons.

Another reason for near/far clipping planes is to avoid numeric underflow/overflow in other computations. It's hard to avoid or check for underflow/overflow cases everywhere, so most things put arbitrary near/far clipping planes, but those can be out at 10^-15 and 10^15, so it's not a big concern.

The biggest reason for them, though, is that just about every graphics course and textbook under the sun teaches clipping only in terms of clipping a 0-1 cube, (because it's easier to teach), in which case, everything needs to be transformed into a space between 0-1. It's easy to do clipping differently, but most people just go by the textbooks. Way back when I was writing my own software renderer, I was figuring most everything out on my own, so I did pretty much no clipping except in screen space; I also got a lot of other things completely wrong, though, so different doesn't necessarily mean better. :wink:

Wow, I should stop rambling. My apologies!

This did work, thanks.
Still the default position for an orthographic camera should be well beyond the bounds of the viewport's default grid (aka display construction plane/ortho grid).

MartybNz
1. Display options/clipping/“Homing Auto Adjusts” == Near & Far Clip Planes

2. Select sphere

3. space-h

:shock:

Stumbled upon this update in OpenGL 4.5:

GL_ARB_clip_control
https://www.opengl.org/registry/specs/ARB/clip_control.txt [opengl.org]

'Developers interested in this functionality may be porting content
from Direct3D to OpenGL and/or interested in improving the numerical
accuracy of depth testing, particularly with floating-point depth
buffers.'

MartybNz
Stumbled upon this update in OpenGL 4.5:

GL_ARB_clip_control
https://www.opengl.org/registry/specs/ARB/clip_control.txt [opengl.org]

'Developers interested in this functionality may be porting content
from Direct3D to OpenGL and/or interested in improving the numerical
accuracy of depth testing, particularly with floating-point depth
buffers.'

Yeah, it doesn't do much. You get a tiny bit more precision, but that pretty much doesn't matter once you start getting close to the far plane due to the non-linear nature of the perspective Z-divide. Even for orthographic viewports, it'd be hard to notice a difference. Until (?) hardware begins supporting 64b z-buffers, the near:far clip plane ratio is pretty much limited to 6 digits.

This extension is more for portability between DirectX and OpenGL than precision.

Hello, please, did you find a solution to set the default position of an orthographic camera well beyond the bounds of the viewport (or the homing object)?

Why not to set the scene origin (or the homing object) right in the middle, between the clipping planes?