RenderMan Interface Extensions and LimitationsRenderMan Interface Extensions and LimitationsImproved Facevarying on Subdivisions
The RenderMan Interface Specification specifies that the RIB binding for handles associated with Lights, Objects and Archives can be either numbers or strings. When using the RIB client library, unique string handles will be automatically generated by default. In order to override the string handle selected, RiLightSource, RiObjectBegin and RiArchiveBegin now recognize the special string __handleid parameter which may be passed in in the parameter list. The value of this parameter will be used to override the handleid which appears in the RIB binding.
RtString id = "mylight";
RiLightSource("spotlight", "__handleid", &id);
For backwards compatibility, integer sequencenumbers are supported, and are equivalent to their string representations Thus, the following RIB statements are equivalent:
LightSource 57 "spotlight" LightSource "57" "spotlight"
Also, starting with PRMan 11.5, RtLightHandles and
Also, when a string value in RI_HANDLEID is passed to RiLightSource in a DSO context, the RtLightHandle returned is guaranteed to have the same string value.
PRMan 10.0 fully supports the RiBlobby geometric primitive as defined in the RenderMan Interface Specification 3.2, and adds an extension for controlling the threshold of the limit function. This is specified in the parameter list by using the primitive variable "__threshold", which is a constant float (i.e specified only once per RiBlobby call). The value specified for this variable is added directly to the threshold value used by RiBlobby.
PRMan supports the RiContext call as described in the RenderMan Interface Specification 3.2. However, note that only RIB contexts may be created by calling RiBegin(), with the filename for that RIB being the name supplied to RiBegin(). An immediate rendering context cannot be created, save for the one already created for you by the renderer.
Thus, the primary purpose of the RiContext call in PRMan will be to create RIB files from within a procedural DSO. Note that it is important in this case to always call RiGetContext() at the beginning of the DSO, and then restore the context to its previous value using RiContext() at the end if you create or set any contexts within your DSO. The active context upon entry should always be the immediate rendering context unless you violate this recommendation.
In PRMan, the RiMakeTexture, RiMakeShadow, and RiMakeEnvironment calls accept additional parameters in the parameter list which control texture creation behavior. These are:
PRMan 11.0 allows two subdivision surfaces to be joined together seamlessly along a shared boundary curve. This is accomplished via a new "stitch" subdivision surface tag. The "stitch" tag has n+1 integer parameters, and no floating point parameters.. The first parameter is an integer identifier, while the remaining n arguments specify a sequence of vertices that form an "edge chain". For example, if you wanted to define a stitch with a 2-vertex edge chain, you could specify the stitch using:
[ "stitch" ] [ 3 0 ] [ 66 5 8 ]
where 66 is the stitch curve ID, and the edge being stitched is defined as that from vertex 5 to vertex 8.
This edge chain must have a limit curve that lies on the boundary of the subdivision surface. Note that the edge chain itself may be interior to the control mesh; for example, this can happen when the "interpolateboundary" tag is not used.
The effect of the "stitch" tag is that if the same edge
chain occurs as the argument to a "stitch" tag elsewhere in
the input stream, then the two sides will be joined together
seamlessly. Both stitch tags must have the same integer
identifier, the same number of vertices,
and the same
limit curve. (The intent of this tag is not to join together
curves at different locations, but simply to prevent
cracking due to differing dicing rates or displacement.)
PRMan 11.5 introduced a new interpolation method for facevarying data attached to subdivision surfaces. This new scheme preserves part of the old behaviour (caused by linear interpolation): it maintains discontinuities in facevarying data on adjacent faces, as well as preserving the interpolation of such data right up to the edge of these discontinuities. However, at the same time, when using the new scheme, continuous facevarying data is now smoothly subdivided across adjacent faces. In other words, this method avoids the linear "kinks" often seen in the old facevarying method, even where the facevarying data was continuous.
The new method is enabled by default. To revert to the old method, a new tag has been added to subdivision surfaces: facevaryinginterpolateboundary. This tag accepts one integer argument. A value of 0 selects the old-style method, while a value of 1 selects the new, smoother method. As well, the default behaviour for subdivision meshes which do not have this tag can be controlled through the rendermn.ini setting /prman/catmark/facevaryinginterpolateboundary; setting this to 0 or 1 will set the same behavior by default as described above.
PRMan supports using archived RIB stored in memory, or inline archives of RI calls. An inline archive is created via the RiArchiveBegin call, which returns a RtArchiveHandle:
RtArchiveHandle handle = RiArchiveBegin(RI_NULL, RI_NULL); ... RiArchiveEnd();In RIB form:
ArchiveBegin id ... ArchiveEnd
An inline archive can be referenced using ReadArchive or DelayedReadArchive, which have been extended to support both inline and disk based RIB archives:
ArchiveBegin "uid" ... ArchiveEnd ReadArchive "uid"Or:
ArchiveBegin "uid" ... ArchiveEnd DelayedReadArchive "uid"In RIB form, inline archives use unique handles. Additionally, it is important to note that inline archives are searched first, before going to disk.
PRMan 12.5.1 introduced a new method for determining the weights of crease edges through subdivision. The 1998 “Geri's Game” paper described how, after subdividing a crease edge, the sharpnesses of the resulting subedges were to be determined using Chaikin's curve subdivision algorithm. Until now, PRMan did not implement this; given a crease sharpness of n PRMan has always just assigned max(n-1, 0) to the two subedges. In situations where a multiedge crease has varying weights this leads to a step-like appearance to the crease geometry or crease normals.
PRMan 12.5.1 adds support for Chaikin's curve subdivision algorithm, which improves the appearance of multiedge creases with varying weights. This new method is off by default. A new tag that accepts a string argument (and consequently is available only to HierarchicalSubdivisionMesh) has been added: "creasemethod". This tag accepts the value "normal" (the default) or "chaikin" (to turn on the new method).
PRMan implements resources of type "attributes", as described in the specification for RiResource. These resources encapsulate the entirety of the graphics state, and can be selectively restored using the "string subset" parameter. The following table describes which parts of the graphics state are manipulated by the subset. In addition, PRMan allows for multiple subsets to be combined using comma separated lists. Hence, restoring the "shading,geometry" subset will be the same as restoring both the "shading" and "geometry" subsets.
| Subset name | Attributes restored by subset |
|---|---|
| shading |
* PRMan currently has limitations related to user attributes and scoped coordinate systems: user attributes or coordinate systems whose values are overridden while in an AttributeBegin-AttributeEnd scope may not save the correct value (the last value set in the current scope will be restored). In other words: AttributeBegin
Attribute "user" "string mytex" ["grass.tex"]
Resource "grass" "attributes" "string operation" "save"
Attribute "user" "string mytex" ["flowers.tex"]
AttributeEnd
Resource "flowers" "attributes" "string operation" "save"
Resource "grass" "attributes" "string operation" "restore" "string subset" "shading"
When the named attribute state "grass" is restored, the attribute user:mytex will contain flowers.tex, not grass.tex. This limitation may be addressed in a future release. |
| transform | Transformation calls (RiConcatTransform, RiTranslate, etc) |
| geometrymodification | |
| geometrydefinition | |
| hiding |
|
Pixar Animation Studios
|