New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PointMaterial's sizeAttenuation blows up near origin with Orthographic Camera #7517

Closed
ericdrobinson opened this Issue Nov 2, 2015 · 12 comments

Comments

Projects
None yet
4 participants
@ericdrobinson

ericdrobinson commented Nov 2, 2015

Environment

Revision #: r73
Browser: Chrome 46.0.2490.80
OS: Mac OS 10.11.1
GPU: NVIDIA GeForce GT 650M

Problem Description

When the sizeAttenuation parameter in a PointMaterial is true and used to render vertices with an Orthographic Camera, points located near the origin (0,0,0) scale incorrectly. See this test case.

A screenshot of this follows:
screen shot 2015-11-02 at 11 51 46 am
There are two sets of points being rendered:

  1. Blue: The material used by these points leaves the sizeAttenuation at its default setting (true).
  2. Green: The material used by these points sets sizeAttenuation to false.

Expected Results

The two sets of points should be drawn at roughly the same size, with the blue points being slightly smaller (as they are further from the camera). That or sizeAttenuation should have no effect when used with an Orthographic Camera.

Possible Culprit

I'm no Open/WebGL wizard but I suspect that something odd is happening with the math in the points vertexShader somewhere around here.

@mrdoob

This comment has been minimized.

Owner

mrdoob commented Nov 2, 2015

The size attenuation code was changed during this cycle.

http://jsfiddle.net/f2pwmf7w/7/

Is this the expected result?

@ericdrobinson

This comment has been minimized.

ericdrobinson commented Nov 2, 2015

Yes and no. Yes in that they are uniformly sized. No in that the result doesn't match expectations given the documentation:

Specify whether particles' size will get smaller with the distance. Default is true.

I guess I have two expectations:

  1. In general, when I draw default points using an orthogonal camera at size 1, they should end up rendering as uniform pixels.
  2. Given the documentation as written, my expectation was that the points would start at size 1 and get smaller with distance.

In my case, I was rendering points in a line based on some data (like a line graph) when I came across this. They ended up filling the viewport and it took a while to figure out that the sizeAttenuation setting was at fault.

I understand the purpose of the feature on a perspective camera but it feels like it makes less sense on an orthographic one. As I understand it, the purpose of that setting is to make Points feel like they make more sense in Perspective views by faking the foreshortening. It doesn't really make sense for orthographic.

If this sticks around for Orthographic I'd like to know what to expect, I guess. What are the sizes going to look like at different distances? I.e. where is the midpoint where the drawn size is 1:1 with the size setting? I tried playing with depth in the example somewhat and the points disappear beyond the far clipping plane of the camera before they even approach the size of a single pixel.

But maybe I just need to study up more on my 3D math ;)

@WestLangley

This comment has been minimized.

Collaborator

WestLangley commented Nov 2, 2015

I understand the purpose of the feature on a perspective camera but it feels like it makes less sense on an orthographic one.

Correct. I do not see how it makes sense to set sizeAttenuation = true when using an orthographic camera.

@mrdoob

This comment has been minimized.

Owner

mrdoob commented Nov 2, 2015

We should just ignore the property when using that type of camera?

@WestLangley

This comment has been minimized.

Collaborator

WestLangley commented Nov 2, 2015

Yes, if possible. If not, then perhaps a comment in the docs is the best we can do.

@ericdrobinson

This comment has been minimized.

ericdrobinson commented Nov 2, 2015

That sounds like it would work well. It would certainly reduce surprises/confusion given that the purpose of the sizeAttenuation property is to simulate perspective, as I understand it.

@mrdoob

This comment has been minimized.

Owner

mrdoob commented Nov 2, 2015

Just checked the code and, at the moment ignoring the property is not easy, so we'll have to add a note in the docs.

@ericdrobinson

This comment has been minimized.

ericdrobinson commented Nov 2, 2015

Would it be possible to switch the default to false? I mean a point is a point is a point. Personally, I would expect points to render as pixels unless I changed their size. ThesizeAttenuation option feels like a helper in the case that you want your points to emulate perspective.

What do lines do? Their width doesn't dynamically change based on distance, right? Even in perspective cameras?

@WestLangley

This comment has been minimized.

Collaborator

WestLangley commented Nov 2, 2015

Just checked the code and, at the moment ignoring the property is not easy

That's what I figured...

@looeee

This comment has been minimized.

Collaborator

looeee commented Dec 15, 2016

Updated the fiddle to use R83:
http://jsfiddle.net/f2pwmf7w/8/

It now gives quite a different result (looks like all points are the same size) - does this note still need to be added to the docs, or has something changed in the meantime?

@ericdrobinson

This comment has been minimized.

ericdrobinson commented Dec 15, 2016

It now gives quite a different result (looks like all points are the same size) - does this note still need to be added to the docs, or has something changed in the meantime?

It is still somewhat surprising that "points" do not have the sizeAttenuation parameter set to false by default. As I mentioned before, lines do not attenuate size, right? Why are points (also basic primitives) given this "special feature"?

At the very least, there does appear to be some math that determines the scaling based on the distance to the camera. There is currently no way to get a decent expectation of what's going to happen when you place a point at a specific distance without some kind of trial and error (especially since size attenuation in an orthographic camera is all fakery). Could something at the very least be done there?

@looeee

This comment has been minimized.

Collaborator

looeee commented Dec 15, 2016

@ericdrobinson fair enough - that should probably be raised as a separate issue though. I think your original issue has been fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment