"ABX" <abx### [at] abxartpl> wrote in message
news:qgj7quotfhqgv5faomtvprd421eqdme434@4ax.com...
> On Tue, 8 Oct 2002 23:19:31 -0700, "Jeff M. Thomas" <zaz### [at] yahoocom>
wrote:
> > Well, I think the real proximity function is in the isosurface code
which
> > I've left essentially unchanged.
>
> There is some proximity function in sources ???? I can't find such a
keyword
> in listing. I mean something like famouse proximity pattern ?
>

No there isn't that I know of either. I was referring to the isosurface code
which focuses in on the surface of the object using recursive subdivision.
It doesn't really have any proximity code, it relies on the user defined
function for proximity information. I wasn't thinking too clearly last
night, sorry :}.

- Jeff
jef### [at] twilightfaircom

Post a reply to this message

> It would be useful to find the intersection with the object in the
> ordinary way and then trace backward (or forward) from the intersection
> point until the ray hits the "closest isosurface".  I don't know if that
> is what you've done here, but it looks like it is similar.

Yes, this very much like what I was thinking when I started out. One of the
problems with it though is with rays that get close to the surface, but
miss. If you're disturbing the surface much there is a chance that the ray
should have actually hit something (as with the crackle distortion sample
image). Unless you're calculating proximities along the length of the ray,
it won't know it was supposed to have hit anything.

Does this make sense? I can probably explain it better.

- Jeff
jef### [at] twilightfaircom

Post a reply to this message

One of the possibilities I've been mulling over is converting the general
case to a specific one at parse time. You could, for example, make a voxel
version of it.

There would naturally be a dramatic loss in precision but the specific case
would only be used for quickly calculating further distances. When a point
in question is found to be close to a surface the code would switch to the
slower general case, but at least with the advantage of knowing in which
general direction the near surface can be found.

- Jeff
jef### [at] mmlivecom

Post a reply to this message

Christoph Hormann wrote:
> 
> As Slime mentioned you should have a look at the IsoCSG library.  Your
> method seems to use about the same method as the proximity pattern in
> megapov and therefore probably will be quite slow.  You can try to
> optimize things but no matter what you try the calculations will almost
> certainly never be as fast as with the mathematically exact proximity
> function (which of course only exists for very few objects).

That's the point. IMO the existence of the IsoCSG library doesn't make 
this patch superfluous: If your object is CSG of primitive objects, use 
the IsoCSG. If it contains fancy objects that can't be modeled by a
simple function, use this patch.

Thomas

Post a reply to this message

On Wed, 09 Oct 2002 08:42:54 +0200, ABX wrote:
> You should look sources of good old proximity pattern available in MegaPOV.

This won't be useful, as it used the same "fire rays until satisfied" method.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

On 16 Oct 2002 10:00:27 -0400, Ron Parker <ron### [at] povrayorg> wrote:

>On Wed, 09 Oct 2002 08:42:54 +0200, ABX wrote:
> > You should look sources of good old proximity pattern available in MegaPOV.
>
> This won't be useful, as it used the same "fire rays until satisfied" method.

That's exactly why I pointed it. Becouse used the same method but was (nearly)
well parametrized and already discussed many times wchich could help.

ABX

Post a reply to this message

In article <sesqqu88iu4okj6gq6enp8jgf8dsk7ai7i@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> That's exactly why I pointed it. Becouse used the same method but was 
> (nearly)
> well parametrized and already discussed many times wchich could help.

It was also very slow...barely useable on my G3, though probably much 
more practical on current machines. I never did finish my work on 
per-object proximity methods or adaptive and non-random sampling...I 
never finished my portal pigment either, maybe I'll get back on those.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message