A quick thought led to this: How about a post-processing clause in the script?
Plug-ins (developed for whatever purpose), or hard-coded keywords could directly
manipulate the output pixel or the generated pixel array (as floats please). At
run-time, some statistics would be available for the scene, such as min and max
colour element values, min and max distance, etc.
Some examples of plug-ins:
1. Setting of dynamic range (to cope with HDR dynamically in animation).
2. Perform quick-and-dirty aparture blurring (if depth information is available
- imitate Photoshop's Lens Blur, which is very competent - and when needed cast
extra rays to see behind objects).
If we take an aspect of this to a logical conclusion, we'd essentially have a
very useful 'shader'. You're doing the processing within the engine, so can do
extra stuff on-demand, whereas with the conventional approach, you're just
stuck with the output. I suspect this kind of complexity is best served with a
plug-in architecture invoked by script, rather than by raw SDL script.
Further, opening other parts of the pipeline to plug-in or scripting might prove
3. Custom camera ray shooting for custom projections - realising that this can
already be done to some extent, or with optical scene objects, e.g. Skewed
frustrum, or wide-angle projections that can be used with spherical viewers.
4. Stitching from render farms (I know there are other problems with this,
outside the remit of a scene file, but I'm just planting seeds for ideas!)
I cast the hat into the ring, in case people can make use of it. However, rather
than concentrating on the flaws of the detail in the above (I know newsgroups
can quickly become pedantically diverted!), perhaps concentrate on *positive*
aspects of what POV-Ray could feasably do in future, and how it could be
Post a reply to this message