That works for me. When I put my 2d hat on, I can see a lot of cases like titling where z as an order key unrelated to a notion of depth makes sense.
Sent from my iPhone > On Jun 4, 2014, at 18:04, "Peter Hillman" <[email protected]> wrote: > > 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 >> >> On Jun 4, 2014, at 9:50, "Larry Gritz" <[email protected]> wrote: >> >>> 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. >>> >>> >>> >>>> On Jun 3, 2014, at 12:32 PM, Jonathan Litt <[email protected]> wrote: >>>> >>>> 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. >>>> >>>> >>>> >>>> On Friday, May 30, 2014 12:21 PM, Larry Gritz <[email protected]> wrote: >>>> >>>> >>>> "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. >>>> >>>> >>>> >>>>> On May 29, 2014, at 6:34 PM, Daniel Dresser <[email protected]> >>>>> wrote: >>>>> >>>>> 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 >>>> >>>> -- >>>> Larry Gritz >>>> [email protected] >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Openexr-devel mailing list >>>> [email protected] >>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel >>> >>> -- >>> Larry Gritz >>> [email protected] >>> _______________________________________________ >>> Openexr-devel mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> >> >> _______________________________________________ >> Openexr-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/openexr-devel >
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
