POV-Ray : Newsgroups : povray.unofficial.patches : POVRay 3.7 with depth-map unofficial patch release Server Time
17 Sep 2021 20:59:27 EDT (-0400)
  POVRay 3.7 with depth-map unofficial patch release (Message 11 to 17 of 17)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: jhu
Subject: Re: POVRay 3.7 with depth-map unofficial patch release
Date: 9 Nov 2011 20:25:00
Message: <web.4ebb2773554df4f5d19b0ec40@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

> One reason is that we want 3.7.0 release proper to be fit for
> distribution without having to apologize for a bunch of remaining flaws.
> Something that can be used not only by POV-Ray veterans, but also by
> newbies, without much hassle. After all, we've already made the software
> available (well, mostly that is) for people who don't mind the flaws; we
> just called it "3.7.RC3", because we don't think it deserves to be
> called a release proper yet.

I guess. At least for the Linux version, there could just be an official static
32-bit and 64-bit binary so people don't have to go through the trouble of
compiling.


Post a reply to this message

From: jhu
Subject: Re: POVRay 3.7 with depth-map unofficial patch release
Date: 9 Nov 2011 20:50:01
Message: <web.4ebb2cc7554df4f5d19b0ec40@news.povray.org>
"jhu" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> > One reason is that we want 3.7.0 release proper to be fit for
> > distribution without having to apologize for a bunch of remaining flaws.
> > Something that can be used not only by POV-Ray veterans, but also by
> > newbies, without much hassle. After all, we've already made the software
> > available (well, mostly that is) for people who don't mind the flaws; we
> > just called it "3.7.RC3", because we don't think it deserves to be
> > called a release proper yet.
>
> I guess. At least for the Linux version, there could just be an official static
> 32-bit and 64-bit binary so people don't have to go through the trouble of
> compiling.

Speaking of which I just compiled a generic 64-bit x86-64 version with gcc 4.6.1
for Linux if anyone is interested.


Post a reply to this message

From: Le Forgeron
Subject: Re: POVRay 3.7 with depth-map unofficial patch release
Date: 10 Nov 2011 04:58:25
Message: <4ebba041@news.povray.org>
Le 10/11/2011 02:22, jhu a écrit :
> clipka <ano### [at] anonymousorg> wrote:
> 
>> One reason is that we want 3.7.0 release proper to be fit for
>> distribution without having to apologize for a bunch of remaining flaws.
>> Something that can be used not only by POV-Ray veterans, but also by
>> newbies, without much hassle. After all, we've already made the software
>> available (well, mostly that is) for people who don't mind the flaws; we
>> just called it "3.7.RC3", because we don't think it deserves to be
>> called a release proper yet.
> 
> I guess. At least for the Linux version, there could just be an official static
> 32-bit and 64-bit binary so people don't have to go through the trouble of
> compiling.

Even with "static", the issue on Linux (and that does not cover all
unix), is the version of libc (which must remains shared);
If you compile for a old libc, fresh system might not have it anymore.
If you compile for a fresh libc, old system might not have it yet.

Moreover, many distributions are happy to make the packaging (especially
if the license turns finally in GPL): debian & ubuntu have their own
povray packages, and i guess redhat has too.

But usually they like stable definitive version, so getting out of RC
stage would be a could step... flyspray 219 and 225 are IMHO the most
blocking (i would say the only blocking) issue.
If you get any clue, I guess you are welcome.
(flyspray 226 might also need an eye, but it's probably a small change
in a constant)


Last but not least: the performance are better if you can compile for
your architecture instead of having to compile in multiple mode with
maximum compatibility (aka 32 bits is compiled for 86386, and 64 bits is
compiled for the first generation of 64 bits...)

(in fact, the performance is even better with the Intel compiler than
with the gnu one, but that's another story)

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.


Post a reply to this message

From: jhu
Subject: Re: POVRay 3.7 with depth-map unofficial patch release
Date: 10 Nov 2011 10:50:01
Message: <web.4ebbf277554df4f5d19b0ec40@news.povray.org>
Le_Forgeron <lef### [at] freefr> wrote:

>
> Even with "static", the issue on Linux (and that does not cover all
> unix), is the version of libc (which must remains shared);
> If you compile for a old libc, fresh system might not have it anymore.
> If you compile for a fresh libc, old system might not have it yet.
>

sThat is incorrect. For example, here's the ldd output of several programs on my
system:

$ ldd `which ls`
 linux-vdso.so.1 =>  (0x00007fff6dfab000)
 libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007ffe5096f000)
 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ffe50767000)
 libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007ffe5055e000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffe501da000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffe4ffd6000)
 /lib64/ld-linux-x86-64.so.2 (0x00007ffe50b9f000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffe4fdb9000)
 libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007ffe4fbb5000)

$ ldd `which povray`
 not a dynamic executable

In the first instance, you'll notice that the program "ls" is dynamically linked
to libc.so.6. In the second instance you'll see that "povray" has everything
compiled into the binary. I used to run Linux From Scratch, and one of the first
stages is to cross-compile an initial statically linked system (even gcc!). At
that point, all programs on the system worked despite the lack of libc.

The only real issue is Linux version that the program is run. If the static
binary was compiled on a Linux 2.6.* system, it might not run on a Linux 2.2.*
system.


>
> Last but not least: the performance are better if you can compile for
> your architecture instead of having to compile in multiple mode with
> maximum compatibility (aka 32 bits is compiled for 86386, and 64 bits is
> compiled for the first generation of 64 bits...)

Yes, performance is better, but some people just don't want to bother. Why else
would there be official Windows, Mac, and Linux binaries? Otherwise Povray would
just be a source distribution only.

>
> (in fact, the performance is even better with the Intel compiler than
> with the gnu one, but that's another story)

That's debatable and depends on the processor.


Post a reply to this message

From: cjaramillo
Subject: Re: POVRay 3.7 with depth-map unofficial patch release
Date: 27 Oct 2017 20:45:01
Message: <web.59f3d1fc554df4f57659d60a0@news.povray.org>
"handos" <han### [at] gmailcom> wrote:
> Hi Le,
>
> I've kept a README_ANKUR here at
> https://github.com/ankurhanda/povray.3.7.0.RC3.withdepthmap/blob/master/README_ANKUR
> where I explained how to use it and what output files it dumps alongside
> output.png
> There is no such enable-disable depth-map facility at the moment but I guess it
> shouldn't be too hard.
>
> I just saw that in the other forum you'd posted the answer to my question on how
> to get the camera parameters and which file to look in ;-). Thanks for that.
>
> Thanks a lot!
> Ankur.
>
>
> Le_Forgeron <jgr### [at] freefr> wrote:
> > Le 18/07/2011 00:05, handos nous fit lire :
> > > Hi Le,
> > >
> > > Thanks for having spent time on this. I understand that it's not cleaned up yet
> > > but it's just a small rudimentary version of the patch I created. I'd take your
> > > advice and clean up a bit so that it's easy for other guys to understand.
> > > My intention here was to just get some good feedback on it.
> > >
> > > Regarding the purpose, there are many applications in computer vision or
> > > graphics where one would like to have a depth-map corresponding to the image.
> > > And one might need to obtain 3D coordinates for each pixel observed in the image
> > > to aid  3D reconstruction or applications related to Augmented Reality. I had
> > > searched in the POVRay website to see if anyone had done that before with
> > > POVRay-3.7. I guess maybe working on depth-map is quite specific but just in
> > > case anyone wanted to have a depth-map along with image, it might be worth
> > > taking a look at this patch I released.
> > >
> > > I'd definitely add the original version of 3.7 into my git-hub so that it's easy
> > > to find out the patches I created.
> > >
> > > Thanks a lot!
> >
> > Nice. I would still need a basic tutorial about what happen (from an
> > external user's point of view).
> >
> > For instance, take a scene.pov; With normal 3.7RC3, the command line
> > would be "foo bar zorglub scene.pov" (well probably something more like
> > "povray -Iscene.pov -H480 -W640 +A0.01 +FN")
> > The output would be a png file, named scene.png.
> >
> > With your patched version, if I want the depth map, what is the command
> > line ? If I do not want the depth map, can I expect using the 3.7RC3
> > command line with the new binary or do I need something else ?
> > How is named the depth map file ?
> > What is its format ? How can I see it (I would like to be impressed like
> > a lambda Mac/Iphone/Ipad user: no internal techniques, just nice pictures) ?
> > Is the camera position & setting output in another file (what is its
> > name ?) or is that part of the depth map file ?
> >
> > I'm sure the people dealing with depth map on a daily basis all know
> > this stuff, but so far the poor neophytes are just left on the side of
> > the road without a clue.

Hi, Ankur. Did the POV-Ray maintainers ever let you merge your depth map
generation patch into the official code? I'm looking for a way to achieve
generating depth maps for the rendered files as you did for the ICL-NUIM
dataset.

Thanks,

Carlos


Post a reply to this message

From: clipka
Subject: Re: POVRay 3.7 with depth-map unofficial patch release
Date: 28 Oct 2017 07:14:02
Message: <59f4667a$1@news.povray.org>
Am 28.10.2017 um 02:40 schrieb cjaramillo:

> Hi, Ankur. Did the POV-Ray maintainers ever let you merge your depth map
> generation patch into the official code? I'm looking for a way to achieve
> generating depth maps for the rendered files as you did for the ICL-NUIM
> dataset.

So far, official POV-Ray does not have any such feature.

You /can/ create depth maps "out of the box" though, provided you have
control over the scene's textures.

To do that, use `finish { diffuse 0 specular 0 phong 0 ambient 0
emission 1 }`, and a gradient pigment rotated and translated in such a
way that it aligns with the camera.

Make sure to render to a 16-bit image format or OpenEXR, or your depth
map precision will be pretty low.


Post a reply to this message

From: William F Pokorny
Subject: Re: POVRay 3.7 with depth-map unofficial patch release
Date: 28 Oct 2017 11:53:06
Message: <59f4a7e2$1@news.povray.org>
On 10/28/2017 07:14 AM, clipka wrote:
> Am 28.10.2017 um 02:40 schrieb cjaramillo:
> 
...
> 
> So far, official POV-Ray does not have any such feature.
> 
> You /can/ create depth maps "out of the box" though, provided you have
> control over the scene's textures.
> 
> To do that, use `finish { diffuse 0 specular 0 phong 0 ambient 0
> emission 1 }`, and a gradient pigment rotated and translated in such a
> way that it aligns with the camera.
> 
> Make sure to render to a 16-bit image format or OpenEXR, or your depth
> map precision will be pretty low.
> 

Also doable "out of the 3.7 box," I've played with storing and 
retrieving +-64bit values in df3 files and there is a small, 
orthographic depth map example using the technique at:

http://wiki.povray.org/content/User:Wfpokorny/DensityFile/DepthMap64BitDf3RsltStoreExample

which also needs parts of the arraycoupleddf3s.inc file at:

http://wiki.povray.org/content/User:Wfpokorny/DensityFile/arraycoupleddf3s

While you do have to create a union of all objects you want as part of 
the depth map to pass to trace(), the approach doesn't require any 
special texture set up. Further because the 'depth value df3' can be 
wrapped in a function the +-64bit values can be used in later renders.

As SDL code using trace() and executed by the parser the approach is not 
fast(1) and be a little paranoid using the related include file macros. 
While I think the df3 value storage/retrieval code OK, and it worked in 
one real project of mine, it has not been much used in practice.

Bill P.

(1) With some planning and care you can run more than one povray-parser 
at a time when creating data for later use.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.