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 ?

> The object function itself simply uses brute force, shooting out rays until
> it thinks it has a decent distance to return, which at this point simply
> means it has one or more hits. Fortunately as the points get closer to the
> object more rays hit and the results get more accurate. I don't pretend at
> this point that it's optimal or even slightly efficient; frankly I'm rather
> surprised how well it works the way it stands.
>
> That's why I've asked for suggestions on optimizing the method, such as an
> efficient proximity function for the general case :-).

You should look sources of good old proximity pattern available in MegaPOV.
You can check additional parameters there were available to control finding
nearest intersection point. I think it is much better to have such an addition
as pattern. It could be placed in traditional texture with apropriate map.
Be sure you have readed all proximity related threads on this news server.
There were some further suggestions IIRC.

ABX

Post a reply to this message

Jeff M. Thomas <zaz### [at] yahoocom> wrote:
> The object function itself simply uses brute force, shooting out rays until
> it thinks it has a decent distance to return

  I see. That's the slow method (and sometimes inaccurate). :)

  It's basically what the proximity pattern in megapov does.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Jeff M. Thomas" wrote:
> 
> I decided to give the current IRTC round a miss (I'm not good with nature
> settings outside of Bryce) and play around with the POV-Ray code instead.
> 
> My goal was to allow mathmatic surface distortions of non isosurface objects
> (aim low, I always say :). I ended up going the other way around, making an
> object function that takes any object and makes it look like it's defined
> mathematically for use in an isosurface, which you can then distort the
> usual way. An example is thus:
> 
> #declare fn_my_box=
>     function{
>         object{
>             Povray_Logo
>         }
>     }
> 
> The problem is, it's rather slow and I'd like some suggestions on how to
> optimize it.
> 
> [...]

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

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

"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