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.

• Documentation on the com.PostHorizon.renderMan and com.PostHorizon.renderMan.rib packages, produced by javadoc
• Examples, including a trivial java application using the bindings (translated from PRMan's tutorial, chapter 16)
• com.PostHorizon.renderMan.rib.Translate, a simple java application to translate RIBs, demonstrating the various com.PostHorizon.renderMan.rib.RIBIn and .RIBOut features
• Download RenderMan-java v0.92.5 (downloading implies that you have read and agree to the license shown below; a copy is included in the distribution):
  • GZipped Tar (UNIX): Precompiled, Source
  • Zip (Windows): Precompiled, Source
• The latest version of this file is based at http://www.PostHorizon.com/RenderMan-java

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
  • Replaced java.util.Hashtable with java.util.Map everywhere (including parameter lists)
  • 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 scier@PostHorizon.com
  • Moved class into renderMan.jar
  • Changed package from scier.renderMan to com.PostHorizon.renderMan
  • PRMan 3.8 support, including subdivision surfaces and inlined declarations
• 13 July 1998: Version 0.92.3
  • The RenderMan Java bindings have a new home: http://www.PostHorizon.com/RenderMan-java
• 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
  • RIB:
    • 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
  • Initial preview release

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 scier@PostHorizon.com.

• 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 library.
• 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 reason.
• 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.