Moin Haggi,
> I'm still try to understand how shading and sampling is done in
> renderman compliant renderers.
RMan compliance only means that the renderer implements a certain set
of required capabilities and exposes them through the RI API (http://
en.wikipedia.org/wiki/RenderMan_Interface_Specification).
RMan compliance does, however, say nothing about the underlying
algorithms used.
You could e.g. slap the RMan API in front of a renderer like VRay and,
if it sup****ted all required capabilities, it could call itself
"RenderMan-compliant".
You are probably thinking about an implementation that is prominent
with RMan-compliant renderers, namely the REYES algorithm (http://
en.wikipedia.org/wiki/Reyes_rendering).
However, some of them (e.g. Pixie & 3Delight with some non-default
hiders or AIR) use completely different approaches. Blue Moon
Rendering Tools, the first freely available RMan implementation was a
pure ray-tracing renderer (http://en.wikipedia.org/wiki/BMRT).
REYES is also found in many other renderers these days, e.g. Modo's
built-in renderer, Poser's Firefly, the Pixels3D renderer and
Houdini's Mantra are all REYES renderers, even though none of them is
RMan-compliant.
> If someone could give me some additional
> insight I'd be very happy.
I urge you to read "How PhotoRealistic RenderMan works" which is a
SIGGRAPH course note that became a chapter of the book "Advanced
RenderMan" (ARMan) and is freely available for download here
http://www.renderman.org/RMR/Publications/infbeyond.pdf
> - a geometry is divided into a micropolygon grid
> - shading is done at the vertices of the micropolygons
> - then the sampling collects the shading samples of all x,y neighboring
> pixels and combine them via a filter into the final pixel
Not exactly. The shading samples are, as you said, the vertices of the
u-polys. The renderer then "shoots" samples through the u-polys under
the pixel in question. These samples will intersect the u-polys at
arbitrary places, not neccesarily at the vertices (which is where the
shading samples took place).
The shading at those pixel sample positions is interpolated from the
vertices of the resp. u-poly (unless you turn smooth shading off, then
each u-poly gets only a single color).
> - at the end, the pixels are filtered with a xyz filter
I'm not sure what you mean by a 'xyz filter'.
The pixel samples within the region specified by filter size are
averaged using a weighting ****tion that is specified through the pixel
filter. This happens in 2D (the image), not in 3D.
> Okay. This mean if I have a high frequency texture where I need more
> shading samples I need more micropolygon vertices. This can be archived
> via a lower shading rate. This way I get a smoother result.
Yes, but if your u-polys get considerably smaller than a pixel you
also need more pixel samples to account for geometric aliasing.
A good rule is a shading rate of 1 for a 2k frame. If your textures
are too blurry, you can tweak the texture filter used during texture
lookup. This includes both the filter used and the filter size.
Decreasing this will introduce some aliasing but give you crisper
result with the need to lower shading rate (which is much more
expensive).
In general, doing this only for the displacement texture solves most
issues that upset artists. :)
> And because all shading samples in the x/y area for filtering have to be
> in memory until the final pixel is done, I need more memory if I
> increase samples in x and y.
Yes, but this is negligible.
> I did some simple tests with AIR and mayaman.
Afaik, AIR is not REYES renderer.
I might be completely off here but as far as my understading goes, AIR
uses foremost curvature-based tesselation criteria and then creates
shading samples in pixel space instead of shading at u-poly vertices.
So AIR works very different from the way described above.
Try setting shading rate to 10 in AIR, then run the same RIB through
3Delight, Aqsis or PRMan.
AIR's image will look like you ran a mosaic filter on it in Photoshop.
The images created by the other renderers will still look reasonably
good (definitely for lighting previews), only the shading will be
blurrier. Silhoutte quality will definitely be very good still since a
shading rate of 10 results in a u-poly edge length of only a little
more than 3 pixels average, in a REYES renderer.
In any case, the above said about REYES only applies to AIR in parts.
> - If it is true that the renderer creates more micropolygons with a
> lower shading rate, why does my rendering take almost the same memory if
> I have a shading rate of 8 or .1?
Foremost probably because AIR doesn't work that way. If you lower
shading rate in AIR, it creates the same number of polygons but
samples them denser.
REYES renderer process the image in buckets of pixels (default is
16x16). As soon as a bucket is done, any grids it created are purged
unless the renderer can foresee them being needed in adjacent buckets
(e.g. if a grid intersects others than the current bucket). So you
would likely see an increased memory forptint with lower shading rate
in a REYES renderer. How much also depends on bucket- and gridsize
though.
REYES was invented when machines' RAM was measured in KB but people
wanted to renderer photorealistic images at 2k with 3d motion blur,
depth of field and sub-pixel displacement. As such, it is a very
memory-conservative algorithm.
Memory use & speed during shading & sampling in modern REYES depends a
lot on the implementation these days. This is because of multi-
threading.
Some renderers share bucket data between threads, others don't. If
bucket data is not shared, memory use is increased but scaling
archived with increased number of thread is usually higher.
Prost,
Moritz
|
