Java Bindings for the RenderMan API
Copyright (C) 1997-2000, Sean Cier
(The RenderMan API is Copyright 1989 Pixar.
RenderMan (R) is a registered trademark of Pixar)
The Java RenderMan bindings are an effort to allow the
interaction of photorealistic modelling and rendering applications
written in Java via Pixar's RenderMan API. They currently include a
prototype binding, intended to undergo review by the 'net community
(and Pixar, if they wish), as well as a reference implementation which
generates and parses RIB files.
Installation: After unpacking the distribution, move
either the distribution to a location of your choosing (referred to here
as [INSTALLPATH]), and include "[INSTALLPATH]/renderMan.jar" in your
CLASSPATH environment variable.
- Documentation on the
com.PostHorizon.renderMan.rib packages, produced by javadoc
- Examples, including a trivial java application
using the bindings (translated from PRMan's tutorial, chapter 16)
a simple java application to translate RIBs, demonstrating the various
com.PostHorizon.renderMan.rib.RIBIn and .RIBOut features
v0.92.5 (downloading implies that you have read and agree to the license
shown below; a copy is included in the distribution):
- The latest version of this file is based at
Translate utility: Once installed, the RIB Translate utility can be
invoked via "java com.PostHorizon.renderMan.rib.Translate". Give the
-h option to see a list of options.
- 25 October 2000: Version 0.92.5
java.util.Map everywhere (including
- Bug fixes, some efficiency improvements
- Minor code cleanup
- Addition of copy constructors in support classes
- 18 January 1999: Version 0.92.4
- Source is now freely available (see included LICENSE); please
send bug fixes and enhancements as source patches to
- Moved class into renderMan.jar
- Changed package from scier.renderMan to
- PRMan 3.8 support, including subdivision surfaces and inlined
- 13 July 1998: Version 0.92.3
- 18 April 1998: Version 0.92.2
- Support for PRMan extensions through 3.7
- Bug fixes in RIB implementation
- Superficial code structure cleanup (may break source-level
compatibility in some cases)
- Data members made private in helper classes
- RenderMan is now an interface rather than an abstract class
- 26 August 1997: Version 0.92a
- Cosmetic changes
- Boolean accepted as a parameter list element value
- 30 July 1997: Version 0.92
- Full RIB input support via scier.renderMan.rib.RIBIn
- com.scier.renderMan.rib.Translate RIB translation utility
- RIB support moved to scier.renderMan.rib package
- Vastly more robust parameter list / declared variable support;
strictParamTyping option in RIBOut
- RIBOutBinary doublePrecision option
- RIBOutASCII automatric and manual indentation support
- Examples included
- Error handler support
- Update to Java 1.1
- Adhesion to spec and various PRMan extensions through latest
PRMan release notes (coordSysTransform, readArchive,
nuPatch semantics, et cetera)
- Vectors in parameter lists are now disallowed in favour of the
simpler, more robust method of directly sending arrays.
- Minor consistency and functionality changes to helper classes
- 13 October 1996: Version 0.91
- The primary new feature is Binary RIB output via the
RIBOutBinary class; also includes minor bug fixes and
extensions to helper classes.
- 21 September 1996: Version 0.90
- Implementation available.
- Based on The RenderMan Interface Spec version 3.1; there are mostly
only minor changes to the RenderMan class and support classes
(parameter name changes, a few additional routines not documented in
the Companion, fixes to errors in the Companion). The largest change
is RIBOutASCII, the actual RIB output implementation; it is
complete, and should function effectively.
- Version 0.1
The RenderMan Interface was designed by
Pixar to be an interface between
modeling applications and renderers in order to allow each to evolve independent
of the another (more information about RenderMan is available at
The RenderMan Repository).
The original RenderMan API was intended to therefore be
cross-platform and independent of language. However, due to the ubiquity of
C and C++, the C binding for the API has become dominant, and the original
design of the API was tied closely to C.
This binding, a port of the RenderMan API to the cross-platform
Java programming language, is
primarily a direct transcription of the C binding. However, Java does not
support many aspects of C/C++ (such as typeless pointers, typedef statements,
global functions and definitions, and variable-length argument lists) and
supplies additional mechanisms not supported by C (such as built-in exception
handling and polymorphism). It is inevitable, therefore, that a Java binding
to the RenderMan API would be significantly different from the C binding in
appearance, if not functionality. I attempted to keep them as close as
possible, employing additional functionality only when overwhelmingly
useful (such as exception handling).
Note that this binding is currently not endorsed by Pixar in any way.
Please send any feedback, feature requests, and bug
reports -- or better yet, bug fixes and enhancements in the form of
source code patches (unified diffs) -- to
- The Java binding revolves around a single package
(com.PostHorizon.renderMan). This contains helper types
Point, Color, Matrix, Bound,
LightHandle, and ObjectHandle -- RtBasis was subsumed by
Matrix), one class for each `sendable' function
(FilterFunction, RefineFunction), one extra class to handle
errors (RMException), and a central abstract class
(RenderMan) containing the actual API calls, predefined tokens, etc.
- Implementations of the API are integrated by subclassing RenderMan,
a more elegant and completely dynamic solution made possibly by Java's
polymorphism; this replaces the practice of linking with an implementation
- Naming Conventions: The original C binding convention of preceding
function names by Ri and type names by Rt was dropped.
As Java forces the use of classes anyway, an incompatibility with this
convention already existed and so the prefixes were deemed redundant.
Additionally, the first letter of each method was made lowercase for the same
- String was used in place of RtToken in all instances. The original
utility of RtToken was defeated by its interchangability with strings, making
a useful workaround cumbersome. Additionally, the only real benefits were the
ability to use predefined strings to reduce typos and allow more efficient
implementations to avoid string comparisons; both these can be achieved by
the use of static final Strings within the class.
- Parameter lists (originally implemented via variable argument lists,
not supported in Java) were replaced by Hashtable parameters, implementing
more directly the associative array implied by the C binding. The
double-array version of the parameter list was not used. Although this
is a noticable departure from the C-style calling conventions, it is actually
stated in the RenderMan Interface Specification (page 11) that the C argument
passing style was not intended to carry over into other bindings.
- Keys in parameter list hashtables are always Strings. Tokens must be
Strings, Colors, Numbers, Points, or arrays of the same.
- Error handling is accomplished via Java's exception mechanism; however,
the errorHandler method is still used as it provides an (optional) means
of dealing with nonterminal errors. The format of errors from the C binding
is carried over into RMException.
Copyright (C) 1997-2000 Sean Cier
License is granted to use, extend, and redistribute these bindings,
included implementations and interfaces, and other included code (hereafter
referred to as the Bindings), free of charge as part of a package or
product which is itself distributed free of charge under this license and
the source code for which is freely available, provided the above
copyright notice is included, explicit notice is given as to the inclusion
of the Bindings, instructions are provided for obtaining a copy of the
latest distribution of the Bindings, and the source code for any
redistributed extensions or additions to the Bindings is provided in a
timely manner to the author of the Bindings for possible inclusion in
the primary distribution. Neither the Bindings nor any derivations or
subsets thereof may be distributed as part of a commercial product or
service without the explicit written consent of the author.
No warrantee is provided.
Composed & Performed by