Hello all. I'm in the process of making a website.

I have one gallery and a complete tutorial ready. The tutorial is for
learning how to make isosurfaces. I encourage all who want to learn
about isosurfaces to visit it. Enjoy!

The url is:

http://members.aol.com/stbenge/

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

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.

"SamuelT." wrote:

> Hello all. I'm in the process of making a website.
>
> I have one gallery and a complete tutorial ready. The tutorial is for
> learning how to make isosurfaces. I encourage all who want to learn
> about isosurfaces to visit it. Enjoy!
>
> The url is:
>
> http://members.aol.com/stbenge/
>
> --
> 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

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

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

Yes more more, we want more!  The images alone are worth the endevour, IMO.

-Mike

Post a reply to this message

Mike wrote:

> Yes more more, we want more!

Unquestionably !

-- 
Ken Tyler

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

Post a reply to this message

Well I found it helpful and await more!

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



SamuelT. <STB### [at] aolcom> wrote in message
news:37C0A403.D4339684@aol.com...
> Hello all. I'm in the process of making a website.
>
> I have one gallery and a complete tutorial ready. The tutorial is for
> learning how to make isosurfaces. I encourage all who want to learn
> about isosurfaces to visit it. Enjoy!
>
> The url is:
>
> http://members.aol.com/stbenge/
>
> --
> 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

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

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

smellenbergh wrote:

> 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

Thank you for the support! I'm glad you were able to understand it :)

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

David Heys wrote:

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

By having that link, you know about as much as I do about the predefined
functions.

It is pretty much the same patch; you can call up sphere and torus in the
new Superpatch.



> 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

I wish I knew. Perhaps you can e-mail the owner of that site?

I really only know what I saw on that site and what I've experimented with
when it comes to isosurfaces.

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

On Mon, 23 Aug 1999 16:17:14 -0800, David Heys wrote:

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

You probably need to increase max_trace (not max_trace_level, but the
max_trace parameter in the isosurface declaration).  The docs say you 
should use max_trace all_intersections, but that's broken in the current 
version.  I'd use the lowest number that works.

Post a reply to this message

On 24 Aug 1999 04:17:16 -0400, 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.

bounded_by doesn't work as usual.  In fact, some builtin functions, such as 
rounded_box, actually use the bounds to determine their size.  Not the best
design, I'll admit.

Post a reply to this message

On Tue, 24 Aug 1999 17:15:20 -0800, David Heys wrote:

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

For both answers, get a copy of the source code and look at isofunc.c .
Not all of the builtins are just straight functions; some of them, such
as rounded box, are complex conditional expressions.

If you just want the builtins and their parameters, look at the superpatch
docs or at this page from R. Suzuki's old POV 2.2 equipotsurface patch, 
where I got the docs from originally:

http://www.etl.go.jp/etl/linac/public/rsuzuki/e/povray/exmplint.htm

Post a reply to this message

Ron Parker wrote:

> http://www.etl.go.jp/etl/linac/public/rsuzuki/e/povray/exmplint.htm

 Ron,

  You by any chance have any more links to sites that contain Pov patches ?
I have been filling in that section of my links page and would like to
add any you may have that I am missing.

Thanks in advance,

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

On Wed, 25 Aug 1999 07:28:43 -0700, Ken wrote:
>
>
>Ron Parker wrote:
>
>> http://www.etl.go.jp/etl/linac/public/rsuzuki/e/povray/exmplint.htm
>
> Ron,
>
>  You by any chance have any more links to sites that contain Pov patches ?
>I have been filling in that section of my links page and would like to
>add any you may have that I am missing.

I do, somewhere.  Obviously I have links to the patches that are included
in the superpatch, where such links exist, but you seem to already have
most of those.  I also have links to some other patches that I haven't 
included yet, such as povafx and some others.  I'll see what I can find 
this evening and send it to you.

Post a reply to this message

Ron Parker wrote:

> I do, somewhere.  Obviously I have links to the patches that are included
> in the superpatch, where such links exist, but you seem to already have
> most of those.  I also have links to some other patches that I haven't
> included yet, such as povafx and some others.  I'll see what I can find
> this evening and send it to you.

Thanks and no rush on this. Any time this week would be fine.

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

SamuelT. <STB### [at] aolcom> wrote :
>
> What do you need to know?
>

    Well, I am trying to figure out what the base assumption of isosurface
is...

ie: "Show every point which is inside (outside?) the area defined by the
function"
    or...
     "Show those x points which are above y and z but under threshold"

    or whatever.. I haven't figured it out yet and every time I get a
working theory I make an image which contraverts that theory.

Post a reply to this message

It is "show all points where the function is equal to the threshold."
Bounding and clipping shapes will alter it if the surface is not totally
contained in the bounding shape.

Post a reply to this message

It's best understood by using it. Figuring out what bounded_by does, what
threshold changes and so on, can be learned through simple experimentation.

I guess the explanation of it would be 'math that forms a surface.' There
are points involved, but instead of say, x making a point at a certain
place, it makes a plane instead. Bill, I don't think I understand your
question fully. Any theory I have come up with regarding the isosurface I
learned through using it.

If you make an isosurface sphere, it is a sphere bounded by the bounded_by
object. If you make a y plane that has a sin(x) function on it, it is just
that, still bounded by an object. All isosurfaces must be bounded_by
something. If they weren't, they might take forever to render.

Chris Huff wrote:

> It is "show all points where the function is equal to the threshold."
> Bounding and clipping shapes will alter it if the surface is not totally
> contained in the bounding shape.

--
Samuel Benge

E-Mail: STB### [at] aolcom
Website: http://members.aol.com/stbenge

"Ni!"

Post a reply to this message

SamuelT. <STB### [at] aolcom> wrote :
> Bill, I don't think I understand your
> question fully.

    Actually you probably do, maybe even better than I do myself 8-) I am
notorious for running out questions before I know enough to ask questions
which could receive informative answers.

    I think Chris's answer while certainly true and exactly what I asked
for, is maybe one step too basic for me to understand all at once.

    But I'm getting there. The following is a little long and may be
tedious, but if someone could check me on it I would be grateful...

    Using the example "function(x+1.0)", going in the x direction, starting
at x=(-1.0), all points get the value 1.0 added to them. So at x=(-1.0), the
point equals 0.0 (less than the threshold of 1.0), then it moves right to
the middle, where x usually equals 0.0 but now equals 1.0, at that point,
all points are greater than the threshold and so aren't shown. (if x > 0.0
then Point > 1.0)

    Using that way of talking about it, the example
function{ (sin(x*3)+y)+y }" (parenthesis added for emphasis) and starting
from the inmost set of parenthesis(x*3), all x values are tripled. So you
get a similar effect as above, with one third the bounding box filled with
points whose values are greater than 1.0 and so are not shown. (if x > 0.333
then Point > 1.0)

    Then finding the sine of (x*3) you get values which start at -1.0 and
smoothly go to +1.0 then back to -1.0. This gives all points within the
bounding box a value of 1.0 or less and so all points are shown ( If you
drop the threshold below 1.0, you can see where the value of sin(x*3) is
greater than the threshold but never gets above 1.0 ).

    Adding y to the above begins to show the sine curve because at the
bottom of the bounding box where y is -1.0, adding y to it makes it -2.0, in
the middle height, where it is y=0, nothing is added to nothing. But for all
values of y which are greater than 0, y now equals twice as much as before.

    So the area where previously, x -almost- made it above 1.0, is now goes
just over 1.0 (where y>0) and is excluded by the threshold. Further up, as Y
gets exponentially greater, it becomes easier for x to be greater than 1.0
so the area that is excluded becomes wider, giving the look of a sine curve.

    Finally, adding y again flattens the curve even more, bringing all of
it's height into the bounding box. Adding more and more y makes flatter and
flatter waves.

    And I finally figured out that the doubling effect of abs and sqr are
because a negative number times a positive number equals a positive
number...

    All this makes sense to me. Which is either a sign that I am finally
getting a grasp on the whole thing or that I am way wrong. I don't know if
my math skills will go much further since I almost broke a blood vessel
trying to get this far, but if someone can confirm that I am right about
this, I'll consider this a working theory...

> Chris Huff wrote:
>
> > It is "show all points where the function is equal to the threshold."
> > Bounding and clipping shapes will alter it if the surface is not totally
> > contained in the bounding shape.
>
> --
> Samuel Benge
>
> E-Mail: STB### [at] aolcom
> Website: http://members.aol.com/stbenge
>
> "Ni!"
>
>

Post a reply to this message

Wow. You lost me quickly with all that math. Good luck building your theory.

Bill DeWitt wrote:

> SamuelT. <STB### [at] aolcom> wrote :
> > Bill, I don't think I understand your
> > question fully.
>
>     Actually you probably do, maybe even better than I do myself 8-) I am
> notorious for running out questions before I know enough to ask questions
> which could receive informative answers.
>
>     I think Chris's answer while certainly true and exactly what I asked
> for, is maybe one step too basic for me to understand all at once.
>
>     But I'm getting there. The following is a little long and may be
> tedious, but if someone could check me on it I would be grateful...
>
>     Using the example "function(x+1.0)", going in the x direction, starting
> at x=(-1.0), all points get the value 1.0 added to them. So at x=(-1.0), the
> point equals 0.0 (less than the threshold of 1.0), then it moves right to
> the middle, where x usually equals 0.0 but now equals 1.0, at that point,
> all points are greater than the threshold and so aren't shown. (if x > 0.0
> then Point > 1.0)
>
>     Using that way of talking about it, the example
> function{ (sin(x*3)+y)+y }" (parenthesis added for emphasis) and starting
> from the inmost set of parenthesis(x*3), all x values are tripled. So you
> get a similar effect as above, with one third the bounding box filled with
> points whose values are greater than 1.0 and so are not shown. (if x > 0.333
> then Point > 1.0)
>
>     Then finding the sine of (x*3) you get values which start at -1.0 and
> smoothly go to +1.0 then back to -1.0. This gives all points within the
> bounding box a value of 1.0 or less and so all points are shown ( If you
> drop the threshold below 1.0, you can see where the value of sin(x*3) is
> greater than the threshold but never gets above 1.0 ).
>
>     Adding y to the above begins to show the sine curve because at the
> bottom of the bounding box where y is -1.0, adding y to it makes it -2.0, in
> the middle height, where it is y=0, nothing is added to nothing. But for all
> values of y which are greater than 0, y now equals twice as much as before.
>
>     So the area where previously, x -almost- made it above 1.0, is now goes
> just over 1.0 (where y>0) and is excluded by the threshold. Further up, as Y
> gets exponentially greater, it becomes easier for x to be greater than 1.0
> so the area that is excluded becomes wider, giving the look of a sine curve.
>
>     Finally, adding y again flattens the curve even more, bringing all of
> it's height into the bounding box. Adding more and more y makes flatter and
> flatter waves.
>
>     And I finally figured out that the doubling effect of abs and sqr are
> because a negative number times a positive number equals a positive
> number...
>
>     All this makes sense to me. Which is either a sign that I am finally
> getting a grasp on the whole thing or that I am way wrong. I don't know if
> my math skills will go much further since I almost broke a blood vessel
> trying to get this far, but if someone can confirm that I am right about
> this, I'll consider this a working theory...
>
> > Chris Huff wrote:
> >
> > > It is "show all points where the function is equal to the threshold."
> > > Bounding and clipping shapes will alter it if the surface is not totally
> > > contained in the bounding shape.
> >
> > --
> > Samuel Benge
> >
> > E-Mail: STB### [at] aolcom
> > Website: http://members.aol.com/stbenge
> >
> > "Ni!"
> >
> >

--
Samuel Benge

E-Mail: STB### [at] aolcom
Website: http://members.aol.com/stbenge

"Ni!"

Post a reply to this message

SamuelT. <STB### [at] aolcom> wrote in message
news:37C5FF63.4B74E991@aol.com...
> Wow. You lost me quickly with all that math. Good luck building your
theory.
>

    It boils down to adding 1 to a fraction of 1 . It's figuring out what
fraction of 1 is where that causes all the mental sweat.

Post a reply to this message

Thanks Samuel this is just what I need, I'll have a look at it as
soon as this render is done, it's been parsing for a day, and
started rendering now at 0 pps.  So in a few days I'll be able to
have a look. 

"SamuelT." wrote:
> 
> Hello all. I'm in the process of making a website.
> 
> I have one gallery and a complete tutorial ready. The tutorial is for
> learning how to make isosurfaces. I encourage all who want to learn
> about isosurfaces to visit it. Enjoy!
> 
> The url is:
> 
> http://members.aol.com/stbenge/
> 
> --
> 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

-- 
Cheers       email: mailto:sjl### [at] ndirectcouk
Steve           or: mailto:zer### [at] startat

%HAV-A-NICEDAY Error not enough coffee.   0 PPS

web: http://www.ndirect.co.uk/~sjlen/   
 or: http://start.at/zero-pps

Post a reply to this message