Three.js: THREE.Points stop rendering when their center point leaves view frustum, regardless of frustumCulled setting

[flimshaw]

When rendering a pointcloud with THREE.Points, points that get near the edge of the rendering context blink in and out of existence abruptly when passing through their center point. Setting frustumCulled = false on the Points object appears to have no effect, nor does forcing a new boundingSphere calculation etc.

Here is a demo illustrating the problem: http://jsfiddle.net/akmcv7Lh/123/

If you rotate the camera, keep an eye on points near the edges of the view. It appears that once their center point leaves the camera's view, they are no longer rendered. Is this a limitation of this rendering method, or possibly a bug?

Three.js version

• [X] r84
• [X] r85

Browser

• [x] All of them

OS

• [x] All of them

[mrdoob]

This is a limitation of WebGL's GL_POINTS.

[flimshaw]

got it, thank you sir

[mrdoob]

Actually, now you mention it. On the Intel HD Graphics 6000 the particles do not disappear abruptly but I remember this happening on nvidia cards.

@kenrussell do you know what's supposed to be the expected behaviour?

[jostschmithals]

My NVIDIA (GeForce G210) displays the points near the edges correctly.

[flimshaw]

Huh! The plot thickens. Thanks, I'm seeing correct behavior on Intel Iris integrated, but abrupt disappearance on AMD Radeon Pro 480

[kenrussell]

Unfortunately I'm quite sure this is longstanding behavior of AMD's OpenGL driver on multiple platforms.

The Chrome team reported this as a bug against Apple's OpenGL driver, but it was closed as being within the OpenGL spec's behavior.

I was supposed to file a new Radar but dropped that on the floor. I'm sorry about that.

Still, to get the correct behavior on the plethora of cards that are out there, there are basically two choices. One is to emulate GL_POINTS by drawing a pair of quads. The second is (I think) to inflate the GL_VIEWPORT outward by half of the maximum point size that you'll draw. See pitfall #10 in https://www.opengl.org/archives/resources/features/KilgardTechniques/oglpitfall/ .

We looked into doing the latter automatically in Chrome as a driver bug workaround, but it changes the rendering results slightly, so is not easy to do in the general case.

Please give one of these workarounds a try, and sorry for the poor behavior that we weren't able to hide yet in WebGL.

[flimshaw]

hey thanks a lot for the details @kenrussell, your two workarounds were the same ones that ended up on the back of my envelope over here, and I went with quads. It's amazing I'd never noticed this one before, I've done tons of particle and point cloud work, but I guess never slowly, with big particles, and near the edges of the camera. Cheers!

[gabrielmolochko]

@flimshaw I am trying to do something similar, but I'm not sure what it means to use a "pair of quads". Can you demonstrate how you got it working?

[Centipede5]

@flimshaw
if your still having this issue heres what worked for me http://jsfiddle.net/fszmtu8k/1/

I also used this when using the particle system made by squarefeet
code:
this.geometry.verticesNeedUpdate = true; setTimeout(function(){ geo.boundingSphere.radius = 100;/*set to whatever is nessisary, this is just an example*/ },2000)
where geo is the geometry used in THREE.Points

I know about computeboundingsphere, but it didnt seem to work properly for me