I like the idea of overloading Z, but only where depth is
nonsensical.
In most cases, there is a concept of depth: all renderers should
output Z meaning depth in those cases. Elements created by a
renderer using depth cannot be depth-merged with ones created by a
different renderer using distance without doing some conversion
process. This would require knowing the intrinsic camera parameters,
and risks rounding error if objects are distant.
For many operations, all that is required is that z is a linear
variable such that, within a single pixel, closer samples have a
smaller z value than further ones. It isn't particularly relevant
what 'z' actually represents; depth and distance both work. It would
be a nuisance to implement a separate code-path to read a "distance"
channel instead of a "z" channel, only for it to be treated the same
way.
It's simpler if the 'edge cases' where depth cannot be computed
continue to use 'Z' but store distance instead of depth, as long as
that only happens where there's no concept of depth. This would
maintain consistency.
On 05/06/14 06:26, Nick wrote:
It would be nice to have a convention that does not need a
secret decoder ring to understand. Since the time of our
dinomammalian forebears a depth buffer has been parallel to the
image plane. A point projection distance should be named
explicitly, not hidden as a magic mode.
Keep z as is, and if one needs something like this call it
something explicit like 'distance from camera' but please don't
overload the meaning of z.
- Nick
Sent from my iPhone
Interesting. I take back what I said, this isn't quite a
closed case.
I think "z" and "depth" are widely understood to be (B)
(even if not always implemented as such by every last
renderer), though this does not generalize to all possible
transformations. For a spherical projection, say, it does
seem better to store distance, but it would be very
confusing to call it "Z". (One might argue that it should
have been distance from the start, "d-buffer", not
"z-buffer", so as to generalize, but that's water under the
bridge at this point.)
The EXR spec is pretty clear that deep files need a "Z"
channel. What happens for a different projection. Or, for
example, is a "deep" latlong environment map allowed? To the
extent that anyone cares, I would propose one of the
following solutions:
1. Change the spec to allow "Z" -OR- "distance" (and
"distanceBack?"), and nonstandard projections should have
that channel rather than Z.
2. Keep the name "Z" always but dictate that for any
projection that can be specified by a 4x4 matrix, "Z" means
depth, but for non-matrix-based projections, it means
distance.
For what it's worth, V-Ray also
uses type A) for its standard z-depth buffer. I
inquired about this a long time ago and they had a
reasonably logical answer: B) only works for
standard camera projections, but it doesn't work for
other projection types such as spherical and
cylindrical. So they went with A) for consistency.
They could probably be convinced to add an option to
use B) for regular cameras, but it was easy enough
to write a conversion _expression_ in Nuke and we
didn't bother pursuing it further. It's also easy to
generate a "camera space P" AOV and get B) from
that. Also, they do
use B) for the native depth channels in deep exr 2.0
files, which seems an admission that the old way is
just legacy at this point.
My $.02: no harm in asking
3delight to add an option for this.
"depth" (aka "Z")
always means your choice B. That's true
for every textbook, file format, or
renderer, from OpenGL z-buffers to
RenderMan shadow map files.
I can't speak for
3delight, but if your interpretation is
correct, they are just wrong (and
incompatible with other renderers they try
hard to be compatible with), or have
chosen a very strange naming convention
that is different than the rest of the
computer graphics field.
I'm
not exactly sure what the best
way of wording this question is,
which may be why I haven't
turned up many answers in my
searching. Hopefully someone
here can suggest the best
terminology and/or point me to
an answer.
Assuming that we want to store
depth in an image using
unnormalized world space
distance units, there are two
main ways we could do this:
A) Distance from the point
location of the camera (ie. if
the camera is facing directly at
a flat plane, the depth value is
highest at the corners and
lowest in the middle )
B) Distance from the image plane
(ie. if the camera is facing
directly at a flat plane, the
depth value is constant )
The depth channel in an OpenEXR
image is by convention named Z,
which suggests interpretation
B), where depth is orthogonal to
the pixel X/Y location.
I tried looking through the
document "Interpreting OpenEXR
Deep Pixels" for
any sort of suggestion one way
or another, but all I could
find was:
"Each of these samples is
associated with a depth, or
distance from the viewer".
I'm not sure how to parse this
- it's either defining depth
as "distance from the viewer",
which suggests A), or it is
saying you could use either A)
or B).
Is there a convention for this
in OpenEXR? The two renderers
I currently have convenient
access to are Mantra, which
does B), and 3delight, which
does A). I'm wondering
whether I should try and
pressure 3delight to switch to
B), or whether our pipeline
needs to support and convert
between both. It shouldn't be
hard to convert back and
forth, but it's one more
confusing thing that can go
subtly wrong when moving data
between renderers.
-Daniel
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel
|