Clipping behaviour

[paulmelis]

I started to check out the per-Group clipping geometry option, looks nice and usable. Questions/remarks:

1. I assume the clipping geometry set on a Group is in the group's local coordinate system and therefore will transform along with any transform set on the Instance using the Group? And since there's no option to set clipping geometry on an Instance the only way to define clipping geometry in world-space (e.g. clip all instances in the scene with the same plane) is to compute the necessary inverse transform, i.e. world-to-instance-local, and set that on each Group?

2. The docs on Groups say

Any supported geometry can be used for clipping. The only requirement is that it has to distinctly partition space into clipping and non-clipping one. These include: spheres, boxes, infinite planes, ...

but also

Use of clipping geometry that is not closed (or infinite) will result in rendering artifacts

The latter seems both a bit contradictory to the earlier part that e.g. infinite planes can be used. Plus, you won't get rendering artifacts per se, but only in certain cases?

[paulmelis]

In a scene with lots of clipped instances I'm seeing some behaviour I can't explain, with geometry seemingly getting clipped when it shouldn't. Here's a small reproduction, after endless attempts to get the original code to behave:

• A sphere Geometry, containing a single sphere, wrapped in a GeometricModel
• Several instances of this GeometricModel, each clipped differently. The clipping plane per Group is oriented to simulate a single global clipping plane.

See t_clip.cpp.gz for sources based on ospTutorial.cpp. This is with 2.7.0 (binary release), btw.

The code contains a list of 4 spheres, 3 of which are enabled, 1 commented out. This correctly produces this image:

If I remove the comment on the fourth sphere in the list, the result unexpectedly only shows that fourth sphere:

Why are the other 3 spheres clipped in this case? Isn't clipping influence limited to the Group on which the clipping geometry is set? Or is this caused by sharing the Geometry/GeometricModel among the instances (which would be really disappointing)?

Edit: just tested the latter, using a separate Geometry + GeometricModel per sphere instance does not solve the issue.

[paulmelis]

Ah wait, I'm using clipping planes here, which apparently cause these artifacts?

[paulmelis]

Okay, I guess I wasn't expecting infinite clipping planes to cause so much rendering issues. I don't remember such limitations with CSG shapes using infinite planes in other rendering packages, but I guess the lack of a decent bound is what's making it hard to handle them robustly and fast?

After testing with a bounded closed shape (a cube in this case) I do notice something odd, which looks like a genuine bug. Here's a similar scene with 4 sphere geometries, and a clipping cube that cuts away part of the X range. If I apply the inverse of each sphere's transform to the clipping geometry's vertices to set a per-sphere clipping mesh the image is as expected, as it simulates a single global clipping cube:

But if I merely set the same untransformed mesh as clippingGeometry on each sphere there's spheres that get clipped by another sphere's clipping geometry, which should not happen I believe:

Note that I'm not sharing vertex arrays, Data instances, etc, it's all created per sphere. With --osp:debug each instance is also reported to only have a single clipping geometry.

Test code: t_clip2.cpp.gz

[johguenther]

Some clarifications (I'll incorporate those into the documentation as well):

• clipping is not restricted per group but global; clipping geometries are only in the group to be able to instance/transform them
  • that's why the last 4 spheres (previous post) are all clipped (and I think also the first 3 spheres are clipped by the plane of the 4th one in the first post)
  • see also #467; local clipping (limited to the own group) will be even more complex to implement (and we need to also think about usage, how to differentiate between local and global clipping at the API)
  • so for global clipping in world-space just put the plane / clipping geometry in a single group which is instanced with the identity transform
• planes are fine for clipping: although they are not closed they are infinite, i.e. they clip a half-space (we have some special internal handling for planes)

[paulmelis]

Okay, that is a bit of a bummer that clipping geometry only operates globally. There's only so much you can do with layered rendering and compositing. For example, shadows cast from geometry in one layer onto another isn't possible, plus it's easy to get compositing artifacts at edges.

[johguenther]

If objects do not overlap too much, then another workaround (alternative to compositing) could be to use smaller clipping geometries, e.g. (like you tried) using boxes instead of infinite planes, to spatially limit the clipping. Nevertheless, I'll add a feature request ticket.