>



> The docs for superpatch do not give any syntax at all on how to use
> the
> named functions as functions in isosurfaces.
>
> I tried multiple iterations,  using
>     superellipsoid and Superellipsoid
>     <>, [], (),
>
> and couldn't get anything to work even with spheres.
>
> As a general note, it's always helpful to include a working example in
>
> any documentation. From 3.1e and on, too many times the docs simply
> say
> "this goes with that,"  with little clue to syntax.

Post a reply to this message

On Mon, 14 Feb 2000 15:24:56 -0500, Greg M. Johnson wrote:
>> The docs for superpatch do not give any syntax at all on how to use
>> the named functions as functions in isosurfaces.
>>
>> I tried multiple iterations,  using
>>     superellipsoid and Superellipsoid
>>     <>, [], (),
>>
>> and couldn't get anything to work even with spheres.

See the thread in this newsgroup entitled "Superpatch built-in functions"
from 15 July.  Here are the relevant headers for the first article:

From: dav### [at] cwcomnet (David Wilkinson)
Newsgroups: povray.unofficial.patches
Subject: Superpatch built-in functions
Date: Thu, 15 Jul 1999 20:13:22 GMT
Message-ID: <378e3c6d.6326610@news.povray.org>
Xref: news.povray.org povray.unofficial.patches:477

In case you can't look it up (but you should, because it's a useful
thread) here's the syntax that works for me for the sphere function:

isosurface {  function { "Sphere" <1> }  pigment { color red 1}}

>> As a general note, it's always helpful to include a working example in
>> any documentation. From 3.1e and on, too many times the docs simply
>> say "this goes with that,"  with little clue to syntax.

Most of my docs were written by the people who wrote the original docs for
the patches I included, though I tried to make sure the syntax was spelled
out.  This particular case resulted from an oversight in copying R. Suzuki's
original documentation.  I'm no longer maintaining the superpatch, but if
someone wanted to write better docs for various parts of it, I'm sure Nathan 
would gladly accept them.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 14 Feb 2000 16:55:33 -0500, ron### [at] povrayorg (Ron Parker) wrote:

>On Mon, 14 Feb 2000 15:24:56 -0500, Greg M. Johnson wrote:
>>> The docs for superpatch do not give any syntax at all on how to use
>>> the named functions as functions in isosurfaces.

>
>In case you can't look it up (but you should, because it's a useful
>thread) here's the syntax that works for me for the sphere function:
>
>isosurface {  function { "Sphere" <1> }  pigment { color red 1}}
>

You just beat me to the punch Ron :-)

The docs for MegaPov give the correct syntax for the named isosurface functions, but
MegaPov also requires
 contained_by {}
 in the isosurface definition.

e.g.

isosurface {  function  { "rounded_box" <.2> } 
   contained_by { } 
    pigment { Red}
} 

In testing this with MegaPov I found a bug has been added since SuperPatch.
The size of the rounded box is determined by the size of  contained_by !
With no value for contained_by you get a rounded box of unit sides. But; 
contained_by { box {0,4}}
makes the rounded box of sides 4!

Ah well, it just goes to keep us on our toes :-)
----------------------------
dav### [at] cwcomnet
http://www.hamiltonite.mcmail.com
----------------------------

Post a reply to this message

David Wilkinson <dav### [at] cwcomnet> wrote...
> In testing this with MegaPov I found a bug has been added since
SuperPatch.
> The size of the rounded box is determined by the size of  contained_by !
> With no value for contained_by you get a rounded box of unit sides. But;
> contained_by { box {0,4}}
> makes the rounded box of sides 4!

Actually, this is not new to MegaPov.  Let me explain:

Isosurface intersection computation is _always_ bounded.  I don't know how
the intersection is performed, but I do know that it can only happen over a
finite volume using the current implementation(s).

Prior to MegaPov 0.4, this computational boundary was defined using
"bounded_by".  Unfortunately, this caused a conflict with the original
"bounded_by", which has a totally different meaning when applied to any
object other than an isosurface.  And to make things worse, depending on the
order in which you applied the "bounded_by" keyword and the other modifiers
(such as "translate"), you could make it either change the computational
container or change the ray-bound object (the way the original bounded_by
works).

Therefore, we had to change the syntax to remove this conflict.

-Nathan

Post a reply to this message

Thanks for the info, but the docs for sup 3.1e are not complete.
I have mega on another PC and had not looked there, though......

David Wilkinson wrote:

> On 14 Feb 2000 16:55:33 -0500, ron### [at] povrayorg (Ron Parker) wrote:
>
> >On Mon, 14 Feb 2000 15:24:56 -0500, Greg M. Johnson wrote:
> >>> The docs for superpatch do not give any syntax at all on how to use
> >>> the named functions as functions in isosurfaces.
>
> >
> >In case you can't look it up (but you should, because it's a useful
> >thread) here's the syntax that works for me for the sphere function:
> >
> >isosurface {  function { "Sphere" <1> }  pigment { color red 1}}
> >
>
> You just beat me to the punch Ron :-)
>
> The docs for MegaPov give the correct syntax for the named isosurface functions, but
> MegaPov also requires
>  contained_by {}
>  in the isosurface definition.
>
> e.g.
>
> isosurface {  function  { "rounded_box" <.2> }
>    contained_by { }
>     pigment { Red}
> }
>
> In testing this with MegaPov I found a bug has been added since SuperPatch.
> The size of the rounded box is determined by the size of  contained_by !
> With no value for contained_by you get a rounded box of unit sides. But;
> contained_by { box {0,4}}
> makes the rounded box of sides 4!
>
> Ah well, it just goes to keep us on our toes :-)
> ----------------------------
> dav### [at] cwcomnet
> http://www.hamiltonite.mcmail.com
> ----------------------------

Post a reply to this message

On Tue, 15 Feb 2000 07:14:48 -0500, "Greg M. Johnson"
<gre### [at] my-dejanewscom> wrote:

>Thanks for the info, but the docs for sup 3.1e are not complete.
>I have mega on another PC and had not looked there, though......
>
He he he, the docs have never been complete for any POV version that
I've used. That is, if you compare it to some commercial software that
comes with a thick, well written tutorial on how to use the product
and all its features. Of course, we don't have to pay a large price
for POV-Ray, like some of those commercial applicaions with their
thick manuals.   :)

I understand that the programmers are busy enough just writing the
software. I also don't mind "reading between the lines" a little bit,
if it means the developers get to spend more time perfecting the
software. I guess in a perfect world, some talented person would be
appointed the official technical writer for the POV-Team. I'm thinking
of someone who doesn't write any actual code, but spends their time
documenting  what the programmers have done.

Just a thought...

Post a reply to this message

Yes, I know to some degree, I'm an ungrateful whiner.

BUT, there are places where keywords are described with simply the words
"This goes with that."

I just think that with a tiny bit more effort, just one working example of
every concept could be added to the docs.

Glen Berry wrote:

> On Tue, 15 Feb 2000 07:14:48 -0500, "Greg M. Johnson"
> <gre### [at] my-dejanewscom> wrote:
>
> >
> He he he, the docs have never been complete for any POV version that
> I've used. That is, if you compare it to some commercial software that
> comes with a thick, well written tutorial on how to use the product
> and all its features. Of course, we don't have to pay a large price
> for POV-Ray, like some of those commercial applicaions with their
> thick manuals.   :)
>

Post a reply to this message

On Wed, 16 Feb 2000 10:15:10 -0500, Greg M. Johnson wrote:
>BUT, there are places where keywords are described with simply the words
>"This goes with that."

Examples?

>I just think that with a tiny bit more effort, just one working example of
>every concept could be added to the docs.

So stop whining about it and DO IT!  That's how I got to be the superpatch
guy in the first place, I stopped whining about the fact that there were so
many different patches and I did something about it.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Greg M. Johnson wrote:
>> The docs for superpatch do not give any syntax at all on how to use
>> the
>> named functions as functions in isosurfaces.

On 2000/01/27 Y.Tanabe posted two example scene files in this group, 
containing all the functions of i_nfunc and I_algbr.

Message-ID: <388FB2B5.9A9D7483@kh.rim.or.jp>
Message-ID: <3890665D.815A92CE@kh.rim.or.jp>

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

On 16 Feb 2000 10:28:31 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>On Wed, 16 Feb 2000 10:15:10 -0500, Greg M. Johnson wrote:
>>BUT, there are places where keywords are described with simply the words
>>"This goes with that."
>
>Examples?
>
>>I just think that with a tiny bit more effort, just one working example of
>>every concept could be added to the docs.
>
>So stop whining about it and DO IT!  That's how I got to be the superpatch
>guy in the first place, I stopped whining about the fact that there were so
>many different patches and I did something about it.

I can't program well enough to help with that aspect of POV, but
perhaps I could help with the docs a bit - maybe make an unofficial
supplement or tutorial of some sort. I had actually thought of making
a supplement in the past, and now I'd like to give it a try.

Attention Greg: 
Give me some specific examples of topics that you personally feel are
in need of  elaboration and I'll start from there. (Anyone else is
welcome to make suggestions as well.)

later,
Glen Berry

Post a reply to this message