Known Issues
Known Issues
RIS Caveats
- Multi-camera (stereo) rendering does not work in RIS mode.
- Pixel imager shaders are not supported for deep output in RIS mode.
- PxrOSL has several known limitations enumerated in the node's documentation.
- Refinement methods are not supported at this time.
- Instanced NURBS will disappear unless instanceworlddistancelength is explicitly set.
- The adaptive noise suppressor is not yet applied to deep output in RIS mode.
- Rendering via netrender currently only works with "bucket" screenorder and non-progressive rendering. Additionally, only pixel size filters are supported for RIS netrender.
Volumes
- Opacity caching is not used for volumes in RIS-mode. For homogeneous volumes this results in faster renders. For heterogeneous volumes this is currently resulting in noisier and slower renders. We are actively working on addressing this in a subsequent release.
- Users of RiVolume should now ensure that the bounds do not intersect geometry (we may alleviate this restriction in a future release).
General
The "Time tracing transmission rays" stat is now including shading transmission hits. This time is also included in the overall "Tracing Rays" stat.
Calling getshader(), getshaders(), getlight(), or getlights() during construct may result in unexpected behavior or sub-optimal performance.
The RifFaceEdgeData plugin can only be used while rendering with prman.
Point-based global illumination can give discontinuous, aliased results if "falloff" is set to 0 and "maxdist" is shorter than the scene extent. (The default for "maxdist" is 1e15.) With short "maxdist" values, please use "falloff" 1 or 2. If you have to use "falloff" 0, setting "maxsolidangle" to a very small value can reduce the aliasing (but also increases render time significantly).
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.
The evaluateSamplesEnv and generateSamplesEnv can only read latlong environment maps.
REYES (i.e. not RIS) Re-rendering
- Hider restrictions - The only hiders supported are stochastic and raytrace. Sigma buffer and stitching are not supported.
- Camera restrictions - Multi-camera rendering is not supported.
- Graphics primitives - CSG is not supported.
- Display - Progressive refinement is critical to making editing interactive. We have provided a new display driver, multires, that can quickly display the multi-resolution images produced by re-rendering. However, existing display drivers can't display multi-resolution images and will cause the re-renderer to disable progressive refinement, rendering only at the highest resolution.
- Resizable Arrays - Traditional shaders with resizeable arrays will not be baked properly, leading to a crash during re-rendering. However, shader object-based shaders do support the use of resizeable arrays.
- Using the raytrace hider with netrender currently only works with "bucket" screenorder and non-progressive rendering.
Baking 3D Textures
- Be careful about baking at ray hit points! Baking at ray hit points can scatter additional data points in the point cloud, in addition to the regular data baked from REYES shading grids. The additional data points can have widely varying radius values.
- Subsurface scattering and point-based color bleeding from implicit surfaces can be too bright! The points overlap more on implicit surfaces than on other surface types. So any type of computation that relies on the point density, for example subsurface scattering and point-based color bleeding, will be too bright. (Note, however, that area(P, "dicing") and the radius values computed automatically by the bake3d() function are correct on implicit surfaces.)
- Don't bake point clouds or brickmake over slow a network! When generating a point cloud or a brick map, write the resulting file to local disk (i.e. the disk associated with the computer doing the work) and then copy the final file across the network. This is faster than writing the file directly to a remote file location because the points and bricks are written in relatively small packets.
Brick Map Geometric Primitives
- Constructive Solid Geometry (CSG): the brick map geometic primitive cannot be used for constructive solid geometry.
- Backface culling: "sides 1" can only only be used for backface culling of brick map geometric primitives if the brick map contains normal data N.
- Deformation motion blur is not implemented.
- If the displacement shader gives discontinuous (non-smooth) displacements, the result can be "torn" geometry i.e. a surface with holes.
- Ray tracing of brick maps with displacement shading is not implemented: the displacement will be ignored. (However, displacement of directly visible brick maps works just fine.)
- Semitransparent (surface) brick maps can look too opaque. However, the new blobby volume brick maps introduced in PRMan 15.0 render with correct extinction-dependent opacity - see the Volume Rendering application note.
- Ray tracing bias: due to the relatively coarse voxelization of the surface geometry represented by a brick map, rays leaving a brick map geometric primitive can incorrectly hit the same brick map. This problem is significantly reduced if the brick map contains P and N data. Otherwise the only way to avoid such self-intersections is to set the ray tracing bias value rather high.
- When executing a shader on a brick map geometric primitive, the Du() and Dv() functions always return 0.
- If the brick map does not contain normal data N, calculatenormal() will return -I and -I will be used for the Ng parameter to faceforward().
Photon Tracing/Mapping
- Photon tracing can not be done using netrender at this time.
- PRMan can currently only handle one point cloud (or one brick map) for scattering coefficients. It would be nice to have the possibility of having more point clouds and brick maps, for example one per object.
- No glossy reflection or refraction (neither isotropic nor anisotropic) in the photon scattering phase.
- When baked scattering coefficients are used, we can't do direction-dependent scattering coefficients such as the Fresnel formulas. (Use the built-in material "glass" for glass with Fresnel reflection and refraction.)
- Photon transport in volumes is not currently supported.