clipka wrote:
> stbenge schrieb:
>> clipka wrote:
>>> (BTW, someone's asking in povray.newusers for advice on your fastprox 
>>> macros... and speaking of them, do you have them for download anywhere?)
>>
>> There is a pattern which is much easier to use than fastprox. I posted 
>> it also to p.t.s-f. It's actually much more accurate than the "fast" 
>> prox macros, as evidenced by the attached image. It also produces 
>> outside edge data.
> 
> It also seems to give much cleaner results than my reusing radiosity data.

In a way, this is true. But my methods wreak havoc upon memory and CPU 
usage.

> A drawback I see is that it gives only a falloff to a certain distance 
> from edges and crevices, then stays level, right?

Right. A disruption in space by an object continues only to a finite, 
specified distance from the object by way of 3D averaging of point data. 
Objects must be predeclared which is a big drawback.

> At the same time there are benefits of course:
> 
> - It can be used to model an object with dirty crevices and worn-out 
> edges that has recently been transported to someplace else; my approach 
> can only detect proximity to /any/ geometry, and cannot easily be 
> limited to a subset of the scene geometry (let alone some geometry that 
> isn't even in the scene).

Is this good or bad for your method? It seems that having access to 
~any~ scene geometry is good. My method is restrictive and costly for 
high numbers of objects.

> - It is a true 3D pattern; my approach is only suitable for object 
> surfaces, and is therefore unsuited for use in media density, or in a 
> pattern function (which in turn could probably be used to generate a 
> smoothed version of the object using isosurfaces - what a powerful tool 
> for beveling that would be!).

That's the best part I suppose, it's 3D. But I've used it for 
isosurfaces and media, and let me say, the results are a mixed bag. Good 
surface exploration, sure, but bad, bad render times.

> Maybe it would really be a good thing to go for a voxel-based approach, 
> in hope to combine the quality of your approach with the speed gained 
> through caching data (you wouldn't want /all/ those N inside-tests to be 
> executed for /each/ iteration step of /every/ ray-object intersection 
> test to be performed on an isosurface... >_<)

You're very right, I wouldn't and I don't. What looks good as a pigment 
becomes very ugly when used as an isosurface. Actually, it looks great 
when you overload pigment_pattern lists with 256*256 pattern samples, 
keep the accuracy low and the max grad high. Not that I've done it, not 
that I want to, not that I need to learn patience some time ;)

Post a reply to this message