It seems to me that POV still needs a good solution for objects that should, in
theory, touch each other. Like, for example, a glass filled with wine.


We need to model...

(1) the glass, with a certain IOR, a certain reflectivity when interfacing with
air, maybe interior effects like fading, etc.;

(2) the wine, with similar issues, but different values; and

(3) the interface between glass and wine.

(1) and (2) should be no big deal for an experienced POVer, but it seems to me
that the ideal solution to address (3) still has to be found (which gives rise
to the assumption that it would require a change to the POV code).

In practice, what you get is either...

(a) coincident surface artifacts, if you try to make the objects really touch;

(b) unrealistically strong reflections, if you try to make the wine a bit
smaller or larger than the cavity to be filled, due to either an "air gap" or
an "overlap" forming a pair of interfaces instead of a single one, both which
will cause reflections, and even interreflections between the two;

(c) broken interior effects, if you try to suppress one of the interfaces by
using "clipped_by".


I therefore propose the following two alternative mechanisms, both of which I
expect to provide a really sound solution to this issue, and be reasonably
simple to implement:


(A) Overlap Priority

Each object is assigned a priority level for the sake of overlapping with other
objects, defaulting to Zero.

If a ray is still inside object A and enters an object B with lower overlap
priority, the ray will not be affected in any way, except that B will be added
to the "inside stack", so that when the ray leaves A while still inside B, the
tracing algorithm will compute A->B interface effects.

Conversely, if a ray is inside object B and enters object A, B->A interface
effects will be computed, but upon leaving object B while still inside A,
object B will only be removed from the "inside stack", without otherwise
affecting the ray.

If a ray is inside object A and enters an object A' with same overlap priority,
behavior will remain as it is now.

With this mechanism, the "correct" way to model a glass of wine would be to
increase the wine a bit in size, and flag it as "overlap_priority -1" (other
values might be used to create a hierarchy of priorities; the higher the value,
the higher the priority; positive values could be used as well).

"Air" would be considered as having an infinitely low priority.

(Note that this approach would open up an alternative way of creating CSG
objects using only scene-level primitives, which I imagine might increase
performance in certain situations.)

As this approach relies on objects overlapping to create the desired effects, I
propose the following complementary mechanism:

When checking intersection points for the nearest intersection, objects with a
lower overlap priority than the current medium get a "bonus" (i.e. are
considered closer), while those with a higher overlap priority get a "penalty"
(i.e. are considered further away), by a distance slightly more than (maybe
twice) the minimum intersection distance.

This way, to stick with the wine glass example, both the wine and the cavity to
be filled can be modeled to have exactly the same shape, while from the trace
algorithm's point of view they will seem to overlap enough to not suffer from
coincident surface issues.

As a result, the wine could be created as having exactly the same shape as the
cavity to be filled, and would just have to be flagged as "overlap_priority
-1", to get the desired effects.


(B) Coincident Surface Recognition:

When checking intersection points for the nearest intersection, not only the
nearest intersection is determined, but both the nearest "leaving" and
"entering" intersections.

If the distance between these two intersections is smaller than the minimum
intersection distance, this shall be considered as the ray leaving object A
while at the same time entering object B, i.e. object A is removed from the
"inside stack", object B is added to the "inside stack", and effects are
computed for an A->B interface traversal.

With this mechanism in place, the wine would just have to be modeled in exactly
the same shape as the cavity (possibly by differencing away one from the
other); the algorithm would be robust enough to deal with possible rounding
issues; no additional hints would be required in the scene file.

Post a reply to this message