Fix clipping in webgl2_materials_texture3d

[rlschuller]

Description

The camera position was too close to the 3D texture, causing clipping
from certain angles.

Before the repositioning:

After the repositioning:

[Mugen87]

https://threejs.org/examples/webgl2_materials_texture3d
https://raw.githack.com/rlschuller/three.js/dev/examples/webgl2_materials_texture3d.html

TBH, I don't see how the PR improves the example. Do you mind explaining the mentioned clipping in more detail?

[rlschuller]

Sure ;)

When rotating along the axis parallel to a horizontal line in the monitor, the extremities of the 3D texture can get clipped. In this particular model, it affects mostly the pelvic bone:

Setting the x position of the camera to -256 seems to move the model forward relatively to the camera and fix the clipping:

[rlschuller]

The last commit just increase the size of the frustrum and move the object to the middle of it.

Moving the object a bit makes the frustrum positioning more apparent.

Before:

After:

[mrdoob]

Would camera.position.set( 0, 0, 256 ) work too?

[rlschuller]

It makes the camera higher, which would keep the object further away than using camera.position.set( 0, 0, 128 ). From what I understood, what matters is the initial Euclidean distance from the camera to the object's center.

I believe that it would fix the clipping due to rotation only, but not for rotation + horizontal movement.

With the frustrum size of 1000-1=999 (before), I couldn't find a distance that would reliably avoid clipping for rotation + horizontal movement. Either it would clip at the front or at the back.

[rlschuller]

Zooming also doesn't seem to affect the frustrum's near and far planes.

[rlschuller]

Let OOO be the object and C the camera.

changing only camera.position.set( 0, 0, 128 ); to camera.position.set( 0, 0, 256 ); would create the following situation:

O
O     C
O

to

O     C  
O
O

IMO, keeping the z of the camera aligned w/ the center of the exam (z=128) makes sense. But it is subjective.

Here follows the initial viewing angle for camera.position.set( 0, 0, 256 );:

[rlschuller]

From what I understood, any camera.position.set( x, y, z );, such that sqrt(x^2 + y^2 + (z-128)^2) is approx 1000 = half of the new distance for the frustrum's far plane will work fine.

[rlschuller]

We can imagine it as a rotating table.

We don't want the camera to be just outside of the radius of the object:

But outside of the radius of the rotating table itself:

[rlschuller]

for camera.position.set( 0, 0, 256 );, small translations make the clipping appear again:

[WestLangley]

Make these temporary changes so you can see what is happening:

scene.add( new THREE.AxesHelper( 256 ) );

const mesh = new THREE.Mesh( geometry, new THREE.MeshNormalMaterial() );

Fix the clipping by moving the camera back a bit;

camera.position.set( - 64, - 64, 128 );

Then disable panning.

controls.enablePan = false;

[rlschuller]

Thanks for the feedback and suggestions, AxesHelper did indeed live up to its name. Pretty cool.

Your library is awesome, and I'll definitely keep using it in the future. I'm new to Open Source contributions and PRs, so please let me know if I do (or am doing) something wrong, such a too much verbosity or things like that.

All of the translation and positioning functions are working exactly as expected and in agreement with the documentation. The center of the BoxGeometry is corectly beeing drawn at O = (63.5, 63.5, 127.5), w/ relevant lines shown bellow:

three.js/examples/webgl2_materials_texture3d.html

Lines 118 to 120 in 7f9e721

	// THREE.Mesh
	const geometry = new THREE.BoxGeometry( volume.xLength, volume.yLength, volume.zLength );
	geometry.translate( volume.xLength / 2 - 0.5, volume.yLength / 2 - 0.5, volume.zLength / 2 - 0.5 );

Therefore, the suggestion

camera.position.set( - 64, - 64, 128 );

works fine when Pan is disabled, with initial point of view shown bellow:

To keep this point of view and also enable Pan, my suggestion would be to position the object in the center of the frustrum with the far plane 2000 units away and near plane 1 unit away, ie

camera.position.set( - 643, - 643, 128 );

Since, (a - 64)² + (a - 64)² = ((2000+1)/2)², for a < 0, yelds a ~ - 643 (or a ~ - 644 if we consider the fractional coordinates of O).

[WestLangley]

I would do what I recommended. You can't prevent clipping when the user is able to pan without limitation.

[rlschuller]

I usually make the near and far clipping more lenient than the left and right clipping, for reasonable zoom levels and aspect ratios. If the users pan themselves to the moon, it's their fault. ;)

But you're probably right, this model isn't detailed enough to justify enabling Pan.

[mrdoob]

Thanks!