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:
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?
I seem to be on the wrong track. Seems I need this:
const frustum = new THREE.Frustum();
Does anyone know about it?