Next Previous Contents

8. Miscellaneous

This section contains all information about Ayam not fitting into the other main sections.

8.1 The Undo System

With the help of the undo system mistakes made while modelling may be corrected.
Note, that only modifications of objects can be undone. This includes changes made by interactive modelling actions, changes made using property GUIs, but also changes to views (type changes or changes to the camera settings associated with a view, unless explicitly disabled using the view attribute "EnableUndo").
It is currently not possible to undo any changes to the object hierarchy, including clipboard (e.g. cut, paste) and drag and drop operations. If an object is deleted, it is gone! If an object is, accidentally, moved using drag and drop, undo will not help.

The undo system works by storing copies of the different states of changed objects in an undo buffer. It is possible to step backwards through the saved states using <Ctrl+z> (undo) but also forward using <Ctrl+y> (redo).

The storage space occupied by the undo buffer may be adjusted using the preferences option "Modelling/UndoLevels". A value of 0 completely disables the undo system.[∗] The value 1 means that there is always one state of the scene that can be restored, plus, a potential undo operation can also always be undone using redo.

The changes that would be undone or redone are shown in abbreviated form in the default prompt of the Ayam console and also in the main menu entries "Edit/Undo" and "Edit/Redo".[∗]

Several actions will completely clear the undo buffer (i.e. no undo is possible after one of those actions): New Scene, Open (Replace) Scene, and Close View.

Furthermore, undo/redo operations will also modify objects that reside in the object clipboard (if they have saved states in the undo buffer). This means that the following sequence of operations leads to a sphere placed at "0,0,0": 

create Sphere (at 0,0,0)
move Sphere (to 1,1,0)
cut Sphere (to clipboard)
undo
paste Sphere (from clipboard)

8.2 The Modelling Concept Tool-Objects

This section introduces the modelling concept Tool-Objects, as used in Ayam.

In a standard modelling application, to create a surface of revolution, one would either first create a curve then call the revolve tool to get an appropriate surface (losing the curve as object, or even keeping it, but without relation to the surface), or call the revolve tool first, which would then require the user to draw a curve with similar results: the created surface will typically lose the relation to the surface of revolution tool and the curve (even if kept intact) will lose the relation to the surface. There is no easy way to change parameters for the surface creation or to change the geometry of the curve later on without doing it all over again.

The modelling concept Tool-Objects overcomes these drawbacks by transforming the revolve tool into a scene object.

The following example hierarchy shows two objects in a parent-child relation: 

+-Tool_Object(Revolve)
  |         ^
  |         :
  |   <Notification>
  |         :
  \-Parameter_Object(NCurve)
The parent object is called Tool-Object and the child object is called Parameter-Object. There is a flow of information from the parameter object to the tool object. This information flow is controlled by the so called Notification mechanism. The notification mechanism makes sure that whenever the parameter objects change, the tool object is informed so that it may adapt to the changes. For interactive modelling actions, the notification will be carried out while dragging the mouse or after release of the mouse button (i.e. after the modelling action finished), depending on the main preference setting "LazyNotify".

In the example above, a NURBS curve is the parameter object and the tool object is creating a surface of revolution from the curve data. The NURBS curve and parameters of the Revolve object may change at any time. When saved to an Ayam scene file, no surface data will be written, leading to very small files that additionally contain a modelling history and capture design intent to a certain degree.

Tool objects may be parameter objects of other tool objects: 

+-Tool_Object(ExtrNP)
  +-Parameter_and_Tool_Object(Revolve)
    \-Parameter_Object(NCurve)
and there may be more than one parameter object per tool object: 
+-Tool_Object(Skin)
  |-Parameter_Object_1(NCurve)
  |-Parameter_Object_2(NCurve)
  | ...
  \-Parameter_Object_n(NCurve)

Tool objects create new geometric objects from the information delivered by the parameter object(s) or they modify the parameter object(s) and deliver them to their respective parent object.

The pure hierarchical dependency scheme may be broken up by instance objects: 

+-Tool_Object(Revolve)
  \-Parameter_Object(NCurve) --------------.
+-Tool_Object(Revolve)                     | !
  \-Parameter_Object(Instance_of_NCurve) <-'
In the scene above, the second Revolve tool object depends on the shape of the first parameter object. The Instance object transports the data from one part of the hierarchy to another. The notification mechanism is aware of this and initiates updates in the scene hierarchy wherever needed and efficiently (not updating any objects twice) according to the "CompleteNotify" main preference setting. In the example above, due to complete notification, the second Revolve object will get updated automatically whenever the original NCurve object changes.

Two other mechanisms exist, that help tool objects to get the information they need and to increase flexibility in hierarchy building and modelling: Provision and Conversion. Both mechanisms are quite similar and convert objects temporarily/transparently (provision) or finally (conversion) from one type to another, e.g. they convert an ICurve (interpolating curve) to a plain NCurve (NURBS curve).

Due to the provision mechanism, an ICurve object could be used instead of an NCurve as parameter object in all examples above easily. And with the help of the conversion mechanism, the Revolve tool objects could be converted to plain NPatch objects (e.g. for modelling operations not available to Revolve objects).

Note that instance objects are subject to a second round of provision, i.e. the master does not need to be of the wanted type but rather provide the wanted type.

Even though, theoretically, every tool could be implemented as tool object, this has not been done in Ayam (mainly, because this would unnecessarily increase the code base). Only the most often used tools that convey and capture much design intent were implemented as tool objects (those are surface or curve creating tools). But also seldom used tools can be elevated to nearly full tool object capabilities through the employment of the concept of scripting objects (see section Script Object).

This can be done easily by e.g. creating Script objects of type "Modify" that call those tools from their script (after possible conversion of the provided object(s) to a proper type, the tool may need to operate on). Even property GUIs to let the user adjust tool parameters as they know it from the other Ayam objects can be added and different tools can be combined in single objects with normal script code for unmatched flexibility. But let us see a simple example first: 

+-Skin
  +-Script
    \-ExtrNC
In the scene hierarchy above, the Script object could be simply reverting the extracted curve with code like this: 
convOb -inplace; revertC
effectively elevating the tool "revertC" to an object.

A more useful example can be found in the Marsrakete sample scene (as available from the Ayam home page). Here, a curve extracted from a patch is trimmed to the right length using a script like this: 

convOb -inplace; trimNC 0.0 0.5
. See section Script Object Example for information on how this script might be expanded to support a GUI and more error checking.

8.3 Scene File Management

This section contains exhaustive information on what exactly happens, when Ayam reads or writes a scene file.

 

Opening Scene Files

When reading a scene using "File/Open" or the MRU (most recently used) list:

  1. Ayam will first check the scene changed state of the currently loaded scene and warn the user, if the current scene contains unsaved changes,
  2. then Ayam will clear the undo buffer and the current scene (the clipboard content is not touched, except for instance objects, whose masters are cleared with the scene: those instance objects will be deleted from the clipboard),
  3. if the new file appears not to be an Ayam scene file (judged solely by the file name extension) Ayam will try to import the file using an import plugin responsible for the file (automatically loading the matching plugin if not already loaded),
  4. Ayam will change the application working directory to the directory of the scene file,
  5. now, a backup copy of the file to read will be made (depending on the preference setting "Main/BakOnReplace"), a potentially existing old backup copy will be silently overwritten, note: even if the backup fails, scene reading continues,
  6. the header of the scene file will be read to derive the scene file format version,
  7. the file will be read with all objects, *
  8. after reading of all objects, all instances will be connected to their masters using the information stored in "OI" tags; if a master can not be found in the scene, the respective instance object(s) will be removed,
  9. all objects will be connected to their materials using the information stored in "MI" tags; if no matching material can be found, the connection will not be established,
  10. a complete notification will be run,
  11. if the file contains a Root object with "SaveMainGeom" and/or "SavePaneLayout" tags, the respective window/widget geometries from the tags will be re-established,
  12. if no errors occurred during reading, the current scene name will be set to that of the file, otherwise the current scene name will be reset to "unnamed" (to avoid clobbering good scene files that failed to load for some reason with a single, maybe even unintentional, press of <Ctrl+s>),
  13. the file name will be put to the first most recently used files entry in the file menu,
  14. the scene changed state will be reset to "unchanged",
  15. if a Root object was read, a save views flag will be set, otherwise it will be cleared and following save operations will not save the root and any views (i.e. scene files without root and views stay scene files without root and views, even if new views are opened and parameterised).

* When reading objects from a file:

  1. if a view object is read, a new view window will be opened (except for the first three view objects in single window GUI mode, where only the configuration of the view objects read will be copied to the already existing view objects of the three internal views),
  2. if an object is of a currently undefined type (i.e. defined by a plugin), Ayam will derive a potential plugin name from the object type name and attempt to load the plugin, then scene reading continues,
  3. if a material object is read, Ayam will immediately register it; if this registration fails (because there is already a material with that name registered; this material can only be in the clipboard, as all other objects were deleted before opening the file), the new material object will be renamed by appending a number and the registration is attempted again, those steps will be repeated until successful (prior to version 1.21 Ayam did not attempt to rename the material and other objects were then connected to the already existing material),
  4. if loading of an object fails, Ayam skips to the next object and continues to read from the file.

 

Inserting Scene Files

In contrast to reading scenes via "File/Open" or the MRU list, reading scenes via "File/Insert" does some things differently:

  1. the current scene will not be cleared before reading the file,
  2. the current level will not be reset before reading the file; if the scene file to be inserted contains no root and no views, the new objects will be created in the current level, otherwise the objects will be created in the topmost level of the scene, which will also be the new current level in any case (after reading),
  3. no backup copy will be made of the file to be inserted,
  4. if a material is missing from the file, and a matching (by name) material exists in the scene, the objects will be connected to this material,
  5. view windows will be opened for every view object read (the internal views will not be changed),
  6. the current directory will only be changed during the file read operation,
  7. the current file name will not be changed,
  8. the scene changed state will be set to "changed",
  9. the save views flag will not be changed, this means that inserting a scene file without root and views into an empty scene (e.g. directly after application startup or after "File/New") and then saving the scene, will enrich this scene file with root and views (in contrast to loading this scene via "File/Open").

 

Saving Scene Files

When saving a scene using "File/Save":

  1. Ayam will first check the current scene file name, if the name is "unnamed", a new file name will be requested,
  2. if the file to save to appears not to be an Ayam scene file (judged solely by the file name extension) Ayam will try to export the current scene using an export plugin responsible for the file type instead of saving to an Ayam scene file (automatically loading the matching plugin if not already loaded),
  3. the geometry of the main window and internal widgets is saved to "SaveMainGeom" and/or "SavePaneLayout" tags (if present in the Root object),
  4. "OI" tags and "MI" tags will be created to allow instances to be connected to their respective masters and objects to their materials, when reading the scene file again,
  5. then, all objects from the scene will be saved to the file; if the save views flag was cleared while reading the previous scene file, root and views will be omitted (i.e. scene files without root and views stay scene files without root and views, even if new views were opened and parameterised while the scene was loaded),
  6. if no errors occurred during writing of the scene file, the file name will be put to the first most recently used files entry in the file menu, and the scene changed state will be set to "unchanged",
  7. if errors occurred, the current scene changed state will be kept.

8.4 Ayamrc File

To customize Ayam beyond the capabilities of the preferences dialog, the ayamrc file may be used. This file is either pointed to by the environment variable AYAMRC or is determined as following:

The ayamrc file is read on each start of Ayam and saved again on exit (if the preference setting "Main/AutoSavePrefs" is enabled).

The ayamrc file contains:

  1. preference settings (including some hidden settings that require just occasional tweaking and are not reachable using the GUI preference editor),
  2. position and size of the main window and the toolbox window,
  3. position and size of various dialog windows (if the preference setting "SaveDialogGeom" is set accordingly),
  4. keyboard shortcuts to menu entries and modelling actions,
  5. RiOption and RiAttribute databases.

You may edit the file with any text editor (while Ayam is not running), but keep in mind, that the file will be parsed by Tcl. Should you, for some reason, destroy your ayamrc file so that Ayam does not start correctly anymore you can always start Ayam with the command line option "-failsafe". When the application is left the next time, or the main menu entry "File/Save Prefs" is invoked, a correct ayamrc file will be created again. All preference settings will be reset to factory defaults and all your edits of the ayamrc file will be lost, however.

Another way to reset the ayamrc file is to simply delete the file manually or using the main menu entry "Special/Reset Preferences".

To reset single elements to factory defaults, just remove the corresponding lines from the ayamrc file.

Finally, resetting single preference settings without a text editor is also possible with the help of the scripting interface by manipulating the global "ayprefs" array. The following example leads to a reset of the tolerance preference setting to its factory default for the next start of Ayam.

» unset ayprefs(Tolerance)
After unsetting single elements of the preferences array, Ayam should be restarted.

 

Changing Keyboard Shortcuts

You may adapt the keyboard shortcuts used in the GUI to your special needs using the ayamrc file. Note that if you do that, the GUI (the menu entries and the "Show Shortcuts" window) will adapt to your changes but certainly neither this documentation, nor the reference card (unless recreated using the script "refcard.tcl"), nor the tutorials.

Ayam does not check for clashes in key bindings. This means, the last set binding for a key will be used.

On Unix, the output of the program "xev" and the manual page for the "bind" command of Tk provide helpful information about which strings may be used to describe key presses. You can also directly use the Ayam console to infer key names, just enter:

» toplevel .keytest; bind .keytest <Key> {puts %K}
into the Ayam console. Now you can activate the new top level window and type on your keyboard while the Ayam console prints the names of the keys.

For convenience, the special string "Ctrl" will be replaced by "Control" before a shortcut is handed to the bind command.

Example: 

set aymainshortcuts(Prefs) {Ctrl-p}
sets the keyboard shortcut for opening of the preferences editor to <Ctrl+p>. See the ayamrc file itself for a complete listing of available shortcuts.

 

Hidden Preference Settings

The ayamrc file currently contains the following adjustable hidden preference settings:

 

RiOption and RiAttributes Database

With the ayamrc file, also the database of RiOptions and RiAttributes may be adapted to the current target RenderMan rendering system.

Renderer specific options and attributes can then be added to the scenes using tags and the main menu entries "Special/Tags/Add RiOption" and "Special/Tags/Add RiAttribute", see also sections RiAttribute Tag and RiOption Tag.

The syntax for a new RiOption is quite simple as the following example shows: 

set riopt(runtime) {
 { verbosity s { "silent" "normal" "stats" "debug" } }
}
This snippet sets the section "runtime" and adds a single option, "verbosity", to it. The option is declared to be of type string using "s" and provided with a list of default values: "{ "silent" "normal" "stats" "debug" }".

To add another option to this section, say the option "op" which shall be an integer value, the aforementioned snippet needs to be changed to: 

set riopt(runtime) {
 { verbosity s { "silent" "normal" "stats" "debug"} }
 { op i }
}
As you can see, it is not mandatory to provide default values. Be sure to correctly close all the curly braces, otherwise the next start of Ayam may fail.

Available types of parameters are:

8.5 Command Line Arguments

This section documents the command line arguments supported by Ayam.

Command line arguments that follow any of these options are considered to be file names of Ayam scene files. All these scene files will be loaded upon application start.
If multiple scene file arguments are specified, the second up until the last scene files will be inserted into the scene from the first argument, i.e. different argument orders lead to different resulting scene hierarchies. See also sections Scene File Management and File Menu.

8.6 Environment Variables

This section documents the environment variables used by Ayam.

8.7 Plugins Overview

This section serves as a overview of the various plugins available in Ayam.

There are currently five major types of plugins for Ayam:

shader parsing plugins

aysdr, ayslb, ayslc, ayslo, ayslo3d, ayslx, ayso.

See also section Shader Parsing Plugins.

custom objects

metaobj, sdnpatch, sfcurve, sdcurve, bcurve, csphere.

See also section Custom Objects.

import/export plugins

dxfio, mfio, mopsi, objio, onio, rrib, x3dio.

See also section Import and Export.

scripting language plugins

modelling helper plugins

Furthermore, the Ayam distribution contains two plugins that are destined to be loaded by the respective RenderMan renderer and drive the Viewport rendering mode: fifodspy and pixiefifodspy.

See also sections RIB-Export Preferences and Viewport Rendering.

8.8 Shader Parsing Plugins

The following plugins are provided to allow parsing of compiled shaders:[∗] "ayslb" for Air, "ayslx" for Aqsis, "ayso" for RDC, "ayslo" for PRMan, "ayslo3d" for 3Delight, "aysdr" for Pixie[∗] , and "aygso" for Gelato[∗].

After loading of one of the aforementioned plugins, Ayam will be able to parse shaders compiled with the shader compiler of the respective renderer.

There can only be one active shader parsing plugin. You can not first load ayslb and then ayslx and expect Ayam to parse slb and slx shaders.

A shader parsing plugin may be loaded automatically on startup of Ayam using one of the provided Tcl scripts: "loadayslb.tcl", "loadayslo.tcl", "loadayslo3d.tcl", "loadayslx.tcl", "loadayso.tcl", "loadaysdr.tcl", and "loadaygso.tcl". To automatically load a plugin simply add the appropriate script to the preference setting "Main/Scripts" using the "Add" button in the preferences editor.

Additionally, those scripts may be further adapted to set a different "Shaders" preference setting or to immediately scan for shaders after loading of the plugin. For that, just remove the leading hash-marks (#) from the corresponding lines in the script. Note that changing the scripts for immediate shader parsing is not necessary if the shader parsing plugin is loaded automatically on startup of Ayam, as the loading of the scripts (and therefore also of the plugin) will happen before the Ayam startup sequence executes the initial shader scanning pass. The shader search path used for the initial shader scanning pass is taken from the "Shaders" preference setting.

If a shader parsing plugin is loaded manually or via unchanged load script, the shaders search path must be adapted manually. Furthermore a shader scan must be initiated manually too. Both actions may be carried out using the preferences editor. Scanning for shaders may also be started using the main menu: "Special/Scan Shaders".

To better accommodate the fast changing world of RenderMan renderers, since Ayam 1.11 all shader parsing plugins are Ayam version independent (but still renderer version dependent and Tcl version dependent). This allows to distribute updated shader parsing plugins without updating Ayam too and thus in a higher frequency. Furthermore, compiling a shader parsing plugin is now much easier.

For shader parsing without plugins, see also section Shader Parsing.

8.9 Viewport Rendering

Viewport Rendering Example

The viewport rendering mode allows to display an image in a view window while it is being rendered for preview purposes, see also the image above.

After the renderer finished, the image can be zoomed and panned using the mouse wheel and the rightmost mouse button respectively.

Hitting the <Esc> key removes the rendered image and restores the normal view display.

To make this work, the RenderMan renderer must load a special plugin (also called display driver) that is distributed with Ayam.

There are actually two of these plugins provided: fifodspy for standard RenderMan renderers and pixiefifodspy for Pixie (to cater for its non-standard display driver interface). The correct plugin must be set in the corresponding "DisplayDriver" preference option, see also section RIB-Export preferences. See also hidden preference option DisplayPath.

The machine type (32 or 64 bit) of the concrete plugin used must match that of the renderer and may in fact be different from that of Ayam as one can use a 32 bit renderer from a 64 bit Ayam and vice versa.

The image data is send via a named pipe (FIFO), which can be seen as a special type of file, that can be written and read by two processes simultaneously.

Here is what is going on under the hood:

  1. Ayam will write a RIB that instructs the renderer to use the fifodspy display driver,
  2. Ayam will start the renderer on this RIB and wait for the FIFO to appear,
  3. the renderer reads the RIB and searches for the display driver plugin and loads it,
  4. the initialization of the display driver will create the FIFO whose existence instructs Ayam to fully install the viewport rendering machinery, that continuously monitors the FIFO for new image data,
  5. whenever a part of the image (scanline or bucket) is computed, it will be sent via the FIFO from the renderer to Ayam which immediately displays it in the view window,
  6. upon completion, a special message is sent that disables the monitoring and the FIFO will be removed.

If step 3 fails, i.e. the renderer does not find or can not load the display driver, after 5s Ayam will complain about this and offer to either keep on waiting or to cancel the rendering.

8.10 Automatic Instancing

Automatic Instancing Dialog

Automatic Instancing is available via the main menu entry: "Special/Instances/Automatic Instancing". When this menu entry is selected a small parameter dialog will appear, see also the image above.

Automatic Instancing creates instances from all instantiable objects using a simple algorithm that recursively compares objects (see also section Instance object). Two objects are considered to be instantiable when all their attributes, except for the transformation attributes, are the same. The comparison of materials and tags may be turned off. Also the scope of the automatic instantiation can be set to the selected objects, the current level, or all objects in the scene (regardless of current level and selection).[∗]

The instancing algorithm is able to create instances of grouping objects too (objects with child objects, e.g. levels or tool-objects like revolve). However, in order for two grouping objects to be instantiated not only all child objects and the grouping objects have to be instantiable, but the child objects also have to be in the right order. It is not sufficient, that for every child of the potential master, a matching child of the potential instance exists. Instantiation of grouping objects may drastically decrease the total number of objects in a scene.

Note that before the automatic instantiation starts, all currently existing instances will be resolved.
After instantiation some statistics will be displayed in the console.

More information about this subject can be found in:

Schultz, R., and Schumann, H.: "Automatic Instancing of Hierarchically Organized Objects", in: Kunii T.L. (ed.): Spring Conference on Computer Graphics (SCCG 2001) Conference Proceedings, Budmerice, Slovakia, 25-28 April 2001, ISBN 80-223-1606-7

8.11 Importance Driven Rendering (IDR)

The importance driven rendering plugin may be used to drastically reduce rendering times while developing a scene. It works in three main steps:

  1. Importance values are assigned to elements of the scene.
  2. Two rendering passes are started according to the assigned importance values. Elements of different importance values are mutually masked out using "RiMatte" statements.
  3. The resulting partial images are composed to a single resulting image, which is then displayed.
The parameterisation of the two rendering passes ensures, that the total rendering time is lower than the rendering time of a single pass with high quality.

Many options exist to assign importance and parameterise the rendering passes:

Elements of the scenes may be geometric objects, regions in image space, or regions in object space. Importance values are currently just binary values. Assignment may take place manually (using IDR tags) or half-automatic by derivation of importance from currently selected or changed objects. To avoid inconsistency in the resulting images, importance values may be propagated between (geometrically or hierarchically) near objects, or between objects that are related (e.g. from a material to a geometric object).

Parameterisation of the two rendering passes currently includes selection of a different renderer and the possibility to reduce rendering resolution and shading rate. To further reduce rendering times for raytracing renderers, the size of the region to render may be automatically adapted to the elements of the current importance value (including an optimisation run that balances renderer startup times and times needed to render regions not originally occupied by two regions to merge).

Furthermore, caching of partial images is possible. However, the implementation of this feature is not very sophisticated at the moment, as it uses the Unix text tool "diff" to decide whether two RIB streams are identical and hence need no re-rendering.

To start using IDR:

  1. load a scene (e.g. the cactus example scene),
  2. load the IDR plugin (menu "File/Load Plugin"),
  3. open the IDR control window using the main menu "Custom/Open IDR",
  4. set the assign mode to "Selection",
  5. select an object in the scene (e.g. the object named "Pot"),
  6. then press the "Render!" button.
Compare the rendering time with a full render from the view window.

IDR requires that at least the renderer of the second rendering pass honours RiMatte. Since rgl does not honour RiMatte, it is sometimes necessary to simply exclude objects of different importance value. No wrong images are to be expected from this, as rgl does not calculate other than local lighting effects.

More information about this subject can be found in:

Schultz, R., and Schumann, H.: "Importance Driven Rendering - Using Importance Information in the Rendering Process", in: Hamza M., Sarfraz M. (ed.): Computer Graphics and Imaging (CGIM 2001) Conference Proceedings, Honolulu, Hawaii, 13-16 August 2001, ISBN 0-88986-303-2

8.12 CSG preview using the AyCSG plugin

CSG preview example (left without, right with CSG)

The AyCSG plugin may be used to resolve and preview CSG operations. For this, the plugin uses image based CSG rendering algorithms provided by the OpenCSG library by Florian Kirsch. The OpenCSG library, currently, supports the Goldfeather and the SCS algorithm. The latter only works properly with convex primitives. Since both, Goldfeather and SCS, are image based rendering algorithms, there is no limit in geometric object types that may be used in CSG hierarchies. You may e.g. use Quadrics, NURBS, and Metaballs in every possible combination. You just have to make sure, that every CSG primitive describes a closed space.

In order for the CSG rendering algorithms to work properly, the depth complexity (convexity) of a primitive must be known. The depth complexity of a primitive determines the maximum number of forward oriented surfaces any ray through this primitive would pass. A regular sphere has a depth complexity of 1, a torus of 2, but do not confuse depth complexity with genus, they are different values. A 3D representation of the letter A e.g. has a genus of 1 but a depth complexity of 3. The depth complexity of a primitive can be stored in a "DC" tag. A torus would e.g. get a tag named "DC" with the value "2". If no "DC" tag is present for a primitive, a default value for the depth complexity of "1" will be used. If the depth complexity is not specified correctly, rendering errors, like missing parts of surfaces, will occur.

Note that the correct operation of AyCSG not only depends on the depth complexity but also the winding order of the OpenGL primitives (triangles or quads) used for drawing of the CSG primitives. The winding order has to be consistent in a scene, so that the rendering algorithm can decide what is inside and what is outside by looking at a single OpenGL primitive. For all quadric primitives of Ayam the winding order is always consistent. However, for NURBS patches the winding order depends on the orientation of the patch dimensions. If NURBS patches are used in CSG operations one, consequently, may need to revert the patches (e.g. using the "RevertU" tool, see Revert U tool). If the winding order of some of the primitives in a CSG hierarchy is not right, the respective primitives will not be effective in the CSG operations to the extent that the rendered image becomes completely empty.

The AyCSG rendering obeys the "Draw Selection only" and "Draw Level only" view options as well as the hide attribute of objects. If the CSG rendering fails for complete complex scenes, you might still get a preview of the important CSG using objects by selecting them and enabling the "Draw Selection only" view option.

Also note that CSG rendering requires fast graphics hardware (the more fillrate, the better). Furthermore, your OpenGL subsystem has to support the PBuffers extension and, depending on the rendering options chosen, a stencil buffer. Speedups may be achieved using the "GL_ARB_occlusion_query" or "GL_NV_occlusion_query" extensions (if available to you).

Once the AyCSG plugin is loaded successfully you can render the CSG preview in any view window using the keyboard shortcut <Ctrl+C> or using the new button in the menu bar of every view window (see image below). If you hold down <Shift> while pressing the button the view will start to continually render CSG (the button stays pressed to signify this) until you click onto the button again.

View With AyCSG Icon

The AyCSG plugin supports the following options, that are available through the main menu entry "Custom/AyCSG Preferences":

The following table shows an overview of the available options their restrictions and implied requirements.

AlgorithmDCSamplingConcave PrimitivesDC Tags neededRequirements
GoldfeatherOcclusionQueryYesNoocclusion query extension
GoldfeatherDCSamplingYesNostencil buffer
GoldfeatherNoDCSamplingYesYesNone
AutomaticNoDCSamplingYesYesNone
SCSNoDCSamplingNoNoNone
SCSOcclusionQueryNoNoNone
SCSDCSamplingNoNostencil buffer

AyCSG Options Overview

The default settings are to use the Goldfeather algorithm with occlusion queries, as this combination allows complex CSG hierarchies, has widespread hardware support, requires no exotic view argument modifications, and also no DC tags.[∗]

See also: Kirsch F. and Doellner J.: "Rendering Techniques for Hardware-Accelerated Image-Based CSG", in: Skala V. (ed.): Journal of WSCG'04, 221-228, ISSN 1213-6972

8.13 Increasing Drawing Speed

In case of sluggish response of the user interface of Ayam (not accounting for long tree update operations) several things to increase drawing speed can be done:

8.14 Modelling Without Views

To work with very large/complex scenes, it may be necessary to turn off all views. In Ayam this can be done in the multi window GUI mode (see section GUI preference settings). If there are many objects, it is also advisable to switch the object selection widget from tree view mode to list box mode (menu: "Special/Toggle TreeView").

Modelling without views does not work on Apple Mac OS X Aqua if GLU functionality is involved (as every GLU functionality on Mac OS X needs a GL context). GLU is needed for the PolyMesh and NURBS tesselation.

8.15 Restrictions and Implementation Deficiencies

Due to the way Ayam is implemented, several restrictions and deficiencies exist:

Ayam user interface deficiencies:

8.16 How to Join the Fun

Helping to make Ayam even better will spice up your life too. Here is how to do it:

  1. Write/translate tutorials.
  2. Translate some balloon help texts. Create a new translation script file by entering into the Ayam console
    » ms_create lang
    (replacing lang with a two character language designation like it for italian). Now edit/translate the new script file. Test it out by adding it to the "Scripts" preference setting.
  3. Create and submit example objects, scenes, and images.
  4. Implement custom objects like trees, landscape, sky, XSplines, T-Splines, or whatever you can think of. Note that the license of Ayam does not prevent you from implementing your custom object as shareware or even commercial software. However, free software is preferred for obvious reasons.
  5. Donate source to improve several critical parts of the modeler, some ideas are: better (more exact) lighting simulation (is this possible to do with OpenGL at all?), transformation widgets, true support for subdivision surfaces, lift some deficiencies (see above), import/export plugins. The project page of Ayam on SourceForge lists some more tasks and you are always welcome to discuss such matters in the public forum.

Please do not implement custom objects like simple triangles or polygons. This would be something that really is not intended by the Ayam Team, and it would surely show the limits of the current design of all code operating on the scene structure.

Ayam objects should be high-level objects!

Reading the last paragraph you might think that we are a bit biased against polygonal models. We are not. Polygonal models are the only way to preview complex geometry using hardware accelerated graphics, for the moment. But even while RenderMan supports rendering of polygonal models, their use as a primitive is not recommended for good reasons. In other words, use polygonal models in the modeler as quick representation of your higher level objects, but please, if you are going to actually render something, do not use that polygonal representation. If you want to go a complete polygonal way instead, voila, there are good modelers out there.

8.17 References

Suggested reading:

WWW resources related to Ayam:

WWW resources related to RenderMan:

8.18 Acknowledgements

First of all, I would like to express a big "Thank you!" to Bernd (Pink) Sieker. He is the first real Mops user and beta tester, who urged me during the last years via E-Mail and on IRC to fix this particular bug, add some essential features, move the lights again etc. pp. in countless iterations. Bernd, without your help I surely would not be that far, thanks!

Furthermore, I would like to thank the following people:

8.19 Trademarks

OpenGL (R) is a registered trademark of Silicon Graphics, Inc.

The RenderMan (R) Interface Procedures and Protocol are: Copyright 1988, 1989, 2000 Pixar All Rights Reserved

RenderMan (R) is a registered trademark of Pixar

The Affine Libraries and Tools are Copyright (c) 1995, 1996, 1997, 1998 Thomas E. Burge All rights reserved.

Affine (R) is a registered trademark of Thomas E. Burge.

TIFF Software is Copyright (c) 1988-1997 Sam Leffler Copyright (c) 1991-1997 Silicon Graphics, Inc.

Dime is Copyright (c) 1998-1999 Systems In Motion, SA All rights reserved.

AutoCAD (R) is a registered trademark of Autodesk, Inc.

DXF (R) is a registered trademark of Autodesk, Inc.

Next Previous Contents