"clipka" <nomail@nomail> wrote:
> 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
> 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.

A good idea.
But I think you're making the request to yourself! :-D
(Because it seems that you have already in mind where *to put your hands in the
source-code*).
Thanks,

--
Carlo

Post a reply to this message