I've been using Pov-Ray on and off for about a year or two now and I have a
few Ideas I would really like to see implemented.

1.) Have a 'Disable' keyword available for (most) objects.  If POV-Ray
encounters this (or a similar keyword) in an objects description, then it
won't render it.  This would be a much better solution than having to
comment out large blocks of code.

2.) Camera Mode: Depth Map.  This one has probably been suggested many times
before, but here it is anyway.  In the camera block, the user enters
something along the lines of 'Depth' or whatever else the camera is chosen
to be.  It also would need 4 values. Two of which are color vectors, and
two are scalars(MinDepth and MaxDepth).  A ray is traced until it
intersects an object, then the distance is calculated.  Anything closer
than the MinDepth is drawn as the first color (Default is White), and
anything Farther away than the MaxDepth is rendered the second (default is
Black).  Depths in between are given color values in between, much like a
gradient. The end result is something like this:
http://www.quasimondo.com/archives/depthmap.jpg
It may also be possible to specify a color map. This would result in a
rainbow of depths.

3.) Camera Mode: Calculation Density.  This one is more of a debugging
feature than a graphics mode, but it's would be interesting to see
nonetheless.  Instead of calculating the color values of individual pixels,
the image is based on the number of calculations/time required to arrive at
those values.  Complex regions, perhaps those that require area lights,
media, or photon mapping, will show up lighter in color.  Less intensive
areas, such as basic primitives, flatshading, and basic pointlights would
appear darker.  This would be great if you're trying to figure out where
the sticking points are, so that you can temporarily disable the complex
bits while you work on something else.  It may have to be weighted
logarithmically, to prevent the image from appearing as just one color.
Because calculations are counted, not performed, it should make a quick
diagnostic tool.

Post a reply to this message

Ghost2 wrote:
> 1.) Have a 'Disable' keyword available for (most) objects.  If POV-Ray
> encounters this (or a similar keyword) in an objects description, then it
> won't render it.  This would be a much better solution than having to
> comment out large blocks of code.

Moray already has this ability, and you can make this easily in POV SDL 
as well by #declaring your objects then referencing those so you only 
need to comment out the object{declared_item} line that refers to the 
original.

> 2.) Camera Mode: Depth Map.  This one has probably been suggested many times
> before, but here it is anyway.  In the camera block, the user enters
> something along the lines of 'Depth' or whatever else the camera is chosen
> to be.  It also would need 4 values. Two of which are color vectors, and
> two are scalars(MinDepth and MaxDepth).  A ray is traced until it
> intersects an object, then the distance is calculated.  Anything closer
> than the MinDepth is drawn as the first color (Default is White), and
> anything Farther away than the MaxDepth is rendered the second (default is
> Black).  Depths in between are given color values in between, much like a
> gradient. The end result is something like this:
> http://www.quasimondo.com/archives/depthmap.jpg
> It may also be possible to specify a color map. This would result in a
> rainbow of depths.

This is already possible with either fog, or a spherical density media 
centred on the camera's location.

> 3.) Camera Mode: Calculation Density.  This one is more of a debugging
> feature than a graphics mode, but it's would be interesting to see
> nonetheless.  Instead of calculating the color values of individual pixels,
> the image is based on the number of calculations/time required to arrive at
> those values.  Complex regions, perhaps those that require area lights,
> media, or photon mapping, will show up lighter in color.  Less intensive
> areas, such as basic primitives, flatshading, and basic pointlights would
> appear darker.  This would be great if you're trying to figure out where
> the sticking points are, so that you can temporarily disable the complex
> bits while you work on something else.  It may have to be weighted
> logarithmically, to prevent the image from appearing as just one color.
> Because calculations are counted, not performed, it should make a quick
> diagnostic tool.

Again, already possible in POV, see "5.2.2.4  CPU Utilization Histogram" 
in the docs...

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Ghost2 <nomail@nomail> wrote:
> 1.) Have a 'Disable' keyword available for (most) objects.  If POV-Ray
> encounters this (or a similar keyword) in an objects description, then it
> won't render it.  This would be a much better solution than having to
> comment out large blocks of code.

  I don't think it's too much of a trouble to use boolean identifiers
and #if clauses to conditionally render things. I personally use this
way a lot:

#declare Fast = yes;
...
global_settings
{ #if(!Fast)
    photons { ... }
  #end
}

#if(Fast)
  box { whatever }
#else
  object { ComplexObject }
#end

and so on.

  I also often use identifiers to turn on and off many things in the
scene, like for example:

#declare UseAreaLights = yes;
#declare FastTextures = no;
#declare UsePhotons = yes;
#declare SimpleObjects = no;

plus the necessary #ifs using those identifiers. It makes rendering debug
scenes quite a lot easier.

-- 
                                                          - Warp

Post a reply to this message