appendixA.html, appendixF.html, index.html, section01.html, section02.html, section03.html, section04.html, section05.html, section06.html, section07.html, section08.html, section09.html, section10.html, section11.html, section12.html, section13.html, section14.html, section15.html, section16.html
Polygons | Patches | Quadrics | Procedural Primitives | Implementation-specific Geometric Primitives | Solids and Spatial Set Operations | Retained Geometry
RiPolygon( nvertices, parameterlist )
RtInt nvertices;
OK.
RiGeneralPolygon( nloops, nvertices, parameterlist )
RtInt nloops;
RtInt nvertices[];
OK.
RiPointsPolygons( npolys, nvertices, vertices, parameterlist )
RtInt npolys;
RtInt nvertices[];
RtInt vertices[];
OK.
RiPointsGeneralPolygons( npolys, nvertices, vertices, parameterlist )
RtInt npolys;
RtInt nloops[];
RtInt nvertices[];
RtInt vertices[];
OK..
RiBasis( ubasis, ustep, vbasis, vstep)
RtBasis ubasis, vbasis;
RtInt ustep, vstep;
OK.
RiPatch( type, parameterlist )
RtToken type;
OK.
RiPatchMesh(type, nu, uwrap, nv, vwrap, parameterlist )
RtToken type;
RtToken uwrap, vwrap;
RtInt nu, nv;
OK.
RiNuPatch( nu, uorder, uknot, umin, umax, nv, vorder, vknot, vmin, vmax, parameterlist )
RtInt nu, nv;
RtInt uorder, vorder;
RtFloat uknot[]. vknot[];
RtFloat umin, umax, vmin, vmax;
RiNuPatch interprets parameters correctly according to the clarification with the RI specification that Pixar made in PRMan3.6 Release Notes:
"Formerly an RiNuPatch was defined to have just one uniform value and four varying values, one at each corner of the RiNuPatch. Now an RiNuPatch is defined to have a number of segments in each parameter direction with one uniform value per segment and one varying value per segment corner. This is analogous to RiPatchMesh with one uniform value per patch and one varying value per patch corner. An RiNuPatch is now defined to have (1+nu-uorder) segments in the u direction and ( 1+nv-vorder) segments in the v direction. (The number of segment corners is of course one more than that in each direction.) This corresponds to the RiPatchMesh model in the case where the RiNuPatch is a uniform b-spline. This results in redundant parameter values corresponding to repeated knot values, for instance when the knot vector indicates the RiNuPatch is in Bezier form, however the benefit of the flexibility far outweighs any burden due to the redundancy."
In the C binding, RenderDrive supports the old method of parameter passing through the RiNuPatch0 call. The RIB parser library automatically detects which method of parameter passing is being used.
RiTrimCurve( nloops, ncurves, order, knot, min, max, n, u, v, w)
RtInt nloops;
RtInt ncurves[];
RtInt order[];
RtFloat knot[];
RtFloat min[]; max[];
RtInt n[];
RtFloat u[], v[], w[];
OK. The sense of trimcurves, specified by
RiAttribute(RI_TRIMCURVE, "sense", "inside" or "outside")
is also supported. (PRMan 3.8 extension)
RiSphere( radius, zmin, zmax, thetamax, parameterlist )
RtFloat radius;
RtFloat zmin, zmax;
RtFloat thetamax;
OK.
RiCone( height, radius, thetamax, parameterlist )
RtFloat height;
RtFloat radius;
RtFloat thetamax;
OK.
RiCylinder( radius, zmin, zmax, thetamax, parameterlist )
RtFloat radius;
RtFloat zmin, zmax;
RtFloat thetamax;
OK.
RiHyperboloid( point1, point2, thetamax, parameterlist )
RtPoint point1, point2;
RtFloat thetamax;
OK.
RiParaboloid( rmax, zmin, zmax, thetamax, parameterlist )
RtFloat rmax;
RtFloat zmin, zmax;
RtFloat thetamax;
OK.
RiDisk( height, radius, thetamax, parameterlist )
RtFloat height
RtFloat radius;
RtFloat thetamax;
OK.
RiTorus( majorradius, minorradius, phimin, phimax, thetamax, parameterlist )
RtFloat majorradius, minorradius;
RtFloat phimin, phimax;
RtFloat thetamax;
OK.
RiProcedural( data, bound, subdividefunc, freefunc )
RtPointer data;
RtBound bound;
RtFunc subdividefunc;
RtFunc freefunc;
Not implemented.
RiGeometry( type, parameterlist )
RtToken type;
RenderDrive provides a Martin Newell ("Utah") teapot via the RiGeometry "teapot" call. Note that this is the leaky, z-scaled version.
RiCurves( type, ncurves, nvertices, wrap, parameterlist );
RtToken type;
RtInt ncurves, nvertices[];
RtToken wrap;
Not implemented. (PRMan 3.7 extension)
RiPoints( npoints, parameterlist );
RtInt npoints;
Not implemented. (PRMan 3.7 extension)
RiNuCurves( ncurves, nvertices, order, knot, min, max, parameterlist );
RtInt ncurves, nvertices[], order[];
RtFloat knot[], min[], max[];
Not implemented. (RenderDotC extension)
RiSubdivisionMesh( scheme, nfaces, nvertices, vertices, ntags, tags, nargs, intargs, floatargs, parameterlist)
RtToken scheme;
RtInt nfaces, nvertices[], vertices[], ntags;
RtToken tags[];
RtInt nargs[], intargs[];
RtFloat floatargs[];
Not supported. (PRMan 3.8 extension)
RiBlobby( nleaf, ncode, code, nflt, flt, nstr, str, parameterlist)
RtInt nleaf, ncode;
RtInt code[];
RtInt nflt;
RtFloat flt[];
RtInt nstr;
RtString str[];
Not supported. (PRMan 3.9 extension)
RiSolidBegin( operation )
RtToken operation;
RiSolidEnd()
Ignored. Note that RiInterior works on any two-sided geometry.
RtObjectHandle RiObjectBegin() RiObjectEnd()
OK, except that ObjectBegin/End blocks containing no Ri call are not supported and will cause an error when instanced.
RiObjectInstance( handle );
RtObjectHandle handle;
OK.
RiObjectFree( handle );
RtObjectHandle handle;
Supported. (RenderDotC extension)