POV-Ray : Newsgroups : povray.windows : Camera/Debug suggestions for Pov-Ray : Re: Camera/Debug suggestions for Pov-Ray Server Time
26 Jun 2024 01:02:20 EDT (-0400)
  Re: Camera/Debug suggestions for Pov-Ray  
From: Tim Cook
Date: 12 Jan 2006 14:44:18
Message: <43c6b192$1@news.povray.org>
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

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