This section informs you about the property GUIs that appear in the Argument-canvas if a single object and a property have been selected in the appropriate listboxes.
All property GUIs use more or less standardized GUI elements, that are organized in list form. The lists may be scrolled if they get too long.
This object is something special in that it cannot be deleted or copied. It holds scene specific preferences, options, atmosphere and image shaders. Finally, all current views are child objects of the scene object.
The first section of the preferences contain two GUI elements that help you to manage shaders.
"Shaders"
contains a number of paths (separated by ":"
on Unix and ";"
on Win32) where The Mops looks for compiled
shaders (files with the extension ".slc"
that have been compiled
with BMRTs slc). Using the "Add"
button, you may add
another path, simply press it and select a file inside the directory
you want to add. Note, that currently the filenames may contain
just two "."
at maximum. "Scan for Shaders!"
initiates a rebuild of the internal
shaders database. All shaders in the directories specified by
the "Shaders"
entry will be scanned and entered in that database.The next section contains GUI (user interface) related settings.
"BorderWidth"
(2) to get the same
borderwidth, as all other GUI elements.
"AutoResize"
toggles, whether the main window
should be resized horizontally according to the property GUI whenever
a new GUI is displayed.Modeling related settings follow.
"PickEpsilon"
is used by the single point editing actions
to determine which point (vertice) of an object has been selected.
A smaller "PickEpsilon"
means more exact picking.
If you set it to 0.0, however, the picking code will always return the nearest
point (vertice) to the picking coordinates."UpdateTrafos"
determines whether The Mops should
update the transformation property after an interactive
modeling action."LazyNotify"
determines whether notification shall
occur on all mouse movements or just on release of the mouse button,
for the interactive modeling actions.
(Notification is the mechanism used to inform objects that rely
on certain child objects (e.g. the Revolve custom
object) about changes of their childs, so that the parent can adapt
to the childs automagically.)
What should be included in the saved scenes?
"SaveViews"
toggles whether The Mops should save
the view information in the scene files. Switching it off
results in slightly smaller scenes, and makes the scenes
compatible with the load a first scene on startup
that contains just 3 standard views approach. The default, however,
is on.What happens if The Mops encounters an Error?
"OnError"
toggles the behaviour of The Mops in an error
condition, the default "Stop"
will break every operation immediately.
But you may toggle it to "Continue"
; now The Mops will try to
go on and finish the operation.The next section deals with RIB-Export specific settings.
"RIBFile"
allows to set the file The Mops is exporting
RenderMan Interface Bytestreams (RIBs) to. Note, that some
filenames have special meaning. If you set "rendrib"
as filename
libribout.a does not create a file at all, but immediately pipes the
resulting ByteStream into rendrib (the BMRT renderer) for rendering.
When you use these options of direct rendering, be warned, that
for the time of the rendering The Mops will be frozen (it will neither
respond to mouseclicks nor will it update any windows), until rendribs
window is closed.
"Ask"
is another special filename, that allows
to select a different filename each time you export a RIB file.
A file selection dialog will pop up, after the selection of the
export view, if the initial filename is "Ask"
.
The same effect may be achieved by leaving the entry totally
empty!
Filenames that start with a pipe symbol "|"
will
cause the program behind the symbol to be started by libribout
and the written RIB to be piped into. This works e.g.
with Photorealistic RenderMan, try it out with "|render"
.
Last but not least, "Scene"
(the default file name) will
cause the RIB file to be named as the currently loaded scene
with the last extension replaced by ".rib"
."Image"
specifies the image file that will be created,
when you render the exported RIB file.
You may set it to "RIB"
, this will create image
files that are named as the exported RIB file (with the last
file extension replaced by ".tiff"
). Again, setting
it to "Ask"
will cause a dialog box to appear,
each time you export to a RIB file.
Note, that in contrast to the "RIBFile"
option leaving the field
totally empty is not equal to entering "Ask"
but generates
RIB files that will be set up to render to the display."ResInstances"
, if this is enabled all instance
objects are resolved before being written to the RIB file."CheckLights"
, if this is enabled The Mops will
check the current scene for lights and if no lights or
no lights that are actually switched on are to be found in
the scene a distant head light will be added to the scene automatically
for RIB export."RIStandard"
determines whether The Mops
should omit all non standard RenderMan interface options and
attributes on RIB export.The next settings determine what happens on direct rendering of a view:
"QRender"
determines the command that should be executed,
upon quick rendering, %s
denotes the name of the RIB file."Render"
determines the command that should be executed,
upon normal rendering, %s
denotes the name of the RIB file.
RenderMan Interface options. Both, standard and BMRT specific options may be set. Please refer to the documentation of the RenderMan Interface and the documentation of BMRT for more detailed information about the options.
"Width"
, "Height"
, if greater than zero this value
will be used for the image-size instead of the corresponding
dimension of the view window, but only for real RIB exports
and not for the QuickRender and Render actions in view windows.
These will always use the dimensions of the view window."Variance"
, maximum allowed variance of two pixel values.
The default 0.0 causes no setting in the RIB. If the variance is > 0.0
no pixel samples setting will be written to the RIB."Samples_X"
, "Samples_Y"
number of samples taken per
pixel."FilterFunc"
, function used to filter final pixel values."FilterWidth"
, "FilterWidth"
size of the filter."ExpGain"
, "ExpGamma"
,"RGBA_ONE"
,"RGBA_MIN"
, "RGBA_MAX"
,"RGBA_Dither"
,"MinSamples"
, "MaxSamples"
, minimum and maximum number
of samples per pixels."MaxRayLevel"
, maximum number of recursive rays."ShadowBias"
, minimum distance that one object has to
be in order to shadow another object."PRManSpec"
, toggles behaviour of BMRT's specular() function
between PRMan compatible (default) and RiStandard compatible."RadSteps"
, number of radiosity steps, the default 0 leads
to no radiosity calculations to be performed."PatchSamples"
, minimum number of samples per patch to
calculate the radiosity form factors for this patch.
Every 3D-View is a child object of the Scene object. You can change camera settings, the type of the view and other things related to the view using it's properties. Note, that deleting the object that represents a view, will not close the view window. You will just lose a way to configure it. Please, do not mess with the objects in other ways (e.g. copy them), you are asking for trouble otherwise!
"From"
is the point from which the camera (that is attached
to the view) is looking from."To"
is the point the camera is looking to."Roll"
defines an angle by which the camera is rotated
around the axis that is defined by the points from and to."Zoom"
is a zoomfactor.Note, that while it is possible with the interactive rotate view actions to create views with an up-vector pointing down, this is not possible with this property.
Whenever you apply this property the up-vector will be reset
to the up-vector that is normally used; depending on the
type of the view this is <0,1,0>
(Front, Side,
Perspective, Trim) or <0,0,-1>
(Top).
The view is associated with a virtual camera. The type of the view determines the Up-vector of that camera. If the type is "Top" the Up-vector corresponds to the world Z-axis, else the world Y-axis. The type of the view additionally determines the so called input-plane of the view. Interactive actions in a view are limited to that input-plane. The input planes are as following: Front - XY-plane, Side - ZY-plane, Top - XZ-plane, Trim - XY-plane. In perspective views, no interactive actions are possible. You may just position the camera and draw or render.
Views of type trim are very special. They are used to edit trimcurves of NURBPatch objects only. They display that trimcurves as normal NURBCurves when the current level is inside a NURBPatch. The extensions of the patch in parameter-space are drawn as a rectangle. The trimcurves should completely lie inside this rectangle.
Finally, here are all elements of the ViewAttrib property:
"Type"
specifies the type of the view. Front, Side, Top (all
parallel), Perspective and Trim may be selected. Note, that changing the
type alone does not move the camera. Consider the following example:
when switching from a default Front view to a Side view using the
view property, the From and To parameters of the camera
will not change, it still looks from 0,0,10 to 0,0,0.
Since Front and Side view have the same Up vector no (visible) change
will be made to the view. It is better to use the menu
of the view window (perhaps even better the shortcuts
to this menu) to switch view types!"Width"
and "Height"
control the size of the view
window."Grid"
is the grid size, 0.0 means no grid is in use."DrawWire"
toggles drawing of wireframes (wireframes is a
synonym for a low quality representation in this context)."DrawSurf"
toggles drawing of curves and surfaces (surfaces
is a synonym for a high quality representation in this context)."DrawGrid"
toggles drawing of the current grid."DrawSel"
toggles drawing of selected objects. If this is
enabled, only the current selected objects will be drawn."Lighting"
toggles lighting.
Note that the lighting is in no way an exact (or even similar)
representation of the light information you specified with Light objects!
Instead, a single light source, located at the camera origin
(a headlight), will be used!"Redraw"
toggles automatic redrawing of the view.
If this is disabled no drawing takes place in the view until an
explicit redraw is requested (using the view menu, or the shortcut
<Ctrl+d>
).
Most Mops objects have standard properties, they are used to control transformations and attributes of objects and to attach shaders to objects.
Use this property to edit the location, orientation and size of an object.
"Translation_X (_Y, _Z)"
is the displacement of the
object from the world origin in X (Y, Z) direction.
"Rotation_X (_Y, _Z)"
is the angle (in degrees)
of the rotation of the object around the X (Y, Z) axis.
Read the next section for more information on how to use these
entries. Read it!
"Scale_X (_Y, _Z)"
determines a scale factor that will be
applied to the object in the direction of the local X (Y, Z) axis.
"Quat0 (1, 2, 3)"
the quaternion that is used to determine
the orientation of the object in space. This quaternion is not here
to be edited directly! The sole purpose of its appearance here
is to allow copying and pasting of rotations.Tcl commands to get and set the transformation property are:
"getTransfProp"
"transfPropData"
."setTransfProp"
"transfPropData"
.Note, that because of the two different methods of orientation
specification that are contained in "transfPropData"
(Rotate_X,Y,Z vs. Quaternion) you need to decide
whether you want to simply set a new orientation using
"setTransfProp"
or whether you rather want to mimic the
behaviour of the Transformation property GUI. Use the following
construct to overwrite the orientation using "setTransfProp"
:
global prefs set prefs(pasteProp) 1 setTransfProp set prefs(pasteProp) 0
"setTransfProp"
without precautions
will do the same as if the "Apply"
button
in the Transformation property GUI had been used.
The orientation of an object in space may be expressed using so called Euler angles. This notation (simply three angles determining a rotation about the axes of the coordinate system) suffers from a phenomenon called gimbal lock.
To avoid gimbal locks, The Mops internally holds the orientation of an object in a quaternion.
This quaternion not only holds information about the angles but also about the order in which partial rotations occured.
It is important to know, that the values of the angles of the rotation property must not be read in a way that the object will first be rotated around X by x-angle degrees then around Y y-angle degrees then around Z z-angle degrees. In fact, no information about the order in which partial rotations occured may be determined from that three values. This implies, that e.g. the values 0 0 45 may denote a different orientation than the very same values 0 0 45 (no joke)!
But how do you get the three entries to do what you want? You either want to rotate the object around an axis by a given amount or you want to undo a rotation or undo all rotations.
Rotating an object is easy, simply add the amount about which you want to rotate the object to the value currently displayed in the appropriate entry. If you want to rotate about 45 degrees about X and the x-angle entry displays a 30, enter 75. Then press the apply button. If you change multiple entries the rotations made will be in the order X (if changed) then Y (if changed) then Z (if changed). I urge you to not change more than one entry at once until you exactly know what you are doing.
Undoing a rotation made e.g. with the rotate action is simple, but requires you to know which value was displayed in the entry corresponding to the axis of the rotation before the rotation occured. Simply enter the old value after an unsuccessful rotation, then press apply. Since the action does not change the value displayed in the entry while rotating, you may just open the transformation property of that object, and if the rotation failed, simply press apply.
If you want to undo multiple rotations you have to undo them in single steps in exactly the reverse order in which you made them. Lets say, you rotated around X 45, then around Y 90 then around X another 45 degrees. You will not get back to your original orientation if you rotate back around X 90, then around Y 90 degrees. You have to rotate back around X 45, then around Y 90 then around X another 45 degrees! This example unfortunately works, if you start from 0 0 0, in this special case the last rotation back (to 0 0 0) undoes all rotations anyway (see below), but try it once starting from 30 0 0.
Undoing all rotations (resetting the object to its original state) is simple too: enter 0 for all three entries at once, then press apply.
Both, standard and BMRT specific attributes may be set. Please refer to the documentation of the RenderMan interface and the documentation of BMRT for more detailed information about the attributes.
"Color"
, the color of the object. If you set one of the
entries to a negative value (e.g. -1), the color will not be set at all
for this object."Opacity"
, the opacity of the object, the default
255 255 255 means total opaque. If you set one of the
entries to a negative value (e.g. -1), the opacity will not be set at all
for this object."ShadingRate"
,"Interpolation"
,"TrueDisp"
, toggles true displacements on or off. Default off."BoundCoord"
, sets the coordinatesystem in which the
displacement bound is expressed."Bound"
, displacement bound."CastShadows"
, determines how the object casts shadows:
the default "Os"
means the object casts shadows according to it's
opacity; "None"
object does not cast any shadows; "Opaque"
the object is completely opaque and casts shadows; "Shade"
the object has a complex opacity pattern determined by it's surface
shader, that is used in shadow calculations."AverageColor"
, average color of surface, to be used if your
surface shader sets a completely different color as specified by the
color attribute."EmissionColor"
, color and amount of emitted light."SpecularColor"
, to be used, if this object is a specular
reflector that generates the well known caustic effects. Note,
that additionally you need to add a lightsource with a shader
named "bouncer"
to your scene to obtain caustics."PatchSize"
, "ElemSize"
, "MinSize"
determine
how fine the radiosity mesh should be calculated for this primitive."Zonal"
determines the radiosity calculation performed
on this primitive.Tcl commands to get and set the attributes property are:
"getAttrProp"
"attrPropData"
."setAttrProp"
"attrPropData"
.
Use this property to edit the tags of an object.
Tags are an easy way to attach arbitrary information to objects. A tag consists of two strings, one defining the type and one defining the value of the tag.
The Tags property GUI is a simple text widget where you may enter the two aforementioned strings separated by a space, one tag per line. Note, that each line must contain exactly one space to separate name and value. Multiple spaces e.g. in the value string (even if surrounded by quotes) are illegal.
Tags may also be set or get using the commands setTags
and
getTags
respectively.
"setTags [type value]"
"getTags varname1 varname2"
The next sub-sections describe the available tag types.
The tag type "RiAttrib"
can be used to attach
arbitrary RenderMan interface attributes to objects.
In order to create a tag of type RiAttrib the type string must be
"RiAttrib"
. The syntax of the value string is as following:
attrname,paramname,paramtype,param
where attrname is the name of the attribute (e.g. "render") paramname
is the name of the parameter (e.g. "displacementbound") paramtype is a
single character defining the type of the parameter (it may be one of
f
- float,i
- integer, s
- string,
c
- color, p
- point) and finally
param is the value of the parameter itself (a float: "1", a string: "on",
a color: "1,1,1" or a point: "0.4,0.5,1.0").
Examples:
RiAttrib render,truedisplacement,i,1
RiAttrib radiosity,specularcolor,c,0.5,0.5,0.5
Note:
The RiAttrib tag handles just a single parameter at once.
This tag is used by the RIB exporter and the scene storage facility to establish links between instance objects and the original objects they are pointing to.
The tag type OI
is not meant to be used by the end user.
Furthermore, changing the IDs avails to nothing as the
tags are rebuilt before every export/save operation.
Shader properties are used to attach a shader of a certain type to an object.
Each shader property, even if no shader is attached to an object,
starts with the "Set new shader."
button. This button allows
to select a new shader of the appropriate type.
Below this button is the "Delete shader."
button which,
consequently, deletes the current shader from the selected object.
After a new shader has been set, the arguments of the shader will be parsed and a GUI will be generated to allow the arguments of the shader to be filled with values.
Tcl commands to set and get shader properties are:
"getSProp shadertype arrayname [subtype]"
"parray arrayname"
to see how the array is organized."setSProp shadertype arrayname [subtype]"
"Name"
in this array is ""
then the shader of type shadertype will be deleted from the
object instead. If shadertype is volume then a subtype must be
specified.
A solid box, centered at the origin of the object coordinate system. This object will always be exported as solid primitive in RIBs; consisting of six polygons.
"Width"
is the width of the box (size of the box in
direction of the X axis of the objects coordinate system)."Length"
is the length of the box (size of the box in
direction of the Z axis of the objects coordinate system)."Height"
is the height of the box (size of the box in
direction of the Y axis of the objects coordinate system).Tcl commands to get and set the BoxAttrib property are:
"getBoxAttr"
"BoxAttrData"
."setBoxAttr"
"BoxAttrData"
.
A sphere, centered at the origin of the object coordinate system.
This object will be exported as solid primitive or as
simple sphere (depending on the "Closed"
parameter
of the SphereAttrib property) in RIBs.
Note, that the OpenGL representation of this object
does not reflect the settings of the following parameters
of the SphereAttrib property: "Closed"
, "ZMin"
, "ZMax"
and
"ThetaMax"
.
"Closed"
toggles whether the object should
be automatically sealed (closed) when exported to RIB.
Note, that if this option is in use and "ZMin"
, "ZMax"
or
"ThetaMax"
have other than the default values,
a single sphere will be written (in the worst case) as a
CSG hierarchy of two spheres, two cylinders and eight disks!
But it may be used in CSG operations, safely."Radius"
is the radius of the sphere, default is 1."ZMin"
may be used to chop the sphere off at a certain
place at Z."ZMax"
may be used to chop the off at a certain
place at Z."ThetaMax"
is the sweeping angle of the sphere default is 360.Tcl commands to get and set the object type specific attribute property of any quadric (sphere, disk, cone, cylinder, hyperboloid, paraboloid, torus) are:
"getQAttr type"
"QAttrData"
. Type may be one of "sphere"
, "disk"
,
"cone"
, "cylinder"
, "paraboloid"
, "hyperboloid"
and
"torus"
."setQAttr type"
"QAttrData"
.
Type may be one of "sphere"
, "disk"
,
"cone"
, "cylinder"
, "paraboloid"
, "hyperboloid"
and
"torus"
.
A disk, centered at the origin of the object coordinate system.
This object will always be exported as simple disk in RIBs.
Note, that the OpenGL representation of this object
does not reflect the setting of the following parameter
of the RiDiskAttr property: "ThetaMax"
.
"Radius"
is the radius of the disk, default is 1."ZMin"
displaces the disk along the Z axis, default is 0."ThetaMax"
is the sweeping angle of the disk, default is 360.For information on how to set or get this property with the Tcl scripting interface see section RiSphereAttr.
A cone, centered at the origin of the object coordinate system,
with the base at the XY plane.
This object will be exported as solid primitive or as
simple cone (depending on the "Closed"
parameter
of the ConeAttrib property) in RIBs.
Note, that the OpenGL representation of this object
does not reflect the settings of the following parameters
of the RiConeAttr property: "Closed"
and
"ThetaMax"
.
"Closed"
toggles whether the object should
be automatically sealed (closed) when exported to RIB.
Note, that if this option is in use and
"ThetaMax"
has a different than the default value,
a single cone will be written (in the worst case) as a
CSG hierarchy of a cone, a disk and two polygons!
But it may be used in CSG operations, safely."Radius"
is the radius of the cone at the base, default is 1."Height"
is the height of the cone, default is 1."ThetaMax"
is the sweeping angle of the cone, default is 360.For information on how to set or get this property with the Tcl scripting interface see section RiSphereAttr.
A cylinder, centered at the origin of the object coordinate system.
This object will be exported as solid primitive or as
simple cylinder (depending on the "Closed"
parameter
of the RiCylinderAttr property) in RIBs.
Note, that the OpenGL representation of this object
does not reflect the settings of the following parameters
of the CylinderAttrib property: "Closed"
and
"ThetaMax"
.
"Closed"
toggles whether the object should
be automatically sealed (closed) when exported to RIB.
Note, that if this option is in use and
"ThetaMax"
has a different than the default value,
a single cylinder will be written (in the worst case) as a
CSG hierarchy of a cylinder, two disks and two polygons!
But it may be used in CSG operations, safely."Radius"
is the radius of the cylinder, default is 1."ZMin"
determines the Z location of the base, default is -1."ZMax"
determines the Z location of the top, default is 1."ThetaMax"
is the sweeping angle of the cylinder, default is 360.For information on how to set or get this property with the Tcl scripting interface see section RiSphereAttr.
A torus, centered at the origin of the object coordinate system.
A torus is a donut like shape, that results from sweeping
a small circle ( that has been displaced along X sufficiently )
around the Z axis.
This object will be exported as solid primitive or as
simple torus (depending on the "Closed"
parameter
of the RiTorusAttr property) in RIBs.
Note, that the OpenGL representation of this object
does not reflect the settings of the following parameters
of the RiTorusAttr property: "Closed"
, "PhiMin"
,
"PhiMax"
and "ThetaMax"
. Tori have no shaded (surface)
representation in the modeler, currently.
"Closed"
toggles whether the object should
be automatically sealed (closed) when exported to RIB.
Note, that if this option is in use and
"PhiMin"
, "PhiMax"
or "ThetaMax"
have different than the
default values,
a single torus will be written (in the worst case) as a
CSG hierarchy of a torus, two disks and two hyperboloids!
But it may be used in CSG operations, safely."MajorRad"
is the radius of the torus, measured
from the Z axis to the center of the swept smaller circle, default is 0.75."MinorRad"
is the radius of the swept circle, default is 0.25."PhiMin"
determines an angle to limit the swept circle,
default is -180."PhiMax"
determines an angle to limit the swept circle,
default is 180."ThetaMax"
is the sweeping angle of the torus, default is 360.For information on how to set or get this property with the Tcl scripting interface see section RiSphereAttr.
A paraboloid, centered at the origin of the object coordinate system.
This object will be exported as solid primitive or as
simple paraboloid (depending on the "Closed"
parameter
of the RiParaboloidAttr property) in RIBs.
Note, that the OpenGL representation of this object
does not reflect the settings of the following parameters
of the RiParabAttrib property: "Closed"
and
"ThetaMax"
.
Paraboloids have no shaded (surface) representation in the modeler, currently.
"Closed"
toggles whether the object should
be automatically sealed (closed) when exported to RIB.
Note, that if this option is in use and
"ZMin"
, "ZMax"
or "ThetaMax"
have different
than the default values,
a single paraboloid will be written (in the worst case) as a
CSG hierarchy of a paraboloid, two disks and two bicubic patches!
But it may be used in CSG operations, safely."RMax"
is the radius of the paraboloid at a Z of "ZMax"
,
default is 1."ZMin"
determines the Z location of the base, default is -1."ZMax"
determines the Z location of the top, default is 1."ThetaMax"
is the sweeping angle of the paraboloid, default is 360.For information on how to set or get this property with the Tcl scripting interface see section RiSphereAttr.
A hyperboloid, centered at the origin of the object coordinate system.
This shape will be created by sweeping a line specified by two
points in space around the Z axis.
This object will be exported as solid primitive or as
simple hyperboloid (depending on the "Closed"
parameter
of the RiHyperbAttr property) in RIBs.
Note, that the OpenGL representation of this object
does not reflect the settings of the following parameters
of the RiHyperbAttrib property: "Closed"
and
"ThetaMax"
. Hyperboloids have no shaded (surface) representation
in the modeler, currently.
"Closed"
toggles whether the object should
be automatically sealed (closed) when exported to RIB.
Note, that due to a bug in BMRT that is still present in V2.3.6
this option does not work properly when
"ThetaMax"
has a different than the default value and the
hyperboloid has no displacement shader. In fact, using a displacement
shader with a km (amount of displacement) of 0.0 is a work-around
for this bug (found by T. E. Burge).
Also note, that if this option is in use and
"ThetaMax"
has a different than the default value,
a single hyperboloid will be written (in the worst case) as a
CSG hierarchy of a hyperboloid, two disks and two bilinear patches!"P1_X"
, "P1_Y"
and "P1_Z"
, define point one,
default is (0, 1, -0.5)."P2_X"
, "P2_Y"
and "P2_Z"
, define point two,
default is (1, 0, 0.5)."ThetaMax"
is the sweeping angle of the hyperboloid, default is 360.For information on how to set or get this property with the Tcl scripting interface see section RiSphereAttr.
Objects of type Union
, Intersection
, Difference
,
Primitive
, Level
and TrimLoop
are
used to build object hierarchies and perform CSG
operations.
Note, that child objects of a level inherit the levels transformations
attributes and shaders, except for TrimLoop
levels.
If you have a NURB patch in a level that is translated to 10,0,0,
the origin of the local coordinate system of the NURB patch
will be situated at 10,0,0. If you decide to move the patch by a value
of 5 in X direction, you will finally arrive at 15,0,0.
Levels do not have object type specific properties, just standard properties (See section Standard Properties). It is not possible to change the type of a level.
New solid primitives may be created with levels of type Primitive
.
Note, that The Mops is not able to check whether your new primitive obeys
the rule of total closeness.
TrimLoop
levels should only be used inside NURB patches. They
mark a set of NURB curves (all child objects of the TrimLoop
level)
to be a trim loop. See section
Trim Curves
for a more in depth discussion of trim curves.
Note, that the transformation and other attribute settings
of a TrimLoop
are not inherited by it's childs.
The behaviour of a light source object depends heavily on it's type. There are four different types available: custom, point, distant and spot.
Light sources of type custom are the only types of light object a light shader may be attached to.
Note, that The Mops is trying to guess from the names of the light shader
arguments to draw the light.
The names "from"
and "to"
denote location and
destination of the lightsource. You should not use these names for other
things in your light shaders!
These (standard) light sources have well defined parameters that will be displayed in the "LightAttribute" property.
However, their from and to values are fixed to from: (0,0,0) and to: (0,0,-10). These may not be changed. The only way to position these lights is through the Transformations property. To change the distance of the light from it's origin use the Scal_Z action/property.
Depending on the type of the light source, the LightAttribute property contains different parameters. Parameters that are not displayed will not be used on RIB export, however.
"IsOn"
allows you to switch the light off or on. The default
value is on.
With the light attribute "Shadows"
you may determine
whether the lightsource should cast shadows. The default is off, no shadows!
The attribute "Samples"
determines the number of times to sample
an area light source, independent of pixel samples, the default value is 1.
This attribute is available for custom lights only!
All other parameters that may appear are the standard parameters for the standard RenderMan lightsources distantlight, pointlight and spotlight. Please refer to the RenderMan documentation if you are not sure what they mean.
Tcl commands to get and set the LightAttrib property are:
"getLAttrProp"
"lattrPropData"
."setLAttrProp"
"lattrPropData"
.
The common light sources itself have no geometry, this means shadows resulting from it have sharp borders. Soft shadows may be generated using AreaLights.
How do you create AreaLights?
You simply have to create a single object as child object of a
custom light object that has the "arealight"
shader attached, this child object determines the geometry of
the lightsource. Objects that work best as childs are Disks and
simple (e.g. 2x2) NURB patches.
An example:
NURB curves are used to build more complex smoothly shaped objects using operations like extrude, revolve or sweep. They can be closed and used to emulate Bezier and B-Spline curves easily.
NURB curves support so called multiple points. These are control points that have the same coordinates. Those points will be drawn with a bigger handle, than normal points. See sections The Collapse Tool and The Explode Tool for more information regarding multiple points.
The first section of the NCurveAttrib property contains curve specific settings:
"Length"
is the number of controlpoints of the curve."Order"
is the order of the curve."Knot-Type"
: Using "Knot-Type"
you may select from
NURB, Bezier, B-Spline and Custom knot sequences.
If the knot type is not Custom, the next setting
"Knots"
will be ignored. Instead, knots of type NURB, Bezier or
B-Spline will be generated.
How do the different knot types affect the curve?
The knot type NURB will generate knot values from 0.0 to 1.0, where
the multiplicity of the knots at the ends will be of order of the curve.
This guarantees that the curve will touch the controlpoints at the ends
of the curve.
The knot type Bezier will generate just 0.0 and 1.0 values. Note, that
the order of the curve has to be equal to the length of the curve, if
Bezier knots are generated. Otherwise, the generated knot sequence is
illegal. The resulting curve looks and behaves exactly like a real
Bezier curve, interpolating it's ends and so on.
The knot type B-Spline will generate values
without any multiple knots. The resulting curve looks
and behaves like a B-Spline curve."Knots"
lets you enter your own custom knot sequences.
Note, that "Knots"
are not in use if "Knot-Type"
is of type
NURB, B-Spline or Bezier!"Has-Weights"
determines whether weights should be used.
Note, that switching weights off will destroy the current weight information."Closed"
toggles the closeness of the curve.
If this is enabled, the last p controlpoints of the curve will be
made identical to the first p (where p is the degree of the curve,
read order-1). All those points will be multiple points and
single point editing actions will edit both points from now on.Note, that for a cubic spline (order 4) you will need atleast 6 controlpoints to close it. It is important to know, that the multiple points alone can not guarantee that the curve is closed if the knot type of the curve is Custom, if you really want a closed curve switch to type B-Spline.
Also note, that a NURB circle as created by the NURBCircle tool is not a closed curve following this definition, it is nevertheless a closed curve.
"Handlesize"
is the size of the handles."W-Handles"
determines whether the weight information of a vertice should be used
to draw a handle of the appropriate size."Tolerance"
is in fact GLU sampling tolerance, used to
control the quality of the sampling when rendering a curve.
Smaller tolerance settings lead to higher quality.When changing more than one of the above values the changes will be applied in the order of the values in the property. The sum of the changed values should describe a valid NURB curve. It is perfectly legal to change the length of the curve, it's order, switch to a custom knot vector (be sure to actually enter a valid new knot vector) and switch off weights at once. The Mops will check your changes and fall back to certain default values if e.g. your knot sequence is wrong. Check the console for any messages!
Tcl commands to get and set the NCurveAttrib property are:
"getNCAttrProp"
"ncattrPropData"
."setNCAttrProp"
"ncattrPropData"
.
The first section of the NPatchAttrib property contains patch specific settings:
"Width"
and "Height"
control the dimensions of the patch."Order_U"
and "Order_V"
set the orders of the patch."Knot-Type"
and "Knots"
: For a discussion of the
"Knot-Type"
and "Knots"
parameters,
please see section
NCurveAttrib.
"Has-Weights"
determines whether weights should be used.
Note, that switching weights off will destroy the current weight information."Handlesize"
is the size of the handles."W-Handles"
determines whether the weight information of a
vertice should be used to draw a handle of the appropriate size."Tolerance"
is in fact GLU sampling tolerance, used to
control the quality of the sampling when rendering the patch. "Display"
sets the display mode, either the full patch
is drawn as a surface (Fill) or just the outlines of the
polygons created by the tesselation (OutlinePoly), or just the
outlines of the patch (OutlinePatch).Tcl commands to get and set the NPatchAttrib property are:
"getNPAttrProp"
"npattrPropData"
."setNPAttrProp"
"npattrPropData"
.
Trim curves may be used to cut out certain parts of a NURB patch. They are simple NURB curves, but some special restrictions apply.
How do you define a trim curve?
Create a NURB patch. Enter it by double clicking in the
hierarchy listbox. Now you may create a NURB curve, that
will then be a trim curve. You wonder why the curve is not
displayed in any of your modeling views? Well, thats simple,
a trim curve is always defined in the parameter space (u,v) of the
NURB patch. But the normal modeling views display the (x,y,z) space.
Switch one of your modeling views to type Trim.
A rectangle (representing the parameter space of the NURB patch)
and your trim curve should be displayed.
Note, that views of type Trim will display nothing unless
you are inside a NURB patch (with the current level in the
hierarchy listbox, that is).
You may now model the trim curve just as you do it with a normal
NURB curve in a normal view.
Note, that the direction of the trim curve determines which part of
the NURB patch should be cut out. You can use the Revert
tool
(Tools/NURBCurve
menu) to easily change the direction
of a trim curve.
What are the restrictions, that have been mentioned earlier?
TrimLoop
. The order of the curves
in this level is the order of the loop.TrimRect
tool. You can find this tool in the Tools/Create
menu. This curve is needed if you want to cut out a hole with
a single trim curve. This curve is generally not needed if you want
to render the patch with BMRT but it should not hurt if it is present.Warning, certain OpenGL implementations may be easily crashed with trimmed NURB patches with curves that do not follow the aforementioned rules! When in doubt or while heavy modeling, switch off drawing of curves and surfaces temporarily and you will be on the safe side.
Also note, that MesaGLU is currently not able to draw trimmed NURB patches. If you need this, you should use a better or real OpenGL.
The term instance is unfortunately misleading (and can be very confusing if you are accustomed to the terminology of object oriented programming), but it is the term that seems to be used and understood by most computer graphic artists. A better term would be link, as an instance object has the same basic properties as a link in a Unix file system. A link is just a pointer to an original file, the same goes for an instance object: it is just a pointer to an original object. A link can be placed anywhere on the file system, an instance object can be placed anywhere in the hierarchy, and additionally, it can be transformed (otherwise it would be pretty useless).
The sole purpose of instance objects is to save storage. The amount of saved diskspace can be very high, but this depends heavily on the scene. If there are no similar objects in the scene you can hardly use instancing. Similar means "the same except for the transformation property" in this context.
Some simple rules for instancing:
If you cannot delete/cut an object, and the error message tells you something about a reference counter, then you were about to violate the second rule.
You can resolve an instance object at any time using
the converter registered for objects of type Instance
(simply
select the instance object and use the menu entry
"Tools/Convert"
).
The RIB export of instances does not use the RiInstance facility
of the RenderMan interface, but the ReadArchive mechanism.
This means, every original object in the scene will be written
in a separate archive (RIB file) on disk, and every instance will
cause that archive file to be read. You can change that behaviour
using the preference setting "ResInstances"
.
If "ResInstances"
is enabled, all instances will be resolved
before being exported to RIB.
What is a custom object?
Think of it as a plugin that extends The Mops's capabilities by
defining totally new types of objects.
A simple example is the CSphere custom object, which implements
a sphere and has a new property named "CSphereAttr"
.
This property contains all parameters of a simple RenderMan Interface
quadric sphere.
Since a custom object has total control over properties and representations, you should refer to the documentation of the custom object for more information regarding it's properties.
The following sections describe some built in custom objects.
The revolve custom object forms a surface of revolution from a NURB curve.
The object has the generating NURB curve as child object and watches its movements and adapts to it automagically.
The axis of revolution is always the Y axis of the coordinate system that is defined by the next higher level in the object hierarchy (the Y axis of the revolve object itself). The generating curve should lie in the XY plane of this coordinate system. If not, it will be squashed down to this plane!
The following simple experiment should make the last statements more clear, during all steps watch the movements of the revolution:
Tools/NURBCurve/Revolve
).Using the command "revolveCNP"
(revolveConvert to NURB Patch)
you may export the current surface of revolution and the caps,
if there are any, to ordinary NURB patches.
Using the parameter "ThetaMax"
you can specify the
sweeping angle of the revolution just like with an ordinary
RenderMan quadric. If you use a different angle than 360.0,
be warned, that the caps will not be created correctly
anymore (the resulting object will never be fully closed!).
The revolve object can automatically generate caps,
which are trimmed NURB patches. Using "HasUpperCap"
and
"HasLowerCap"
you determine whether such caps should be
generated, default is off (no caps).
See section NPatchAttrib for a description of the other two attributes.
The extrude custom object forms an extrusion from a number of NURB curves.
The first curve determines the outline, and the other curves determine holes in the extrusion object. Holes may be used by objects that form e.g. letters.
The object has the generating NURB curves as child objects and watches them and adapts to them automagically.
The extrude object can generate caps, if the generating curves are closed. Cap generation may fail, if the outer curve has weights and the curve itself leaves the convex hull of the control polygon. Be careful when using curves with weights!
The sharp corners between caps and extrusion may be beveled.
The axis of the extrusion is always the Z axis of the coordinate system that is defined by the next higher level in the object hierarchy (the Z axis of the extrude object itself). The generating curves should lie in the XY plane of this coordinate system. If not, they will be squashed down to this plane!
Using the command "extrudeCNP"
(extrudeConvert to NURB Patch)
you may export the current surface of extrusion and the caps and bevels,
if there are any, to ordinary NURB patches.
Using the parameter "Height"
you determine how
big in Z direction the extrusion should be. Note, that
the height of the bevels will not be taken into account here,
if you have an extrusion with height 1.0 and you switch on
beveling (upper and lower) with radius 0.1 you end up
with an object that is 1.2 whatever big in Z direction.
The extrude object can automatically generate caps,
that are trimmed NURB patches. Using "HasUpperCap"
and
"HasLowerCap"
you determine whether such caps should be
generated, default is off (no caps). Note, that this feature
does only work properly, if the generating NURB curves are closed
and not self intersecting, this is because the generating curves themself
are used as trim curves for the caps. Warning, The Mops will not check whether
your curves conform to this criteria. The Mops, however,
detects the correct orientation of the curves
(and reverts them if necessary).
Using "LowerBevel"
and "UpperBevel"
you determine
whether bevels should be created to round the otherwise sharp
corners of the extrusion with the cap. The bevels may be
controlled using "BevelType"
and "BevelRadius"
.
"BevelType"
allows to choose from "Round"
(a complete round bevel,
built using a quarter circle), "Linear"
(not round at all,
but just a connecting linear patch) and "Ridge"
which forms a more complex beveling similar to some frames for
(real world) images.
The "BevelRadius"
determines the size of the bevels. It is
expressed in untransformed object coordinates of the generating curve,
but the resulting radius of the bevel may differ a bit (depending
on the shape of the curve).
See section NPatchAttrib for a description of the other two attributes.
All curves forming holes in the extruded object must be defined inside (geometrically) the first curve (the outline curve). Additionally, they may not intersect each other or themself and you cannot have hole curves inside hole curves. The Mops will not check whether your curves conform to these criteria!
With the direction of the curve you decide the direction of the bevel as well (should it round outwards or inwards?). If the bevels of the holes look wrong try to revert the generating curves of the holes. Note, that beveling does not work well with open curves. You should always use closed curves for beveling!
The sweep custom object forms a surface that results from moving a NURB curve (cross section) along a second NURB curve (trajectory).
The object has the generating NURB curves as child objects and watches their movements and adapts to them automagically. The first curve is the cross section and the second is the trajectory.
Note, that the "Translate"
attributes of the cross section curve
will be fully ignored. All other transformation attributes
(of cross section and trajectory!) will be used to determine
place, orientation and size of the sweep object!
Using the command "sweepCNP"
(sweepConvert to NURB Patch)
you may export the current sweep to an ordinary NURB patch.
If "Interpolation"
is enabled, all section curves
will be interpolated by the swept surface.
The second parameter "Sections"
determines how many
sections (in u direction) should be used, when generating the
sweep NURB patch. The NURB patch always has sections+1 control
points in u direction.
If "Rotate"
is enabled, the cross sections will be
rotated so that they are always perpendicular to the trajectory,
this is the default.
See section NPatchAttrib for a description of the other two attributes.
The skin custom object forms a surface that results from lying a surface through a set of curves, where the first and last curve will be interpolated by the surface.
Note, that the curves may be of arbitrary length and order. If the curves are of different length or order, they will all be converted internally until they match. Be warned, that this process may consume a considerable amount of time (for the ones of you who know NURBS better: all unclamped curves have to be converted to clamped ones; then, for every curve with low order degree elevation has to be done; then a uniform knot vector has to be found; then all curves have to be refined using this new knot vector; interpolation adds another dimension of complexity...). If you experience lags when editing the child curves of a Skin try to switch to lazy notification.
Also note, that the resulting patch may be quite big even though the curves are not if their orders do not match. A skinned patch from two curves of length 4 but one with order 4 and the other with order 2 will result in a patch with a width of 2 and a height of 10!
The skin custom object has the generating NURB curves as child objects and watches their movements and adapts to them automagically.
Using the command "skinCNP"
(skin Convert to NURB Patch)
you may export the currently selected skin to an ordinary NURB patch.
The first parameter "Interpolation"
controls,
whether the inner curves should be interpolated by the
skinning surface.
The second parameter "Order_U"
determines the order
of the resulting surface in u direction (the order in v direction is
determined by the curves). The order may not be lower than the
number of curves used. If the specified value is lower than the number
of curves the order of the generated surface will be silently
set to the number of curves.
Using the next parameter "Knot-Type_U"
, you can adapt the
type of the knot vector that should be used in the u direction of the
skin. Note, that this setting will have no effect if interpolation
is switched on because then a chord length parameterisation
will be used. If the knot type is Bezier and the specified
order does not match the number of skinned curves, then the order
will be silently adapted to the number of skinned curves.
See section NPatchAttrib for a description of the other two attributes.
The ICurve custom object creates an interpolating spline which is either a C2 cubic with n+2 control points or a curve with n points with arbitrary order from a set of control points.
The global interpolation generates a bit smoother curves which look best with an order of 3, your mileage may vary however.
In both interpolation modes chord length parameterization will be used to determine the knot vector of the interpolating curve.
This object is the first to make use of the new provide mechanism for custom objects. It marks itself as providing a NURBCurve (it creates and uses NURB curves internally anyway) and all other objects that work with the provide mechanism (revolve, sweep, extrude) are able to work with an ICurve object instead of an object of type NURBCurve.
"Length"
you determine the number of points to interpolate.
"Closed"
.
"Mode"
determines whether the curve should
be a C2 cubic curve (with n+2 control points (n+3 if the curve is
closed)) or a so called global interpolating curve
(with n control points (n+3 if the curve is closed)
and arbitrary order).
"Order"
is used only if the mode is
Global4D. It determines the order of the interpolating curve. If the
specified order is bigger than the number of control points used
by the interpolating curve, then the order is silently changed to
match the number of control points.
"IParam"
is used to control the position
of the second and last-1 controlpoint of the interpolating curve.
It scales the vectors used to position the aforementioned points.
You can try to change (decrease) this value, if you are not satisfied
with the shape of the curve near the first or last interpolated point.
This parameter has no effect on open curves when the mode is Global4D.
"Tolerance"
.
The shell custom object that is distributed with The Mops is just a demo version. Please, keep this in mind. The objects functionality has been crippled a bit, read, it will not appear in any RIBs and the export to NURB patch feature has been disabled too.
The documentation given here is not complete in terms of ShellyLib parameters, please refer to the original ShellyLib documentation.
The Shell object always exports as NURB patch.
Note, that the shell object searches all shaders
for parameters named "mys"
and puts
additional texture coordinate information
into RIBs if it finds such a parameter.
The "mys"
parameter is used (as varying float with per vertex
information) in the SLtxtmyssrf shader from ShellyLib
to map textures on shells with generation curves
with unevenly distributed control points more accurately.
The Shell custom object creates two entries in
a submenu (named Shell) of the custom menu.
"Export to NPatch"
exports the current shell
to a NURB patch (this feature is disabled in the demo version!).
"Export GCurve"
creates a NURB curve child object
of the current shell. This curve may be used as generation curve
if ShellyLib is in GCurve mode.
"ApplyMode"
controls the behaviour of the sliders
of the other properties. If it is set to the default value
of "Manual"
the sliders will change nothing until
the "Apply" button is pressed. If set to "OnMouseUp"
or "Continuous"
movements of the sliders will
lead to immediate apply operations (whenever the slider
is released or while the slider is moved, respectively).
Using "SLMode"
you can control, wether ShellyLib is in
Normal or GenCurve mode while generating the shell.
GenCurve mode allows to use an arbitrary curve instead of an ellipse (as in Normal mode) as cross section. The generation curve has to be a child NURB curve of the shell custom object. The shell object will automatically adapt to this curve. You may create such a curve easily using the export GenCurve feature.
Note, that the parameters "a"
, "b"
and "A"
change
the generation curve as they do it in Normal mode. With a freshly
exported curve you need to set "a"
and "b"
to 1.0
and "A"
to 0.0, consequently. Otherwise, the exported generation
curve would be scaled and moved inappropriately, and the new shell would
be e.g. much bigger than expected.
If "CacheShell"
is enabled, the shell generator will just be used
when a parameter has been changed, the full geometric
representation of the shell will be cached in memory, allowing
to be drawn multiple times withot re generation but with memory
overhead.
If "Display"
is set to "NURB"
, the shell will be drawn as
NURB surface (with a sampling tolerance of "Tolerance"
)
when draw surface is enabled in a view. Otherwise
it is drawn as a bunch of polygons.
"WatchSurf"
and "WatchDisp"
control whether the
shell object should search its surface and displacement shaders
(while RIB export) for parameters labeled "O"
and "W"
and fill in appropriate values.
This feature allows the shaders that come with ShellyLib
to detect the aperture of the shell, and handle the interior
appropriately. If you use shaders that use "O"
and "W"
for other things you should not enable this feature.
Using "Import Shell"
you may import any ShellyLib data
files, written e.g. by the Shell Laboratory.
When importing a shell with a generation curve, you
need to export the generation curve manually using
"Export GCurve"
in the custom menu after import
but before switching to GCurve mode!
All parameters displayed in these properties are ShellyLib parameters. In contrast to the other standard GUI elements that are used throughout The Mops, the Shell object uses more comfortable sliders.
A slider may be reconfigured using a double click on any of the two labels beside the slider. Reconfiguration is necessary if you want to set parameters that are not allowed by the current min, max or stepsize parameters of the slider.
Depending on the ApplyMode in the SLControl property the slider
may do an automatic apply leading to an immediately updated
shell when you drag it, or when you let it go.
The default, however, is no automatic apply at all.
The entries do not change a value until the focus leaves
the entry (always press <Tab>
if you are finished with an entry!).