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:

https://github.com/wfpokorny/povray/tree/independent/PGMimageDepthMap

For details see similarly titled post to povray.unofficial.patches.

Bill P.

Post a reply to this message

Attachments:
Download 'depthmapstory.png' (108 KB)

Preview of image 'depthmapstory.png'

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:
>
> https://github.com/wfpokorny/povray/tree/independent/PGMimageDepthMap
>
> 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 ?

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")

imagine outputting all of this after just pushing render once and going for a
coffee !

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.

Bill P.

(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