"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

"Carlo C." <nomail@nomail> wrote:
> A good idea.
> But I think you're making the request to yourself! :-D

Yeah, I was already worried that I might be :)

Still, even *if* I should end up implementing it myself (duh - once again, hope
is the last to die >_<), comments may be helpful to decide which of the two
approaches to pursue.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Carlo C." <nomail@nomail> wrote:
> > A good idea.
> > But I think you're making the request to yourself! :-D
>
> Yeah, I was already worried that I might be :)
>
> Still, even *if* I should end up implementing it myself (duh - once again, hope
> is the last to die >_<), comments may be helpful to decide which of the two
> approaches to pursue.

Sure!

From my point of view (always Beginner!), *(A) Overlap Priority* sounds good.
A kind of "z-index" (inappropriate comparison) to delete coincident surface
artifacts, unrealistically strong reflections, broken interior effects...
Sounds good!

And...

>(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.)

....This makes it even more attractive!
:-)

--
Carlo

Post a reply to this message

In terms of *coding*, solution B seems to be the most *elegant* and 
straightforward. I suppose it would tackle automatically all possible cases. 
Solution A though, leaves some latitude to the user for tweaking things one 
way or another... Overall, I prefer solution B.

Like Carlo suggested, it seems that you are well-provided for doing this :-)

[I have some - and very ancient (Fortran 77) - experience in coding, so I 
always look at this with interest.]

Thomas

Post a reply to this message

On Mon, 16 Mar 2009 22:13:20 EDT, "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.

I would prefer solution B as this would involve no changes to existing scenes.
Also for solution A to work with a modeller the modeller would need to be
changed.
If I understand your proposed solutions, correctly.

BTW a volunteer is worth ten pressed men. Well done that man :)
-- 

Regards
     Stephen

Post a reply to this message

Thomas de Groot wrote:
> In terms of *coding*, solution B seems to be the most *elegant* and 
> straightforward. I suppose it would tackle automatically all possible cases. 
> Solution A though, leaves some latitude to the user for tweaking things one 
> way or another... Overall, I prefer solution B.
> 
> Like Carlo suggested, it seems that you are well-provided for doing this :-)
> 
> [I have some - and very ancient (Fortran 77) - experience in coding, so I 
> always look at this with interest.]
> 
> Thomas 
> 
> 
I would agree with B, for two main reasons: 1. It seems like a more 
realistic model, 2. It requires no change in existing SDL code (and 
existing coding habits of people)

One potential issue in using this method is that many people tend to 
define their pov 'base unit' differently, some with the whole scene 
bounded by box{-10,10} while others could have a wine glass itself 200 
units tall.
I propose that when the epsilon value (min intersection distance) is 
set, it could be determined in a somewhat variable sense:
1) Set it to the standard 1e-6 by default and let the user change it in 
global_settings{}, call it 'coincidence_distance' or something. I think 
this would be best.
or
2) Set it to be a function of some aspect of the scene during parsing, 
be it the largest finite object, the distance between the camera 
location and look_at, sky sphere radius, whatever. This might not work 
because you'd want to use the value before the scene is fully parsed.

cshake

Post a reply to this message

CShake <cshake+pov### [at] gmailcom> wrote:
> One potential issue in using this method is that many people tend to
> define their pov 'base unit' differently, some with the whole scene
> bounded by box{-10,10} while others could have a wine glass itself 200
> units tall.
> I propose that when the epsilon value (min intersection distance) is
> set, it could be determined in a somewhat variable sense:
> 1) Set it to the standard 1e-6 by default and let the user change it in
> global_settings{}, call it 'coincidence_distance' or something. I think
> this would be best.

As a matter of fact, there already is a constant with similar use in POV: The
MIN_ISECT_DEPTH (currently hard-coded to 1e-4) is the minimum distance from a
ray's origin (camera or an earlier intersection) to accept an intersection; any
intersection closer than that is currently ignored, probably mainly to avoid
"re-intersecting" at the ray's origin.

I was already thinking about making some of POVs internal key distances
accessible to the user. However, there is some risk of breaking the established
balance between those constants (and possibly even some more hidden in remote
parts of the code).

> 2) Set it to be a function of some aspect of the scene during parsing,
> be it the largest finite object, the distance between the camera
> location and look_at, sky sphere radius, whatever. This might not work
> because you'd want to use the value before the scene is fully parsed.

Actually... no, that would not be a problem. With the approach I have in mind,
the "extension" of the wine (I just stick to that example) will not be done
during scene parsing, but during tracing.

But I guess attempting to auto-tune those key distances would be faced with too
many unknowns. Distance between camera and look_at seems like the best
reference value to me for such a purpose (or focal plane if focal blur is used
in the shot), but still someone might e.g. have chosen look_at just because the
direction was ok, without paying attention to its distance. Or a shot may have
look_at point somewhere in the distance, but highly detailed stuff visible in
the foreground.

Post a reply to this message

clipka wrote:
> As a matter of fact, there already is a constant with similar use in POV: The
> MIN_ISECT_DEPTH (currently hard-coded to 1e-4) is the minimum distance from a
> ray's origin (camera or an earlier intersection) to accept an intersection; any
> intersection closer than that is currently ignored, probably mainly to avoid
> "re-intersecting" at the ray's origin.
Ah, that's why I was getting what I thought was a clipping issue with a 
very small distance between two image_map (filtering) surfaces (1e-5 or 
so, since it was a distance in less than mm when my base unit was in 
ft). I sorta figured that was happening when it disappeared with a 
change in scale.

> But I guess attempting to auto-tune those key distances would be faced with too
> many unknowns. Distance between camera and look_at seems like the best
> reference value to me for such a purpose (or focal plane if focal blur is used
> in the shot), but still someone might e.g. have chosen look_at just because the
> direction was ok, without paying attention to its distance. Or a shot may have
> look_at point somewhere in the distance, but highly detailed stuff visible in
> the foreground.
Exactly, it has too many potential problems to pick any single method. I 
know I've made my camera look_at by normalizing a vector of the right 
direction and adding it to the location, though it is infrequent. I've 
almost never used a sky_sphere, since I either use a box to contain an 
interior scene or a real sphere when doing HDRI lighting (for brightness 
control). Focal blur is usually not turned on until final tests and the 
'production' render, so any initial shape testing would not trigger it.
Using a randomly large object just to have a nearly infinite backdrop 
yet still do something to it with CSG happens too, so the largest object 
method I threw out there has its own set of problems. Even more so when 
someone uses a big difference CSG and doesn't manually set a bounding box.

Having a loop that runs through all the possible intersections in the 
scene and then maybe finding the number of 'intersections' (if only 
between objects that have any transmit or filter, maybe even just with 
defined ior) and the amount of overlap for each, then setting the value 
to catch some percentage of them would be a bear to code. It could also 
slow down parsing significantly.

Though having intersection detection code could make some things easier 
  for the user, like "drop all these spheres and stuff until they touch 
the floor" ... yeah, that's not what povray is for anyway.

Post a reply to this message

I'd vote for B, which seems rather elegant. The overlap priority
sounds a bit like a cumbersome adhoc parameter. I also second the
suggestion to make the epsilon configurable. In particular, it
should be possible to set it to 0 for backward compatibility
with existing wine glasses ;)

Post a reply to this message

CShake nous illumina en ce 2009-03-19 00:55 -->
> clipka wrote:
>> As a matter of fact, there already is a constant with similar use in 
>> POV: The
>> MIN_ISECT_DEPTH (currently hard-coded to 1e-4) is the minimum distance 
>> from a
>> ray's origin (camera or an earlier intersection) to accept an 
>> intersection; any
>> intersection closer than that is currently ignored, probably mainly to 
>> avoid
>> "re-intersecting" at the ray's origin.
> Ah, that's why I was getting what I thought was a clipping issue with a 
> very small distance between two image_map (filtering) surfaces (1e-5 or 
> so, since it was a distance in less than mm when my base unit was in 
> ft). I sorta figured that was happening when it disappeared with a 
> change in scale.
> 
>> But I guess attempting to auto-tune those key distances would be faced 
>> with too
>> many unknowns. Distance between camera and look_at seems like the best
>> reference value to me for such a purpose (or focal plane if focal blur 
>> is used
>> in the shot), but still someone might e.g. have chosen look_at just 
>> because the
>> direction was ok, without paying attention to its distance. Or a shot 
>> may have
>> look_at point somewhere in the distance, but highly detailed stuff 
>> visible in
>> the foreground.
> Exactly, it has too many potential problems to pick any single method. I 
> know I've made my camera look_at by normalizing a vector of the right 
> direction and adding it to the location, though it is infrequent. I've 
> almost never used a sky_sphere, since I either use a box to contain an 
> interior scene or a real sphere when doing HDRI lighting (for brightness 
> control). Focal blur is usually not turned on until final tests and the 
> 'production' render, so any initial shape testing would not trigger it.
> Using a randomly large object just to have a nearly infinite backdrop 
> yet still do something to it with CSG happens too, so the largest object 
> method I threw out there has its own set of problems. Even more so when 
> someone uses a big difference CSG and doesn't manually set a bounding box.
> 
> Having a loop that runs through all the possible intersections in the 
> scene and then maybe finding the number of 'intersections' (if only 
> between objects that have any transmit or filter, maybe even just with 
> defined ior) and the amount of overlap for each, then setting the value 
> to catch some percentage of them would be a bear to code. It could also 
> slow down parsing significantly.
> 
> Though having intersection detection code could make some things easier 
>  for the user, like "drop all these spheres and stuff until they touch 
> the floor" ... yeah, that's not what povray is for anyway.

And, there is the case when you have the camera with a look_at point a unit in 
front of it that get rotated and translated to it's final orientation and 
location. That location been maybe 1000 units from the main objects of the scene.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when your 18 year-old daughter asks if 
she can marry one of the POV Team, and you give her your complete blessing.
Taps a.k.a. Tapio Vocadlo

Post a reply to this message