Next Previous Contents

4. Objects and Properties

This section informs you about the different object types of Ayam and about the property GUIs that appear in the properties section of the main window if a single object and a property have been selected.

4.1 Standard Properties

Most Ayam objects have standard properties. They are used to control transformations and common attributes of objects. The following sections describe the standard properties "Transformations", "Attributes", "Material", "Shaders", and "Tags".

4.2 Transformations Property

Use this property to edit the location, orientation, and size of an object.

The transformations are applied to the object in the following order: Scale, Rotation, Translation.

Using the Rotation Attributes

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, Ayam 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 derived 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). Do not change more than one entry at once until you exactly know what you are doing.

Undoing a single rotation works in the same way, just use a subtraction instead of an addition.

Undoing all rotations (resetting the object to its original state) is simple too: enter 0 for all three entries at once, then press apply.

If you want to copy the orientation of an object to other objects using the property clipboard, make sure that you select all Rotation and Quat property elements.

4.3 Attributes Property

The attributes of an object contain currently:

4.4 Material Property

The material property allows you to connect geometric objects to material objects (see also section Material Object). The material property GUI consist of the following elements:

4.5 Shaders Properties

Shader properties are used to attach shaders of a certain type to objects. The name of the property contains the type of the shader, e.g. light shaders may be attached using a property named "LightShader" only. Other types of shaders or shader properties are: "Surface", "Displacement", "Interior", "Exterior", "Atmosphere", and "Imager".

Each shader property GUI, 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. If you press the "Set new shader."-button, a dialog with a list of shaders pops up. If this list is empty, Ayam is probably not set up properly (or you simply do not have shaders of the appropriate type). Check the preference setting "Main/Shaders". 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.

The "Delete shader."-button may be used to delete the current shader from the selected object.

The "Default Values."-button resets all arguments of the shader to the default values. See also section Working with Shaders below.

All other elements of the shader property GUI depend on the currently attached shader.

Shader Parsing

If no plugin is loaded, the official Ayam binaries use libslcargs (from BMRT) to parse shaders that have been compiled with slc (the shader compiler from BMRT). Parsing incorporates detecting the type of the shader and detecting the names, types, and default values of all shader arguments.

Note that currently, Ayam only works properly with shaders that have at most two dots in their file name and that Ayam will simply skip all array arguments (and emit a warning message) while parsing a shader. Those array arguments consequently never appear in the shader property GUIs and RIBs exported by Ayam. Also note that default values for shader arguments of type color will be silently clamped to the range 0-255.

Many shaders use array arguments to define transformation matrices. If this is the case and you have access to the shader source code you may want to modify those shaders to enable working with the transformation matrix carrying shader arguments. To do this, just change all definitions of transformation matrix carrying floating point arrays to real matrices. If the shader contains a

"float a_matrix_parameter[16]"

change this to

"matrix a_matrix_parameter".

Note that these changes of the shader argument definitions probably also require changes of the code that uses those arguments. Ayam is able to deal with matrices because of their fixed size of 16 float values, and because libslcargs is able to deliver the default values for a matrix (but not for an array!).

If Ayam has been compiled without a shader parsing library (e.g. without libslcargs), Ayam will parse XML files created by "sl2xml" from the K-3D project (see "http://www.k-3d.com/") instead of compiled shaders. The "Set new shader."-button will in this case always open a file requester, allowing you to select a XML file, that has been created by sl2xml. Furthermore, the "Default Values."-button will not be available; you have to use "Set new shader." instead.

From version 1.3 on, Ayam also supports shader parsing plugins to allow parsing of shaders compiled with different shader compilers, see also section Shader Parsing Plugins.

Working with Shaders

The "Default Values."-button resets all arguments of the shader to the default values. For that, the compiled shader will be parsed again. Therefore, this button is quite handy if you have to deal with changing shaders: just edit the shader, recompile it, then back in Ayam just hit the "Default Values."-button. Note that this destroys your possibly carefully adjusted shader argument values.

If you want to keep the old shader argument values when a shader changes, simply copy the shader property using the property clipboard (main menu: "Edit/Copy Property") before you load the new default values and paste the property back using "Edit/Paste Property" after loading of the new default values. Note that this works only properly, if you do not change the type of existing shader arguments and if no shader arguments are removed in the new version of the shader!

You can also just copy certain parameter values by selecting them using double-clicks on the parameter names in the shader property GUI and then use e.g. "Edit/Copy Marked Prop" (see also the description of the property clipboard in section Properties).

4.6 Tags Property

Use this property to edit the tags of an object.

Tags provide 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 consists of the following standard elements:

The next sub-sections describe the currently available tag types. Note that extensions and plugins may define their own types.

RiAttribute Tag

The tag type "RiAttribute" can be used to attach arbitrary RenderMan interface attributes to objects. This is handy if you use a renderer with lots of RiAttributes that differ from the standard RiAttributes.

"RiAttribute" tags attached to a geometric object override "RiAttribute" tags possibly attached to the material object of this geometric object.

In order to create a tag of type RiAttribute, the type string must be "RiAttribute". 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, g - float pair, i - integer, j - integer pair, s - string, c - color, p - point) and finally param is the value of the parameter itself (e.g. a float: "1", a string: "on", a color: "1,1,1" or a point: "0.4,0.5,1.0").

Examples:

RiAttribute render,truedisplacement,i,1

RiAttribute dice,numprobes,j,3,3

RiAttribute radiosity,specularcolor,c,0.5,0.5,0.5

Note that the RiAttribute tag handles just a single parameter at once. Also note that RiAttribute tags may be created much more easily using the menu entry Special/Tags/Add RiAttribute. The database of RiAttributes for this GUI may be extended by the user using the ayamrc file, see section Ayamrc File.

RiOption Tag

The tag type "RiOption" can be used to attach arbitrary RenderMan interface options to objects. This is handy if you use a renderer with lots of RiOptions that differ from the standard RiOptions. However, they will be only used by the RIB exporter if they are attached to the "Root" object! The syntax is similar to the "RiAttribute" tag type, see above. Note that RiOption tags may be created easily using the menu entry Special/Tags/Add RiOption. Tags created with this GUI will always be added to the "Root" object. It does not have to be selected! Furthermore, the database of RiOptions for this GUI may be extended by the user using the ayamrc file, see section Ayamrc File.

TC (TextureCoordinates) Tag

The tag type "TC" can be used to attach texture coordinates to objects or materials. "TC" tags attached to a geometric object override "TC" tags possibly attached to the material object of this geometric object. The "TC" tag always contains a list of eight comma separated float values, that specify a mapping for four points (a quadrilateral) in texture space from the default values (0,0), (1,0), (0,1), and (1,1) to the new specified values.

Examples:

TC 0,0,10,0,0,10,10,10

Changes the texture coordinate space so that more and smaller tiles of a texture would be displayed on a primitive.

TC 0,0,0,1,1,0,1,1

Flips the texture coordinate space over two corners. A shader normally generating vertical stripes will create horizontal stripes now.

TC 0,1,0,0,1,1,1,0

Turns the texture coordinate space by 90 degrees. A shader normally generating vertical stripes will create horizontal stripes now.

Note that the exact behaviour depends heavily on the shader and its use of the texture coordinates!

Texture Coordinate Editor

The texture coordinate editor may be opened using the main menu entry "Special/Tags/Edit TexCoords" and lets you edit texture coordinate tags in an intuitive way.

For that, the texture coordinates are displayed as a black polygon in a canvas with regard to the original values, that are displayed in gray. Small arrows point to positive s and t direction respectively.

Texture Coordinate Editor

The "RotateR" and "RotateL" buttons shift the coordinate values between the four points. This results in a 90 degree rotation.

The "FlipS" and "FlipT" buttons flip the texture coordinate values in s and t direction respectively. This is useful, if you want to correct a texture mapping for an image that appears upside down.

The next buttons allow to move (using "MoveS" and "MoveT") and scale (using "ScaleS" and "ScaleT") the texture coordinates by a specific amount that is given in the first entry field.

The "Load" and "Save" menu buttons allow you to:

Note that the tag numbers in the menu entries count TC tags only.

The texture coordinate dialog is modeless, it may stay open while you model. The "Dismiss" button closes the dialog.

PV (Primitive Variable) Tag

The tag type "PV" can be used to attach arbitrary data to geometric primitives and even sub-primitives. When rendering, all data is handed over to the surface shader attached to the respective geometric primitive. Note that Ayam does not check, whether your shader actually uses this data. With the help of primitive variables you can e.g. attach your own texture coordinates to a NURBS patch primitive or attach distinct colors to the faces or even to single vertices of a polygonal mesh. In the latter case, the data is properly interpolated by the renderer before it is handed over to the shader.

The syntax of the value string of a PV tag is as following:

<name>,<detail>,<type>,<ndata>,<data>

where "<name>" is the name of the primitive variable; "<detail>" or storage class should be "uniform", "varying", "vertex", or "constant"; "<type>" is a single character describing the type of the data (see also the documentation of the "RiAttribute" tag above); "<ndata>" is an integer number describing how many data elements will follow; and "<data>" is a comma separated list consisting of a certain number of elements of type "<type>".

Examples:

PV mycolor,constant,c,1,0,1,0

adds a single color value (0,1,0), which is the same all over the primitive;

PV mys,varying,f,4,0.1,0.2,0.3,0.4

could be used to add a distinct float value to each corner point of a standard NURBS patch (order, width, and height 4).

Note that not all geometric objects currently honour PV tags on RIB export. The geometric objects currently supporting PV tags are: SDMesh, PolyMesh, PatchMesh, NURBPatch, and BPatch.

Furthermore, the number of data elements, which depends on the detail or storage class, the type of geometric primitive, and the configuration of the geometric primitive is not checked by Ayam. Some RIB writing libraries, however, check the number and silently omit the primitive variable if there are mismatches. Check your RIB for the presence of the primitive variable after export, especially, if you are adding or editing PV tags manually!

RiHider Tag

The tag type "RiHider" can be used to choose and parameterize different algorithms for hidden surface removal. RiHider tags have to be attached to the root object in order to be used. The syntax of a RiHider tag is quite similar to a RiAttribute tag: "<type>,<parameterlist>" where "<parameterlist>" is a comma separated list of triplets consisting of name, type, and value of a parameter.

An example for a RiHider tag could look like this:


RiHider hidden,depthfilter,s,midpoint

RiDisplay Tag

The tag type "RiDisplay" can be used to add more output files of different type (e.g. containing depth-buffer information) to the scene. RiDisplay tags have to be attached to the root object in order to be used. The syntax of a RiDisplay tag is as follows: "<name>,<type>,<mode>,<parameterlist>", where name is e.g. a file or device name, type specifies the destination of the image data (e.g. screen or file), mode specifies which information should be stored or displayed (e.g. color values: rgb, or depth values: z), and "<parameterlist>" is a comma separated list of triplets consisting of name, type, and value of a parameter. The name will be automatically changed to "+name" on RIB export if it does not already start with a plus.

An example for a RiDisplay tag could look like this:


RiDisplay imagez.tif,file,z

NoExport Tag

The tag type "NoExport" can be used to exclude certain objects from exported RIBs. The value string of this tag is ignored. All that counts is the presence of the tag. Child objects of objects with the "NoExport" tag will also be excluded from the RIB. Since Ayam 1.6, light objects also honour the "NoExport" tag. Note that regardless of potentially present "NoExport" tags, RIB archives will be created for all referenced objects all the time (even if "NoExport" tags are added to all instances).

SaveMainGeom Tag

The tag type "SaveMainGeom" can be used to save the geometry of the main window and the toolbox window (if open) with a scene file. For that the scene saving code checks for the presence of a "SaveMainGeom" tag for the root object and fills it with the current geometry information. The scene reading code checks for the presence of a "SaveMainGeom" tag for the root object after replacing a scene and re-establishes the geometries of main and toolbox window.

TP Tag

The tag type "TP" can be used to save tesselation parameters to objects of type "NPatch". Those tesselation parameters will be used when the NPatch object is tesselated for e.g. a conversion to a PolyMesh object. The syntax of the TP tag is: "<tmethod>,<tparam>" where "<tmethod>" is an integer value between 1 and 3, describing which tesselation method to use (1 - ParametricError, 2 - PathLength, and 3 - DomainDistance) and "<tparam>" is a float value describing the respective parameter value for the chosen tesselation method.

TP tags may be easily created using the tesselation GUI, that can be started with the main menu entry "Tools/NPatch/Tesselate" (see also section The Tesselation Tool).

An example for a TP tag could look like this:


TP 1,0.5

DC Tag

The tag type "DC" is only used by the AyCSG CSG preview plugin to store the depth complexity of CSG primitives. The syntax of the DC tag is: "<dcval>" where "<dcval>" is a positive integer value describing the depth complexity of the CSG primitive. See also section CSG preview using the AyCSG plugin for more information regarding the depth complexity value.

An example for a DC tag (valid for e.g. a torus) could look like this:


DC 2

Internal Tags

The following tags are of no general use. They are used by Ayam internally only.

OI - Object ID Tag

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 manually avails to nothing as the tags are rebuilt before every export/save operation.

MI - Material ID Tag

This tag is used by the RIB exporter and the scene storage facility to establish links between material objects and the objects they are assigned to.

The tag type MI is not meant to be used by the end user. Furthermore, changing the IDs manually avails to nothing as the tags are rebuilt before every export/save operation.

List of Known Tags

This section contains a comprehensive list of tag names, that are known in Ayam 1.8 and in the accompanying extensions.

"RiAttribute", "RiOption", "RiHider", "RiDisplay", "NoExport", "TC", "PV", "SaveMainGeom", "TP", "MI", "OI", "DC", "IDR", "IIDR", "RIDR", "R3IDR", "CIDR", "CCIDR"

Documentation on those tags can be found in the sections above.

4.7 Root Object

There is always exactly one Root object in the scene. This object is something special in that it cannot be deleted or copied. It holds options global to the scene like RiOptions, atmosphere and imager shaders. Furthermore, all currently open view windows are child objects of the Root object.

If you hide the Root object the little red/green/blue coordinate system will not be drawn in any view.

The global scene options are documented in the following sections.

RiOptions Property

This property carries RenderMan Interface options. Both, standard and BMRT specific options may be set using this property. For the sake of brevity only a short description of the available options will be given here. Please refer to the documentation of the RenderMan Interface and the documentation of BMRT for more detailed information about the options. The RiOptions property consists of the following elements:

Imager, Atmosphere Property

The Imager and Atmosphere properties let you define shaders for the Root object, please refer to section Shaders Properties for information on how to deal with shader property GUIs.

Imager shaders are executed once for every rendered pixel, they may e.g. be used to set a specific background color.

Atmosphere shaders are volume shaders that may be used to implement global atmospheric optical effects like fog.

4.8 View Object

Every view window (see also section Anatomy of a View) has a corresponding view object as a child object of the root object. You can change camera settings, the type of the view, and other things related to the view using the properties of the view object. 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!

Each 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 modeling actions in a view are limited to that input plane (unless the view is switched to local modeling; available since Ayam 1.4; see also section Editing in Local Space). The standard input planes are as following: Front - XY-plane, Side - ZY-plane, Top - XZ-plane, Trim - XY-plane.

In perspective views no interactive modeling actions are possible, but you may position the camera and pick objects.

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. Note that picking of objects currently does not work in views of type "Trim".

View objects act in special ways, when certain objects are dropped onto them in the tree view:

When a camera object is dropped onto a view object using Drag-and-Drop in the tree view the camera settings of the camera object will be copied to the views camera.

When a light object of type "Spot" is dropped onto a view object using Drag-and-Drop in the tree view the views camera will be changed, so that the user looks along the light to see what objects of the scene are lighted by the light object (this works best with perspective views that have equal width and height).

Since Ayam 1.8 it is possible, to directly drag objects from the tree view to a view window, for geometric objects, the view then performs a zoom to object operation, for cameras and light sources the views camera will be changed accordingly (see the description of Drag-and-Drop with view objects above).

Camera Property

This section describes all elements of the "Camera" property:

Note that the up vector is not checked for erroneous values (e.g. pointing in the direction of from-to) when applying the changes of the "Camera" property.

ViewAttrib Property

This section describes the elements of the "ViewAttrib" property:

4.9 Camera Object

Camera objects are used to temporarily save camera settings of views. Therefore, they has just have two properties explained above, see sections Camera and Attributes Property.

When a view object is dropped onto a camera object using Drag-and-Drop in the tree view, the camera settings from the view will be copied to the camera object.

4.10 Box Object

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 bilinear patches.

BoxAttrib Property

4.11 Quadric Primitives

Box, and Quadric Primitives

Sphere Object

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.

RiSphereAttr Property

Disk Object

A disk, centered at the origin of the object coordinate system. This object will always be exported as simple disk in RIBs.

RiDiskAttr Property

Cone Object

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.

RiConeAttr Property

Cylinder Object

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".

RiCylinderAttr Property

Torus Object

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.

RiTorusAttr Property

Paraboloid Object

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.

RiParabAttr Property

Hyperboloid Object

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.

RiHyperbAttr Property

4.12 Level Object

Level objects may be used to build object hierarchies and perform CSG operations. Note that child objects of a level inherit the levels transformations attributes and shaders. Inheritance of e.g. transformations means: If you have a NURBS patch in a level that is translated to 10,0,0, the origin of the local coordinate system of the NURBS 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.

LevelAttr Property

Levels do not have many object type specific properties, you may just modify the type of the level using the attribute "Type".

Levels of type "Level" just group objects and inherit attributes.

Levels of type "Union", "Intersection", and "Difference" are used to build CSG hierarchies. Additionally, they inherit attributes. Note that Ayam is currently not able to correctly display the results of CSG operations, all objects are always drawn completely, even though a CSG operation cut parts away. Since Ayam 1.8 there is a plugin available, that is able to preview the CSG operations, see also section CSG preview using the AyCSG plugin.

New solid primitives may be created with levels of type "Primitive". Note that Ayam is not able to check, whether your new primitive obeys the rule of total closeness.

4.13 Material Object

Material objects are used to attach RiAttributes and shaders to geometric objects.

When geometric objects are dropped onto a material object using Drag-and-Drop in the tree view they will be connected to this object.

When geometric objects are connected to a material object this material object may not be deleted.

RiAttributes Property

Using this property 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 RenderMan specific attributes.

Surface, Displacement, Interior, Exterior Property

These properties let you define shaders for the material object, please refer to section Shaders Properties for information on how to deal with shader property GUIs.

Surface shaders may be used to procedurally encode lighting models and textures. Displacement shaders may procedurally deform the object while rendering. Interior and Exterior shaders are so called volume shaders that may be used to capture special optical effects, encoding how light is affected while passing through an object.

MaterialAttr Property

The MaterialAttr property contains attributes related to the management of material objects:

4.14 Light Object

In contrast to the light sources as defined in the RenderMan interface, Ayam light sources are always global. This means, regardless of the place of a light source in the scene hierarchy, it will always light all other objects.

The behaviour of a light source object depends heavily on the type of the light source. There are four different types available: "custom", "point", "distant" and "spot".

Custom Lights:

Light sources of type custom use the attached light shader.

Note that Ayam 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!

Point-, Distant-, and Spotlights:

These (standard) light sources have well defined parameters that will be displayed in the "LightAttr" property. Please refer to the RenderMan documentation for more information about the standard light sources (see section references).

LightAttr Property

Depending on the type of the light source, the light attribute property contains different parameters. Parameters that are not displayed will not be used on RIB export, consequently.

Using "Type" you can change the type of the light source. When you change the type of a light source, the property GUI will be adapted but only after you use the "Apply"-button.

"IsOn" allows you to switch the light off or on. The default value is on.

"IsLocal" controls whether the light source should light just local objects (objects, that are defined in the same level in the scene hierarchy as the light source object or below) or all objects in the scene. The default is off, all objects in the scene are lighted! The "IsLocal" attribute is ignored for lights that are defined in the root level of the scene. Note that shadow maps will always contain shadows from all objects in the scene, regardless of local lights.

Using 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!

"UseSM" determines, whether shadow maps should be created and used for this light source. The resolution of the shadow map may be determined by "SMRes". If "SMRes" is 0, a default of 256 by 256 pixels will be used. These options are for renderers that do not support raytraced shadows like PRMan or Aqsis only.

For lights of type "Distant" the "Scale" attributes of the "Transformations" property of the light object may be used to scale the camera transformation used for the creation of the corresponding shadow map. Values of 1 for "Scale_X" and "Scale_Y" create a shadow map that is sized 1 by 1 units in world space.

All other parameters that may appear in the "LightAttr" property are the standard parameters for the standard RenderMan light sources: distant, point, and spot:

In order to ease the parameterisation of spot lights, you may drop the light source object on to a view object (preferably one with a perspective viewing transformation and with equal width and height) to see what objects of the scene are actually lighted by the light object.

Using ShadowMaps

Using shadow maps requires the global preference setting "RIB-Export/ShadowMaps" to be switched on. Furthermore, for each light source for which a shadow map should be created, the attributes "IsOn" and "UseSM" have to be switched on.

If the preference setting "RIB-Export/ShadowMaps" is set to "Automatic", Ayam will create a special version of the RIB on export, that creates all shadow maps automatically. This is done, by rendering depth images from the position of every light source that casts shadows. Special light source shaders later pick up these depth images and calculate shadows. This approach implies, that the scene is rendered multiple times. To reduce the size of the RIB, the objects to be rendered are written to a second RIB file named "<scene>.obj.rib". This file is read from the main RIB several times via "ReadArchive". The RIB contains multiple frames which may be rendered separately. To help you picking the right frame number for the image (e.g. to re-render just the image), a comment with the frame number of the last frame (the image) will be written as last statement to the RIB.

Because multiple files (RIBs and shadow maps) are used, it is suggested to change the preference setting "RIB-Export/RIBFile" to "Scenefile". This will strip the leading absolute path component from the filenames so that you may move the scene from one system to another more easily.

If the preference setting "RIB-Export/ShadowMaps" is set to "Manual", the exported scene will not render the shadow maps but rather expects them to be present already. You can create them manually (hence the name "Manual") using the view menu entry "View/Create ShadowMaps" or the main menu entry "Special/RIB-Export/Create ShadowMaps". The manual approach has the advantage, that the shadow maps will not be re-created each time you render the scene.

Ayam supports three different methods for the creation of shadow maps for certain types of light sources: point, distant, and spot:

The point method is used with lights of type "Point" and custom lights that have a light shader argument named "from". Six shadow maps pointing in all possible axis aligned directions and named "<rib>.point<num>_<dir>.shd" (where "<rib>" is the name of the RIB, "<num>" is the number of the light source that makes use of shadow maps and "<dir>" is one of "x+", "x-", "y+", "y-", "z+", or "z-") will be created.

The distant method is used with lights of type "Distant" and custom lights that have a light shader argument named "from" and a light shader argument named "to". One shadow map is created and named "<rib>.dist<num>.shd". By default, the size of the shadow map is 1 by 1 units in world space, but this may be adapted using the scale transformation attributes of the light object.

The spot method is used with lights of type "Spot" and custom lights that have a light shader argument named "from", a light shader argument named "to", and a light shader argument named "coneangle". One shadow map is created and named "<rib>.spot<num>.shd". The spot method uses the cone angle (and additionally the delta cone angle, if present) argument to determine the size of the shadow map in world space.

If a light object of type "Spot", "Distant" or "Point" is used, Ayam automatically changes the name of the exported light shader to "shadowspot", "shadowdistant", and "shadowpoint" respectively. Additionally, the shader will be parameterized to use the created shadow maps. If the light source is of type "Custom", no automatic renaming and adjusting of the shader takes place. This means, you have to make sure that the shader really uses the shadow maps, by selecting the right shader and parameterizing it accordingly. See the discussion above for the names of the shadow map files. Those file names, probably, will have to be entered as parameter to the light shader.

For example, you will not get any shadows if you use a light source of type "Custom" with a "distantlight" shader attached, even though Ayam is able to create the necessary shadow maps. The "distantlight" shader just makes no use of them. You have to manually switch to a shader that makes use of the shadow maps ("shadowdistant" in this case) to get shadows.

Here is a short example for a scene using a shadow map:

  1. Go to the preferences (section "RIB-Export") and set "ShadowMaps" to "Automatic".
  2. Create two boxes.
  3. Open the "Transformations" property of the second box.
  4. Translate it by X: 0.0, Y: -1.0, Z: 0.0.
  5. Scale it by X: 4.0, Y:1.0, Z:4.0.
  6. Create a light source.
  7. Open the "LightAttr" property.
  8. Change the type to "Spot". Press "Apply".
  9. Now change the parameters of the spot light to "IsOn": Yes, "Intensity": 18.0, "UseSM": Yes, "ConeAngle": 45.0, "BeamDistrib": 3.0, "From": -2, 2, 2, "To": 1, 0, -1; leave all other parameters at their default values.
  10. Create a new view and make it perspective (Menu: "Type/Perspective").
  11. Export a RIB from that perspective view (Menu: "View/Export RIB").
  12. Render the RIB with a RenderMan compliant renderer, that uses shadow maps, e.g. Photorealistic RenderMan (prman) or Aqsis.

This scene is distributed with Ayam as an example scene named "shadowmaps.ay".

Note that for Aqsis you should add a RiHider hidden,depthfilter,s,midpoint tag to your root object if shadow maps are in use. Other renderers might require additional tweaking using shadow bias RiOption tags.

Do not render directly from a view window if your renderer does not write image files when the command line option to render directly to the display (-d for rendrib, or -fb for Aqsis) is in use. This command line option may inhibit writing of the shadow maps, so that the resulting image will look wrong.

Using AreaLights

A common idealized light source has no own 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. According to L. Gritz, Spheres and Cylinders work best as arealight geometry for BMRT, because of special sampling code.

An example:

There is an example scene named "arealight.ay" distributed with Ayam.

4.15 NURBCurve Object

NURBS curves are used to build more complex smoothly shaped objects using operations like extrude, revolve, sweep or skin. They can be closed and used to emulate Bezier and B-Spline curves easily.

Multiple Points

A NURBS Curve with Multiple Points (big handles)

The NURBS curves of Ayam support so called multiple points. A multiple point is made of a number of different control points that have the same coordinates. Modeling actions will always modify all the control points that make up a multiple point. Multiple points will be drawn with a bigger handle than normal points (see image above). They may e.g. be used to create closed curves. Note that the control points that make up a multiple point do not have to be consecutive (in the control point vector of the NURBS curve). Multiple points may be created using the collapse tool, and split up again using the explode tool (see sections The Collapse Tool and The Explode Tool for more information regarding those tools). Note that even though you might have exploded some multiple points Ayam will re-create them on several occasions like reading of a scene, inserting/deleting points, and applying the NURBCurveAttrib property if they still have identical coordinate values. In other words, you should immediately edit the control points after exploding! You may also totally inhibit creation of multiple points for a NURBS curve using the attribute "CreateMP".

NCurveAttrib Property

The first section of the NCurveAttrib property contains curve specific settings:

The GLU-Parameters control the appearance of the curve when curve/surface display is enabled.

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 NURBS curve. It is perfectly legal to change the length of the curve, it's order, and switch to a custom knot vector (be sure to actually enter a valid new knot vector) at once. Ayam 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!

4.16 NURBPatch Object

NPatchAttrib Property

The first section of the NPatchAttrib property contains patch specific settings:

The next parameters control the appearance of the patch for display in Ayam:

4.17 Trim Curves

Trim curves may be used to cut out certain parts of a NURBS patch. They are simple 2D NURBS curves defined in the parametric space of the associated NURBS patch. Trim curves have to be defined as child objects of the NURBS patch object they belong to. In contrast to other child objects, however, they do not inherit the transformation attributes of the parent object. Trim curve editing should take place in views of type Trim, that draw the boundaries of the parametric space of the corresponding NURBS patch as rectangle, but otherwise act as normal Front views.

Note that the direction of the trim curve determines which part of the NURBS patch should be cut out. You can use the Revert tool (Tools/NURBCurve menu) to easily change the direction of a trim curve.

Some special restrictions apply to trim curves:

Note that Ayam is not checking whether your trim curves follow these rules!

Warning: Certain OpenGL implementations may be easily crashed with trimmed NURBS patches with curves that do not follow the aforementioned rules! When in doubt or while heavy modeling, switch to wireframe drawing and switch off shading temporarily and you will be on the safe side.

Since Ayam 1.5 also NURBS curve providing objects are supported as trim curves.

4.18 BPatch Object

A BPatch is a bilinear patch (as it is used to build box objects, see Box Object).

BPatchAttrib Property

The BPatchAttrib property allows you to set the four points defining the geometry of the patch:

4.19 PatchMesh Object

The PatchMesh object may be used to model with bilinear and bicubic patch meshes. The PatchMesh object may be converted to a NURBS patch representation. However, this does not work for all possible types of patch meshes (e.g. patch meshes with the basis types Catmull-Rom, Hermite, or Custom). The NURBS patch representation is also in use when drawing the patch mesh (if the "DisplayMode" is not "ControlHull") and when shading the patch mesh. Consequently, there is currently no shaded representation of patch meshes of basis type Catmull-Rom, Hermite or Custom.

PatchMeshAttr Property

The first section of the PatchMeshAttr property contains patch specific settings:

The parameters "BType_U" and "BType_V" and consequently "Step_U"/"Step_V" and "Basis_U"/"Basis_V" are only available to bicubic patch meshes.

The next parameters control the appearance of the patch for display in Ayam:

4.20 PolyMesh Object

The PolyMesh object may be used to include objects that have been modeled using the polygonal modeling paradigm in Ayam scenes.

There are no special modeling actions for this type of object, but you may select and modify single points as you can do it with other object types, e.g. curves.

The PolyMesh object is equivalent to the general points polygons primitive of the RenderMan interface. This means, each PolyMesh object may contain multiple general (convex or concave) polygons, which in turn may consist of an outer loop and an arbitrary number of inner loops that describe holes in the polygon. The loops use a point indexing scheme to efficiently reuse coordinate values. This general approach requires a so called tesselation to be carried out, in order for the PolyMesh object to be shaded. For that, Ayam uses the tesselation routines of the GLU library.

Ayam is able to automatically create face normals for PolyMeshes. They will be calculated while tesselating the PolyMesh and be perpendicular to the plane determined by the first three vertices of the outer loop of a polygon. Furthermore, Ayam supports vertex normals (normals stored for every control point).

Note that storing a bunch of triangles each in its own PolyMesh object will lead to a real waste of memory. You may use the merge tool (main menu "Tools/PolyMesh/Merge") to merge many PolyMesh objects into a single PolyMesh object.

PolyMeshAttr Property

The PolyMeshAttr GUI just displays some information about the PolyMesh object:

4.21 SDMesh Object

The SDMesh object may be used to include objects that have been modeled using the subdivision modeling paradigm in Ayam scenes.

There are no special modeling actions for this type of object, but you may select and modify single points as you can do it with other object types, e.g. curves.

The SDMesh object is equivalent to the Subdivision Mesh primitive of the RenderMan interface. This means, each SDMesh object may contain multiple faces with arbitrary number of vertices that form a polygonal mesh. This polygonal mesh is then successively refined using a subdivision scheme and, depending on the number of refinement (or subdivision) steps, results in a more or less smooth surface. There are several different subdivision schemes, but the scheme currently supported by most RenderMan compliant renderers is named "Catmull-Clark".

Tags may be specified for faces, edges, or vertices to control the subdivision process (e.g. to create sharp corners or edges in the resulting surface). All tags known from the RenderMan interface (hole, crease, corner, and interpolateboundary) are supported by Ayam, but they may currently not be changed by the user.

Furthermore, Ayam is currently not able to do the subdivision and show the resulting smooth surface. All that is shown in wireframe and shaded views is the original polygonal mesh.

SDMeshAttr Property

The SDMeshAttr GUI just displays some information about the SDMesh object:

4.22 Instance Object

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 (master). 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 an object, and the error message tells you something about a reference counter, then you were about to violate the second rule. Clean the clipboard using the menu "Special/Clipboard/Paste (Move)" and delete or resolve all references.

Note that it is not possible to copy a master object and some instances of it, so that the new instances point to the newly created master. All copies of instance objects always point to the same master object. However, it is possible to move instances using Drag-and-Drop in the tree view or using the clipboard with "Edit/Cut" and then "Special/Clipboard/Paste (Move)".

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"). To resolve all instance objects in a scene to normal objects, you may use the main menu entry: "Special/Instances/Resolve all Instances".

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 (temporarily) before being exported to RIB.

Ayam can also create instances automatically (see section Automatic Instancing).

To easily find the master object of an instance, just select the instance, then use the main menu entry: "Edit/Master".

4.23 Clone Object

Clone Object with Trajectory Curve (white)

The Clone object allows you to easily create and control a number of instances of a single object. The instances will be created internally and transformed, each by a certain amount. The original object is the first child object of the Clone object. If a second object is present as child of the Clone object it is treated as trajectory (or path) curve, similar to the Sweep object (see section Sweep Object).

Thus, the object hierarchy of a Clone object may look like this:


+-Clone
 | Cloned-Object
 \ [Trajectory(NCurve)]

If you use a trajectory curve to place the clones, you may want to hide the parameter object and add a "NoExport" tag to it. Otherwise the original object will appear twice, on the trajectory and on its normal position. Note that the transformation attributes of the parameter object will be completely overwritten when placing the clones on the trajectory curve. If the parameter object has distinct scale or rotation attributes it should be placed inside a level object like this:
+-Clone
 +-Level
 |\-Cloned-Object with non-standard Scale/Rotation
 \ Trajectory(NCurve)

It is not possible to create clones from objects that may not be master objects of instance objects (e.g. light objects, or material objects). However, (since Ayam 1.7) it is possible to use instances as parameter objects.

If an instance object is used as parameter object it should be placed in a level (see above) and the "NoExport" tag should added to the level object (as you can not add tags to instance objects).

The following attributes further control the clone process:

CloneAttr Property

4.24 Revolve Object

Revolve Object (left: Curve, right: Surface of Revolution)

The Revolve object forms a surface of revolution from a NURBS curve.

The Revolve object has the generating NURBS curve as child object and watches its changes 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:

You may convert the current surface of revolution and the caps, if there are any, to ordinary NURBS patches using the main menu entry "Tools/Convert".

RevolveAttr Property

Using the parameter "ThetaMax" you can specify the sweeping angle of the revolution just like with an ordinary RenderMan quadric.

Since Ayam 1.8 the Revolve object supports a B-Spline mode, that may be enabled by setting the new parameter "Sections" to a value higher than 2. In this mode, a circular B-Spline is used as basis for the surface of revolution, instead of the standard NURBS circle. Depending on the number of sections choosen, the surface of revolution does not exactly interpolate the parameter curve, but the surface may be edited more easily after a possible conversion to an ordinary NURBS patch object, because the control points will not be rational. In addition to the number of sections, in B-Spline mode it is possible to control the order of the surface of revolution using the new parameter "Order". If "Order" is 0, a standard value of 3 will be used. Note that the B-Spline mode is currently only available for full revolutions ("ThetaMax" should be 360.0).

The revolve object can automatically generate caps, which are trimmed NURBS patches. Using the parameters "UpperCap", "LowerCap", "StartCap", and "EndCap", you determine whether such caps should be generated, default is off (no caps).

If the side caps of a surface of revolution of an open curve are not created correctly, (GLU complains about "intersecting or misoriented trimcurves"), try to revert the revolved curve.

See section NPatchAttrib for a description of the other two attributes "DisplayMode" and "Tolerance".

4.25 Extrude Object

Extrude Object (left: Curve, middle: normal Extrusion, right: Extrusion with Caps)

The extrude object forms an extrusion from a number of NURBS 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 NURBS curves as child objects and watches them and adapts to them automagically.

Consequently, the object hierarchy of an Extrude object may look like this:


+-Extrude
 | Outline(NCurve)
 | [Hole1(NCurve)]
 \ [Hole2(NCurve)]

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!

You may convert the current surface of extrusion and the caps and bevels, if there are any, to ordinary NURBS patches using the main menu entry "Tools/Convert".

ExtrudeAttr Property

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 NURBS patches. Using "UpperCap" and "LowerCap" you determine whether such caps should be generated, default is off (no caps). Note that this feature does only work properly, if the generating NURBS curves are closed and not self intersecting, this is because the generating curves themselves are used as trim curves for the caps. Warning, Ayam will not check whether your curves conform to this criteria. Ayam, 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 "DisplayMode" and "Tolerance".

Using Holes and Bevels

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. Ayam 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! Beveling may lead to self intersecting trimcurves in sharp corners of an extrusion. Decrease the bevel radius or round the corners of the extruded curve (using insertion of additional control points) if cap generation fails due to self intersecting bevels.

4.26 Sweep Object

Sweep Object (left: Curves, right: Resulting Swept Surface)

The sweep object forms a surface that results from moving a NURBS curve (cross section or profile) along a second NURBS curve (trajectory or path). The cross section may be scaled while sweeping using a third curve, the scaling function.

The sweep object has the generating NURBS curves as child objects and watches their movements and adapts to them automagically. The first curve is the cross section, the second is the trajectory, and the third curve represents the scaling function.

The object hierarchy of a Sweep object, thus, may look like this:


+-Sweep
 | Cross_Section(NCurve)
 | Path(NCurve)
 \ [Scaling_Function(NCurve)]

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!

The cross section curve has to be defined in the YZ-plane. This means, that a simple circular curve as e.g. created with the toolbox has to be rotated 90 degrees around the Y-axis.

The scaling function is sampled for each section and the Y-component of the coordinates of the current curve point will be used as scale factor, that is applied to the cross section in Y- and Z-direction. This implies, that a scaling function that does nothing should e.g. be linear from (0,1,0) to (1,1,0).

Sweep Object with Scaling Function (white)

Here is a short example for the creation of a sweep:

Section Easy Sweep has an example script that automates creation and parameterisation of a suitable cross section curve.

You may convert the current sweep and the caps, if there are any, to ordinary NURBS patches using the main menu entry "Tools/Convert".

SweepAttr Property

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 NURBS patch. The NURBS 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.

The attributes "StartCap" and "EndCap" may be used to automatically create cap surfaces, that close the Sweep on both ends. Note that this works properly only if the cross section curve is closed and planar (defined in the XY plane).

See section NPatchAttrib for a description of the other two attributes "DisplayMode" and "Tolerance".

4.27 Birail1 Object

Birail1 Object (left: Curves, right: Resulting Swept Surface)

The Birail1 object forms a surface by sweeping a cross section (or profile) curve along two so called rail curves. The object hierarchy of a Birail1 object, thus, looks like this:


+-Birail1
 | Cross_Section(NCurve)
 | Rail1(NCurve)
 \ Rail2(NCurve)

When the cross section touches the rail curves in their respective starting points, the resulting surface will interpolate the rail curves. The direction of the cross section curve will be parallel to the v parametric dimension (height) and the direction of the rail curves will be parallel to the u parametric dimension (width) of the resulting surface. Height and width of the surface will be derived from the length of the cross section curve and the number of sections, respectively.

Valid Configuration of Parameter Curves (white) for Birail1 (blue)

The image above shows a valid configuration of parameter curves for the Birail1 object. Mind the direction of the rail curves (R1 and R1) with regard to the cross section curve (CS) and the fact that the cross section curve touches the starting points of the rail curves.

Note that the cross section curve does not have to be two dimensional, and, in contrast to the normal Sweep object, it also does not have to be defined in a special plane. Also note that the precision with which the resulting surface will interpolate the rail curves depends on the number of sections choosen.

The following parameters further control the birailing process:

Birail1Attr Property

The parameter "Sections" determines how many sections (in u direction) should be used, when generating the birailed NURBS patch. The birailed NURBS patch always has sections+1 control points in u direction.

The attributes "StartCap" and "EndCap" may be used to automatically create cap surfaces, that close the birailed surface on the respective end. Note that this only works properly if the cross section curve is closed and planar (e.g. defined in the XY plane).

See section NPatchAttrib for a description of the other two attributes "DisplayMode" and "Tolerance".

4.28 Birail2 Object

Birail2 Object (left: Curves, right: Resulting Swept Surface)

The Birail2 object forms a surface by sweeping a cross section (or profile) curve along two so called rail curves, while morphing it into a second cross section (or profile) curve. The morphing process may be controlled by a fifth parameter curve. The object hierarchy of a Birail2 object, thus, looks like this:


+-Birail2
 | Cross_Section1(NCurve)
 | Rail1(NCurve)
 | Rail2(NCurve)
 | Cross_Section2(NCurve)
 \ [Interpolation_Control(NCurve)]

When the cross sections touch the rail curves in their respective starting points, the resulting surface will interpolate the rail curves. The direction of the cross section curves will be parallel to the v parametric dimension (height) and the direction of the rail curves will be parallel to the u parametric dimension (width) of the resulting surface. Height and width of the surface will be derived from the length of the cross section curves and the number of sections, respectively.

Valid Configuration of Parameter Curves (white) for Birail2 (blue)

The image above shows a valid configuration of parameter curves for the Birail2 object. Mind the direction of the rail curves (R1 and R1) with regard to the two cross section curves (CS1 and CS2) and the fact, that all curves touch at their respective end points.

Note that the cross section curves do not have to be two dimensional, and, in contrast to the normal Sweep object, they also do not have to be defined in a special plane. Furthermore, they do not have to be compatible in terms of length, order, and knots. Incompatible curves will be made compatible before birailing automatically, the height of the resulting surface, however, is not easily predictable anymore in this case. Also note that the precision with which the resulting surface will interpolate the rail curves depends on the number of sections choosen.

If a fifth curve is present as parameter object, this curve will control the morphing (interpolation) process. The y coordinate of this curve at a specific point, which should have a value between 0 and 1, will control the ratio of control of the first cross section (0) and the second cross section (1) over the interpolated curve. Thus, a straight line running from point (0,0) to (1,1) will mimic the standard linear interpolation that would be carried out if no interpolation control curve were present. Note, however, that the interpolation control curve has no influence on the first and last copy of the respective cross section curve. Those will always exactly match the parameter curves.

The following parameters further control the birailing process:

Birail2Attr Property

The parameter "Sections" determines how many sections (in u direction) should be used, when generating the birailed NURBS patch. The birailed NURBS patch always has sections+1 control points in u direction.

The attributes "StartCap" and "EndCap" may be used to automatically create cap surfaces, that close the birailed surface on the respective end. Note that this only works properly if the cross section curve is closed and planar (e.g. defined in the XY plane).

See section NPatchAttrib for a description of the other two attributes "DisplayMode" and "Tolerance".

4.29 Skin Object

Skin Object (left: Curves, right: Resulting Skinned Surface)

The skin object forms a surface defined by a set of cross section curves, where the first and last curve will always be interpolated by the surface (this process is sometimes also called lofting).

The complete template for the Skin object hierarchy, consequently, looks like this:


+-Skin
 | C1(NCurve)
 | C2(NCurve)
 | [...
 \ Cn(NCurve)]

Note that in contrast to the build from curves tool, the curves may be of arbitrary length and order. You may e.g. easily skin a curve of order 2 and length 6 with a second curve of order 4 and length 4 and a third curve with order 3 and 5 control points. If the curves are of different length or order, they will all be converted internally until they are compatible. Be warned, that this process may consume a considerable amount of time because 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 object try to switch to lazy notification.

The direction of the parameter curves will be parallel to the v dimension (height) of the skinned surface. The number of the parameter curves will define the u dimension (width) of the skinned surface.

Also note that the resulting patch may be quite complex, even though the curves are not, if the orders or knot vectors of the curves 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 object has the generating NURBS curves as child objects and watches their changes and adapts to them automagically.

You may convert the current skin and the caps, if there are any, to ordinary NURBS patches using the main menu entry "Tools/Convert".

SkinAttr Property

The first parameter "Interpolation" controls, whether the inner curves should also 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. If "Order_U" is 0, a default value of 4 will be used.

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 (see above) does not match the number of skinned curves, then the order will be silently adapted to the number of skinned curves. New in Ayam 1.7 is support for the knot type Custom, which creates a chord length parameterisation.

The attributes "StartCap" and "EndCap" may be used to automatically create cap surfaces to close the skin on both ends. Note that this works only if the first (last) curve is closed and planar (defined in XY plane). Furthermore, if the skin is not interpolating the first (last) parameter curve (this may be the case if the "Knot-Type_U" parameter is set to "B-Spline") the cap(s) will not be created on the right place. The cap(s) will always be on the position of the first (last) parameter curve.

See section NPatchAttrib for a description of the other two attributes "DisplayMode" and "Tolerance".

4.30 Gordon Object

Gordon Object (left: Curves, right: Resulting Gordon Surface)

The Gordon object forms a surface defined by two sets of intersecting curves (a network of curves), where all curves will always be interpolated by the surface (see image above). The image below shows the simplest configuration of such a network consisting of four parameter curves. Note the order and the direction of the curves.

Gordon Surface with Parameter Curves (white)

The curves may be of arbitrary length and order. You may e.g. use a curve of order 2 and length 6 with a second curve of order 4 and length 4 and a third curve with order 3 and 5 control points for the u parametric dimension. Note, however, that only non-rational curves can be used as parameter curves for a Gordon surface. If the parameter curves have weights, the weight information of the curves will simply be ignored.

The Gordon object has the generating NURBS curves as child objects and watches their changes and adapts to them automagically. Separation of the two sets of curves has to be done using an empty level object. The first set of curves determines the u direction and the second set of curves the v direction of the Gordon surface. For the example surface in the image above, the child objects of the Gordon object would have to look like this in the Ayam object tree view:


+-Gordon
 | U1(NCurve)
 | U2(NCurve)
 | Level
 | V1(NCurve)
 \ V2(NCurve)

The creation of a Gordon surface is computationally expensive. It involves (interpolated) skinning of the two sets of parameter curves, finding the intersection points of the two sets of parameter curves, interpolating the matrix of intersection points, making the three resulting surfaces compatible, and finally combining the three surfaces into the resulting Gordon surface. If you experience lags while editing the parameter curves of a Gordon surface, consider switching to lazy notification.

In order to ease the computationally intensive intersection detection for Ayam you may specify a third argument (separated from the two sets of parameter curves by a second empty level object). This third argument should be a NURBS patch object that describes all intersection points (by its control points). If present, this intersection patch always takes precedence over the intersection points calculated internally. You may want to add a "NoExport" tag to this patch. The object hierarchy of a Gordon object using such a patch, consequently looks like this:


+-Gordon
 | U1(NCurve)
 | U2(NCurve)
 | Level
 | V1(NCurve)
 | V2(NCurve)
 | Level
 \ Intersections(NPatch)

The complete template for the Gordon object hierarchy, consequently, looks like this:


+-Gordon
 | U1(NCurve)
 | U2(NCurve)
 | [...
 | Un(NCurve)]
 | Level
 | V1(NCurve)
 | V2(NCurve)
 | [...
 | Vn(NCurve)]
 | [Level
 \ Intersections(NPatch)]

You may convert the current Gordon surface to an ordinary NURBS patch using the main menu entry "Tools/Convert".

The following parameters of the Gordon object further control the creation of the Gordon surface:

GordonAttr Property

If the parameter "WatchCurves" is switched on, Ayam will check for all four outer parameter curves, whether they touch in their endpoints. If not, the endpoints will be corrected. Note that this works only properly with clamped curves and objects that directly contain editable control points (i.e. it works with NCurve and ICurve objects, but not with Instance or ConcatNC objects). If Ayam can determine which curve was modified last, the other curve that should meet at the endpoint in question will be modified by "WatchCurves". If Ayam finds no information on modifications, the U curves take precedence (i.e. the V curves will be modified).

The parameters "Order_U" and "Order_V" determine the desired order of the resulting surface in u and v direction. However, depending on the number and configuration of curves used in the u or v direction, it may not be possible to create a Gordon surface of the desired order. If "Order_U" or "Order_V" are 0, a default value of 4 will be used.

See section NPatchAttrib for a description of the other two attributes "DisplayMode" and "Tolerance".

4.31 Cap Object

Cap Object (Curve, Resulting Cap Surface)

The cap object forms a surface that fills a planar NURBS curve. If multiple curves are present as child objects, the curves following the first curve define holes in the cap surface (see also section Using Holes and Bevels).

Consequently, the object hierarchy of a Cap object may look like this:


+-Cap
 | Outline(NCurve)
 | [Hole1(NCurve)]
 +-[Hole2(Level)
  | Part1(NCurve)
  \ Part2(NCurve)]

Note that the curves have to be planar and defined in the XY plane. Furthermore, cap generation may fail, if the control points of the first curve have weights and the curve leaves the convex hull of the control polygon. Be careful when using weights!

You may convert the current cap to an ordinary NURBS patch object using the main menu entry "Tools/Convert".

CapAttr Property

See section NPatchAttrib for a description of the two attributes "DisplayMode" and "Tolerance" of the "CapAttr" property.

4.32 ICurve Object

The ICurve 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.

Different ICurves

The image above shows some interpolating curves, the left ones are C2 cubic, the right ones Global4D, the upper open, and the lower closed ones. The interpolation fidelity for the closed curves could be increased considerably adjusting "IParam", see below.

In both interpolation modes chord length parameterisation will be used to determine the knot vector of the interpolating curve.

This object makes use of the provide mechanism. It marks itself as providing a NURBCurve (it creates and uses NURBS curves internally anyway) and all other objects that work with the provide mechanism (e.g. revolve, sweep, extrude, and skin) are able to work with an ICurve object instead of an object of type NURBCurve.

You may convert the current ICurve to an ordinary NURBS curve using the main menu entry "Tools/Convert".

ICurveAttr Property

4.33 ConcatNC Object

ConcatNC Object from a Linear Curve and 3 Instances (white)

The ConcatNC object concatenates all child objects (which should be NURBS curves or provide NURBS curves) to a single NURBS curve. Since the ConcatNC object also provides a NURBS curve, it is possible to use it as child object for another ConcatNC object (with possibly different parameters) or as a parameter object for a tool object that works with NURBS curves such as Revolve or Extrude.

How does the concatenation work? First, all curves will be clamped (see section clamp tool for more information on clamping). Then, the control points of all child curves are simply copied into a new big control point vector, without checking for double points. Attributes like order, display mode, tolerance etc. for the new concatenated curve are taken from the first child object. The knot sequence of the new concatenated curve will be NURBS. This means, the shape of the concatenated curve will differ from the child curves if any of the child curves has a custom knot vector with non equidistant knots.

You may convert the current ConcatNC object to an ordinary NURBS curve object using the main menu entry "Tools/Convert".

The following attributes further control the concatenation process:

ConcatNCAttr Property

4.34 ExtrNC Object

The ExtrNC object extracts a NURBS curve from a NURBS patch object, for use as parameter object for other tool objects, like e.g. Revolve.

The extraction process is controlled by the following attributes:

ExtrNCAttr Property

See section NPatchAttrib for a description of the other two attributes "DisplayMode" and "Tolerance".

4.35 Text Object

Text Object set in Verdana

Text objects may be used to easily create objects that form letters or even whole words in very high quality. For that, they parse TrueType font description files, extract the Bezier curves from the font description, sort the curves, connect them properly and finally extrude them. As with the Extrude objects, caps and bevels may be created automatically.

Parsing of TrueType font descriptions is quite tricky. For the sake of brevity and ease of the implementation, Ayam does not support elaborate TrueType features like kerning tables, that control distances between certain letters (You are not going to typeset a book with Ayam, aren't you?). Therefore you might experience wrong letter distances from time to time. If this happens, just create a Text object for each letter, and arrange the objects as you like.

The following attributes control the creation of the text objects.

TextAttr Property

See section NPatchAttrib for a description of the other two attributes "DisplayMode" and "Tolerance".

4.36 RiInc Object

RiInc objects may be used to include objects or whole scene parts into your scenes that, for some reason, are just available as a piece of RIB.

RiIncAttr Property

4.37 Script Object

Script objects are the most flexible object type of Ayam. They may be used to create new objects, modify existing objects, or realise mechanisms like constraints.

Theoretically, the scripts can use any functionality from Tcl and the Tcl scripting interface of Ayam (see also section The Tcl Scripting Interface). However, certain script object types may impose special constraints.

For security reasons, if scene files containing script objects are loaded, Ayam will raise a warning offering to disable all script objects that will be read.

The script will be run each time it is modified and each time the notification callback of the object is called (e.g. because one of the children of the script object changed). As long as the script of a script object is executed, Ayam will not process any events except for checking whether the script emergency hotkey <Ctrl+Shift+c>, that may also be used to escape from infinite loops in the Ayam console, is pressed. Calling commands and procedures that lead to the processing of events or that are slow because they manipulate or update the GUI of Ayam should be avoided. In particular, the following procedures and commands should not be used: uS, uCR, uCL, sL, selOb, plb_update, cutOb, copOb, delOb, undo.

The binary and source distributions of Ayam contain several example scripts for script objects in the "ayam/bin/scripts" and "ayam/src/scripts" directories, respectively.

The next section discusses the available script object types and additional controlling parameters.

ScriptAttr Property

4.38 Custom Objects

What is a custom object?

Think of it as a plugin that extends Ayam's capabilities by defining totally new types of e.g. geometric 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.

4.39 Metaball Object

A Metaball Object from Six Meta Components

A metaball object is a custom object (see also section Custom Object). It allows you to model with implicit surfaces in realtime.

To start modelling you should first create a "MetaObj" object using the menu entry "Create/Custom Object/MetaObj" (if this menu entry is not available, you have to load the "metaobj" plugin using the menu entry "File/Load Custom" first). "Create/Custom Object/MetaObj" creates a so called meta world with a single meta component (a sphere) in it. The meta world is represented by a "MetaObj" object and the component by a "MetaComp" object which is a child of the "MetaObj" object.

The complete template for the MetaObj object hierarchy, consequently, looks like this:


+-MetaWorld(MetaObj)
 | C1(MetaComp)
 | [...
 \ Cn(MetaComp)]

Meta components live only in a meta world, therefore it makes no sense to create "MetaComp" objects in other places except as a child of a "MetaObj" object. Type, parameters, and transformation attributes of the meta components define the function of an implicit surface. The "MetaObj" object, that represents the meta world, evaluates this function on a regular three-dimensional grid and creates a polygonal representation for a specific function value (the so called threshold value).

This process may be further parameterized using the "MetaObjAttr" property:

MetaObjAttr Property

New in Ayam 1.5 is an adaptive calculation mode of the implicit surface. It may be switched on using the new attribute "Adaptive". In the adaptive calculation mode, Ayam tries to vary the resolution of the resulting polygonal mesh according to the features of the implicit surface in order to capture fine details, even though a coarse grid is used. This is not done using a successively refined grid but by a refinement of the triangles created by the original algorithm (see also XXXX). You may control the adaptation process using three parameters: "Flatness", "Epsilon", and "StepSize". If "Adaptive" is set to "automatic", Ayam will not use the adaptive calculation while a modelling action is in progress. This mode has been introduced, because the adaptive mode may consume a considerable amount of CPU ressources.

While modelling with meta balls you may add other "MetaComp" objects to the "MetaObj" object and parameterize them. A "MetaComp" object has the following properties.

MetaCompAttr Property

The other parameter are specific to the type of the component:

Metaball

Torus

Cube

Custom


Next Previous Contents