Hello folks,

I'm no expert in isosurfaces, but I suspect POV 3.5 to be less powerful than
MegaPOV because it doesn't have the "method" keyword.. I liked method 1 and
now I am forced to use what appears to be method 2.. So I must specify a
max_gradient and in most cases I a gradient of over 100 for my shapes to
render properly.. This is much slower than method 1..

I don't know how to solve that.. But sometimes it would also be great to
convert ISO's to bitmaps so they can be used as heightfields.. I read the
documentation for POV 3.5 and I only see the possibility of making 255
slices of an isosurface, each of them with a "pigment object" that is either
on/off... Remember the "pigment { object { ...." keywords? Then I put these
255 pigments on 255 boxes, all of them with a transparant white color. Then
the camera + light in front of it.. If it sounds confusing, maybe this code
explains my idea, although you can't render anything with it:


#declare Steps=255;  // Amount of slices
#declare Start=-.3;  // Z position to start
#declare End=.25;    // Z position to end
#declare Next=(End-Start)/Steps; // The next step pre-calculated.

#while (Start<End)
    #declare ISO=isosurface { function { .... }
        contained_by { box
{ <-1,-1,Start-.0001>,<1,1.25,Start+Next+.0001> } } }
    box { <-1,-1,Start>,<1,1.25,Start+Next>
    pigment { object { ISO color rgbt <0,0,0,1> color rgbt
<1,1,1,1/Steps> } } }
    #declare Start=Start+Next;
    #end


But I mostly get a black result. The form is only recognizeable if I use 5
or 6 steps istead of 255.. What's wrong, and are there more clever ways? I
think MegaPOV could output a density file.

Regards,
Hugo

Post a reply to this message

"Hugo" <hua### [at] post3teledk> wrote in message news:3bc31497@news.povray.org...
> Hello folks,
>
> I'm no expert in isosurfaces, but I suspect POV 3.5 to be less powerful than
> MegaPOV because it doesn't have the "method" keyword.. I liked method 1 and
> now I am forced to use what appears to be method 2.. So I must specify a
> max_gradient and in most cases I a gradient of over 100 for my shapes to
> render properly.. This is much slower than method 1..
>

I'd be careful of making assumptions about 3.5 - remember it is still in beta.
That aside, the lack of a keyword to me indicates that the 3.5 is probably
better in this regard than MP, but what would I know?

> I don't know how to solve that.. But sometimes it would also be great to
> convert ISO's to bitmaps so they can be used as heightfields.. I read the

I've also considered a similiar thing - my approach was slightly different. Just
use a gradient pattern on the iso, having scaled it to go from y=0 to y=1. No
lights and ambient 1, then place the camera directly above. This should result
in an image that can be used as a hf...

Post a reply to this message

I would just give it a color_map of colors from black to white from bottom
to top, and then render it from above.

I'm pretty sure there's also a way to just use a function and tell povray to
evaluate it at certain points in order to "pretend" it's an image.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

"Hugo" <hua### [at] post3teledk> wrote in message
news:3bc31497@news.povray.org...
> Hello folks,
>
> I'm no expert in isosurfaces, but I suspect POV 3.5 to be less powerful
than
> MegaPOV because it doesn't have the "method" keyword.. I liked method 1
and
> now I am forced to use what appears to be method 2.. So I must specify a
> max_gradient and in most cases I a gradient of over 100 for my shapes to
> render properly.. This is much slower than method 1..
>
> I don't know how to solve that.. But sometimes it would also be great to
> convert ISO's to bitmaps so they can be used as heightfields.. I read the
> documentation for POV 3.5 and I only see the possibility of making 255
> slices of an isosurface, each of them with a "pigment object" that is
either
> on/off... Remember the "pigment { object { ...." keywords? Then I put
these
> 255 pigments on 255 boxes, all of them with a transparant white color.
Then
> the camera + light in front of it.. If it sounds confusing, maybe this
code
> explains my idea, although you can't render anything with it:
>
>
> #declare Steps=255;  // Amount of slices
> #declare Start=-.3;  // Z position to start
> #declare End=.25;    // Z position to end
> #declare Next=(End-Start)/Steps; // The next step pre-calculated.
>
> #while (Start<End)
>     #declare ISO=isosurface { function { .... }
>         contained_by { box
> { <-1,-1,Start-.0001>,<1,1.25,Start+Next+.0001> } } }
>     box { <-1,-1,Start>,<1,1.25,Start+Next>
>     pigment { object { ISO color rgbt <0,0,0,1> color rgbt
> <1,1,1,1/Steps> } } }
>     #declare Start=Start+Next;
>     #end
>
>
> But I mostly get a black result. The form is only recognizeable if I use 5
> or 6 steps istead of 255.. What's wrong, and are there more clever ways? I
> think MegaPOV could output a density file.
>
> Regards,
> Hugo
>
>

Post a reply to this message

In article <3bc31497@news.povray.org> , "Hugo" <hua### [at] post3teledk> wrote:

> I don't know how to solve that.. But sometimes it would also be great to
> convert ISO's to bitmaps so they can be used as heightfields.. I read the
> documentation for POV 3.5 and I only see the possibility of making 255
> slices of an isosurface

What you are looking for is the "function" image type.  It turns out that
for some reason it is missing in
<http://www.povray.org/working-docs/id000164.html#6_5_1_5> so no wonder you
didn't find it.

It basically will work like this in a hfield, but to be more precise it will
work everywhere where a image file is allowed:

    height_field
    {
        function 100, 100 { x + y }
    }

Note that the hfield will be of 16 bit precision.  If you want it to look
less smooth, you have to modify the function, i.e.

    height_field
    {
        function 100, 100 { floor((x + y) * 10) / 10 }
    }

will give you a less smooth hfield surface with more visible steps.  Note
that this is more useful for a more complicated function.  This one is so
simple you will hardly see a difference.

    Thorsten

Post a reply to this message

Hugo wrote:
> 
> [...]
> 
> I don't know how to solve that.. But sometimes it would also be great to
> convert ISO's to bitmaps so they can be used as heightfields.. I read the
> documentation for POV 3.5 and I only see the possibility of making 255
> slices of an isosurface, each of them with a "pigment object" that is either
> on/off... Remember the "pigment { object { ...." keywords? Then I put these
> 255 pigments on 255 boxes, all of them with a transparant white color. Then
> the camera + light in front of it.. If it sounds confusing, maybe this code
> explains my idea, although you can't render anything with it:
> 

Apart from what others said it should be mentioned that not all
isosurfaces can be converted to heightfields, although functions of the
form

  function { z - funct(x, y, 0) }

can be easily converted with the method Thorsten mentioned.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3bc320fb@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> What you are looking for is the "function" image type.  It turns out that
> for some reason it is missing in
> <http://www.povray.org/working-docs/id000164.html#6_5_1_5> so no wonder you
> didn't find it.

Ah, I found it.  It is only in
<http://www.povray.org/working-docs/id000193.html#6_7_11_16>.

    Thorsten

Note to docs coordinator:  Could this be placed elsewhere?  The last place I
looked for it was in the pattern section.  I would rather put it in the user
defined function doc section, but even there isn't really the right place
for it :-(  Maybe a totally new section describing the image formats and
where they can be used in a nice and general way would be best.  This would
be a consolidated version of the "6.7.1.5 Image Maps", "6.7.2.3 Bump Maps",
etc docs which right now all describe the image specification syntax over
and over again.  If they would all point to a common section it would
probably be much easier and less of a hassle to update the docs as well...

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

in news:3bc31497@news.povray.org Hugo wrote:

> But sometimes it would also be great to
> convert ISO's to bitmaps so they can be used as heightfields..

I'm not shure I understand what you try to achieve, but my first 
thought was, why not use your functions as a pigment, use that on a 
plane and render. Use the resulting image for a hf. Actually, you can 
do it directly, see "6.7.11.16  Function Image" in the 3.5 doc.


Ingo

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

Post a reply to this message

in news:3bc3244d@news.povray.org Thorsten Froehlich wrote:

> Note to docs coordinator:  Could this be placed elsewhere?

Yes, 
Rune/Chris have mentioned this earlier and I managed to forget it :(

Ingo

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

Post a reply to this message

Hugo <hua### [at] post3teledk> wrote:
: I'm no expert in isosurfaces, but I suspect POV 3.5 to be less powerful than
: MegaPOV because it doesn't have the "method" keyword..

  This is like assuming that the radiosity in POV 3.5 is less powerful than
in 3.1 because the distance_maximum is now obsolete while in 3.1 it was
essential.

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

Post a reply to this message

Hugo wrote:
> 
> Hello folks,
> 
> I'm no expert in isosurfaces, but I suspect POV 3.5 to be less powerful than
> MegaPOV because it doesn't have the "method" keyword.. I liked method 1 and
> now I am forced to use what appears to be method 2.. So I must specify a
> max_gradient and in most cases I a gradient of over 100 for my shapes to
> render properly.. This is much slower than method 1..

To be honest, I haven't seen a significant difference in render times
between method 1 and method 2. ISTR that method 1 allowed the user to
optionally specify a max_gradient, and that it was often necessary to do
so for complicated isosurfaces to render without artifacts anyway, so
I'd say you've lost nothing. I admit to not testing this, however...

-Xplo

Post a reply to this message