I need an offset on my frustum

Questions
1

While waiting for the r156, which I’m really looking forward to because of a valuable WebGPU extension, I’m passing the time with the further development of my ocean geometry. I have added morphing to my quadtree so that you can no longer see any lod jumps when new childs are added. Although the CPU and the GPU still have reserves, it ran slowly. Then it occurred to me that I had deactivated frustumCulling. So every geometry was rendered, which is bad. Why did I disable frustumCulling? Because the IFFT shader can be shift geometries in such a way that childs who are outside the frustum can be shifted into the camera’s frustum.

At the bottom right of the picture you can see two areas with invisible chunks because they are actually outside the frustum:

Screenshot_20230904_111726_Chrome
Screenshot_20230904_111726_Chrome1920×943 272 KB

Because of the waves, however, the shader then shifts them into the camera.

So I looked in three.js for something nice to be able to set a frustum offset area and I found this.
“.setViewOffset” This is described in the documentation in connection with multiple monitors. I imagine an offset in such a way that a kind of frustum camera simply is behind the original camera (e.g. 250 m in +z direction behind the camera in the cameras local space) and thus automatically covers a larger area with the same fov.

Description in the documentation:

.setViewOffset ( fullWidth : Float, fullHeight : Float, x : Float, y : Float, width : Float, height : Float ) : undefined
fullWidth — full width of multiview setup
fullHeight — full height of multiview setup
x — horizontal offset of subcamera
y — vertical offset of subcamera
width — width of subcamera
height — height of subcamera

I don’t have a clear idea of ​​what the frustum of the camera looks like depending on setViewOffset.
Does anyone have a visual description?

P.S:
I seem to be on the wrong track. Seems I need this:

const frustum = new THREE.Frustum();

Does anyone know about it?

2

Im afraid no matter what view offset is, frustum planes will still go to the edges of the screen :man_shrugging: however, what you want to do is kind of possible: in WebGLRenderer, culling is done by

if ( ! object.frustumCulled || _frustum.intersectsObject( object ) ) {

check, and in intersectsObject you can see that it is possible to alter the result by altering object bounding sphere

1 Like
3

This is exactly what I needed!

The waves move the wireframe back and forth.
With your advice, I simply created a boundingSphere with twice the size of the respective child. This is enough to ensure that everything within the camera view is visible.

const localToWorld = params.transform;
const boundingSphereCenter = new THREE.Vector3(params.offset.x, params.offset.y, params.offset.z);
boundingSphereCenter.applyMatrix4(localToWorld);
const boundingSphere = new THREE.Sphere(boundingSphereCenter, params.width * 2);
this.mesh_.geometry.boundingSphere = boundingSphere;
this.mesh_.geometry.computeBoundingSphere();

Thanks makc3d you saved me a lot of time with tedious search.
Now I have a perfect stepless morphing quadtree. The whole thing still runs in WebGL2. Now I’m looking forward to r156 and I’m excited about the textureStore extension from sunag. This should make it even more efficient since the IFFT wave generator with its many render targets in WebGL2 is cumbersome.