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

Download and compile rather than pull probably best. The generated 
povray module should be copied somewhere executable like $HOME/bin and 
renamed pDepth, povrayPGMDepthMap or the like.

No scene modifications are needed, but turnig off photons and radiosity 
will help performance. This version of POV-Ray itself hard coded to run 
a pixel at a time with options creating additional camera rays like AA 
and focal blur hard coded off. Output is always to a file called 
depth.pgm in plain text format and linear values normalized to a range. 
Option SDL variables and defaults are:

DepthMapMin           = 0.0;
DepthMapMax           = 1000.0;
DepthMapPGMDepth      = 65535.0;
DepthMapRangeXVal     = 0.0;
DepthMapComments      = 0.0;   (*) - Float depth from ray origin.
DepthMapIntersections = 0.0;   (*) - Where intersections in range.
DepthMapNormals       = 0.0;   (*) - Raw shape normal at intersection.
DepthMapRayOrigins    = 0.0;
DepthMapRayDirections = 0.0;

These options can be set with the existing Declare=<var_name>=<float> 
command line mechanism. For example, the sample balcony.pov and 
woodbox.pov scenes in the image posted to povray.binaries.images were 
rendered with:

pDepth +W450 +h600 balcony.pov Declare=DepthMapMin=0 Declare=DepthMapMax=800

and

pDepth +W800 +h600 woodbox.pov Declare=DepthMapMin=10 
Declare=DepthMapMax=50 \
    Declare=DepthMapPGMDepth=15

If you turn on comments these get added to the pgm file. 
DepthMapComments must be on (not 0.0) to get other information. So the 
command:

pDepth +W400 +h300 woodbox.pov Declare=DepthMapMin=10 
Declare=DepthMapMax=50 \
        Declare=DepthMapComments=1 \
        Declare=DepthMapIntersections=1 Declare=DepthMapNormals=1

creates an ascii pgm file where the first lines look like:

P2
400
300
65535
# DepthMapMin = 10.000  DepthMapMax = 50.000  for mapped range of = 40.000
51196  # 41.2482798167746 I=<-7.6527354,6.4294999e-17,24.929733> N=<0,1,0>
51151  # 41.2204724321481 I=<-7.5807234,-8.7917847e-17,24.905729> N=<0,1,0>
... and so on

There is a significant performance hit given this feature is hanging on 
a debug mechanism. Strongly recommend running on a ramdisk as the file 
I/O opens and closes the file on every string write. Further files can 
get really large depending upon selected output.

---- Performance woodbox.pov with v3.8 master 400 x 300 no AA
Original scene on my 2 core 4 thread i3: 1.22s

---- Performance hit with pDepth
Blocksize 1x1 with 1 thread:             3.98s
Creating depth map pgm no comments       5.82s
Comments on. Ray origins and directions  7.96s

Note. POV-Ray itself fails on image read when the comments are present 
in the output depth.pgm. All the other programs I've tried work OK - 
including netpbm programs. To the netpbm site documents on file formats, 
I think POV-Ray correct. It's just not what netpbm itself actually does 
for the plain ascii format. Run without comments if using the depth.pgm 
directly as input to POV-Ray.

To view pgm bit depths >255 (ie using 16 bit channel) on a srgb-ish 
display environment correctly you may need to use POV-Ray itself. The 
programs I most frequently use for viewing seem to be mapping internally 
to 0-255 channel ranges. I see more banding with 16 bit channel outputs 
than should be. A small scene file which can be used for viewing 16 bit 
pgm output with POV-Ray follows. The view is gamma corrected one of the 
linear depth.pgm. Specifying proportionally matching width and height to 
the depth.pgm file, use your normal version of POV-Ray as in:

povray asPGMViewer.pov +p

Bill P.

//------------- Start asPGMViewer.pov
#version 3.8;
// Scene using POV-Ray as linear pgm file srgb-viewer.
// Use +w +h values which match pgm file's.
global_settings { assumed_gamma 1 }
#declare Grey20 = srgb <0.2,0.2,0.2>;
background { color Grey20 }
#declare VarOrthoMult = 
1.0/max(image_width/image_height,image_height/image_width);
#declare Camera01z = camera {
     orthographic
     location <0,0,-2>
     direction z
     right VarOrthoMult*x*max(1,image_width/image_height)
     up VarOrthoMult*y*max(1,image_height/image_width)
}
#declare FileName = "depth.pgm"
#declare ImageMap00_P = pigment { image_map { FileName gamma 1 
interpolate 2 }};
#declare ImageMap00_Range = max_extent(ImageMap00_P);
#declare ImageMap00_NrmScale =
     <min(1,ImageMap00_Range.x/ImageMap00_Range.y),
      min(1,ImageMap00_Range.y/ImageMap00_Range.x),1>;
#declare Finish00 = finish { ambient rgb 1 }
#declare Pigment00 = pigment {
     image_map { FileName
         gamma 1
         premultiplied off
         map_type 0
         once
         interpolate 2
     }
}
#declare Texture00 = texture {
     pigment { Pigment00 }
     finish { Finish00 }
}
#declare Box00 = box { <0,0,0>,<1,1,1> }
#declare Object00 = object {
     Box00
     texture { Texture00 }
     translate <-0.5,-0.5,0>
     scale ImageMap00_NrmScale
}

//--- scene ---
    camera { Camera01z }
    object { Object00 }

//------------- end asPGMViewer.pov

Post a reply to this message

Not having really ever compiled much from scratch, perhaps someone can give some
details about what might seem painfully obvious, but isn't to the uninitiated.

"Download and compile rather than pull probably best. The generated
povray module should be copied somewhere executable like $HOME/bin and
renamed pDepth, povrayPGMDepthMap or the like."

What needs to be done first?
I'm assuming all of that pre-install stuff in the readme.md

Then "download".   OK.  What file - like a filename.tar.z - where best to
download it TO?  /home/username/downloads?

But now it has to be extracted...  do this in the downloads directory?

"compile" - I'm assuming this has to do with the "make" instructions - which
don't make much sense to me at the moment, but maybe the unix/ directory is in
the extracted directory structure?  As well as the prebuild.sh shell script?

I don't have a $HOME/bin directory - just make one?  Details for posterity,
please.

Thanks so much   :)


ALSO:
How do I get the files necessary to play with _this_:
http://wiki.povray.org/content/User:Wfpokorny/DensityFile/FillingVolumeWithShapes

Post a reply to this message

hi,

no idea about the patch, just a couple of general points.

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Not having really ever compiled much from scratch, perhaps someone can give some
> details about what might seem painfully obvious, but isn't to the uninitiated.
>
> "Download and compile rather than pull probably best. The generated
> povray module should be copied somewhere executable like $HOME/bin and
> renamed pDepth, povrayPGMDepthMap or the like."
>
> What needs to be done first?
> I'm assuming all of that pre-install stuff in the readme.md
>
> Then "download".   OK.  What file - like a filename.tar.z - where best to
> download it TO?  /home/username/downloads?

I tend to use a scratch directory like /tmp/xx/ for downloading + exploring
stuff.  since /tmp/ typically lives in memory, file ops are fast(er).

> But now it has to be extracted...  do this in the downloads directory?
>
> "compile" - I'm assuming this has to do with the "make" instructions - which
> don't make much sense to me at the moment, but maybe the unix/ directory is in
> the extracted directory structure?  As well as the prebuild.sh shell script?

confused, is this a povray executable you're talking about?


> I don't have a $HOME/bin directory - just make one?

yes.  just create one, and add something like the following to your '.bashrc'
file:

export PATH="~/bin:$PATH"

from your next login you'll be able to run any executable stored in '~/bin/'
like any system command.  (your '~/bin/' as first PATH element so you can
override system commands with own, same-named ones).


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> confused, is this a povray executable you're talking about?

Confused about your confusion.
You are correct - it's the experimental fork referenced in WP's link in the
initial post.

I'm also keenly interested in installing and experimenting with Jerome
Grimbert's HgPovRay38 fork, with all of the goodies he's implemented in that.

So, I just want to know that I'm doing the right thing[s] when trying to install
it, and not mucking up my OS directory with all sorts of cruft that doesn't
belong there, or doing something stupid whilst in sudo mode.

see:
https://github.com/LeForgeron/povray/blob/hgpovray38/unix/install.txt
https://github.com/LeForgeron/povray/blob/hgpovray38/unix/README.md
https://bitbucket.org/LeForgeron/povray/wiki/Compilation

And if there's a way I can start playing with some source code and trying to
compile my OWN fork, as a learning experience, then that would be super cool as
well.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > confused, is this a povray executable you're talking about?
> Confused about your confusion.
> You are correct - it's the experimental fork referenced in WP's link in the
> initial post.
>
> I'm also keenly interested in installing and experimenting with Jerome
> Grimbert's HgPovRay38 fork, with all of the goodies he's implemented in that.
>
> So, I just want to know that I'm doing the right thing[s] when trying to install
> it, and not mucking up my OS directory with all sorts of cruft that doesn't
> belong there, or doing something stupid whilst in sudo mode.

haven't got the actual url to hand, but for stock POV-Ray, I do the following,
as regular user:

- make a directory, eg /tmp/P, and cd into it.
- use 'wget' to retrieve the archive.
- unpack the archive with 'tar xf filename'.
- change into the (newly created) povray directory.
- execute '( cd unix ; ./prebuild.sh)'.  note the parentheses around the
commands.
- run './configure', usually first with '--no-create --help' to look see the
stuff that may need adapting.
- run 'make'.

if you capture the whole configuration and compile sequence with something like
'typescript(1)', you have a "log" in case of problems.  only actual install
needs be done with privilege.

>
> see:
> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/install.txt
> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/README.md
> https://bitbucket.org/LeForgeron/povray/wiki/Compilation
>
> And if there's a way I can start playing with some source code and trying to
> compile my OWN fork, as a learning experience, then that would be super cool as
> well.

good luck.  enjoy.


regards, jr.

Post a reply to this message

On 7/15/19 6:28 PM, jr wrote:
> hi,
> 
...
> haven't got the actual url to hand, but for stock POV-Ray, I do the following,
> as regular user:
> 
> - make a directory, eg /tmp/P, and cd into it.
> - use 'wget' to retrieve the archive.
> - unpack the archive with 'tar xf filename'.
> - change into the (newly created) povray directory.
> - execute '( cd unix ; ./prebuild.sh)'.  note the parentheses around the
> commands.
> - run './configure', usually first with '--no-create --help' to look see the
> stuff that may need adapting.
> - run 'make'.
> 
> if you capture the whole configuration and compile sequence with something like
> 'typescript(1)', you have a "log" in case of problems.  only actual install
> needs be done with privilege.
> 
>> see:
>> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/install.txt
>> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/README.md
>> https://bitbucket.org/LeForgeron/povray/wiki/Compilation
>>
>> And if there's a way I can start playing with some source code and trying to
>> compile my OWN fork, as a learning experience, then that would be super cool as
>> well.
> 
...
> 
I'm partly back from my break away... Always interesting to see how 
others are working and compiling compared to me. To what jr and Jerome 
have said, I'll somewhat randomly add:

- While /tmp is ramdisk on some systems I don't think this today true 
for Debian based ones like mint - but maybe. You can check with the 'df' 
command which run from an xterm window will spit out a bunch of lines, 
one of which should be something like:

tmpfs            8108248     37556   8070692   1% /tmp

if your /tmp is running on the tmpfs ram disk. If not, it can be changed 
to be so or you can use one of the other ram disk directories which 
typically exist. Look for tmpfs lines in the df output. /run and 
/dev/shm are common user ram disks. I have long used /run/shm/<DirNames> 
on Ubuntu though suppose /run falling out of favor. You should have a 
reasonable amount of ram (min 8GB I'd say) to use ram disk. Use regular 
drives if you know you'll be creating files larger than the free space 
shown by the df command for any tmpfs directory.

- Instead of wget to grab the github zips, I usually just go the to 
github web page for the branch and click the green clone/download button 
which pops up a window with a download zip at the bottom.

- With implementations like the depthmap patch, hgpovray38 or uberpov 
downloading the zip compiling and putting the created 'povray' load 
module somewhere in the executable path with a unique name usually OK 
(uberpov installs apart from povray so make install OK in that case). 
With my other public, routinely re-based to master branches such as:

https://github.com/wfpokorny/povray/tree/update/JG_sdl2

the intent is for users to be set up with git and to be staying current 
with the master development branch. Then, to add any of my published 
features to the current master, you'd do something like the following 
from the master branch in git:

git branch pUltra
git checkout pUltra
git branch --set-upstream-to master pUltra

git pull https://github.com/wfpokorny/povray.git 
feature/newDensityPatternInterpolations

git pull https://github.com/wfpokorny/povray.git update/JG_sdl2

git pull . feature/MyVortex    ;# <-- Your Vortex branch.

...

After which you'd do the normal build sequence. You end up with a 
personal version of POV-Ray with all the additional features you want. 
With my published branches you could download the matching zip and 
compile - but then you'd have only that feature in addition to what's in 
master.

Aside: re-basing branches to master is what I do today and it takes time
on each re-base. My branches not always current with the most recent 
commit. As I write this they are, but - check. The branches I publish 
are today all pull-able / merge-able with master - you can use them all 
at once. Might or might not be true if personal or other's branches are 
pulled too. Modern code control is great, but colliding changes have to 
be sorted out (or avoided) in the end.

- In addition to the packages listed in the <...>/unix/README.md file I 
would also recommend installing sdl2 if you plan to use hgpovray38 or my 
JG_sdl2 patch. I've been running with Jerome's sdl2 update for months 
with good result. If sdl2 not already installed use:

sudo apt-get install libsdl2-dev

Note. Unlike most packages where you don't want to specify the version 
to get the linux package's supported version. It is needed with libsdl2 
due libsdl1.2 being dissimilar to 2.* versions. Install git if you plan 
to roll your own branches or version of POV-Ray.

- Perhaps useful. I use the following (debian) command to check what is 
already installed:

dpkg -l | grep sdl

Which for me shows both libsdl1.2-dev and libsdl2-dev given I run 
versions of POV-Ray using both.

- If you'll be running multiple versions of POV-Ray routinely you might 
find installs to unique directories and the wrapper script approach, 
discussed most recently at: 
https://github.com/POV-Ray/povray/issues/374, useful. The build 
processes are today set up to support only one install of a version at a 
time in a target directory. When you run the configure script you can 
specify an install directory in your local space for each compiled 3.8 
version. Individual wrapper scripts then can run each.

Hope my rambling of some help.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/15/19 6:28 PM, jr wrote:
> > haven't got the actual url to hand, but for stock POV-Ray, I do the following,
> > as regular user:
> > ...

> I'm partly back from my break away... Always interesting to see how
> others are working and compiling compared to me.

ah, I now wish I'd been more truthful.  :-)  I do the steps outlined up to
running ./configure --help, but from then it's editing a copy of the package
build script of the previous POV-Ray installed, then executing that.

(snipped good stuff on tmpfs)

> - Instead of wget to grab the github zips, I usually just go the to
> github web page for the branch and click the green clone/download button
> which pops up a window with a download zip at the bottom.

I always prefer the .tar.gz archive, when there's a choice.

> - If you'll be running multiple versions of POV-Ray routinely you might
> find installs to unique directories and the wrapper script approach,
> discussed most recently at:
> https://github.com/POV-Ray/povray/issues/374, useful. The build
> processes are today set up to support only one install of a version at a
> time in a target directory. When you run the configure script you can
> specify an install directory in your local space for each compiled 3.8
> version. Individual wrapper scripts then can run each.

thank you for the link, I'll need to think about that tip.  (I currently rename
the executables to their full names and use bash aliases like 'pov371', 'pov38',
and 'pov38x', but that means shared documentation etc)


> Hope my rambling of some help.

sure was.  :-)


regards, jr.

Post a reply to this message

"Then, to add any of my published
features to the current master, you'd do something like the following
from the master branch in git:

git branch pUltra
git checkout pUltra
git branch --set-upstream-to master pUltra

git pull https://github.com/wfpokorny/povray.git
feature/newDensityPatternInterpolations

git pull https://github.com/wfpokorny/povray.git update/JG_sdl2

git pull . feature/MyVortex    ;# <-- Your Vortex branch.

....

After which you'd do the normal build sequence."

I guess I have to read up on exactly what git does and how it works.
trying
git branch pUltra
or
git pull https://github.com/wfpokorny/povray.git
gave me a "not a git repository" error

I'm assuming it's more complicated than just downloading an extra file or two
before the compiling, since there's stuff that needs to get integrated in
several places.


But I did get hgpovray38 downloaded and installed, so that's a start   :)

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I guess I have to read up on exactly what git does and how it works.

there's a free ebook "Pro Git".  https://git-scm.com/book/en/v2


regards, jr.

Post a reply to this message