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.

If you're interested in seeing sample images and a brief explanation of how
it works (how else can you offer optimization suggestions?) please follow
this rather obtuse link:

http://www.angelfire.com/weird2/gonk/povray/TwilightPOV/TW.html

Thanks!
- Jeff M. Thomas
jef### [at] twilightfaircom

Post a reply to this message

This is cool and could be very helpful. (The CSG isosurface include file
does the same thing, but requires using a different syntax to create objects
with.)

Perhaps you can easily tell which direction the closest surface is in for
some primitives by using known facts about them. Spheres and cylinders, for
example, should be easy to do this for.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in message
news:3da37703$1@news.povray.org...
> This is cool and could be very helpful. (The CSG isosurface include file
> does the same thing, but requires using a different syntax to create
objects
> with.)

What CSG isosurface include? I didn't know there was one. Ack.

> Perhaps you can easily tell which direction the closest surface is in for
> some primitives by using known facts about them. Spheres and cylinders,
for
> example, should be easy to do this for.

True, and I'd thought about that. But I like to avoid special casing for
object
types or dissecting CSGs if at all possible. If I can keep it coded to the
genral
case it should work for all object types now and into the future.

Thanks!
- Jeff
jef### [at] twilightfaircom

Post a reply to this message

> What CSG isosurface include? I didn't know there was one. Ack.

http://www-public.tu-bs.de:8080/~y0013390/pov/ic/

A built in solution would, however, be much more helpful.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Jeff M. Thomas <zaz### [at] yahoocom> wrote:
> 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.

  I don't understand how this can work in a general case (ie. with any
object and any CSG combination of objects) without some efficient
proximity function...
  Could you explain a bit more?

-- 
#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 -

I really like the images on your site.  I've thought about programming
something like this for a while, and what I finally landed on was this :

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.

To implement this method, you could declare an isosurface function as an
extra, specialized kind of Texture in the OBJECT_FIELDS definition, and
you could just modify All_Object_Intersections to look at this field and
trace the ray forward or backward after calculating the ordinary
intersection.

Is any of this useful?  I'm not sure, cause I haven't tried to implement
any of it yet...


- Ben Birdsey

Post a reply to this message

>   I don't understand how this can work in a general case (ie. with any
> object and any CSG combination of objects) without some efficient
> proximity function...
>   Could you explain a bit more?
>

Well, I think the real proximity function is in the isosurface code which
I've left essentially unchanged. The Find Root functions have the onerous
task of locating the actual isosurface surface, as it were.

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

Also I can't claim to have tested every possible case, just some relatively
complex CSGs with other object types. But since the code relies mostly on
the Intersection method I believe it should work with most general cases, if
not all.

Hope made sense,
- Jeff
jef### [at] twilightfaircom

Post a reply to this message

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