I seem to have started something here...
[plunges in headfirst]


> Do you know #include and #declare directive?
I know I could just #declare a value for the golden ratio, (as I often
do), but then we could do that for pi as well surely; we don't really
_need_ them built-in, it's just handy.

Mark Wagner <mar### [at] gtenet> wrote:
> #fkill("c:\windows\win.com")
Excellent point; I had considered that and, as Warp says, we would need
restrictions on #fkill. Perhaps it could only kill files created by
POV-Ray?


>Are you thinking about matrices with transformations ?
No, general matrices of arbitrary size. I guess my #macros will do the
job (when finished), but I'd like to see built-in support.

Now for the really contraversial one...
I came up with the idea for the polygonal preview after a particulary
long trace on my laptop (known as "The Breezeblock") which took several
minutes for a test render (and this a fairly simple scene). Admittedly,
this was largely due to the fact that Breezeblock is old, slow and ugly,
but even on fast computers, a test render can sometimes take a
disproportionatly long time.
Now, we know it's possible to tesselate finite simple primitives with no
problems, but as you say, advanced shapes like julias, isosurfaces, and
polys can & will cause problems. I can't see a way round this (besides
having an option to turn on/off these shapes for poly_preview). Unless
we could create a new object property called approx_object{  }? Say you
have a hideously complicated isosurface, whose shape is nevertheless
vaguely similar to a set of 3 mutually perpendicular cylinders. Then we
could use the code:
isosurface{
  $ISOSURFACE_STUFF$
  approx_object{
    union{
      cylinder{ -2*x, 2*x, 1 }
      cylinder{ -2*y, 2*y, 1 }
      cylinder{ -2*z, 2*z, 1 }
    }
  }
}
and the poly_preview could then tesselate this structure easily, giving
the impression of the final shape (which is all we want anyway!)

Here's some more ideas for you to argue over...

5> animation variables "current_frame", "initial_frame", "total_frames"
I am SO tired of having to redo an animation render because I #declared
the wrong value for final_frame (usually because I test-render at a
lower framecount)

6> The ability to tell POV-Ray when we only want an include file to be
parsed once, instead of having to use special handling systems (check
the very top and bottom of any standard include for example). Possible
syntax:

#include "colors.inc" once  //  any future #inclusions of colors.inc are
ignored
#include "nkflare.inc"  //  nkflare.inc can be #included again later on
(NKFlare relies on this to create multiple flares; also allows for
backwards compatibility)

-- 
From the Grey Knight
//@---signature---
//  Grey Knight's site of the week: 
url{ "http://mathworld.wolfram.com" }

Post a reply to this message