Robert McGregor's recent comments on using AO for grime layers tweaked me
thinking about how to achieve an object pattern that could do this.  I was
thinking along the lines that we have slope and aoi patterns for example that
depend upon the object surface itself, would it be possible to have a pattern
that basically for any given surface point, shoots a trace ray or the like,
normal out from the surface and returns the value or a function based on
distance to self-intersection, likely an inverse function ranging from no
intersection=0 (1/inf=0) to immediate=1 (0/1=0).

Does this sound like something doable without unacceptable increase in render
overhead?

-tgq

Post a reply to this message

On 3/9/2011 9:34 AM, Trevor G Quayle wrote:
> Robert McGregor's recent comments on using AO for grime layers tweaked me
> thinking about how to achieve an object pattern that could do this.  I was
> thinking along the lines that we have slope and aoi patterns for example that
> depend upon the object surface itself, would it be possible to have a pattern
> that basically for any given surface point, shoots a trace ray or the like,
> normal out from the surface and returns the value or a function based on
> distance to self-intersection, likely an inverse function ranging from no
> intersection=0 (1/inf=0) to immediate=1 (0/1=0).

IME, the best (not to mention the most accessible) way to do this is to 
use a proximity pattern, which is basically just an object pigment 
blurred in 3D space. The advantage of using proximity patterns is that 
you can obtain *outside*edge* data as well as inside edge data.

Any other AO-like ray tracing/casting method would require some new 
routines to be added into POV's rendering core... but I could be wrong. 
(anything can be done if you're willing to wait through a long render)

Look for anything related to "proximity patterns." It might not be the 
most efficient method for adding "crevice grime" to objects, but you can 
always bake the effect into meshes using POV-Ray 3.7b.

Good luck!

Sam

Post a reply to this message

Am 11.03.2011 00:50, schrieb stbenge:

> IME, the best (not to mention the most accessible) way to do this is to
> use a proximity pattern, which is basically just an object pigment
> blurred in 3D space. The advantage of using proximity patterns is that
> you can obtain *outside*edge* data as well as inside edge data.
>
> Any other AO-like ray tracing/casting method would require some new
> routines to be added into POV's rendering core... but I could be wrong.
> (anything can be done if you're willing to wait through a long render)

Trevor's idea was actually the path I followed with my earlier attempt 
at a proximity pattern. Code-wise it was not much of a change, as 
radiosity already has everything that's needed, even including some 
optimization. However, it could not do outside edges, and the approach 
also didn't allow for choosing only a subset of objects to affect the 
pattern - it would always use the complete scene.

My next attempt would probably be based on the "blurred object" 
approach; syntax-wise it might even be a simple extension to the object 
pattern. But don't hold your breath.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 11.03.2011 00:50, schrieb stbenge:
>
> > IME, the best (not to mention the most accessible) way to do this is to
> > use a proximity pattern, which is basically just an object pigment
> > blurred in 3D space. The advantage of using proximity patterns is that
> > you can obtain *outside*edge* data as well as inside edge data.
> >
> > Any other AO-like ray tracing/casting method would require some new
> > routines to be added into POV's rendering core... but I could be wrong.
> > (anything can be done if you're willing to wait through a long render)
>
> Trevor's idea was actually the path I followed with my earlier attempt
> at a proximity pattern. Code-wise it was not much of a change, as
> radiosity already has everything that's needed, even including some
> optimization. However, it could not do outside edges, and the approach
> also didn't allow for choosing only a subset of objects to affect the
> pattern - it would always use the complete scene.

My thought was that it could be implemented as a pattern type where it is object
based.  One slight issue with my idea is that if you only use the direct normal,
it would fail at the very valley of a crevice as the normal ray would come
straight back out without intersection.  This could maybe be solved by not using
the normal, but perhaps an average of a few normals some angle from
perpendicular (eg 45deg) that would intersect.

I don;t see the issue with outside edges, as what I think of as grime tends to
be only on interior edges or crevices; that is surface areas that are not
exposed.

I would look at trying to code this myself, but I'm not really up to snuff yet
with the internal POV coding.  Maybe in the future if I have time, I may look at
it and a few other things, but for now just throwing it out there as ideas for
those that are playing at the code.  Would be nice to see if you can come up
with something.

-tgq

Post a reply to this message

Am 12.03.2011 14:36, schrieb Trevor G Quayle:

> I don;t see the issue with outside edges, as what I think of as grime tends to
> be only on interior edges or crevices; that is surface areas that are not
> exposed.

While crevices might accumulate grime, prominent edges might show the 
effects of handling; e.g. an otherwise dull and oxidized metal object 
might be polished at prominent edges (think of a brass statue). A 
proximity pattern that could account for that as well would be a good thing.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 12.03.2011 14:36, schrieb Trevor G Quayle:
>
> > I don;t see the issue with outside edges, as what I think of as grime tends to
> > be only on interior edges or crevices; that is surface areas that are not
> > exposed.
>
> While crevices might accumulate grime, prominent edges might show the
> effects of handling; e.g. an otherwise dull and oxidized metal object
> might be polished at prominent edges (think of a brass statue). A
> proximity pattern that could account for that as well would be a good thing.

I guess that's true.  Maybe there's a need for two pattern types then, or at
least the ability to choose either/or.

-tgq

Post a reply to this message

On 3/12/2011 10:48 AM, Trevor G Quayle wrote:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 12.03.2011 14:36, schrieb Trevor G Quayle:
>>
>>> I don;t see the issue with outside edges, as what I think of as grime tends to
>>> be only on interior edges or crevices; that is surface areas that are not
>>> exposed.
>>
>> While crevices might accumulate grime, prominent edges might show the
>> effects of handling; e.g. an otherwise dull and oxidized metal object
>> might be polished at prominent edges (think of a brass statue). A
>> proximity pattern that could account for that as well would be a good thing.
>
> I guess that's true.  Maybe there's a need for two pattern types then, or at
> least the ability to choose either/or.

By default a proximity pattern is both combined, so one only has to 
adjust the color_map to choose between one or the other. This choosing 
ability could be in the form of two macros in an #include file somewhere...

Sam

Post a reply to this message

On 3/11/2011 11:54 PM, clipka wrote:
> Am 11.03.2011 00:50, schrieb stbenge:
>
>> IME, the best (not to mention the most accessible) way to do this is to
>> use a proximity pattern, which is basically just an object pigment
>> blurred in 3D space. The advantage of using proximity patterns is that
>> you can obtain *outside*edge* data as well as inside edge data.
>>
>> Any other AO-like ray tracing/casting method would require some new
>> routines to be added into POV's rendering core... but I could be wrong.
>> (anything can be done if you're willing to wait through a long render)
>
> Trevor's idea was actually the path I followed with my earlier attempt
> at a proximity pattern. Code-wise it was not much of a change, as
> radiosity already has everything that's needed, even including some
> optimization. However, it could not do outside edges, and the approach
> also didn't allow for choosing only a subset of objects to affect the
> pattern - it would always use the complete scene.

Wasn't there also an issue with how radiosity precaches samples on a 
screen-level basis, which was in turn causing the prox pattern to give 
different results depending on the camera location/screen size/etc.?

> My next attempt would probably be based on the "blurred object"
> approach; syntax-wise it might even be a simple extension to the object
> pattern. But don't hold your breath.

I won't, but I am wondering how you plan to approach the problem...

Sam

Post a reply to this message

Am 12.03.2011 20:13, schrieb stbenge:

> Wasn't there also an issue with how radiosity precaches samples on a
> screen-level basis, which was in turn causing the prox pattern to give
> different results depending on the camera location/screen size/etc.?

No.

>> My next attempt would probably be based on the "blurred object"
>> approach; syntax-wise it might even be a simple extension to the object
>> pattern. But don't hold your breath.
>
> I won't, but I am wondering how you plan to approach the problem...

Essentially the same as those macros used, by jittering an object 
pattern. Implementing this as an intrinsic feature is likely to allow 
for some performance improvements, such as adaptive sampling of the 
object pattern, and re-using cached samples similar to what's done for 
radiosity.

Post a reply to this message