POV-Ray : Newsgroups : povray.beta-test : isosurface MegaPov conversion to POV3.5 : Re: isosurface MegaPov conversion to POV3.5 Server Time
31 Jul 2024 04:20:27 EDT (-0400)
  Re: isosurface MegaPov conversion to POV3.5  
From: Mike Williams
Date: 10 Sep 2001 13:10:06
Message: <N8tIiKAuDOn7Ewvz@econym.demon.co.uk>
Wasn't it smellenbergh who wrote:

[Lots of extremely useful stuff]

>or, when declaring the function directly, without using the include
>file:
>  #declare MySphere = function { internal(61) }
>  isosurface{ function{ MySphere(x,y,z,0.8) } }

I'd guess that would be a bad idea. The "functions.inc" file is
insulating you from having to change your scene files whenever the
internal function numbers get changed. 'The ID's used to access the
internal functions through calls to "internal(XX)", are not guaranteed
to stay the same between POV-Ray versions.' (Help file 7.7)

If the authors keep the ID numbers in alphabetical order and a couple of
new ones get inserted you may well find that what you thought was a
sphere will become a ridged_multifractal.

>* sign is no longer used in 3.5 isosurface
>to switch inside/outside, turn the whole function negative:
>  #declare Landscape = function { f_ridged_mf(x,y,z,1,2,10,1.1,2) }
>  isosurface{function{ Landscape(x,0,z)-y }
>becomes
>  isosurface{function{ -(Landscape(x,0,z)-y) }

Note also that if your function used a threshold you must make that
negative too.
   threshold 0.5
becomes
   threshold -0.5

>I think these are the main changes, but I probably forgot some :-)

Also, some minor stuff.

MegaPOV accepted 
        contained_by {sphere 0,1}
3.5 requires the brackets
        contained_by {sphere {0,1}}

MegaPOV required a contained_by keyword
3.5 defaults to {box{-1,1}}

MegaPOV built-in function names were case independent
        "Sphere"
3.5 requires lower case
        f_sphere

MegaPOV isosurfaces never suffered from coincident surface artefacts.
3.5 isosurfaces that have coincident surfaces get the traditional
coincident surface speckles. (So the MegaPOV trick of avoiding "open"
containers by making an invisible surface coincident with your container
doesn't work. However, 3.5 doesn't have much of a speed penalty for
having an "open" container, so you don't need the trick.)

The parametric isosurface syntax is completely different.


There's also probably lots of really clever new stuff that can be done
because of the way that 3.5 functions have become more flexible. For
example, in MegaPOV you couldn't #declare functions that had extra
parameters. In 3.5 I can create an include file that declares functions
that take extra parameters just like the built in functions do.
    #declare Whitneys_Umbrella = function(x,y,z,A,B){A*x*x -B*y*y*z}
can then be referenced like
    isosurface {
      function { Whitneys_Umbrella(x, y, z, 2, -1) }
Whereas in MegaPOV if I wanted a Whitney's Umbrella (2,-1) and another
Whitney's Umbrella(1,1) I'd have had to #declare them separately.


I've so far found that the hardest bit of converting my isosurface
tutorial scene files (and I've done over 150 of them so far) is finding
a sensible max_gradient in situations where I had previously used the
MegaPOV defaults.

-- 
Mike Williams
Gentleman of Leisure


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.