clipka <ano### [at] anonymousorg> wrote:

> (As a matter of fact, if I'm not mistaken older versions of POV-Ray
> provided such a feature. At the very least MegaPOV did.)

I did come across mention of such a feature, as well as your pointing out how
gamma needs to be considered:
https://news.povray.org/povray.unofficial.patches/thread/%3Cweb.4ab74a31bf54fa92ea2377910%40news.povray.org%3E/?ttop=43
3088&toff=50

> The caveats I mentioned aren't necessarily problems, just things to be
> mindful of, that might require modifications to the process if they
> should happen to not exactly be what you need.

I think that when a somewhat commonly requested solution for a problem like this
gets solved, that's the time for the/a contributor to post a functional scene
file so that it gets added to the pile of stuff we have on the server.   Then
it's simply a matter of pointing them to the link, or including such a sample
scene in the next release.

(Some things ought to be added to the engine, since SDL is slow and the code for
such tasks would need to be FAST, and therefore compiled)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 19.06.2021 um 15:37 schrieb Norbert Kern:
>
> > If you set every diffuse, specular, phong, ambient, emission and reflection
> > value as zero, you get a black material.
> > A white fog turns this to an inverse depthmap. Then you can adapt
> > the color_map of your blurring file or you can invert it via Photoshop
> > and co to get a "regular" depthmap.
> > Here is a depthmap of my last image.

< [Clipka:]
> Some caveats of this approach:
> [snip]

Using fog to create a depth-map is a very clever idea, even with the caveats
that Clipka mentions.

From some quick experiments I just did, I've found what may be a simpler fog
method, that does not require any adjustments to a scene's object textures at
all. They can be left as-is.

1) Turn off any LIGHTS in the scene.
2) In the scene's global_settings block, add   ambient_light 0.0 -- which is a
multiplier for any ambient light in the objects' finishes.
3) Use a simple fog statement (default fog_type 1) like
             fog{rgb 1 distance 15}
..... or whatever distance value looks correct. This will produce a gray-scale
depth_map with pure white in the distant background, and black *at* the camera,
I think. The interesting point about this set-up is that all of the objects'
COLORS seem to be 'eliminated'-- the entire scene is now just gradations of
gray. Apparently, with no actual light in the scene, and no finish{ambient or
emission}, the fog 'color' is the only color seen; all of the object colors are
suppressed.

Perhaps a ground fog (fog_type 2) may be better-suited to this, but modified--
possibly by setting the fog's  'sky' vector to be the same as the camera look_at
vector(?). The idea being that ground fog has more parameters that can be
tweaked, to possibly 'fudge' some of the depth/distance problems that Clipka
mentioned. Just a guess though.

Also, try  srgb 1 for the fog color, which should(?) produce a 'different' type
of exponential fog-color falloff. Maybe.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> From some quick experiments I just did, I've found what may be a simpler fog
> method, that does not require any adjustments to a scene's object textures at
> all. They can be left as-is.
>
 Well...it was a nice *idea*, but... no good.

Objects' surface finishes like phong/specular, and/or especially reflection,
screw up the gray-scale values imposed by the fog. So all of those need to first
be reduced to zero, as has already been mentioned. And any texture transparency
is also a big problem.

My bad.

----------
It would be useful to have 'global' multipliers for most or all of the various
finish{...} attributes-- similar to the current ambient_light keyword-- to
easily and quickly reduce any of those parameters in a scene to zero if needed.

Like...
emission_light *float value*
reflection_global *float value*
phong_global *float value*
.... etc.

And maybe even one for object transparency! (t and f both)

Post a reply to this message

On 2021-06-24 1:09 PM (-4), Kenneth wrote:
> 
> Also, try  srgb 1 for the fog color, which should(?) produce a 'different' type
> of exponential fog-color falloff. Maybe.

This will not make any difference.  POV-Ray has only one type of color,
and the srgb keyword is merely a different way of specifying them.

To change the falloff, try changing assumed_gamma.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-06-24 1:09 PM (-4), Kenneth wrote:
> >
> > Also, try  srgb 1 for the fog color, which should(?) produce
> > a 'different' type  of exponential fog-color falloff. Maybe.
>
> This will not make any difference.  POV-Ray has only one type of color,
> and the srgb keyword is merely a different way of specifying them.
>

Yep, you're right. I just tried it anyway, but no change.

I also thought that render Quality_Level might be a way to suppress the objects'
finish{...} attributes; but fog itself does not 'appear' until Quality_Level 9,
at which point all of the finish stuff is there as well.

Post a reply to this message

> Also, try  srgb 1 for the fog color, which should(?) produce a 'different' type
> of exponential fog-color falloff. Maybe.
> 

srgb 0 is exactly the sama as rgb 0, and srgb 1 exactly the same as rgb 1.
Those are the two intersection points between those two.
The use of srgb have no effect on any fading or gradient.

gradient x colour_map{[0 rgb 0][1 rgb 1]}
will render exactly the same as
gradient x colour_map{[0 srgb 0][1 srgb 1]}

Post a reply to this message

I have essentially accomplished the end goal 4+ years ago, when I needed a depth
map for laser-engraving "2D" images in 3D relief.

I simply use the orthographic camera, union everything in the scene, find the
min and max z, normalize that to a 0-1 range, and then trace over every pixel
position of the image in the direction of the "direction" vector.
Then I create a 1 pixel-wide box with an rgb value directly proportional to the
normalized distance to the ray intersection point.
It's maybe 30 lines of code including the #debug statements.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
>
>
> > Also, try  srgb 1 for the fog color, which should(?) produce
> > a 'different' type of exponential fog-color falloff. Maybe.
> >
>
> srgb 0 is exactly the sama as rgb 0, and srgb 1 exactly the same as rgb 1.
> Those are the two intersection points between those two.
> The use of srgb have no effect on any fading or gradient.
>
> gradient x colour_map{[0 rgb 0][1 rgb 1]}
> will render exactly the same as
> gradient x colour_map{[0 srgb 0][1 srgb 1]}

Oops! You are correct. Yes, I was thinking of the *possible* change that 'srgb'
might make to the black-to-white fog gradient. But as you say, rgb and srgb look
the same.

I must have been thinking instead about the effects that the newer blend_mode
and blend_gamma keywords have on a color_map. But simple fog cannot use a
color_map, unfortunately.

Post a reply to this message

On 6/19/2021 8:52 PM, clipka wrote:
> Am 19.06.2021 um 21:38 schrieb Mike Horvath:
> 
>> Would it work better if depth maps were an engine feature versus a 
>> bunch of tricks/hacks with pigments or fog?
> 
> No. It would just be simpler to set up (no tampering with textures, 
> pigments, fog and/or interiors) while at the same time potentially less 
> flexible.
> 
> (As a matter of fact, if I'm not mistaken older versions of POV-Ray 
> provided such a feature. At the very least MegaPOV did.)
> 
> 
> The caveats I mentioned aren't necessarily problems, just things to be 
> mindful of, that might require modifications to the process if they 
> should happen to not exactly be what you need.

Sorry, I don't mean would it "work better". I mean would it "be better", 
as in "easier" or "more convenient".

But I no longer am interested in this topic since I will likely not be 
making any additional 3D photos in the near future. My use case has its 
own separate issues and is not worth pursuing further.


Mike

Post a reply to this message

On 6/19/2021 12:58 PM, Alain Martel wrote:
> Whenever you use a macro, it get expanded every times it's used, so, 
> will use more memory while parsing.
> 

I have 16GB RAM, so it makes no difference in my case. But it seems 
wasteful.


Mike

Post a reply to this message