openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] OpenEXR in Blender's CVS


From: Florian Kainz
Subject: Re: [Openexr-devel] OpenEXR in Blender's CVS
Date: Tue, 15 Mar 2005 12:39:26 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314

Gernot Ziegler wrote:
My normalization of Z to between 0.0 and 1.0 is only a first solution for
orthographic cameras.

Z data storage is still somewhat undefined, therefore I always resort to
the only common denominator: providing a formula on how to derive world
coordinates for each pixel sample from the x,y coordinates and z value in
the image. The only way for mixing Z output from different renderers is to
have this formula available. Such a formula implies usually the camera
position in world space, its orientation, its x/y extents (ortho mode) or
FOV (perspective mode) and its near and far clipping planes.

I haven't yet thought about how this should be written to OpenEXR (is
there a standard yet ?), in the meanwhile I store it in an extra
metafile.

I know this Z mapping formula for perspective OpenGL cameras, and
I know how this works for general orthographic cameras (they simply do a
linear subdivision between the near and far clipping plane).

For non-OpenGL renderers in perspective rendering mode or other lens
setups, I need to know how its Z buffer values map to world coordinate
values.  Since I don't know this yet for Blender's output, I only map its
near=-INTMAX to far=+INTMAX to 0.0 and 1.0, which is correct for its
orthographic mode, but NOT for the perspective mode :-)

What does ILMs rendering setup use ?


At ILM, we store camera-space Z coordinates in the Z channel.
Empty pixels that are not covered by any objects in the scene
contain positive infinity.

ILM's Renderman driver also stores the world-to-camera and
the world-to-NDC matrices as M44f (4 by 4 float matrix)
attributes in the file header.   This allows you to recover
the pixels' positions in world space or in camera space.

Florian


P.S.:

If you have Renderman and ILM's OpenEXR driver, you can
use the following RIB file to test Z channel output:

    Quantize "z" 0 0 0 0
    Display "z.exr" "exr" "z"
    Projection "perspective" "fov" 120.0
    WorldBegin
    Surface "constant"
    Polygon "P" [-1 1 1   -1 -1 1   1 -1 1   1 1 1]
    Polygon "P" [-3 1 2   -3 -1 2   0 -1 2   0 1 2]
    Polygon "P" [ 0 1 3    0 -1 3   5 -1 3   5 1 3]
    WorldEnd

This scene contains three rectangles that are parallel to
the XY plane.  The Z coordinates of the rectangles are
1.0, 2.0 and 3.0 respectively.

Feeding this file to Renderman produces an OpenEXR file with
the following header:

    file format version: 2, flags 0x0
    channels (type chlist):
        Z, 32-bit floating-point, sampling 1 1
    clipFar (type float): 1e+38
    clipNear (type float): 0.1
    compression (type compression): zip, multi-scanline blocks
    dataWindow (type box2i): (0 0) - (639 479)
    displayWindow (type box2i): (0 0) - (639 479)
    flip (type int): 0
    lineOrder (type lineOrder): increasing y
    pixelAspectRatio (type float): 1
    screenWindowCenter (type v2f): (0 0)
    screenWindowWidth (type float): 4.6188
    worldToCamera (type m44f):
       (1 0 0 0
        0 1 0 0
        0 0 1 0
        0 0 0 1)
    worldToNDC (type m44f):
       (0.433013 0 0 0
        0 0.57735 0 0
        0 0 1 1
        0 0 -0.1 0)

The pixels in the OpenEXR file contain only four different
values: 1.0, 2.0, 3.0 and positive infinity.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]