formZ SDK | 4.0 Call Back Reference | Renderer
Description
level info function. It is called by formZ to retrieve basic
information about the renderer.
The first function argument sets the type of renderer. Three choices are available :
pixel, vector or polygonal. A pixel renderer is expected to create a pixel based
image, using techniques such as scanline z-buffering or raytracing.
The Shaded Render and RenderZone display modes are examples of a pixel renderer.
A vector renderer is expected to draw lines to the screen. The basic vector renderer
provided by formZ is Wire Frame. A vector renderer is also expected to provide a
callback function which exports the lines to a 2d vector format. This callback
function is described in more detail below. A polygonal renderer draws the faces
of objects as closed and color filled polygons on the screen. The faces are usually
sorted in the viewing direction, to provide proper depth display. It is also
expected to provide the 2d export callback function. The Quick Paint and Surface Render
display modes are examples of a polygonal renderer.
The behave argument tells formZ, whether the render is fast enough to be
executed as an interactive renderer or not. This will allow a user to create
and edit objects and manipulate views in real time. Two return values are
possible : FZ_RNDR_BEHAVE_INTERACT and FZ_RNDR_BEHAVE_STATIC. If the renderer
is interactive, additional callback functions must be supplied.
Depending on the combination of type and behavior, different drawing methods
need to be used. If a renderer is static and the type is pixel, it must store
one horizontal scanline of the rendered image at a time in an image buffer,
which is provided by formZ. This is done with the API call .
If a renderer is interactive, it may use simple screen drawing commands, such
as the formZ API functions fzrt_move_to and fzrt_line_to, but must do so fast
enough to be reasonably interactive. The formZ Wire Frame drawing mode, for
example, uses this technique. An interactive renderer may also use hardware
assisted drawing, such as OpenGL. This is done in the Interactive Shaded display
mode. Static vector and polygonal renderers may use any drawing method to put the
image on the screen.
formZ manages the storage of the options, window level and project level data
for a plugin renderer. To allocate the proper amount of memory, the plugin
renderer needs to tell formZ how many bytes are needed for each data block.
This is done with the last three function arguments. Typically, a renderer
has the options stored in a structure, whose size can be inquired with a
sizeof(structure_type) call. If 0 is returned for any of the sizes, no memory
will be allocated for the respective data block. The options data holds the
parameters for a renderer, that can be set by a user. They are also displayed
in the corresponding options dialog, which can be accessed through the Display
menu. The project data is information that may be needed by a renderer on a per
project level. For example, the renderer may need to keep a copy of the geometry
to be rendered. This information would be stored in the project data block. Likewise,
the renderer may need to keep information on a per window basis. For example, it may
be necessary to keep track of whether the rendering in a window needs to be
regenerated since last rendered, or whether the previously rendered image can be
displayed from a buffer. This information can be stored in the window data block.
Plugin Prototype
fzrt_error_td fz_rndr_cbak_info(
type, | |
behave, | |
fzrt_int * | proj_data_size, |
fzrt_int * | wind_data_size, |
fzrt_int * | wind_opts_size ) |
Parameters
type [Result]
The type of renderer.
behave [Result]
The rendering behavior (interactive or static).
proj_data_size [Result]
The size of the renderer's project data.
wind_data_size [Result]
The size of the renderer's window data.
wind_opts_size [Result]
The size of the renderer's window options (user interface parameters)
Returns
Error codes
Availability
5.0.0.0
Function Set
Defined in