[Bf-committers] OpenEXR plugin for Blender :-)

Gernot Ziegler gz at lysator.liu.se
Wed Mar 9 14:04:09 CET 2005

Hej Ton !

> I have no time to check on this patch now, but like to mention that
> another developer has been working on the feature as well (Alfredo de
> Greef). Afaik this wasn't finished yet.
I would gladly cooperate with him if he wants to ('cause I don't know if
I can maintain this plugin in the future).

> Kent Mein is also working on 64/128 bits images support in our ImBuf
> (image) library, something to keep synced as well!
Yes, we have already been talking :-)

> > Restrictions are:
> > .) It is C++-code, so openexr.cc is using g++ to compile
> Check on how for example the Freetype/FTGL library was linked in
> Blender. This is C++ code as well, nicely wrapped to a C API. The local
> Blender component for it (C++ too) is in the directory
> source/blender/ftfont/, the FTGL library in extern/, the freetype
> library belongs either in lib/<platform>/ or defined to use a link path
> in makefiles/scons.
I don't think that it necessary, as openexr.cc exposes
in C calling style, but I guess it could be done if really needed.

> OpenEXR should be done in a similar way. The library itself doesn't
> belong in our source tree, but precompiled as static lib (with
> headers).
> Make a nice C Api for it in source/blender/openxr/ or so
The library is not in the source tree, it is linked in just like libpng
and friends :-)

> > .) 16 bit-short-output: Is there example code for that ?
> I doubt we'll support that in the short term.
Okej, that is no interest ? Good to hear, I think that this is actually
nothing important to support, anyways, if the renderer can produce float

> Check on the code for other image saving... warning, this is a very
> antique abused dutch named routine "schrijfplaatje()" in toets.c. Could
> use major cleanup, but will work for you.
No prob, I understand Dutch ;)

> The 4xfloat buffer is simply accessible as the global R.rectftot (float
> pointer, RGBA). Check the RE_floatbuffer_to_output() code in render
> module.
Excellent !

> There's space for 1 or 2 buttons... not much. :)
I saw pop-up menu buttons - maybe that is possible in the output
settings, too ?

> Output choices could be limited to 4 x float, with/without Z
> Optional is 4 x short, with/without Z. Dunno...
Half and Float output, with/without Z, Unclamped HDR output are the most
important for film making, I think ...

There are lots of other output things I could imagine, based on 3DSMax'
RPF plugin, e.g. normals output.

> > .) Z data channel: How is the Z data defined ? Is it relative to the
> > camera, starting with Z=0 at the image plane ? Where is Z=1.0 ?
> The zbuffer is the actial Z buffer as used for rendering. It isn't even
> 'correct' since it misses transparency and halos or particles. The
> values are signed integers, ranging from -max to +max for clipping
> planes (between near and far).
Okej, that would be good enough for me at the moment, I can convert that
to float, thanks ! Needed for continued research in MPEG Z/Alpha as demoed on
http://www.geofront.se/products_software_mza.php , actually :-)

Relief texture merger is also why I am interested in unclamped float
values, since I need to merge several RGBZ images together in one final
real-time rendering
- if the renderer has clamped the partial images with different
settings, then it is impossible for me to fuse them together without a
color "seam" (I had
problems with that in the "Head" rendering, as can be seen on the page).


O  The Austria <=> Sweden <=> Germany <=> Netherlands connection.....   H
|  http://www.mpi-sb.mpg.de/~gziegler | http://lysator.liu.se/~gz       E

More information about the Bf-committers mailing list