Display DriversDisplay DriversThis section describes the display drivers which may be selected for use with PhotoRealistic RenderMan via the type parameter to RiDisplay. These include two framebuffer drivers (x11 and windows), nine image file formats (tiff, sgi, alias, targa, cineon, softimage, mayaiff, openexr, texture), and three depth data formats (shadow, zfile, deepshad). The user may also extend PRMan's image capabilities by writing custom display drivers.
This driver draws into a new window on 24-bit DirectColor, 8-bit PseudoColor, or 1-bit monochrome displays under the X11 window system. The driver dynamically determines whether the X11 display system has a 24-bit DirectColor, or 8-bit PsuedoColor visual available and behaves appropriately for each. If neither of the above is available, the default visual is used as a 1-bit monochrome display. The size of the inside of the window is determined from the image resolution. The window can be moved, closed and reopened without affecting output.
After rendering is completed or aborted, the window remains on the screen. The window is removed only when the window is selected for focus and a “q” is typed on the keyboard. For 8- or 1-bit displays, after rendering is completed, an image-improvement process takes place and the image is redrawn. Monochrome images are dithered, and 8-bit images are redisplayed using a color map selected by the median cut color selection algorithm and dithered (see “Color Image Quantization for Frame Buffer Display,” Paul S. Heckbert, Proc. SIGGRAPH '82, pp. 297-307).
In order to view a color image properly, the colors should be adjusted for the monitor. If this isn't done, images will usually appear to be too dark. The x11 display driver does this using a technique called “gamma correction” using a “gamma” value of 2.0 to approximate the color response of most color monitors. A different gamma value can be used by setting the DSPYGAMMA environment variable; for example,
DSPYGAMMA=2.6
will cause the driver to use a gamma value of 2.6 instead of the default. If the image appears washed out (bright), lower the gamma value (usually not below 1.0). If the image is too dark, raise the gamma value (usually not above 3.0). A gamma value of 1.0 will display the image unaltered on a display that has the color correction handled in another fashion.
This driver draws into a new framebuffer window, on Windows systems. The size of the inside of the window is determined from the image resolution. The window can be moved, closed and reopened without affecting output.
After rendering is completed or aborted, the window remains on the screen. The window is removed by the normal methods, or when a 'q' is typed on the keyboard. The image window also supports one additional command: when 's' is typed, the currently display image will be saved to disk with the filename specified in RiDisplay, if possible.
This driver produces an output file in Tagged Image File Format (TIFF). It can be used to store "r", "rgb", "rgba", "rgbz", and "rgbaz" images in 8-, 16-, or floating point 32-bit-per-component resolutions. The TIFF file created employs LZW compression; 8, 16, or 32 bits per sample; one, three, or four samples per pixel; and a planar contiguous configuration.
The tiff driver also has special configuration options to control the resolution information written into the output file as well as the compression used for output. These may be set from the RiDisplay parameter list or through the configuration file.
The TIFF compression scheme can be controlled by setting the parameter "compression", which takes a string value which should be one of "lzw", "packbits", "deflate", "pixarlog", or "none". The default value for the compression scheme may be set by adding the following line
/display/tiff/compression compression-scheme
where compression-scheme is is one of the above strings. If no compression scheme is specified, LZW compression is used.
The TIFF resolution unit can be controlled by adding the parameter "resolutionunit", which takes a string value which should be one of "inches", "centimeters", or "none". The default value for the resolution unit may be set by adding the following line
/display/tiff/resolutionunit unit
where unit is is one of the above strings. If no units are specified the default is "none".
If the TIFF resolution unit has been defined as above, the TIFF resolution values can be controlled by setting the parameter "resolution", which takes a value that is an array of two floats specifying the resolution in the x and y directions. The default value for the resolution values may be set by adding the following line
/display/tiff/resolutionunit xresolution,yresolution
where xresolution, yresolution are floating-point numbers separated by a single comma. There should be no spaces between the comma and xresolution. If no values are specified, values of 100.0 are used, except in the case where no units are specified, in which case values of 1.0 are used.
The default image size and pixel aspect ratio are set through the configuration file as follows:
/display/tiff/xres xresolution
/display/tiff/yres yresolution
/display/tiff/par pixelaspectratio
This display driver writes Silicon Graphics, Inc., image files. It supports three or four channel files (mode "rgb", or "rgba") with 8 or 16 bit per channel depth. The files produced can be read by programs using the SGI "img" library or SGI "img" utility programs like "ipaste" and "izoom".
This driver produces an output file containing RGB information. In addition, the driver will interpret the alpha channel by writing a separate 8-bit Alias Matte output file, and will handle z data by writing a separate 32-bit Alias or Composer depth file. Thus, the driver can handle "z", "rgb", "rgba", or "rgbaz" images. The alias driver creates a file whose name is specified in the RiDisplay call. The Matte file, if any, will have the additional suffix .mask, and the Depth file will have the additional suffix .depth.
When writing depth data, the driver will by default write Alias depth files. This behaviour can be changed with an additional parameter, "zformat", which can be either "composer" or "alias".
This driver supports Truevision, Inc. of file type 2, which is an uncompressed RGB or RGBA image (selected with RiDisplay modes "rgb" or "rgba").
The targa driver allows images to be merged over an existing TGA file. This option is selected by using the "merge" parameter to RiDisplay. If this option is selected, the existing file must have the same name as that specified with RiDisplay and it must be of the same x and y dimensions and file type.
This driver produces an output file in Kodak's Cineon image file format. It can be used to store RGB images in a 10-bit-per-channel, logarithmic encoding, as preferred by Kodak's Cineon software suite.
The cineon driver creates a file whose name is specified in the RiDisplay call. It accepts pixel data in either 8- or 16-bit-per-channel quantized integer format, or 32-bit floating-point format. These values are companded by the driver to 10-bit log, for optimal registration with film's recordable color range. Because 10-bit log can encode and store colors which are "brighter than white", use of full floating-point (unquantized) RGB output is recommended for best use of the format's capabilities. The format only supports RGB image files (mode "rgb"), and any alpha channel supplied by the renderer is ignored.
The cineon driver also has special configuration options to control the log codes which are used to compand the data which is written into the output file. These may be set from the RiDisplay parameter list or through the configuration file.
The Cineon companding equation be controlled by adding the parameter "setpoints" to the RiDisplay parameter list. The parameter takes an array of two integers, which represent the 10-bit code used to represent 1% Black, and the 10-bit code used to represent 90% White (see Kodak's Cineon documentation for explanations of these values). The default values for these setpoint codes can be set by adding the following line to the rendermn.ini configuration file:
/display/cineon/setpoints black,white
where black and white are integer values separated by a single comma. There should be no spaces between the comma and white. If no values are specified, the standard default values of 180,685 are used.
This display device driver produces an output file in the Softimage Picture File Format. The driver supports 8-bit "rgb" or "rgba" images, with or without RLE compression.
The softimage driver has one configuration option to determine whether the output undergoes run length encoding compression. This can be controlled by setting the parameter "compression" in the RiDisplay parameter list. The parameter takes the value of "rle" or "none", to enable or disable compression, respectively. The default setting is "rle".
This driver produces an output file in the Maya Image File Format. The driver can generate 8-bit or 16-bit RGB along with an optional 8-bit or 16-bit Alpha channel and optional 32-bit Z data; thus, this driver supports the "rgb", "rgba", "rgbz", and "rgbaz" display modes.
This display driver which produces an output file containing depth (mode "z") information in the shadow map texture file format, which is a proprietary format peculiar to PhotoRealistic RenderMan. The shadow map texture format is accepted by the renderer for use in light shaders which produce shadows via the shadow() shadeop.
The shadow driver has two configuration options. The "minmax" parameter can be set to a value of 1 to indicate that the generated shadow should be a minmax shadow map, suitable for use in soft shadow generation. By default this option is disabled (has a value of 0). The "format" parameter can be set to a value of "tiff" or "pixar" to indicate the format of the output texture map; it defaults to the value specified for /prman/textureformat in rendermn.ini.
Zfile is a PhotoRealistic RenderMan display driver which produces an output file containing depth (mode "z") information. The zfile format is accepted by the renderer and the txmake utility program as the depth image required to make a shadow texture map.
The file format is peculiar to PhotoRealistic RenderMan. It has the following form:
Header: Bytes Description 0-3 magic # (0x2f0867ab) 4-5 width (short) 6-7 height (short) 8-135 shadow matrices (32 float values, 16 each for NP and Nl) Image Data: (immediately follows) width*height IEEE floats
Deepshad is a PhotoRealistic RenderMan display driver which produces "deep shadow maps", which store more information per pixel than a normal shadowmap. These files are stored in a proprietary format peculiar to PhotoRealistic RenderMan. The deep shadow map texture format is accepted by the renderer for use in light shaders which produce shadows via the shadow() shadeop.
This display driver works only as a secondary display (similar to extra-output variables), which means a primary display must be used as well. For example, in RIB,
PixelFilter "box" 1 1 Display "out.zfile" "zfile" "z" Display "+out.dshad" "deepshad" "deepopacity"
will generate a deep shadow file out.dshad (as well as a zfile out.zfile). Like depth displays, deep shadows require 'PixelFilter "box" 1 1'.
One display mode is currently available for deep shadow output: "deepopacity" indicates that the given file contains deep shadow transparency information.
The deep shadow driver accepts one configuration parameter: "volumeinterpretation". This parameter may take one of two uniform string values, "discrete" and "continuous". If set to "discrete", the display driver will faithfully emit all samples - this is useful in preserving the discontinuous nature of scenes where the depth samples are further apart. When set to "continuous" the display driver will instead interpolate through the middle of discontinuous samples; this optimizes the output but should be used only when reproducing a generally smooth depth function (such as that caused by a volume of fog, or a dense stack of hair). By default this parameter is set to "discrete".
This driver supports OpenEXR, a high dynamic-range image, floating point file format developed by Industrial Light & Magic.
When using this display driver for rgba or Z output, you should turn rgba and Z quantization off by using a floating point Quantize statement, ie:
Quantize "rgba" 0 0 0 0
Quantize "z" 0 0 0 0
This display driver also supports the output of image channels other than rgba using the Arbitrary Output Variable mechanisms.
This driver maps Renderman's output variables to image channels as follows:
| Renderman output variable name | image channel name | type |
|---|---|---|
| "r" | "R" | preferred type |
| "g" | "G" | preferred type |
| "b" | "B" | preferred type |
| "a" | "A" | preferred type |
| "z" | "Z" | FLOAT |
| other | same as output variable name | preferred type |
By default, the "preferred" channel type is the value specified for /display/openexr/type in rendermn.ini, which can be either "half" (16-bit) or "float" (32-bit). If not specified therein, it defaults to "float". The preferred type can be changed by adding an "exrpixeltype" or "type" argument to the Display command in the RIB file. For example:
# Store point positions in HALF format Display "gnome.points.exr" "exr" "P" "string exrpixeltype" "half"
The default compression method for the image's pixel data is the value specified for /display/openexr/compression in rendermn.ini, which may take the value of "rle", "zip", or "piz"; if not specified therein it defaults to "zip". You can select a different compression method by adding an "exrcompression" argument or simply the "compression" argument to the Display command. For example:
# Store RGBA using run-length encoding Display "gnome.rgba.exr" "exr" "rgba" "string exrcompression" "rle"
This display driver produces an output file which will be accepted directly by the renderer for use in the texture() shadeop. The image will either be in TIFF format or in Pixar's mipmapped texture file format, which is a proprietary format peculiar to PhotoRealistic RenderMan. 8-, 16-, and 32- bit (floating point) image output is supported. Images rendered using this display driver must have power of two dimensions - no attempt will be made to resize the image when using this driver.
The texture driver supports several configuration options. The "pattern" parameter can be set to a value of "none", "diagonal", or "all" in order to control the mipmapping mode; the default is "diagonal". The "smode" and "tmode" parameters control the wrap modes of the texture and accept the values "black", "clamp", or "periodic"; the default is "black". The "format" parameter can be set to a value of "tiff" or "pixar" to indicate the format of the output texture map; it defaults to the value specified for /prman/textureformat in rendermn.ini.
Note that for proper 16 bit output, one must use Quantize 32767 0 32767 0, and not the usual Quantize 65535 0 65535 0. This is because PRMan's system currently expects signed, not unsigned shorts.
In addition to the display drivers supplied with PRMan, users may extend the system by writing their own custom drivers. This allows for new image types or framebuffers to be directly supported for rendering.
Display drivers are written as dynamic shared objects (DSOs), which are also known as dynamic link libraries. (You should consult the documentation for your compiler on how to compile and link these objects.) You may compile your display DSO's either with a 'C' or 'C++' compiler, but you must use 'C' linkage -- i.e. if you use C++, you need to use extern "C" to guarantee C-style linkage. A header file has been provided, ndspy.h, which contains function prototype declarations which should be used when writing display drivers, as these prototypes should guarantee that the correct linking and exporting of symbols occurs across various platforms.
Please note, however, that RenderMan Pro Server for OSX display driver DSOs do not support Objective C (ObjC).
Display driver DSOs must export and implement at least four required functions:
Data to the display drivers will be provided in a variety of formats and byte orders. The display driver can then choose which formats and byte orders it would prefer that data in. Constants for those formats are defined in ndspy.h. The names should be self explanatory: PkDspyFloat32, PkDspyUnsigned32, PkDspySigned32, PkDspyUnsigned16, PkDspySigned16, PkDspyUnsigned8 and PkDspySigned8.
A few more types are defined for optional parameters: PkDspyString, PkDspyMatrix.
If byte orders aren't specified, the machine default is assumed. Byte order can be specified by "or"ing in one of two values:
All functions return one of the following enumerated error codes:
PtDspyError DspyImageOpen(PtDspyImageHandle * image,
const char *drivername,
const char *filename,
int width,
int height,
int paramCount,
const UserParameter *parameters,
int formatCount,
PtDspyDevFormat *format,
PtFlagStuff *flagstuff);
This opens an image called filename and puts a handle to any local data into *image. If width or height is 0, it chooses an appropriate default value for them.
drivername is the name before the /display/dso or /display/dsomapping translation. This allows a single driver to change its behavior based on the name used in the RIB file.
Image types which can include various other tag information might investigate the parameters, which are passed through from the RIB Display line. A list of the commonly interpreted ones appears later in this document. Two important points: The data pointed to by both the parameters structures and the format structures is valid only for the duration of this function call, copy any information that you plan to reuse to your own structures; and the values pointed to by the UserParameter structure are not necessarily aligned, which is why all of the helper functions copy this information to your own variables rather than trying to use them in place.
formatCount and format describe the data as it will be sent to the driver. The driver should reorder the format array into the order it expects to deal with data (it is important that the format.name fields point to the original strings!), and set format[x].type to types and byte orders that it can deal with.
Finally, flagstuff allows the driver to request that data be sent in different ways. Three flags can be "OR"ed into flagstuff->flags:
If you don't use PkDspyFlagsWantsScanLineOrder the renderer won't call DspyImageData for regions of the image where it doesn't draw anything. Don't assume that the entire image (or even any of the image, if none of the geometry is visible) will be filled in.
This example will implement a trivial image format. It makes no allowances for differences between platforms. The format is just an "int" which is the number of channels being sent to this image, that many strings, which name them all, and that many floating point values per pixel for the rest of the image.
#include#include #include #include typedef struct { FILE *file; int channels; int width, height; } *MyImageType; PtDspyError DspyImageOpen(PtDspyImageHandle *pvImage, const char *drivername, const char *filename, int width, int height, int paramCount, const UserParameter *parameters, int formatCount, PtDspyDevFormat *format, PtFlagStuff *flagstuff) { PtDspyError ret; MyImageType image; /* We want to receive the pixels one after the other */ flagstuff->flags |= PkDspyFlagsWantsScanLineOrder; /* Do stupidity checking */ if (0 == width) width = 640; if (0 == height) height = 480; image = NULL; ret = PkDspyErrorNone; image = (MyImageType) malloc(sizeof(*image)); if (NULL != image) { int i; image->channels = formatCount; image->width = width; image->height = height; image->file = fopen(filename, "wb"); if (image->file) { fwrite(&formatCount, sizeof(formatCount), 1, image->file); for (i = 0; i < formatCount; i++) { format[i].type = PkDspyFloat32; fwrite(format[i].name, strlen(format[i].name) + 1, 1, image->file); } } else { free(image); image = NULL; ret = PkDspyErrorNoResource; } } else ret = PkDspyErrorNoMemory; *pvImage = image; return ret; }
PtDspyError DspyImageQuery(PtDspyImageHandle pvImage,
PtDspyQueryType type,
size_t size,
void *p);
DspyImageQuery is used to communicate state
information about the features of the display driver and the image
the display driver can produce. Each query is made by calling
DspyImageQuery with a query-type and corresponding
query-structure passed as p. DspyImageQuery fills
values in the query-structure and returns a value indicating the
sucess or failure of the query.
The following query-types may be passed to
DspyImageQuery:
PkSizeQuery: Asks for the size of the image, or a default size of no image is supplied (pvImage may be NULL!). It will be called with an image handle when the DspyImageOpen was called with a 0 width and height. It will also be called without an image handle for applications which want to query for a fixed image size (as might happen with a framebuffer).
PkOverwriteQuery: Asks whether the driver in question actually overwrites the file name given, and is used to keep the user from accidentally overwriting an image. The response structure, PtDspyOverwiteInfo, has two fields. The .overwrite field tries to keep the user from doing damage when using tools like sho for image conversion, or when writing to the "framebuffer" display device which may be mapped to something destructive. The .interactive field isn't yet used in any tools, the hope was that it would make batch tools a little bit smarter.
PkSupportsCheckpointing: Asks whether the display driver
supports image checkpointing. Image checkpointing allows the
render to skip a portion of a render if the "-recover 1" option is
passed to render. The PkSupportsCheckpointing is
first issued by the render to all display drivers that are used in
the render. If all respond positively to the
PkSupportsCheckpointing query, the display drivers
are initialized with DspyImageOpen, and the
PkRenderingStartQuery is issued to determine where
restart the render. PkSupportsCheckpointing is issued
with a NULL pvImage. Any data that needs to be
communicated to the display driver before the
DspyImageOpen method needs to be initialized upon
receiving PkSupportsCheckpointing. If the display
driver supports image checkpointing, DspyImageOpen
needs to determine where the render should start.
PkRenderingStartQuery: Asks where the display driver
can recover to. After issuing a
PkSupportsCheckpointing query, the render knows if it
is possible to recover. The render needs to know how far along in
the image the display driver can recover. The
PtDspyRenderingStartQuery return structure indicates,
in image space, where the display driver contains its last piece
of valid image data. The render will compile all of the rendering
start locations from all the display drivers to determine where to
start rendering. PkRenderingStartQuery is called
with a valid pvImage so any information that needs to be
passed to the DspyImageData needs to be initialized
here. If the display driver supports image checkpointing, the
display driver must ignore all data passed to
DspyImageData that is less than the value returned in
the PtDspyRenderingStartQuery structure.
PtDspyError
DspyImageQuery(PtDspyImageHandle pvImage,
PtDspyQueryType querytype,
int datalen,
void *data)
{
PtDspyError ret;
MyImageType image = (MyImageType )pvImage;
ret = PkDspyErrorNone;
if (datalen > 0 && NULL != data)
{
switch (querytype)
{
case PkOverwriteQuery:
{
PtDspyOverwriteInfo overwriteInfo;
if (datalen > sizeof(overwriteInfo))
datalen = sizeof(overwriteInfo);
overwriteInfo.overwrite = 1;
overwriteInfo.interactive = 0;
memcpy(data, &overwriteInfo, datalen);
break;
}
case PkSizeQuery :
{
PtDspySizeInfo sizeInfo;
if (datalen > sizeof(sizeInfo)) {
datalen = sizeof(sizeInfo);
}
if (image)
{
if (0 == image->width ||
0 == image->height)
{
image->width = 640;
image->height = 480;
}
sizeInfo.width = image->width;
sizeInfo.height = image->height;
sizeInfo.aspectRatio = 1.0f;
}
else
{
sizeInfo.width = 640;
sizeInfo.height = 480;
sizeInfo.aspectRatio = 1.0f;
}
memcpy(data, &sizeInfo, datalen);
break;
}
case PkRenderingStartQuery :
{
PtDspyRenderingStartQuery startLocation;
if (datalen > sizeof(startLocation))
datalen = sizeof(startLocation);
if (image) {
/*
* initialize values in startLocation
*/
memcpy(data, &startLocation, datalen);
} else {
ret = PkDspyErrorUndefined;
}
break;
}
default :
ret = PkDspyErrorUnsupported;
break;
}
}
else
{
ret = PkDspyErrorBadParams;
}
return ret;
}
PtDspyError DspyImageData(PtDspyImageHandle pvImage,
int xmin,
int xmax_plusone,
int ymin,
int ymax_plusone,
int entrysize,
const unsigned char *data)
{
PtDspyError ret;
MyImageType image = (MyImageType )pvImage;
int oldx;
oldx = xmin;
for (;ymin < ymax_plusone; ymin++)
{
for (xmin = oldx; xmin < xmax_plusone; xmin++)
{
fwrite(data, sizeof(float), image->channels, image->file);
data += entrysize;
}
}
return ret;
}
PtDspyError DspyImageClose(PtDspyImageHandle pvImage)
{
PtDspyError ret;
MyImageType image = (MyImageType )pvImage;
fclose(image->file);
free(image);
ret = PkDspyErrorNone;
return ret;
}
PtDspyError DspyImageData(PtDspyImageHandle image,
int xmin,
int xmax_plusone,
int ymin,
int ymax_plusone,
int entrysize,
const unsigned char *data);
Write data for the image area described. entrysize is the skip in bytes to the next pixel in data. Unlike the old dspy system, xmax_plusone and ymax_plusone are 1 more than the last pixel to be written, that is that the width of the region to be written is xmax_plusone-xmin and not xmax-xmin+1.
PtDspyError DspyImageData(PtDspyImageHandle pvImage,
int xmin,
int xmax_plusone,
int ymin,
int ymax_plusone,
int entrysize,
const unsigned char *data)
{
PtDspyError ret;
MyImageType image = (MyImageType )pvImage;
int oldx;
oldx = xmin;
for (;ymin < ymax_plusone; ymin++)
{
for (xmin = oldx; xmin < xmax_plusone; xmin++)
{
fwrite(data, sizeof(float), image->channels, image->file);
data += entrysize;
}
}
}
PtDspyError DspyImageClose(PtDspyImageHandle);
Simply free any resources associated with the image handle.
PtDspyError DspyImageClose(PtDspyImageHandle pvImage)
{
PtDspyError ret;
MyImageType image = (MyImageType )pvImage;
fclose(image->file);
free(image);
ret = PkDspyErrorNone;
}
PtDspyError DspyImageDelayClose(PtDspyImageHandle);
There are situations where a display manager might want to keep running after the renderer has finished sending data. For instance, a driver which displays images in a window may want to keep that window available for user manipulation. This function is the perfect place to put a display loop; simply don't return until the window is closed.
If this function exists in the display driver, then the display driver will run in a separate process from the main renderer and the renderer itself will exit as soon as the image is complete. This is important for two reasons:
In order to use the shared object, the renderer must be able to find it. When you pass a format name in via the type (second) parameter to RiDisplay:
Common usage is to put the driver into ${RMANTREE}/etc/ named d_type.so or d_type.dll.
There are a set of basic functions that nearly every image implementation needs to do. Many of these have to do with accessing parameters, which are either predefined or passed through from the RIB Display line. These are automatically made available by the renderer, and do not require linking with any further files.
PtDspyError
DspyFindStringInParamList(const char *string,
char **result,
int paramCount,
const UserParameter *parameters)
If string is found in parameters, put
a pointer to it in *result and return
PkDspyErrorNone, else return
PkDspyErrorNoResource.
char *result = NULL;
DspyFindStringInParamList("secondchoice", &result, paramCount, parameters);
DspyFindStringInParamList("firstchoice", &result, paramCount, parameters);
if (result)
{
...
void DspyMemReverseCopy(unsigned char *target, const unsigned char *source, int len);
Fairly self explanatory. Reverse len bytes from source to target.
PtDspyError
DspyFindMatrixInParamList(const char *string,
float *result,
int paramCount,
UserParameter *parameters)
Example:
float matrix[16];
if (DspyFindMatrixInParamList("NP", matrix, paramCount, parameters))
{
...
PtDspyError
DspyFindFloatInParamList(const char *string,
float *result,
int paramCount,
const UserParameter *parameters)
Get a floating point value from the parameter list. Here's an example of getting the near clipping plane from the parameter list:
float nearClip;
DspyFindFloatInParamList("near", &nearClip, paramCount, parameters);
PtDspyError
DspyFindFloatsInParamList(const char *string,
int *resultCount,
float *result,
int paramCount,
const UserParameter *parameters)
Get a floating point array from the parameter list. Similar to DspyFindFloatInParamList except that *resultCount is the maximum number of floats available at result, and is set to the number actually copied into result.
PtDspyError
DspyFindIntInParamList(const char *string,
int *result,
int paramCount,
const UserParameter *parameters)
Get an integer value from the parameter list. Used similarly to DspyFindFloatInParamList().
PtDspyError
DspyFindIntsInParamList(const char *string,
int *resultCount,
int *result,
int paramCount,
const UserParameter *parameters)
Get an integer value from the parameter list. Used similarly to DspyFindFloatsInParamList().
PtDspyError
DspyReorderFormatting(int formatCount,
PtDspyDevFormat *format,
int outFormatCount,
const PtDspyDevFormat *outFormat)
Attempt to reorder format to look like outFormat. We can't save users from themselves, but if we expect to get "abgr", we can use this to try to order the incoming parameters to look more like "abgr" than "rgba" or whatever other random format our caller may request.
Obviously users can provide any set of parameters they want. The renderer will also provide a standard set of parameters:
| Name | Type | Description |
|---|---|---|
| NP | matrix | world to screen space |
| Nl | matrix | world to camera space |
| near | float | near clipping plane (useful for scaled Z buffer formats) |
| far | float | far clipping plane |
| origin | int[2] | with crop windows provides the origin of this image within the larger image, in pixels. |
| OriginalSize | int[2] | with crop windows provides the size of the larger image into which this image fits. |
| PixelAspectRatio | float | pixel aspect ratio |
| Software | string | renderer version |
| HostComputer | string | host name |
|
Pixar Animation Studios
|