 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Please forgive me if I'm being ignorant but from what Ron has said
about planar applied rays (sorry Ron, I'm quoting vaguely) versus
spherical it seems the "depth" is not a part of the original
calculations. Could that be true at all? For instance, a scene gets
figured orthographically first maybe and then any other camera
perspectives are added into that afterward, like a sort of non-ray
warping?
Just curious now.
Bob
Simen Kvaal <sim### [at] student matnatuiono> wrote in message
news:37e8b591@news.povray.org...
> I am replying to my own post, now, because I've developed a way to
do what I
> wanted. I hope this could be of use to anyone who needs a
depth-buffer from
> a pov-ray scene.
>
> I looked at an old pov-zine, and there it was mentioned that if I
removed
> all texures from the object and applied a deafult texture with
gradient
> which varies from white (near) to black (far) in the direction of
the
> looking vector of the camera, then I'd essentially get the depth
information
> in the rendering. Near points would be white and black points would
be the
> ones far away.
>
> Some of you asked why someone would want tihis? One answer, (not
mine), is
> to use then in a SIRDS-program, which requires depth information
from the
> scene in order to generate the illusion of depth. This method works
fine for
> that purpose.
>
> However, I wanted a real Z-buffer output. I am testing a shading
program I
> have written and want to use some objects that I really know what
looks
> like. I have generated several million random points that form a
shape in
> three dimensions. POV cannot easily handle that many spheres, so
I've
> written a program that makes a Z-buffer and shades the scene from
that. In
> order to test the performance, I needed som Z-buffers of "real"
world
> things, like cubes, spheres, torii et.c. Then it would be easy too
se how
> realistic the shading of the z-buffer was. (It's hard to see with
some
> smoke-resembling cluod of dots.)
>
> To the point. Here is a scene I wrote this morning (local time):
>
>
> // beginning of code:
>
> #declare cam_pos = <0,0, -5>
> #declare cam_rot = <20, 0, 0>
> #declare max_depth = 10;
> #declare min_depth = 1;
>
>
> default {
> texture {
> pigment {
> onion
> color_map {
> [0.0 color rgb 1]
> [1.0 color rgb 0]
> }
> phase min_depth/(max_depth-min_depth)
> scale (max_depth-min_depth)
> }
> finish { ambient 1 diffuse 0 }
> translate cam_pos
> rotate cam_rot
>
> }
> }
> camera {
> location cam_pos
> direction z
> up y
> right 4/3*x
> look_at 0
> rotate cam_rot
> }
>
> box {-1, 1 rotate <50, 40>}
>
> // end of code.
>
>
> This scene is a general case. I can change the camera position in
cam_pos
> and rotation in cam_rot and still generate a z-buffer output. If I
used a
> simple gradient texture, I would have errors. Mainly because of
perspective
> distortion. Points on the edge of the image which have color w, say
0.8,
> would actually be farther away than a point with color w in the
middle of
> the image. The solution was to use the onion procedural texture,
which is
> cocentric spheres centered at the origin. For the depth-view
purposes, the
> texture is translated to the camera location, so that the centre of
the
> spheres is located at the view-point. Then, it is rotated, if the
camera is
> rotated to a new place.
>
> By using this method, one can easily verify that a point (x,y,z)
with
> distance d from the eye, would get the same color as any other point
(x1,
> y1, z1) with distance d from the eye.
>
> The next problem is scaling of the texture. The texture has
originally a
> range of 1, that is it wraps from black to white every 1 units from
the
> centre of the texture, that is the eye in this case. We want to
scale it so
> that the nearest *visible* point gets a shade close to white, while
the
> farthest visible point gets a shade closer to black. There must be
no
> wrapping, or else we would get wrong depth-information.
>
> The solution is quite easy, you scale and offset the wrapping of the
texture
> with
> phase min_depth/(max_depth-min_depth)
> scale (max_depth-min_depth)
>
> where max_depth is an estimate of the distance to the farthest point
we want
> to shade, and min_depth is the distance to the nearest.
>
> The output from this source is an approximate depth-buffer from the
scene,
> which then can be used as wished.
>
> Simen.
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 22 Sep 1999 16:37:19 -0500, Bob Hughes wrote:
>Please forgive me if I'm being ignorant but from what Ron has said
>about planar applied rays (sorry Ron, I'm quoting vaguely) versus
>spherical it seems the "depth" is not a part of the original
>calculations. Could that be true at all? For instance, a scene gets
>figured orthographically first maybe and then any other camera
>perspectives are added into that afterward, like a sort of non-ray
>warping?
Nope, not true at all. The camera type is the only thing that determines
the distribution of the eye rays that are shot into the scene.
My calculations were for a standard perspective camera, as that was the
only kind available in POV 2.2. They'd do weird things with the newer
camera types.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Great, thanks for making that clear to me. Camera is the key I guess
a person could say. I knew of the typical concept of rays going from
camera to scene rather than from scene to camera, just wondered of
that possible final derivitive because it sure sounded like it was a
two step process you were talking about. I need to stay out of the
logistics of it anyway if I can't work with them : )
Bob
Ron Parker <par### [at] fwicom> wrote in message
news:37e94fdb@news.povray.org...
> On Wed, 22 Sep 1999 16:37:19 -0500, Bob Hughes wrote:
> >Please forgive me if I'm being ignorant but from what Ron has said
> >about planar applied rays (sorry Ron, I'm quoting vaguely) versus
> >spherical it seems the "depth" is not a part of the original
> >calculations. Could that be true at all? For instance, a scene
gets
> >figured orthographically first maybe and then any other camera
> >perspectives are added into that afterward, like a sort of non-ray
> >warping?
>
> Nope, not true at all. The camera type is the only thing that
determines
> the distribution of the eye rays that are shot into the scene.
>
> My calculations were for a standard perspective camera, as that was
the
> only kind available in POV 2.2. They'd do weird things with the
newer
> camera types.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Simen Kvaal" <sim### [at] studentmatnatuiono> wrote:
> I am replying to my own post, now, because I've developed a way to do what I
> wanted. I hope this could be of use to anyone who needs a depth-buffer from
> a pov-ray scene.
>
> I looked at an old pov-zine, and there it was mentioned that if I removed
> all texures from the object and applied a deafult texture with gradient
> which varies from white (near) to black (far) in the direction of the
> looking vector of the camera, then I'd essentially get the depth information
> in the rendering. Near points would be white and black points would be the
> ones far away.
>
> Some of you asked why someone would want tihis? One answer, (not mine), is
> to use then in a SIRDS-program, which requires depth information from the
> scene in order to generate the illusion of depth. This method works fine for
> that purpose.
>
> However, I wanted a real Z-buffer output. I am testing a shading program I
> have written and want to use some objects that I really know what looks
> like. I have generated several million random points that form a shape in
> three dimensions. POV cannot easily handle that many spheres, so I've
> written a program that makes a Z-buffer and shades the scene from that. In
> order to test the performance, I needed som Z-buffers of "real" world
> things, like cubes, spheres, torii et.c. Then it would be easy too se how
> realistic the shading of the z-buffer was. (It's hard to see with some
> smoke-resembling cluod of dots.)
>
> To the point. Here is a scene I wrote this morning (local time):
>
>
> // beginning of code:
>
> #declare cam_pos = <0,0, -5>
> #declare cam_rot = <20, 0, 0>
> #declare max_depth = 10;
> #declare min_depth = 1;
>
>
> default {
> texture {
> pigment {
> onion
> color_map {
> [0.0 color rgb 1]
> [1.0 color rgb 0]
> }
> phase min_depth/(max_depth-min_depth)
> scale (max_depth-min_depth)
> }
> finish { ambient 1 diffuse 0 }
> translate cam_pos
> rotate cam_rot
>
> }
> }
> camera {
> location cam_pos
> direction z
> up y
> right 4/3*x
> look_at 0
> rotate cam_rot
> }
>
> box {-1, 1 rotate <50, 40>}
>
> // end of code.
>
>
> This scene is a general case. I can change the camera position in cam_pos
> and rotation in cam_rot and still generate a z-buffer output. If I used a
> simple gradient texture, I would have errors. Mainly because of perspective
> distortion. Points on the edge of the image which have color w, say 0.8,
> would actually be farther away than a point with color w in the middle of
> the image. The solution was to use the onion procedural texture, which is
> cocentric spheres centered at the origin. For the depth-view purposes, the
> texture is translated to the camera location, so that the centre of the
> spheres is located at the view-point. Then, it is rotated, if the camera is
> rotated to a new place.
>
> By using this method, one can easily verify that a point (x,y,z) with
> distance d from the eye, would get the same color as any other point (x1,
> y1, z1) with distance d from the eye.
>
> The next problem is scaling of the texture. The texture has originally a
> range of 1, that is it wraps from black to white every 1 units from the
> centre of the texture, that is the eye in this case. We want to scale it so
> that the nearest *visible* point gets a shade close to white, while the
> farthest visible point gets a shade closer to black. There must be no
> wrapping, or else we would get wrong depth-information.
>
> The solution is quite easy, you scale and offset the wrapping of the texture
> with
> phase min_depth/(max_depth-min_depth)
> scale (max_depth-min_depth)
>
> where max_depth is an estimate of the distance to the farthest point we want
> to shade, and min_depth is the distance to the nearest.
>
> The output from this source is an approximate depth-buffer from the scene,
> which then can be used as wished.
>
> Simen.
I would like to get depth image and found your solution here. Thanks.
Beyond depth image, I would like to get the coordinates of each pixel.
Do you have any idea to do that? Thanks again.
Best
Shouyang
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/24/19 7:43 PM, muyu wrote:
> "Simen Kvaal" <sim### [at] studentmatnatuiono> wrote:
...
>
> I would like to get depth image and found your solution here. Thanks.
> Beyond depth image, I would like to get the coordinates of each pixel.
> Do you have any idea to do that? Thanks again.
>
> Best
> Shouyang
>
>
Hi, If you are willing to compile your own POV-Ray version, and if I
remember correctly, someone in the last year or two created a
fork/branch of POV-Ray on github which created a depth map output.
Unfortunately, while trying to figure out how to search all POV-Ray
forks for the branch on github I triggered some sort of "abuse
detection" thing and I'm for a while frozen out of github search...
Unsure how to really do such a search so maybe I indeed created some
kind of search a problem for github.
It should be at worst you can look through the user-forks for the branch
starting perhaps from:
https://github.com/POV-Ray/povray/network/members
There have been other patches over the years too, but unsure of the
state of these.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"muyu" <lsy### [at] gmailcom> wrote:
> I would like to get depth image and found your solution here. Thanks.
> Beyond depth image, I would like to get the coordinates of each pixel.
> Do you have any idea to do that? Thanks again.
>
> Best
> Shouyang
Hi Shouyang,
Perhaps you could take a look at something a few of us worked on a while back:
http://news.povray.org/povray.tools.general/thread/%3Cweb.5ba183edb47e1707a47873e10%40news.povray.org%3E/?mtop=424641
You could put your whole scene inside a union{} and then use the macro to output
where the ray intersects the scene for each pixel.
Alternatively, you might be able to use the color of the depth map to return a
numerical z-position, and use the x,y position on the screen to give the rest of
the vector info. Using an orthographic camera would probably make life easiest
here.
So, create a deep gradient texture, apply it to an untextured scene, Then you
can do an x, y nested loop with eval_pigment to determine the x, y, and z
coordinates (within certain limits of accuracy)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "muyu" <lsy### [at] gmailcom> wrote:
>
> > I would like to get depth image and found your solution here. Thanks.
> > Beyond depth image, I would like to get the coordinates of each pixel.
> > Do you have any idea to do that? Thanks again.
> >
> > Best
> > Shouyang
>
> Hi Shouyang,
>
> Perhaps you could take a look at something a few of us worked on a while back:
>
>
http://news.povray.org/povray.tools.general/thread/%3Cweb.5ba183edb47e1707a47873e10%40news.povray.org%3E/?mtop=424641
>
> You could put your whole scene inside a union{} and then use the macro to output
> where the ray intersects the scene for each pixel.
>
> Alternatively, you might be able to use the color of the depth map to return a
> numerical z-position, and use the x,y position on the screen to give the rest of
> the vector info. Using an orthographic camera would probably make life easiest
> here.
>
> So, create a deep gradient texture, apply it to an untextured scene, Then you
> can do an x, y nested loop with eval_pigment to determine the x, y, and z
> coordinates (within certain limits of accuracy)
Thanks for your answer. Your work on the trace macro is very interesting!
However, I did not know how to do that for all the pixels and output the
coordinates information. Could you please provide a small code example?
(Sorry for this greedy request.) Thanks again.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"muyu" <lsy### [at] gmailcom> wrote:
> Thanks for your answer. Your work on the trace macro is very interesting!
> However, I did not know how to do that for all the pixels and output the
> coordinates information. Could you please provide a small code example?
> (Sorry for this greedy request.) Thanks again.
I'll see what I can work out.
I can't recall where we all left off with this, so I'll have to pick through it
again. It's good practice anyway ;)
The thing you want to do is look at the macro call.
pos_finder (SURFACE, CL, LA, Angle, screen_x_position, screen_y_position, 1.0)
SURFACE is the collection of abjects in the scene
CL - camera location
LA - look at
Angle - camera angle
screen_x_position
screen_y_position
1.0 - no idea what this is at the moment. :D
So basically the idea is to just plop that into a nested x-y loop, and have it
spit out the location vector of where the trace() ray intersects the scene
objects. Probably the best way if to write it to a file.
I think I had some free time when I was helping to work this out, but less so
now, so it may take a while.
But I'd say that the end goal would be to package it all up into a macro that
will scan the whole view frustum and output the visible surface vectors to a
file.
Might be fun to have the option to write the pigment data to file as well with
eval_pigment, and then reconstruct the scene with pixel-sized boxes or spheres.
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/26/2019 8:22 PM, Bald Eagle wrote:
> "muyu" <lsy### [at] gmailcom> wrote:
>
>> Thanks for your answer. Your work on the trace macro is very interesting!
>> However, I did not know how to do that for all the pixels and output the
>> coordinates information. Could you please provide a small code example?
>> (Sorry for this greedy request.) Thanks again.
>
> I'll see what I can work out.
> I can't recall where we all left off with this, so I'll have to pick through it
> again. It's good practice anyway ;)
>
> The thing you want to do is look at the macro call.
> pos_finder (SURFACE, CL, LA, Angle, screen_x_position, screen_y_position, 1.0)
>
> SURFACE is the collection of abjects in the scene
> CL - camera location
> LA - look at
> Angle - camera angle
> screen_x_position
> screen_y_position
> 1.0 - no idea what this is at the moment. :D
>
> So basically the idea is to just plop that into a nested x-y loop, and have it
> spit out the location vector of where the trace() ray intersects the scene
> objects. Probably the best way if to write it to a file.
>
> I think I had some free time when I was helping to work this out, but less so
> now, so it may take a while.
> But I'd say that the end goal would be to package it all up into a macro that
> will scan the whole view frustum and output the visible surface vectors to a
> file.
>
> Might be fun to have the option to write the pigment data to file as well with
> eval_pigment, and then reconstruct the scene with pixel-sized boxes or spheres.
> :)
>
>
Shouldn't each pixel have four corners that need to be measured?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/27/2019 8:57 PM, Mike Horvath wrote:
> Shouldn't each pixel have four corners that need to be measured?
>
>
> Mike
That was probably a stupid question. :(
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
