Renderer's `resetCamera()` is biased to height when calculating zoom

[mix3d]

I've noticed that there is a render bias for fitting the bounds in the render viewport when using renderer.resetCamera(). Note that these examples are with Parallel enabled, but I can try to reproduce with normal perspective as well.

Example:
Wide viewport scales to fit:

VS
Narrow viewport crops significantly

[mix3d]

Any tips for getting wide volumes in tall viewports to render well? @jourdain?

[finetjul]

Renderer.resetCamera() does not take into account the viewport size (nor ratio).

Instead it fits the bounding sphere of the scene into a square frustum viewport.
It seems to work fine because it the vertical axis is always correctly fitted (it could be improved by not using a bounding sphere but the actual bounds).

A solution is to create your own resetCamera function that takes into account the viewer size ratio.

There is useful documentation in code:

vtk-js/Sources/Rendering/Core/Renderer/index.js

Lines 411 to 421 in 0a4f91d

	// compute the distance from the intersection of the view frustum with the
	// bounding sphere. Basically in 2D draw a circle representing the bounding
	// sphere in 2D then draw a horizontal line going out from the center of
	// the circle. That is the camera view. Then draw a line from the camera
	// position to the point where it intersects the circle. (it will be tangent
	// to the circle at this point, this is important, only go to the tangent
	// point, do not draw all the way to the view plane). Then draw the radius
	// from the tangent point to the center of the circle. You will note that
	// this forms a right triangle with one side being the radius, another being
	// the target distance for the camera, then just find the target dist using
	// a sin.

[mix3d]

If the bounding sphere is supposed to fit in the view frustum, wouldn't you expect the sphere to always fit, regardless of the viewport frustum ratio? The point of the sphere is to account for the potential oblong-ness or arbitrary orientation of the volume itself, right? So the Sphere is the correct way to go, because as long as the sphere fits, the bounds will be included.

If it's only checking the vertical axis, and that's the one that seems to work all the time, I think a quick check on the frustum to determine if it should use the vertical or horizontal axis would be an easy fix here.

[finetjul]

C++ implementation takes into account aspect ratio:
https://gitlab.kitware.com/vtk/vtk/-/blob/master/Rendering/Core/vtkRenderer.cxx#L1138-1157

Interestingly, it used to be possible (though bugged?) to choose wether sphere is fit horizontally or vertically:
b9956c7

Best is to ask original author: @martinken WDYT ?

[floryst]

We can add an option to resetCamera() to fit vertically or horizontally.

[mix3d]

I would recommend adopting the c++ logic that calculates the viewport ratio and fits to the smaller dimension, by default.

Manual COULD be nice, but the goal of reset is "fit the content in the viewport", and should be ratio agnostic.

As a developer, I shouldn't have to manually track what the viewport ratio is.

[aerogt3]

The behavior of resetCamera has been a sore point for us for many years in paraview and vtk.js - it's inconsistent between the two, and neither one does what you would expect coming from CAD systems and other 3D viewers. Most resetCamera calls give you a view which is zoomed quite far out.

I can share the solution that we use here, which fits the scene to the window regardless of window aspect ratio, working even for display of high aspect ratio objects, like this STL of a random train from a CAD website. It's performant on scenes with over 500 actors.

It works nicely when parallelProjection is ON. When OFF, it can give imperfect results for high AR objects like this train, so it's currently only active with parallelProjection. I think users would still find this an improvement over the default behavior, maybe even enough to bring the behavior into paraview.

One thing we noticed (with or without the linked commit) is that computeVisiblePropBounds returns the full bounds of an object that has been treated with clipPlanes - in theory the bounds should be based on the clipped item? That seems to be how it works in paraview, for example.

EDIT: offsetRatio is set to 1 on the right, to force a full fit on the screen

X and Y views after resetCamera for an STL with aspect ratio ~20. Standard (left), vs. the above commit (right)

[sankhesh]

@aerogt3 If you have a better alternative to the reset camera approach, please create a PR.

Just to clarify, did you mean that you have a different solution i.e. other than what is in 1d2afae? Because, those changes do look at the viewport aspect ratio when figuring out the camera basis vectors. FWIW, that is the recommended approach.

One thing we noticed (with or without the linked commit) is that computeVisiblePropBounds returns the full bounds of an object that has been treated with clipPlanes

That seems like a bug to me.