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

Chris Huff <Chr### [at] compuservecom> wrote:
: 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.

  Is it so? Then I really don't like it. If bounded_by works in one way
with one object and in other way with other object, that definitely is not
a good thing. Bounded_by should always work as a bounded_by, not as an
intesection CSG.
  Using bounded_by for other reasons than limiting the object is quite rare,
but not impossible. If it doesn't work equally for all objects, you are
breaking the functionality of the povray engine.
  If I want to clip an object and add new surfaces to the clipped parts, I
use intersection. If I want to clip and object without adding new surfaces
I will use clipped_by. For bounding I will use bounding_by and I will expect
it to work as with all the other objects (for example with quartics, which
also are isosurfaces).
  Sometimes you _want_ the side-effects of bounding objects (for example
for the so-called 'vampire' or 'anti-vampire' objects).

  If I know povteam, I will not be surprised if they changed the behaviour
of bounded_by for isosurfaces to work exactly like for other objects in
pov3.5. I approve this idea. I don't like the idea of bounded_by working
in different ways for different objects.

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

David Heys <cel### [at] hotmailcom> schreef in berichtnieuws
37C1E489.68910B68@hotmail.com...
> ........
> I "did" get an interesting effect with this:
> ......
> 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,

Try adding (a higher value for) the max_intersections statement in the
isosurface object. Due to a bug the maximum for this is 10.


ingo

Post a reply to this message

SamuelT. <STB### [at] aolcom> wrote:

> Oh, could I get some feedback about the tutorial? Either a post or e-mail
> is fine. I just need to know if it is worth putting up more isosurface
> tutorials. Thanks.
> 
Hi,
It sure is worth it. 
Actually: "does anyone know about docs or a tutorial for the
isosurface?"" has become a FAQ in these newsgroups.

We often see stunning isosurface images. Only to make us wish we knew
more about maths. Your tutorial shows that it isn't that difficult after
all.
Please go on with it.

-smellenbergh

-- 
e-mail:sme### [at] skynetbe

Site of the POV-RayUnofficial for Macintosh (isosurface patch included)
http://users.skynet.be/smellenbergh

Post a reply to this message

I tend to agree, there should be a separate keyword(limit_object?
limited_by?) and the inconsistency is annoying. I don't think it would
be difficult at all to do this, but I don't know anything about the
isosurface source.(This "bounding" shape is necessary for the
calculation method to work)
However, I think you can still declare an isosurface, and then manually
bound an instance of that isosurface, and it will work normally. I
haven't tried it, though, but if it works, it would allow vampire
isosurfaces, etc.

Post a reply to this message

Hey Samuel,

I notice there are a lot of predetermined functions already. Thing like
Torus (which you mentioned) and Mesh (I just saw on:

http://www.etl.go.jp/etl/linac/public/rsuzuki/e/povray/iso/index.html

Which is one of the sites that detail (to some degree) the isosurface
patch. This is the same one that's built into Superpatch, right? How can
I:

a) Find a list of all these predefined functions and a description of
what shapes they produce.

b) See the actual math of these functions if I want to play with one or
more of them?

David

Post a reply to this message