William F Pokorny <ano### [at] anonymousorg> wrote:
> It recently hit me some of the solver related debug output I was
> creating was not too far from providing a decent depth map output. Given
> depth maps are a frequently requested feature, a *nix only stand alone
> version of POV-Ray specifically modified to create depth map output
> based on the current v3.8 master can be had at:
> For details see similarly titled post to povray.unofficial.patches.
> Bill P.
This is great ! I hope this gets integrated in official version.
A few other features might be worth channeling along with it to an optional pass
system or maybe it already exists ?
* a simple first ray hit diffuse color
* ILLUMINATION, anything with diffuse > 1.0
* anything with alpha (REFRACTION)
* SSLT ; TRANSPARENCY ABSORPTION ;
* this Z Depth
* a global white proximity texture usable as an AO pass
* anything with the ghost feature output in a specific layer
* iridescence to its own
* phong layer
* specular layer
* rest of the image without any existing pass
* plus the normal image all combined as a reference, ("beauty pass")
imagine outputting all of this after just pushing render once and going for a
Then imagine, when you come back and find a glitch in the beauty pass, to
un-check and re-render only the one culprit !
.... Yes I know I didn't invent the wheel... But you kind of made me hope for
having one now.
Post a reply to this message
On 8/7/19 4:35 AM, Mr wrote:
> This is great ! I hope this gets integrated in official version.
> A few other features might be worth channeling along with it to an optional pass
> system or maybe it already exists ?
> For instance:
> * a simple first ray hit diffuse color
> * ILLUMINATION, anything with diffuse > 1.0
> * anything with alpha (REFRACTION)
> * Reflections
> * SSLT ; TRANSPARENCY ABSORPTION ;
> * MEDIA
> * Mist
> * this Z Depth
> * a global white proximity texture usable as an AO pass
> * anything with the ghost feature output in a specific layer
> * iridescence to its own
> * phong layer
> * specular layer
> * photons
> * radiosity
> * rest of the image without any existing pass
> * plus the normal image all combined as a reference, ("beauty pass")
Thanks. I think for now it's likely to stay as a patch. As coded it's
very inefficient. Adding better into the existing code structure would
itself add overhead to all renders. Already, we have too many
conditionals in the ray tracing paths(1).
Suppose your thinking of more support for image compositing & ease of
understanding what is contributing to the final result. A few things on
your list you might be able to do already to some degree or other with
various settings like quality level, max trace - many not of course.
Well, not without significant scene/material changes.
The ray tracing would need to be repeated in large part for each result
so performance of the whole set of images would be worse. Possible to be
more efficient if patching just one aspect. The current code base
doesn't really support the feature isolation excepting in a few ways.
Also want to point out features like AA more or less need everything
calculated on each ray to most accurately know what to do AA-wise. You
can of course blur or render large and scale - but then we'd be faking
AA-ish behaviors. Keeping billions of rays and associated information
around and updating just some information is probably not manageable.
Sampling, interpolation - on the fly 'uv' mapping everything with layers
maybe, but complex. I don't know - seems unlikely to happen in any case
with the resource in play.
I'll keep your ideas in mind. Perhaps we can push some aspects forward.
I've myself played recently some with creating general textures via a
sort of Z depth sliced/mapped version of a scene using the depth map
patch and an orthographic camera.
On my to play with list - once I sort out the photon file format - is to
try creating lighting effects via loaded photon files created/deposited
by some form of the depth map patch rather than by shooting photon rays.
(1) - The conditional tests themselves take time. Plus, a question
banging around in my head of late is whether the speculative execution
of paths never taken - but at least partly executed - are affecting
cache performance and so overall performance?
Hmm, maybe a shipped dual form of POV-Ray. Once with the odd ball
features hard coded off and another with those conditionals still
'conditional'. Put a switch way up top - not in the tracing path - that
would pick which 'POV-Ray' to use. Taken to extremes might each quality
level be it's own hard coded engine. Anyway... Ideas for the maybe try
it someday list.
Post a reply to this message