I've been doing some experimenting with isosurfaces.

i) The normals don't seem to look so nice as I might expect for say a plane
or sphere.  I'm imagining that it might take more computing time to get the
normal calcs right for an isosurface-- maybe the max_gradient recommendation
allows one to avoid holes rather but not optimize the look and feel of the
normal.  I've actually started trying "normal" effects with pigment_maps
instead. OR maybe I just need to keep trying the normal.  Any pointers?

ii) I've been defining a function, then using it to define a pigment map
where I can create plateaus, etc.   The pigment thus created can be turned
back into a function and used as the basis for an isosurface.   What is the
max_gradient? (Already RTFM).  Does it have a property such that if I set up
true "step functions" in my pigment that the max_gradient will skyrocket?

I'm talking about the difference between:
{[0.5 rgb 0.5] [0.5 rgb 1.0]}
and
{[0.5 rgb 0.5] [0.501 rgb 1.0]}
Do I need to introduce the latter so as to not screw up max_gradient?

iii)  As discussed in ii, I've got a pretty slick system where I can use
much of the same "typing" to set up the fuction for an isosurface with
plateaus and lakes in an isosurface  and the texture_map{} for the same iso.
Getting the texture perfectly lined up with the actual surface is a trivial
task.

I have, however, sometimes wanted to try a height_field with my
function{}because I know they are much quicker in rendering.   But when I've
tried to code-up a perfect aligment of texture and function, it just doesn't
happen.   Could someone explain how to do this, if it were possible?

Post a reply to this message

Wasn't it Greg M. Johnson who wrote:
>I've been doing some experimenting with isosurfaces.
>
>i) The normals don't seem to look so nice as I might expect for say a plane
>or sphere.  I'm imagining that it might take more computing time to get the
>normal calcs right for an isosurface-- maybe the max_gradient recommendation
>allows one to avoid holes rather but not optimize the look and feel of the
>normal.  I've actually started trying "normal" effects with pigment_maps
>instead. OR maybe I just need to keep trying the normal.  Any pointers?

Setting a lower value for accuracy should give you better normals. It
will make the isosurface render slightly more slowly.

>ii) I've been defining a function, then using it to define a pigment map
>where I can create plateaus, etc.   The pigment thus created can be turned
>back into a function and used as the basis for an isosurface.   What is the
>max_gradient? (Already RTFM).  Does it have a property such that if I set up
>true "step functions" in my pigment that the max_gradient will skyrocket?
>
>I'm talking about the difference between:
>{[0.5 rgb 0.5] [0.5 rgb 1.0]}
>and
>{[0.5 rgb 0.5] [0.501 rgb 1.0]}
>Do I need to introduce the latter so as to not screw up max_gradient?

A true step function will have an infinite gradient at the points on the
edge of the step, but most of the time you can get away with setting a
much lower max_gradient value than that recommended by POVRay (displayed
in the message pane when you have used a value that's not close to the
recommended value.)

It is possible to calculate the gradient of a function if you can
differentiate it, there's a very simple example in my tutorial at
<http://www.econym.demon.co.uk/isotut/maxgradient.htm>
however, it's generally much easier to look at what POVRay recommends.

>iii)  As discussed in ii, I've got a pretty slick system where I can use
>much of the same "typing" to set up the fuction for an isosurface with
>plateaus and lakes in an isosurface  and the texture_map{} for the same iso.
>Getting the texture perfectly lined up with the actual surface is a trivial
>task.
>
>I have, however, sometimes wanted to try a height_field with my
>function{}because I know they are much quicker in rendering.   But when I've
>tried to code-up a perfect aligment of texture and function, it just doesn't
>happen.   Could someone explain how to do this, if it were possible?

Yes it is possible. See my tutorial at
<http://www.econym.demon.co.uk/isotut/patterns.htm#hf>
and grab the zip file that contains the source code.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wonderful advice.

"Mike Williams" <nos### [at] econymdemoncouk> wrote in message
news:VzR### [at] econymdemoncouk...
>
> Yes it is possible. See my tutorial at
> <http://www.econym.demon.co.uk/isotut/patterns.htm#hf>
> and grab the zip file that contains the source code.
>


I think you may have mislabelled some of your figures.  You have two
captions which identify noise type 2.

Q: can one make a universally true statement about speed of isosurface vs.
subpixel (?) height field?

Post a reply to this message

Wasn't it Greg M. Johnson who wrote:
>Wonderful advice.
>
>"Mike Williams" <nos### [at] econymdemoncouk> wrote in message
>news:VzR### [at] econymdemoncouk...
>>
>> Yes it is possible. See my tutorial at
>> <http://www.econym.demon.co.uk/isotut/patterns.htm#hf>
>> and grab the zip file that contains the source code.
>>
>
>
>I think you may have mislabelled some of your figures.  You have two
>captions which identify noise type 2.

I'll update it later today.

>Q: can one make a universally true statement about speed of isosurface vs.
>subpixel (?) height field?

I don't know of any.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Greg M. Johnson <gregj;-)565### [at] aolcom> wrote:
> i) The normals don't seem to look so nice as I might expect for say a plane
> or sphere.  I'm imagining that it might take more computing time to get the
> normal calcs right for an isosurface-- maybe the max_gradient recommendation
> allows one to avoid holes rather but not optimize the look and feel of the
> normal.

  'accuracy' is the keyword.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message