javascript - Three.js/WebGL: Large spheres appear broken at intersection

Question

Let me preface this with saying I'm very inexperienced with 3D graphics.

Problem

I'm using Three.js. I have two spheres which (deliberately) collide in my WebGL model. When my spheres are incredibly large, the overlapping spheres appear "broken" where they intersect, but smaller spheres render perfectly fine.

I have a very specific reason for using such large units for some objects, and scaling down objects isn't really an option.

Example

Here is a fiddle for the larger spheres: http://jsfiddle.net/YSX7h/

and for the smaller ones: http://jsfiddle.net/7Lca2/

Code

var radiusUnits = 1790; // 179000000
var container;
var camera, scene, renderer;
var clock = new THREE.Clock();
var cross;
var plane;
var controls;
var cube;
var cubeMaterial = new THREE.MeshBasicMaterial( { color: 0xffffff, vertexColors: THREE.VertexColors } );
init();
animate();

function init() {
    camera = new THREE.PerspectiveCamera(100, window.innerWidth / window.innerHeight, 0.1, 3500000);
    controls = new THREE.OrbitControls(camera);
    camera.position.set(2000, 2000, 2000);
    camera.position.z = 500;
    scene = new THREE.Scene();

    var texture = THREE.ImageUtils.loadTexture('http://i.imgur.com/qDAEVoo.jpg');
    var material = new THREE.MeshBasicMaterial({
        color: 0xFFFFFF,
        map: texture,
        opacity:1
    });

    var material1 = new THREE.MeshBasicMaterial({ color: 0xFF0000, wireframe: true, opacity:1 });
    var geometry = new THREE.SphereGeometry(radiusUnits, 32, 32);
    var geometry1 = new THREE.SphereGeometry(radiusUnits, 32, 32);
    var mesh = new THREE.Mesh(geometry, material);
    var mesh1 = new THREE.Mesh(geometry1, material1);
    mesh1.position.set(0, 1000, 0);
    mesh.position.set(0, -1000, 0);

    scene.add(mesh);
    scene.add(mesh1);

    renderer = new THREE.WebGLRenderer( { antialias: true, alpha: true } );

    document.body.appendChild(renderer.domElement);
    renderer.setSize( window.innerWidth, window.innerHeight );
}

function onWindowResize() {
    renderer.setSize( window.innerWidth, window.innerHeight );
    render();
}

function animate() {
    controls.update();
    requestAnimationFrame( animate );
}

window.requestAnimFrame = (function(){
    return  window.requestAnimationFrame       ||
                window.webkitRequestAnimationFrame ||
                window.mozRequestAnimationFrame    ||
                window.oRequestAnimationFrame      ||
                window.msRequestAnimationFrame     ||
                function( callback ){
                  window.setTimeout(callback, 1000 / 60);
                };
})();

(function animloop(){
    requestAnimFrame(animloop);
    render();
})();

function render() {
    var delta = clock.getDelta(); 
    renderer.render( scene, camera );
}

Why, exactly, does this happen? And is there anything I can do to fix this, short of scaling down these objects?

Thanks in advance.

Answer 1

The short answer, set your z near plane further away

Change

camera = new THREE.PerspectiveCamera(
    100, window.innerWidth / window.innerHeight, 0.1, 3500000);

to

var zNear = 1000;
var zFar = 3500000;
camera = new THREE.PerspectiveCamera(
    100, window.innerWidth / window.innerHeight, zNear, zFar);

Note: I don't know if 1000 will work, if it doesn't try 10000.

A zBuffer, the thing used to be able to tell which pixels go in front of other previously drawn pixels, has limited resolution. In WebGL it could be 16bits, 24 or 32. I'm guessing 24 is the most common. For the point of illustration let's assume it was just 4 bits though. That would mean for a given z range there are only 16 possible values. Given the standard math used for 3D projection, on a 4 bit zbuffer, if the range was zNear = 0.1 and zFar = 3500000 the 16 possible values are something like

0 = 0.100
1 = 0.107         range: 0.007
2 = 0.115         range: 0.008
3 = 0.125         range: 0.010
4 = 0.136         range: 0.011
5 = 0.150         range: 0.014
6 = 0.167         range: 0.017
7 = 0.187         range: 0.021
8 = 0.214         range: 0.027
9 = 0.250         range: 0.036
10 = 0.300        range: 0.050
11 = 0.375        range: 0.075
12 = 0.500        range: 0.125
13 = 0.750        range: 0.250
14 = 1.500        range: 0.750
15 = 3499999.993  range: 3499998.493 

As you can see the range between values increase exponentially meaning there is almost no resolution far away from the camera.

If we increase zNear to 1000 we get

0 = 1000.000
1 = 1071.407       range: 71.407
2 = 1153.795       range: 82.389
3 = 1249.911       range: 96.115
4 = 1363.495       range: 113.584
5 = 1499.786       range: 136.291
6 = 1666.349       range: 166.564
7 = 1874.531       range: 208.182
8 = 2142.158       range: 267.626
9 = 2498.929       range: 356.771
10 = 2998.287      range: 499.358
11 = 3747.056      range: 748.769
12 = 4994.292      range: 1247.236
13 = 7486.097      range: 2491.805
14 = 14940.239     range: 7454.142
15 = 3500000.000   range: 3485059.761 

You can see it starting to spread out a little. On a 24bit depth buffer with zNear at 0.1 and zFar at 3500000 the range between the last 15 units is

16777201 = 115869.957       range: 7485.454
16777202 = 124466.066       range: 8596.109
16777203 = 134439.829       range: 9973.763
16777204 = 146151.280       range: 11711.451
16777205 = 160097.879       range: 13946.599
16777206 = 176987.000       range: 16889.122
16777207 = 197859.711       range: 20872.711
16777208 = 224313.847       range: 26454.135
16777209 = 258933.659       range: 34619.812
16777210 = 306189.940       range: 47256.281
16777211 = 374545.842       range: 68355.902
16777212 = 482194.095       range: 107648.253
16777213 = 676678.248       range: 194484.154
16777214 = 1134094.478       range: 457416.229
16777215 = 3499999.993       range: 2365905.515

Where as with zNear at 1000 they're

16777201 = 3489810.475       range: 725.553
16777202 = 3490536.330       range: 725.855
16777203 = 3491262.487       range: 726.157
16777204 = 3491988.947       range: 726.459
16777205 = 3492715.709       range: 726.762
16777206 = 3493442.773       range: 727.064
16777207 = 3494170.140       range: 727.367
16777208 = 3494897.810       range: 727.670
16777209 = 3495625.784       range: 727.973
16777210 = 3496354.060       range: 728.277
16777211 = 3497082.640       range: 728.580
16777212 = 3497811.524       range: 728.884
16777213 = 3498540.712       range: 729.188
16777214 = 3499270.204       range: 729.492
16777215 = 3500000.000       range: 729.796

Which is probably a little more reasonable? It's basically saying 2 points that are less than ~728 units different when far away from the camera may be sorted incorrectly. Or to put it in a positive light, as long as 2 points are at least 728 units away from each other in their distance from the camera they'll be sorted correctly.

All of this is to point out that you have to set your near and far clipping planes appropriately for your application.

I should probably note that the math being applied is just the most common math and probably the same math that three.js used by default. With your own vertex shaders you could make the zbuffer do something else. Here's a good article on it.