LightMan 1.0 Documentationlast change: 11/13/01 |
|
| 1. LightMan Reference | top |
|
This Reference explains the installation and use of the several PlugIn modules LightMan consists of. It's just a plain list of functions and what they do. Often the way a certain option behaves is very dependant on the Renderer you are using or is hard to explain without a deeper knowledge of rendering algorithms. In these cases a reference for further information is given which may be a tutorial, FAQ or an external resource in the Further Reading section. LightMan 1.0 works best with LightWave 6.5b, lower Versions of LightWave are not supported, version 7 works fine. |
|
| 1.1. Installation |
top |
|
Extract the .zip file into your PlugIns directory, which should then create a new LightMan Directory below in the PlugIns Directory. It is very important, that the LightMan directory is put below Lightwave's Plugins directory, because otherwise LightMan won't find it's license file and the shaders! Next register the lightman.p PlugIn from within Lightwave (more information on
how to load PlugIns into Lightwave can be found in the Lightwave Manual).This should add a bunch of PlugIns to Lightwave, a shader PlugIn (which lets you replace Surfaces by RenderMan Shaders), an Object Replacement PlugIn which enables you to Replace Objects by RIB Archives and Custom RIB Statements and a Generic PlugIn to do the actual RIB Export are visible to the user. For a first quick tour through LightMan refer to the Getting Started Tutorial. You should consider setting the LightWave Alert Level (General Options) to Intermediate or Expert, since LightMan makes use of Info Messages quite a bit. |
|
| 1.2. LightMan RIB Exporter |
top |
|
This is the Main PlugIn which does the actual Export. It's a generic PlugIn which can be found under Plug-in Options Menu/Generics in Lightwave Layout.
|
|
| 1.2.1. Renderer |
top |
![]() The picture above shows the Export PlugIn's Renderer Tab. When you first start LightMan you'll only have the Minimal RenderMan Renderer set up. You can customize LightMan to support Renderer Specifics by loading RenderMan Renderer Resource Files. To do that select '(add)' and then choose a .rmr file for a certain Renderer. Some configuration files come with LightMan, the latest configuration files can be downloaded from the LightMan Website. |
|
| 1.2.2. Lights |
top |
|
The Lights panel let's you set some Light related things that have no LightWave equivalent. ![]() The DepthFilter determines what depth filter is used for determining what depth value is recorded for a certain pixel in the Shadow Depth Map. The available filters may change dependant on the renderer. Roughly min means the smalles depth found within one pixel will be recorded, max means the maximum depth will be recorded and average will record the average value. The midpoint filter is slightly different but usually works very good when available. It determines visibility by using the middle between the surface nearest to the camera and the surface which is next. Shadow maps often suffer from numerical inaccuracy because of their limited spatial resolution. In some cases this will lead to Shadow Maps reporting objects to be in shadow which actually aren't. To avoid this kind of self-shadowing a small fudge-factor is introduced which moves the shadow slightly away from the object. To set this bias on a per LightSource Basis check the Shadow Depth Map Bias checkbox and set the value to a small distance you think is appropriate. Be aware that too high values might detach the shadow from the shadow casting object. These two options only apply when depth map shadows are used for this light. With the options on the bottom of this panel you can replace the current light with a custom RenderMan LightSource Shader. |
|
| 1.2.3. Objects |
top |
|
The Objects panel let's you set some Object related things that have no LightWave equivalent. ![]() With the LightWave Renderer you always have to specify the size/thickness of point and line primitives in raster space. LightMan uses these values and tries to do the same, but you might want to override this behaviour by checking the Particle/Line Width checkbox and select an object space thickness. This will let lines and points scale properly when viewed from different distances (raster space points/lines always have a constant width on the screen independent from the distance of the viewer). The Apply to Children, Apply to Instances and Apply to All buttons will apply the settings for the current object to its children, all other instances of this object or to all objects respectively. The Export Entity function can be used to export individual objects into RIB Archives for later use by LightMan (e.g. through Object Replacement) or from other RenderMan Exporters. The Export Entity Button brings up another Panel which gives you a couple of export options. ![]() Export Path and Export Name have the same functionality as the corresponding fields on the Export Tab. The '.rib' extension will be added to the Export Name and in case of Animation Export also a frame number. Animation Export means that the whole range of frames from Lightwaves Render Options Panel will be exported, if it isn't checked only the current frame is exported. Surfaces will have all surface assignements exported with the object when checked. World Coordinates will export all Polygon Vertices in World Coordinates if checked. Checking Motion Blur will enable export of Motion Blur information. Individual Polygons has the same meaning as the 'Raw Individual Polygons' option from the Export Tab. Export Children exports all child objects into the same RIB Archive. Binary Encoding and Use GZIP Compression have the same meaning as the corresponding checkboxes on the Export Tab. |
|
| 1.2.4. Options |
top |
|
This panel let's you set up Rendering Options and relates directly to the Options in the RenderMan Interface Specification [ 1 ]. ![]() Pixel Filter is the Sampling Filter used by the Renderer. Which filters you can select here, may depend on the Renderer you are using. The Standard Pixel Filters specified by the RenderMan Spec are box, triangle, catmull-rom, gaussian and sinc. Gaussian is basically a slight blur which is usually successfull to a certain degree in hiding sampling artifacts, Catmull-Rom and Sinc usually produce a crisper image. For the description of these filters and nonstandard filters provided by a certain renderer please consult the manual of your particular renderer. The Filter Width defines the size or range of influence of the Filter (in pixels). This may have slightly different effects with different filters. In the case of a Gaussian filter a larger value will increase the bluryness. Gain and Gamma are the usual Gamma correction controls. You may apply one of the standard Imager Shaders as specified in the RenderMan Interface Specification 3.2 or your own shader and it's Imager Shader Parameters. Output Type specifies which channels are actually written to the output image file. The Shading Rate influences how often per pixel Shading Calculation is done. It basically does the same for Shading, what PixelSamples does for Hidden Surface Eliminination. How this is exactly honored is up to the Renderer and may be very different. REYES Renderers (PRMan, RenderDotC) usually use it to estimate how fine the Objects are being diced into micropolygons and has a great influence on Rendering Time and Quality (you might want to use very high Shading Rates for Previews and lower ones for final Rendering. BMRT uses it to decide whether it will reuse Shading Samples within one Pixel. If Shading Rate is 1.0, BMRT will try to make only one Shading Calculation per Pixel, lower values force BMRT to do more Shading Calculations per Pixel. This can have significant Influence on Rendering Time, but usually less significant than for REYES Renderers. Look up your Renderers Documentation on how Shading Rate influences Rendering Quality and Time. Shading Interpolation is not always meaningful. In Reyes Renderers it determines, whether the color of a micropolygon is assumed to be the result of the Shading Calculations at one of its Vertices, or whether the Color of all four Corners is interpolated. Usually constant is fine, but it may produce artifacts in some cases, especially when ShadingRate is high. Archive, Shader and Texture Searchpath are the Searchpath Options passed to the Renderer to let it know, where to look for Shaders, Textures and Archives. You should only edit this, if you use external Shaders, Textures or Archives in your Scene and don't want to copy them to the respective directory LightMan creates. The Syntax is a little bit nonstandard to make sure, that this Options can be used for both, Windows and Unix Systems. The Point tells the Renderer to look into the current directory first, the colons are used for both, seperating entries and for specifying windows drive names. The next standard entry tells the renderer to look in the shaders, textures or archives directory respectively. As an example: If you want to add a directory '../mycustomshaders' to the Shader Searchpath, the line would look like this: .:shaders:../mycustomshaders:&You should always use forward slashes to seperate directories, if you use backslashes, they must be doubled. The RenderMan Interface allows Renderers to have nonstandard Options which are specific to a certain implementation. To access these Options for the currently selected Renderer, use the Renderer Specific Button. It will bring up another window with Options, for the meaning of these refer to the Documentation of your Renderer. The picture below shows an example of the Renderer Specific Options Panel for Exluna's Entropy Renderer.
|
|
| 1.2.5. Export |
top |
|
The Export Tab let's you set up the export settings and either export to file for later rendering or render directly with the selected renderer (if it is properly installed on your system). ![]() Export Root is the base directory the all temporary files for Rendering are exported to. If needed also subdirectories are created there which contain RIB Archive Files, Shaders and Textures. Export Name is the base name for the main RIB File. The Export Geometry as Selector let's you choose how geometric objects are going to be exported.
Since ASCII scehen descriptions tend to grow very large you can make your RIB files more compact by using Binary Encoding and GZip Compression. These two options can be used individually or together. These options make hand editing of RIB impractical. Be aware that there might be RenderMan Renderers which won't directly read binary or gzipped RIB or both. Shadow Pass, Environment Pass and Main Pass let's you select which passes actually get put out. This may help for preview Rendering, for example if you don't want Shadow Maps or Environment Maps to be rerendered when you just changed a shader. Light Sources will still make use of their Shadow Maps (and the Renderer may complain when they are not there) so this has not the same effect as disabling Shadow Mapped Shadows. Separate Frames will write Rendering information for each frame into an individual RIB file instead of one big file. On the bottom there is a selector box which let's you choose an export mode and the Do It! button which will execute that action. Possible export modes are:
|
|
| 1.3. LightMan Surface Shader |
top |
|
Currently LightMan only exports basic LightWave Surface properties, no textures are exported. For getting textures, you need to write a RenderMan Shader and apply it to a surface using the LightMan Surface Shader as shown below. ![]() This example uses the wood2 Shader, which ships with BMRT. You can
switch the replacement on and off with the checkbox in the top, the Shader Name
is wood2 in this case. The Shader is in the file wood2.sl.
Be aware, that a shader name is not neccessarily the name of the file it is in, a
file may even contain more than one shader. The Shader Parameters are a token value
list which uses the same syntax as used in the .rib File. Nonstandard Tokens need
to be inline declared. The whole line in this example is:"Ka" 1.0 "Kd" 0.7 "Ks" 0.3 "specularcolor" [1 1 1] "roughness" 0.1 "float txtscale" 8 "color lightwood" [0.75 0.55 0.40] "color darkwood" [0.69 0.44 0.25]For an deeper understanding of how this works, I recommend reading the RenderMan 3.2 Spec [ 1 ], especially the paragraph describing the Surface call and Section 3 ('Relationship to the RenderMan Shading Language'). You'll also have to put this shader somewhere, where your renderer can find it. One way would be copying it to the shaders directory created by LightMan in your export directory, the other way would be adding the directory where it can be found to the Shader Searchpath on the Export Tab in the Export PlugIn. You'll also have to compile this shader by yourself for preview rendering. For a good introduction to the concept of Shaders in RenderMan I would recommend the Advanced RenderMan Book [ 3 ] (especially chapter seven) and Steve Mays notes on Shader writing [ 7 ]. |
|
| 1.4. LightMan Object Replacement |
top |
|
With the LightMan Object Replacement PlugIn you can easily replace Objects by calls to RIB Archives, RenderMan Procedural objects, calls to implementation specific geometry or abitrary statements which are put directly into the RIB stream. ![]() The Replacement Type lets you select by what kind of RIB Statement this object should be replaced:
The Argument depends on the Replacement and Procedural Type. For ReadArchive it is the name of the RIB File, for Procedurals it's the argument string passed to the procedural (in case of DelayedReadArchive also the name of the RIB File). For the RIB Statement Replacement, Argument is just the string which is directly inserted into the RIB Stream, in case of a geometry replacement it's the name string of the geometric primitive. Parameterlist is only used for the Geometry Replacement Type. It's the Parameterlist string passed to the Geometry call (similar to the Shader Parameterlist). All these things can be really powerful when used effectively. Chapter 5 in the 'Advanced RenderMan' Book [ 3 ] covers a lot of techniques using Procedural Primitives. Some talks of the Siggraph RenderMan Courses [ 6 ] also give a lot of insight on how to use this effectively. The Basic idea is to use some very simple stand-in geometry for interactive editing in LightWave which can effectively replaced by lots of heavy geometry for final Rendering. |
|
| 2. What get's exported (and how) | top |
||||||||||||||||
|
LightMan is designed to use as many settings and Options from within LightWave and directly translate them into the RenderMan format. This Chapter explains which settings are exported, how they get exported, which ones not get exported (and why) and why sometimes settings may produce results that are different from what the LightWave Renderer would produce. |
|||||||||||||||||
| 2.1. Geometry | top |
||||||||||||||||
|
All types of geometry that the LightWave Renderer renders will be exported for Rendering with the RenderMan renderer of your choice. SubPatches and Metaballs will be exported as Polygon Meshes, frozen in Render Resolution. Some Renderers might not draw point and line primitives, consult your renderers manual for information on that. Have a look at the LightMan Export Options for different ways of Polygon export. |
|||||||||||||||||
| 2.2. Shaders/Surfaces | top |
||||||||||||||||
|
Currently nearly all surface properties are exported, but procedural and image textures are not supported right now. Nevertheless you can produce complex surface appearances by writing a RenderMan Shader [ 3 ] and assigning it to a Surface using the LightMan Surface Shader. Automatic conversion of LightMan Surfaces to RenderMan Shaders will be adressed in a future release. |
|||||||||||||||||
| 2.3. Lights and Global Illumination | top |
||||||||||||||||
|
|||||||||||||||||
| 2.4. Camera and Rendering settings | top |
||||||||||||||||
|
|||||||||||||||||
| 2.5. Limitations | top |
||||||||||||||||
|
There are a few things LightMan just can't export. These things include:
|
|||||||||||||||||
| 2.6. Odds and Ends | top |
||||||||||||||||
|
This Chapter deals with a few subtle differences in how LightMan deals with certain options in respect to the LightWave Renderer. Enabling/Disabling Raytracing and Global Illumination Most RenderMan Renderers consider Global Illumination to be a Raytracing feature. If Raytracing is explicitly switched off in LightWave's Rendering Panel some Renderers may not do any Global Illumination calculations. |
|||||||||||||||||
| 3. Tutorials | top |
||
|
This section is supposed to contain simple step by step instructions to provide solutions to common complicated situations. If you feel that something is missing here, send your tutorial suggestions to td@td-grafik.de. |
|||
| 3.1. Getting started | top |
||
|
At first load the 'Chessboard.lws' scene that comes with Lightwave. Loaded in Lightwave the scene should look like below. ![]() Lets first do some changes to the Lighting. Change the Light position to X: -500, Y: 300, Z: -275 and bring up the Light Properties panel. Change the Light Type to Spotlight, the Shadow Type to Shadow Map, uncheck Fit Cone and set the Map Angle to 20.0°. If you change the Viewport Type to Light View it should look like the screenshot below. ![]() You'll notice that the Shadow Map with that angle covers a smaller area than the chessboard, but that's perfectly ok, because nothing outside the Shadow Map will actually cast any shadows (there's nothing for the chessboard to cast shadows on). This is a good way to increase rendering efficiency. You could even completely disable shadow casting for the Chessboard object to completely remove it from the Shadow Map generation pass. You might also want to increase the AntiAliasing setting a little (Lightwaves Camera Properties). Now let's start with the export preparations. Bring up the PlugIn Options panel and select the LightMan_RIB_Export Generic PlugIn. On the LightMan Panel select the Renderer you want to use. Refer to the Reference of the Renderer Tab to learn more about this step. ![]() Next bring up the Lights Tab, make sure the depthfilter is set to 'min' (or 'none' if different depth filters are not supported by the renderer), check the 'Shadow Depth Map Bias' checkbox and set the bias to 0.005 like on the screenshot above. Now we are prepared to select the Export Tab, make sure the Export Type (bottom left) is set to 'Render Preview' and hit the 'Do It!' button. The picture below has been rendered with Entropy. ![]() |
|||
| 3.2. Using a RenderMan Shader for Texture Mapping | top |
||
|
In Version 1.0 of LightMan only basic Surface properties get exported, but still you can use a broad range of Surface appearances. RenderMan Renderers always accept Surface Descriptions as a small program in the RenderMan Shading Language. This short tutorial shows how to use one of the standard surfaces coming with every RenderMan renderer can be used to apply surface a color textures. ![]() The screenshot above shows a head model with a color texture applied to add the eyebrows and add some detail to the mouth. If we hit F9 in Lightwave, we get the left of the pictures below, just hitting 'Render Preview' within LightMan will yield the result on the right (rendered with Entropy in this case).
As you can see the model and texture are fine, but the texture is missing. As a preparation step we should make sure, that the name of the UV Texture Channel we use for projection of the texture map is 'st'. As in Lightwave the Names of texture channels in RenderMan are abitrary, but we should stay out of the way of reserved names ('uv' for example is reserved for something else), they shouldn't contain spaces and 'st' is the standard name for texture coordinates in RenderMan, so all the default or example shaders will look for texture coordinates there. ![]() Next we have to change the surface Shader of the exported object. To do that, we apply the 'LightMan Surface Shader' to the Surface of our Head. This will replace the standard RenderMan Shader LightMan uses to approximate the Lightwave Surface by a different shader of your choice. Here our choice is one of the Standard RenderMan Shaders: 'paintedplastic'. The standard RenderMan Shaders are available through the dropdown box next to the 'Shader Name' field (don't forget to switch on replacement first). The Shader Parameters are passed to the Shader, which parameters are available depends solely on the Shader. This Shader Parameter string consists of Token Value Pairs, which means the first string is the name of a parameter, the next thing (usually in brackets) is the value, next comes a parameter name again and so on. The Parameter Line we want to use here is: "Kd" [0.6] "Ks" [0.1] "texturename" ["head_hcol.tex"]![]() Hitting the 'Render Preview' Button now produces the picture below.
That looks better, doesn't it? But what did we actually do?Let's examine the Shader Parameter line: Kd is the standard RenderMan name for the diffuse coefficient of the Surface, Ks stands for the specular component. Texturename is self explanatory, but you have to be careful with the name of the texture file itself. The original texture file used within LightWave was called 'hcol.jpg'. LightMan has to do some preprocessing with the texture which is expected by the RenderMan renderer. First it evaluates all image filters you may have applied and saves the texture as a tiff file with the name of a scene (and an underscore) as prefix, so 'hcol.jpg' is saved to 'head_hcol.tif' if the name of our scene is 'head'. Then LightWave invokes the preprocessor of your Renderer which saves the texture to another file with the same name but the extension '.tex'. This is a little complicated but makes sense. The first step makes sure that image filters are applied to the texture and that it is in a format every RenderMan Renderer can read (tiff is supported by all RendeMan renderers). What the second step does depends on the Renderer, but it usually optimizes the texture for filtering, fast access and memory efficiency. LightMan does this processing automatically for all image files used in the scene, so if you want to use an image file in a RenderMan shader it makes sense to somehow use it in the LightWave Scene so it gets exported properly. You can also do this conversion by hand, how this can be accomplished will be mentioned in the manual of your Renderer. You can find the image files inside the 'textures' directory below the export root if you are not sure about the filename of a certain texture. The same also applies to Shaders. If you use shaders different from the standard RenderMan Shaders you'll have to compile them with your Renderers Shader compiler and make sure the Renderer can find them (either by copying them to the export root or pointing the 'Shader Path' on the Options Panel to the directory the shader is in. The head model used in the tutorial above is courtesy of Ikemefuna Okafor (ikem@mb.rosenet.ne.jp) |
|||
| 4. FAQ | top |
|
Are SubPatches exported to RenderMan as Catmull Clark Subdivision Surfaces?
It would be nice to directly pass SubPatches to the Renderer without dicing to reduce
the amount of data passed to the renderer and to let the renderer decide how fine to
subdivide in order to avoid meshing artifacts. |
|
| 5. Renderer Notes | top |
|
This Chapter contains Odds and Ends you might run into related to certain RenderMan compliant Renderers. Contributions or questions to answer here can be sent to td@td-grafik.de. |
|
| 5.1. Common | top |
|
Eyesplits Users of traditional REYES Renderers like PRMan or RenderDotC might run into a problem with Eyesplits. Usually the Renderer issues a warning about a certain primitive not splitting at the eye plane. REYES renderers split primitives into smaller pieces until they not longer exceed certain criterions (like the number of micropolygons the grid will be diced into, screen space size, maximum number of splits, etc.). If the a grid is created, cannot be culled because it's offscreen but passes through both, the near clipping plane and the plane parallel to the near clipping plane passing through the point of view (the eye plane) the renderer cannot project the primitive to raster space since the math to do this only works for points in front of the camera. Prone to this kind of error are big ground planes and objects moving fast towards or away from the camera (with motion blur enabled). Objects with large Motion Blur or especially near to the camera will increase this problem. Splitting for Primitves whose motion path actually goes through the camera splitting can never succeed. Solutions can be to increase the maximum number of possible splits (you may find an 'eyesplits' Option on the Renderer Specific Options Panel) which is exactly the maximum number of eyesplits. Be careful with increasing this number because it may greatly increase rendering time and memory consumption. For ground planes it is worth to try increasing the detail especially in regions near the camera. Also the near clipping plane should be as far away from the camera as possible, if you are using no clipping, switch to automatic clipping and eventually try to set 'Expand Clipping By' to zero or even a small negative value. Shadow Bias The Lightwave Renderer never let's you set the Shadow Bias. In general the automatic Shadow Biasing Lightwave uses works good, but in some situations you can still get self-shadowing artifacts. Most RenderMan renderers let you set the Shadow Bias explicitly. Usually there is one per light and a global bias value (often called 'minshadowbias') whose interrelation might be different for different renderers. More details are given in the Lights Panel section and in the manual of your Renderer. |
|
| 5.2. BMRT | top |
|
BMRT and Polygons BMRT takes the planarity criterion for Polygons (all vertices of a Polygon have to lie on the same plane in space) much more seriously than the LightWave renderer to speed up rendering. Sometimes you might run into problems with nonplanar Polygons which didn't show up with the Lightwave Renderer. Try to keep all Polygons planar or just dice them into triangles (which are always planar). There are also cases in which BMRT draws Polygons wrong or not at all. This only occurs with Polygon Meshes so LightMan has a setting which puts out Polygon Meshes as individual Polygons (see the 'Raw Individual Polygons' setting of the 'Export Geometry as' button on the Export Tab). This also lifts the planarity restriction for four sided Polygons although at the cost of longer export times and larger .rib Files. |
|
| 6. Troubleshooting | top |
|
LightMan seems not to Export certain Objects in Animations or when Render and Display Dicing Rate for Subdivision Meshes or Metaballs are different. This is a known Problem and there is no clean automatic solution in LightWave 6.5b. The Problem appears when LightWave has to reevaluate Objects before they get exported by LightMan. This happens when Objects change from frame to frame (deformation, motion, etc.) or when SubPatches or Metaballs have to be diced in a different resolution than for display. LightWave only does this evaluation when the Polygon count of the object is below the 'Bounding Box Threshold' and 'Dynamic Update' is set to 'Interactive' (Display Options Panel). A solution is to manually set the Bounding Box Threshold to a very high value (such as 1000000000) and Dynamic Update to 'Interactive' before exporting. |
|
| 7. Further Reading | top |
||||||||||||||||
|
|||||||||||||||||
| 8. License/Disclaimer | top |
|
Copyright © 2001 Timm Dapper. All rights reserved. LightMan is a trademark of Timm Dapper THIS SOFTWARE IS DISTRIBUTED "AS-IS" WITHOUT WARRANTY OF ANY KIND AND WITHOUT ANY GUARANTEE OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. In no event shall Timm Dapper be liable for any indirect or consequential damages or loss of data resulting from use or performance of this software. NO ONE MAY REDISTRIBUTE LightMan or any parts of it. The RenderMan ® Interface Procedures and Protocol are: Copyright 1988, 1989, Pixar All Rights Reserved RenderMan ® is a registered trademark of Pixar |
|