WEBGL stroke weight misbehaves after call to perspective()

[jwdunn1]

After perspective() is called, stroke weights become unexpectedly thin near the camera while objects far away are stroked too thickly. I noticed this on another sketch I was building with a roving camera. For reporting purposes, I've created a minimal sketch to illustrate the problem.

Nature of issue?

• Found a bug

Most appropriate sub-area of p5.js?

• Core/Environment/Rendering
• WebGL

Which platform were you using when you encountered this?

• Mobile/Tablet (touch devices)
• Desktop/Laptop

Details about the bug:

• p5.js version: v0.10.2
• Web browser and version: Chrome 79.0.3945.88, Firefox 71.0, Safari 12.1.1
• Operating System: Windows 7 Pro, macOS 10.13.6, Android 7
• Steps to reproduce this:

1. Run this repro sketch https://editor.p5js.org/jwdunn1/sketches/VGEuB8mTP
2. Note the stroke weights - these are rendered correctly at this point. Stroke weight is set to 3 for emphasis.
3. Now, click on the sketch canvas to invoke perspective()
4. Note the change in stroke weights (items closer to the camera become too thin while those further away become too thick) This is not the expected behavior.
   The stroke weights work correctly with perspective() in v0.9.0 and earlier.

Sketch code is below:

function setup() {
  createCanvas(400, 400, WEBGL);
  strokeWeight(3);
}

function draw() {
  background(220);
  rotateY(PI/8);
  rotateZ(PI/8);
  translate(0,0,300);
  for(let i=0; i<12; i++){
    translate(0,0,-100);
    box();
  }
}
function mousePressed(){
  perspective(PI/3, width/height, 1, 10000);
}

[stalgiag]

Thanks for the well-written issue @jwdunn1 !

This is known behavior. Currently the stroke shader doesn't track the amount of perspective that is applied to the sketch. There are only two states, default perspective and custom perspective. Custom perspectives always use orthographic projection on the stroke. In the example you linked, after clicking, the stroke doesn't get larger further from the camera but instead stays the exact same size while the box itself gets smaller.

This behavior begins with this PR which I filed. The PR was a way of fixing broken stroking in custom perspectives. As a blunt solution, stroke perspective was given a simple on or off state. This was done to avoid calculating the mix of perspective to orthographic projection in a user's custom perspective.

That said, if you (or anyone) has interest in adding a calculation of the ortho-to-perspective interpolation of a custom perspective then I'd be happy to review.

[jwdunn1]

Thank you for the information. As an experiment (without knowing the deeper ramifications), I removed the else clause introduced by the PR in p5.Shader.js. With this change, my sketch (which uses a roving camera: EasyCam) now operates as expected with a custom perspective (or ortho) and with correctly scaling and rotating strokes. Do you see a problem with this approach? Could this solution work in the general case?

This is the code change I include at the beginning of my sketch to override the v0.10.2 _setMatrixUniforms method:

p5.Shader.prototype._setMatrixUniforms = function() {
  this.setUniform('uProjectionMatrix', this._renderer.uPMatrix.mat4);
  if (this.isStrokeShader()) this.setUniform('uPerspective', 1);
  this.setUniform('uModelViewMatrix', this._renderer.uMVMatrix.mat4);
  this.setUniform('uViewMatrix', this._renderer._curCamera.cameraMatrix.mat4);
  if (this.uniforms.uNormalMatrix) {
    this._renderer.uNMatrix.inverseTranspose(this._renderer.uMVMatrix);
    this.setUniform('uNormalMatrix', this._renderer.uNMatrix.mat3);
  }
};

Examples with this 'fix':
https://www.openprocessing.org/sketch/811370
https://www.openprocessing.org/sketch/817106

[stalgiag]

@jwdunn1 I don't see a problem with that solution for your sketches. Unfortunately, it isn't a general solution because it is possible for a user to make a sketch that has a projection matrix that breaks this.

Here is an example that shows this.. If you comment out your prototype override you can see that the ortho is more legible than the incorrect perspective.

This is a situation where a fix introduces another problem. The thought with introducing this behavior was that orthographic stroke projection was a safer assumption for custom perspective, but perhaps it is better to assume perspective projection. It is difficult to say which problem will present itself more, or be more obtrusive, but I am open to arguments either way.

The only true fix, as I said in my earlier comment, would be a calculation of where a custom perspective is on an interpolation between orthographic and perspective, but I don't know how to do that easily.

[Garima3110]

That said, if you (or anyone) has interest in adding a calculation of the ortho-to-perspective interpolation of a custom perspective then I'd be happy to review.

I have come up with an approach to calculate the interpolation value. Please let me know if I am going in the right direction or not ..!
I think we can use the ratio of the object's distance from the camera to the max distance (maybe using the bounding box approach) ,
And then using the Math.min() function to get the min of the two values , i.e 1 and the calculated ratio.

@davepagurek @stalgiag , I would love to have your suggestions on this ..
Thankyou..!

[davepagurek]

Could you describe the bounding box method you're mentioning @Garima3110? Also, in case it's useful, p5.Camera has a cameraFar property describing the maximum z value that will get rendered.

Another option we have is just to add a way to manually set whether or not lines should have perspective, e.g. linePerspective(true) or linePerspective(false). Someone on discord was recently asking whether or not they could turn off perspective on lines while using the default perspective camera. Maybe it's easier to keep the current defaults but let users pick for themselves if they want?