Kyle <hob### [at] gatenet> wrote:
> Please refer to the following thread...
>
>
http://news.povray.org/povray.general/thread/%3Cv4pqj217fg814vqilvmdgf2v3ri3i8qj77%404ax.com%3E/

I like this Patrick Elliott quote:
"Its not always possible to argue successfully for solution that make things
easier to do in 'specific' cases, when there is a perception of a more
physically 'correct' model already in the engine, and it just happens to
be complicated, frustrating and confusing to get the same result with it
(like subsurface scattering effects, for example)."

I wonder, when povray goes open-source it could probably benefit from using
libraries or code from projects such as Blender to handle displacements,
tesselation or decimate.  I'm not sure it'd be of any help for a raytracer, but
OTOH, Blender uses an internal renderer which seems to mix a scanline with a
raytracer...

BTW, speaking of requests, perhaps it should be useful to allow for the simple
geometric shapes to be treated as isosurfaces in syntax.  So, the parser would
interpret these two in different ways:

sphere { 0, 1 } <-- basic optimized quadratic shape
sphere { 0, 1 displacement { crackle .2 turbulence .06 } }  <-- isosurface
sphere shape displaced by pattern

or even:

union {
  sphere { x/2, 1 }
  box { -1,1 translate -x/2 }
  glue_level .2
  displacement { granite .04 }
} <-- the whole union is an isosurface of the shapes above glued together by 20%
and displaced by pattern

you know, kinda like supporting Chris Hormann' excellent IsoCSG macro lib
directly in syntax.  It's much easier for non-math folks to work on shapes and
transforms rather than functions and function composition.  I always though of
povray's isosurfaces as povray's NURBS... :)

Post a reply to this message