I agree! Your examples and tutorial finally prompted me to download the
Superpatch. I've been playing around with it and it's quite interesting,
but also very frustrating. I kind of feel like a blindfolded gunman who
has been spun around and told to shoot at the target. I don't have
enough confidence in my math abilities at the moment to be able to
predict the results of my experiments once they go beyond the simple
sphere/cylinder/superellipsoid.

Any suggestions, tutorials, sample forumlae, etc.. would be welcome.
Most of my results, though interesting, seem to end up being infinite
(or seem so) in size. :{P

I "did" get an interesting effect with this:

difference {
 isosurface{
  function{ abs(cos(x)+cos(z)+sin(y))}
  threshold 0.25
  sign 1
  bounded_by{sphere {0,80}}
  hollow
 }
 torus {85,30 hollow}
 pigment {rgb<(63/255),(38/255),(7/255)>}
 finish {specular 0.76 roughness 0.075 ambient 0.54 diffuse 0.62}
}

I have a question on this as well. I'll post an image in
binaries.images. I tried plunking a light inside this object. Light
pours out quite nicely onto the plane that intersects the object, but
does not shine within (even with a Hollow added to the isosurface and
torus). It's almost as if the "holes" in the object let light pass
through, but not impact upon the interior of the object. Am I wrong in
this?

David

Post a reply to this message

Bill DeWitt wrote:

> Well I found it helpful and await more!

I'm glad to hear it.


>     Um... but does anyone else have more? I found the doc's of the
> superpatch to be rather sparse.

What do you need to know?


STB### [at] aolcom

"While you were sleeping
he went on keeping the final line in his mind."
 -Tortoise and the Hare, The Moody Blues

Post a reply to this message

David Heys wrote:

> I agree! Your examples and tutorial finally prompted me to download the
> Superpatch. I've been playing around with it and it's quite interesting,
> but also very frustrating. I kind of feel like a blindfolded gunman who
> has been spun around and told to shoot at the target. I don't have
> enough confidence in my math abilities at the moment to be able to
> predict the results of my experiments once they go beyond the simple
> sphere/cylinder/superellipsoid.

My math abilites aren't that great either. Most of what I know about making
functions I learned from hours of experimentation; trying out strange things
like abs and sqr, which I didn't know anything about beforehand. Persistance
will help you in your endeavor.


> Any suggestions, tutorials, sample forumlae, etc.. would be welcome.
> Most of my results, though interesting, seem to end up being infinite
> (or seem so) in size. :{P

<snip code>

I hope to be adding a couple more tutorials soon. I think such things as
noise3d and the pigment functions are very neat and have many applications.


> I have a question on this as well. I'll post an image in
> binaries.images. I tried plunking a light inside this object. Light
> pours out quite nicely onto the plane that intersects the object, but
> does not shine within (even with a Hollow added to the isosurface and
> torus). It's almost as if the "holes" in the object let light pass
> through, but not impact upon the interior of the object. Am I wrong in
> this?
>
> David

After reading your post, I tried some experiements using your code. I tried
all of the things that I could think of that might solve the problem, but
the problems remain anyway. I even tried making the torus you used have
no_shadow. I'm starting to think that it might be a bug. Strangely enough, I
have never used csg operations with isosurfaces.

Here, this will perform an intersection inside your isosurface function:

function{ (your function)&(function to be intersected with) }

Both functions must be within parentheses as shown. The & is like intersect
for functions. Here is an example of this feature which makes a sphere cut
in half by a y plane:

function{ (x^2+y^2+z^2)&(y+1) }

By the way, I have run into that shape you posted. It is an infinite shape,
to be sure. I like the way you use your rgb colors, too! It's a good way to
convert rgb colors from a paint application to pov.


--
Samuel Benge

STB### [at] aolcom

"While you were sleeping
he went on keeping the final line in his mind."
 -Tortoise and the Hare, The Moody Blues

Post a reply to this message

SamuelT. wrote:

> My math abilites aren't that great either. Most of what I know about making
> functions I learned from hours of experimentation; trying out strange things
> like abs and sqr, which I didn't know anything about beforehand. Persistance
> will help you in your endeavor.
>

<smile> I planned to do that regardless.

> I hope to be adding a couple more tutorials soon. I think such things as
> noise3d and the pigment functions are very neat and have many applications.
>

I haven't quite gotten there yet. :{)

> After reading your post, I tried some experiements using your code. I tried
> all of the things that I could think of that might solve the problem, but
> the problems remain anyway. I even tried making the torus you used have
> no_shadow. I'm starting to think that it might be a bug. Strangely enough, I
> have never used csg operations with isosurfaces.
>
> Here, this will perform an intersection inside your isosurface function:
>
> function{ (your function)&(function to be intersected with) }
>
> Both functions must be within parentheses as shown. The & is like intersect
> for functions. Here is an example of this feature which makes a sphere cut
> in half by a y plane:
>
> function{ (x^2+y^2+z^2)&(y+1) }
>
> By the way, I have run into that shape you posted. It is an infinite shape,
> to be sure. I like the way you use your rgb colors, too! It's a good way to
> convert rgb colors from a paint application to pov.
>

Is it possible you could post the isosurface function for a torus so I could try
it with the intersection method you've mentioned? As an aside, how do you scale
one of these things? Every attempt I've made has resulted in very odd reactions.
Maybe there's a specific place I should put the scale command, or should I just:

function {((my function)*Scale_Factor)}
or
function {((my function)/Scale_Factor)}

I use the #/255 for my rgb quite often as pretty much half of what I do with POV
these days is destined to be used on a website somewhere. Having to use parts of
POV scenes and other items in Photoshop, I find it convenient to use the #/255
method.

David

Post a reply to this message

I started to read this tutorial and found the first error in less than
one minute... :)
  I quote:

> bounded_by - This gives the isosurface a limit. For instance, if you make an
> isosurface sphere that is larger than 1 at its radius, and you put 

> bounded_by{ box{ <-1,-1,-1>,<1,1,1> } } 

> in the isosurface statement, what do you think will happen? The box will
> cut into the sphere, giving you an intersected box and sphere, the sphere
> having 6 flat sides. 

  I don't know if this works differently with isosurfaces since I have never
used the superpatch, but if bounded_by works as usual, that's not true.
  I think that you are confusing bounded_by and clipped_by together.
clipped_by cuts the object like an intersection does (except that it doesn't
add a new surface to the cut part). bounded_by just bounds the object. The
result is that the object becomes clipped by the projection of the bounding
object on screen. This is completely different from being clipped in
3D-space.
  If you want your bounding object to also clip the object, you have to do:

clipped_by { box { -1,1 } }
bounded_by { clipped_by }

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
>   I started to read this tutorial and found the first error in less than
> one minute... :)
>   I quote:
> 
> > bounded_by - This gives the isosurface a limit. For instance, if you make an
> > isosurface sphere that is larger than 1 at its radius, and you put
> 
> > bounded_by{ box{ <-1,-1,-1>,<1,1,1> } }
> 
> > in the isosurface statement, what do you think will happen? The box will
> > cut into the sphere, giving you an intersected box and sphere, the sphere
> > having 6 flat sides.
> 
>   I don't know if this works differently with isosurfaces since I have never
> used the superpatch, but if bounded_by works as usual, that's not true.
>   I think that you are confusing bounded_by and clipped_by together.
> clipped_by cuts the object like an intersection does (except that it doesn't
> add a new surface to the cut part). bounded_by just bounds the object. The
> result is that the object becomes clipped by the projection of the bounding
> object on screen. This is completely different from being clipped in
> 3D-space.
>   If you want your bounding object to also clip the object, you have to do:
> 
> clipped_by { box { -1,1 } }
> bounded_by { clipped_by }
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Stop posting binaries to this group ! :)

There is one way to get a bounded_by to act as a clipped_by without having
to specify the clipped_by statement:

camera { location  <0, 0, -3> look_at 0}
light_source {<0, 0, -20> rgb 1}

intersection {
        sphere { 0,1 
         pigment { rgb 1 }
     bounded_by {
              box { -.5,.5 }
        }
     }
}

If you do not wrap it in the CSG wrapper Pov simply ignores the bounding
operation so that the clipping is ignored. With the CSG wrapper used as
shown the bounded_by clips the sphere to the shape of the box and then
Pov issues a warning (not an error) that you need two objects in a CSG
operation. Even with the warning the CSG operation is performed not by
the intersection but rather by the bounded_by operation. This can be
confirmed by simply adding another object to the CSG operation such as:

camera { location  <0, 0, -3> look_at 0}
light_source {<0, 0, -20000> rgb 1}

merge {
        sphere { x*-.5,1 }
        sphere { x* .5,1 }
         pigment { rgb 1 }
       bounded_by { box { -.5,.5 }}
}

  I think you will find the above interesting if you take the time to
actually render it.

Nieminen Mika 
Nieminen Juha  <---  ?????

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:

: Stop posting binaries to this group ! :)

  It's not a binary, it's a C program O:)

: There is one way to get a bounded_by to act as a clipped_by without having
: to specify the clipped_by statement:

: camera { location  <0, 0, -3> look_at 0}
: light_source {<0, 0, -20> rgb 1}

: intersection {
:         sphere { 0,1 
:          pigment { rgb 1 }
:      bounded_by {
:               box { -.5,.5 }
:         }
:      }
: }

  The sphere is not being clipped here. The projection of the sphere on
screen is being clipped by the projection of the box in screen. This is
very easy to test. Try this:

camera { location  <2, 2, -3> look_at 0}
light_source {<0, 0, -20> rgb 1}

intersection {
  sphere
  { 0,1
    pigment { rgb 1 }
    bounded_by { box { <-10,0,-10>,<10,-.1,10> } }
  }
}

  If the box were clipping the sphere, we would see a circular section of
the box. Instead, we see a regular sphere. Why? Because the projection of
the box on screen completely covers the projection of the sphere on screen.
  The 'intersection' has no effect here.

: Nieminen Juha  <---  ?????

  It's a long story.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:

>   If the box were clipping the sphere, we would see a circular section of
> the box. Instead, we see a regular sphere. Why? Because the projection of
> the box on screen completely covers the projection of the sphere on screen.
>   The 'intersection' has no effect here.

Ok let's agree that it is not a clipping operation but in the least it is
effecting the shape of the object presented on screen. In that regard the
bounded_by statement can and will when used (im)properly affect an objects
shape and can be used somewhat like a csg operation can. Although it's
probably not a good idea to use it regularly it has possibilities. Foremost
of these are the fact you don't have to worry about parent/child texture
problems and there are no open object situations as seen with a clipped_by
operation.

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

You can use the built in function for a torus like this:
function{"torus", <R0,R1>} or you can use the actual equation like this:
function{sqrt(sqr(sqrt(sqr(x)+sqr(z))-R0)+sqr(y)) -R1 }.

And to scale the object, what you were doing is scaling the values the
function returns, you need to scale the coordinate values. Like function
{(x/scaleVal)^2 + (z/scaleVal)^2 * y}
You can do it more easily like this:
#declare torusFunc = function{sqrt(sqr(sqrt(sqr(x)+sqr(z))-R0)+sqr(y))
-R1 }
isosurface {...
    function {torusFunc(x/scaleVal, y/scaleVal, z/scaleVal)}
    ...
}

Post a reply to this message

bounded_by does work differently for isosurfaces, it creates a shape
with a closed surface where it intersects the bounding shape, while
clipped by works the same but leaves that area open.

Post a reply to this message