Hi!

Just switched from PovRay to MegaPOV to create a depth map using the
PP_Init_Depth_Output() / PP_Depth(min,max) postprocessing feature.

Unfortunately the postprocessing is currently a re-rendering, getting image
+ depth map takes twice as long as getting only the image (also in the +D0
graphical output I see the depthmap being rendered line by line on top of
the image).

So I figured that the internal storage of the depth information does not
work during the main render pass (even though I used PP_Init_Depth_Output),
and MegaPOV has to render a second time.
I looked for additional options to activate an internal buffer and saw that
old PovRays supported 'Buffer_Output' and 'Buffer_Size'. Or what else do I
need to activate?

Many thanks for your help and the great work on MegaPOV,

Elmar

Post a reply to this message

Elmar Krieger wrote:
> Hi!
> 
> Just switched from PovRay to MegaPOV to create a depth map using the
> PP_Init_Depth_Output() / PP_Depth(min,max) postprocessing feature.
> 
> Unfortunately the postprocessing is currently a re-rendering,

That's not correct.

> getting image
> + depth map takes twice as long as getting only the image (also in the +D0
> graphical output I see the depthmap being rendered line by line on top of
> the image).

That is quite possible.

> So I figured that the internal storage of the depth information does not
> work during the main render pass (even though I used PP_Init_Depth_Output),
> and MegaPOV has to render a second time.

No, the current post processing is simply not very efficient (it is 
designed to be very flexible but this limits performance quite 
significantly).  What you think is a second render is simply gathering 
the depth information from the data stored during the main render.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

> No, the current post processing is simply not very efficient (it is
> designed to be very flexible but this limits performance quite
> significantly).  What you think is a second render is simply gathering
> the depth information from the data stored during the main render.

Thanks for your quick reply Christoph.
Is there maybe a trick to bypass the macro bottleneck and quickly dump the
collected depth + normal information into a binary file which I can then
analyze myself? (especially the edge detection is a factor 100 slower than
the actual rendering).

Greetings,
Elmar

Post a reply to this message

Elmar Krieger wrote:
> 
> Thanks for your quick reply Christoph.
> Is there maybe a trick to bypass the macro bottleneck

What macro bottleneck?

> and quickly dump the
> collected depth + normal information into a binary file which I can then
> analyze myself?

The data is written to a temporary file.  The format of this is 
currently not documented though.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

On Fri, 29 Jul 2005 09:13:46 EDT, "Elmar Krieger" <elm### [at] cmbirunl> wrote:
> Is there maybe a trick to bypass the macro bottleneck and quickly dump the
> collected depth + normal information into a binary file

If you only need depth and normal, I do not understand why you need MegaPOV.
trace() functions does it in POV-Ray. But indeed it can be simpler sampling
over camera_view during parsing and skip rendering part. Would that be
sufficient temporary solution?

ABX

Post a reply to this message