Progressively rendering infinitely large meshes

Please read my SO question here:

How would you go about solving this problem?

Has anyone had experience customizing the WebGLRenderer class?

I want to call renderer.renderBufferDirect() in my scene.onAfterRender callback ( to progressively render more geoms ), but the WebGLState closure variable is set to null immediately after the callback is invoked. I cannot prevent this behavior unless the WebGLRenderer API is modified.

How do you plan on loading the geometry data? Ideally you should have the data tiled and then you could do something like Potree ( does which is building an octree and rendering only the data which is visible up to a certain number of points (in your case it would be polygons or vertices).

You can also take a look at Cesium, which has support for 3d-tiles:

1 Like

Thanks for your response. Actually, the loading of the geometry is not my main concern, its the progressive rendering. I have not seen any other examples of this before, as I believe it requires modifications to the three.js render method to achieve good performance.

This blog post is very close to what I want to achieve, I wish they open sourced the code.

I’ve implemented a similar technique in my engine, i’ve modified few lines in the renderer to let an object takeover render calls, this null-object traverses the octree-managed scene for LOD, loading and unloading.

For the models i’ve made a converter which generates various things like adding bounding details by default but also generating a internal culling octree with it’s depth depending on the polycount. One is for really big models, so it basically splits them into groups, another to optimize for collision and raycasting.

What do you actually want to archive / for what kind of models?

The main use-case is rendering large architectural models, but it should be able to handle arbitrary meshes.

Have you considered a PR back into three.js with your renderer modifications?
My goal is to find a way to modify the renderer in such a way that the maintainers can merge the changes, so other developers like us can have more flexibility in the future without having to fork the project.