Pointcloud "setRadius" sets half-radius

[dcoeurjo]

Without any autoscale, one needs to set the (0,0,0) point radius to 0.5 to make it "match" with a centred spherical mesh of radius 1

[nmwsharp]

Hm, I think that this may an "absolute" vs. "relative" values issue. If I set the point radius with pointCloud->setPointRadius(1., false);, it lines up with a unit sphere as expected.

However, just doing pointCloud->setPointRadius(1.); (or dragging the slider in the GUI) sets a relative radius, which might not line up with other in-scene geometry. By chance, loading up a scene containing a unit-sphere mesh leads to a scene length scale of 2.0, which causes relative point radii to be off by a factor of 2.

[dcoeurjo]

mmmmh.. thanks for the link to the doc page, still a bit confused by relative/absolute stuff and the global "lengthScale" state variable.

[nmwsharp]

Actually, I'd like to leave this open as a task to better-document the relative/absolute variables, they're not really clear at all right now.

The direct answer is that almost all values in Polyscope are relative by default. That is, you aren't setting the point radius to e.g. 1.0, you're setting the radius to 1.0 * lengthScale, where lengthScale is automatically computed by Polyscope for the scene. This is useful because it ensures that the same parameters result similar-looking scenes, regardless of whether your data is measured in millimeters or kilometers. Of course, in some situations it's important explicitly set absolute values for consistency, so all setters expose overloads/options which circumvent the lengthScale mechanism and directly set a value. There's currently no way to set absolute values by hand in the GUI.

Most of the time we don't have to think this whole system, because the relative values work out just fine. However, when you need absolute values, it gets confusing. One improvement could be to expose a tooltip in the GUI---perhaps when you hover over a relative slider, you could get a tooltip with a checkbox to change it to absolute. Similarly, explicitly naming the setters setRadiusRelative() and setRadiusAbsolute() might make it more clear what is happening.

More broadly, I think the technical design of the absolute/relative values is reasonable, but I'm not sure how to make it more clear to users.

[dcoeurjo]

That makes sense. Let me describe a bit what I was trying to do: I had a mesh (with apparently has a unitary bbox because the /2.0 worked also for it:)), a point, the distance d of that point to the mesh (physical distance, in millimeters, let's say). point->setRadius(d) did not look good as the default flag is relative for the setter (and from your explanations, I perfectly understand). point->setRadius(d,false) would have been the correct way to do it.

I definitely understand the interest of relative stuff in the engine (for the camera, the object or quantity scalings...). I may be wrong but I don't see many use cases for which the users would like to set/get relative values. As you say, maybe when you have a process parametrized by some params and you would like to use the same params for various meshes but it would only make sense if the process is homogeneous wrt to the input size. The absolute/relative value design is super reasonable, but for my usecases I would have preferred an absolute default value for the flags of the setters which are exposed to the user.

But yes, setRadiusRelative() and setRadiusAbsolute() would make things explicit and would be perfect.

These are tiny details ;) polyscope rocks! 🚀