Advanced Interactive Rendering (A.I.R.) Routines


Define_System_Options

Insert_Area_Light

Set_Color

Set_Driver_Options

Set_Rendering_Options

Set_Visibility

Show_Area_Light


HOOPS A.I.R. (Advanced Interactive Rendering) is an optional package providing photo-realistic rendering capabilities to HOOPS scenes. A.I.R. includes high quality "radiosity", and "ray-tracing" solutions; or combinations of these methods. Through HOOPS A.I.R. you can automatically generate shadows, surface transparency, mirror reflections, and other lighting effects for your HOOPS scenes.

As constructed at Autodesk, there are two different compiled versions of HOOPS

1. HOOPS Classic

2. HOOPS A.I.R.

With the HOOPS Classic version, I.M. and Kanji functionality can be unlocked by using an Autodesk OEM Sales supplied key. Likewise I.M. and Kanji functionality can be unlocked using the key and HOOPS A.I.R version. A.I.R. functionality is also unlocked using a key. Naturally, A.I.R. functionality cannot be unlocked with HOOPS Classic regardless of the key used.

------------------------------------------------------------
          Classic       I.M.         A.I.R.         Kanji     
------------------------------------------------------------
HOOPS    available  requires key                requires key  
Classic                                                       
HOOPS    available  requires key  requires key  requires key  
A.I.R                                                         
------------------------------------------------------------

Define_System_Options

PURPOSE

Define_System_Options is part of the classic HOOPS product---HOOPS A.I.R. relies on being activated with the license option.

CALLING SEQUENCE

Define_System_Options (list)

-----------------------------------------------------------------------------
list    string   A quoted string or a string variable containing a list of the   
                 desired option settings.                                        
-----------------------------------------------------------------------------

DETAILS

"System options" are a group of status settings that don't have anything directly to do with graphics. They control how the system reacts to some error and debugging situations. "System options" are defined system-wide; they are not a part of the graphics segment tree.

license = (customer = customer, product = (AIR [, IM] [, Kanji]), key = key)

The license system option is used to enable one or more optional HOOPS products. The license option requires a numeric key obtained from Autodesk OEM Sales. As one would expect, an application cannot activate an optional product for which it is not entitled. However, it is not required that an application activate ALL of the optional products for which it is entitled. In other words, using a supplied numeric key, only the products requested in the product list are activated. For programming convenience, the license option can be specified by the HOOPS_LICENSE environment variable; however, for shipping applications, a programmatic call to Define_System_Options is desirable.

NOTES

For HOOPS A.I.R., there is a special system option to enable the Advanced Interactive Rendering functionality. Enabling the optional HOOPS A.I.R. product requires a licensing agreement with Autodesk OEM Sales. For example,

Define_System_Options("license = (customer = ABC, product = AIR, key = 1E345)");

To obtain a company specific key to enable HOOPS A.I.R. functionality, please contact Autodesk OEM Sales Technical Support. Chapter 3 of the HOOPS Installation Guide identifies various methods of contact.

SEE ALSO

Define_Callback_Name, HIC_routines, Set_Callback.

Back


Insert_Area_Light

PURPOSE

Inserts a flat, infinitely thin, polygonal source of light into your scene (requires A.I.R.).

CALLING SEQUENCE

Insert_Area_Light (count, points, list)

-----------------------------------------------------------------------------------
count     integer        Number of valid points in points.                             
points    point vector   Vector of x-y-z triplets for the coordinates along the edge   
                         of the area light. (A simple N ¥ 3 array may also be used.    
                         Fortran callers should reverse the subscripts.) Passed by     
                         reference always.                                             
list      string         A quoted string or a string variable containing a list of     
                         desired options for this specific light.                      
-----------------------------------------------------------------------------------

VARIANTS

KInsert_Area_Light (count, points, list), returns key

QInsert_Area_Light (segment, count, points, list)

QKInsert_Area_Light (segment, count, points, list), returns key

------------------------------------------------------------------------------------
count      integer        As above.                                                     
points     point vector   As above.                                                     
list       string         As above.                                                     
key        HC_KEY         Unique numeric identifier for this particular area light.     
                          Returned to caller.                                           
segment    string         Segment(s) to be inserted into, if other than the currently   
                          open segment.                                                 
------------------------------------------------------------------------------------

DETAILS

Normally, when you set the color of a surface (a polygon, mesh, or shell face), HOOPS draws the surface in the specified color. When HOOPS sees that a window is going to have one or more lights in it, it switches gears and performs what is known as a "lighting calculation". The lighting calculation consists of taking the color and orientation of each face, and the color and orientation of each light, and figuring out what color the face would appear to be at your camera's viewpoint in the "real world".

In HOOPS there are five possible sources of light. These are the sources:

  • The scene's ambient light intensity defined by Set_Color.

  • Individual distant (point) lights created by Insert_Distant_Light.

  • Individual local (point) lights created by Insert_Local_Light.

  • Individual directional local (point) lights created by Insert_Spot_Light.

  • Emissive surfaces created by Insert_Area_Light.

    An area light is similar to a HOOPS polygon that emits light into the environment. Area lights are the most realistic type of light in HOOPS since all "real-world" light sources have a nonzero surface area. In fact, an area light is the only type of light source that can be "seen" when looked at---unlike point style lights, which illuminate surfaces, but are otherwise invisible to the camera (they are an infinitely small point).

    Currently, area light sources can only be simulated via extensive "radiosity" calculations (see Set_Rendering_Options). When using nonradiosity rendering methods, the illumination effects of area lights are simulated internally by (much) less accurate "spotlights". When viewed directly, a nonradiosity renderer will draw area light sources as simple polygons.

    The scope of a light is always its containing window; even if the light is many levels down from the window in the segment tree, it still "shines light" on everything in the scene---i.e., everything in the window (except as noted below, under "light visibility"). In fact, if you want to have several lights of different colors you'll have to put them in different lower-level segments in order to set the different color attributes. You might also want to put a light in its own subsegment so that you can use Rotate_Object on it in order to make the light orbit around your scene.

    The options you provide in the string list specify characteristics for one specific light; they are not inherited like normal attributes. The following choices for list are recognized:

    bright side = side

    An area light is a surface that has two sides. The "bright side" option lets you specify which of the two sides should emit light. Side can be any of the following:

    front---Light is emitted only from the "front" side of the area light (the default).

    back---Light is emitted only from the "back" side of the area light.

    both---Light is emitted from both sides of the area light.

    The "front" side of an area light is defined by the handedness of the world coordinate system (see Set_Handedness). When the coordinate system is right handed (the default), think of wrapping the fingers of your right hand around the area light in the order the vertices were originally defined---your thumb will then point away from the "front" side of the light. When the world coordinate system is left handed, you would curl the fingers of your left hand instead.

    NOTES

    Area lights, just like polygons, can be selected with the mouse. All other types of lights (point sources) are not directly visible, and therefore not selectable.

    It does not make sense to use the "quick moves" heuristic with area lights since even though the area light could be drawn in "quick moves", the rest of the scene will need to be redrawn whenever a light changes position.

    The intensity received by a surface from an area light (when using the radiosity method) follows an inverse-square law. Essentially this means that an area light's intensity decreases with distance from the source. This can lead to scenes that have an extremely large range of intensities to be displayed. See the "brightness" and "contrast" radiosity options of Set_Rendering_Options for a way of brightening up dark areas caused by this effect.

    If the light is shining on one side of a given face and you're looking at the other side, the side you're looking at is in the shadow of the face and is not lit by the light. Beyond this effect, shadows are not computed by the standard shaders ("no lighting interpolation", Gouraud, and Phong). If you request shadows in your scene via advanced radiosity computations (see Set_Rendering_Options), shadows generated from a specific light can be turned off with Set_Visibility(shadows = no emitting").

    The number of lights you can have in a scene is almost unlimited. Since the screen isn't able to keep getting brighter and brighter as additional lights are inserted, HOOPS scales the total brightness by the total brightness of all the light sources. See the "light scaling" Driver Option for a means of overriding this calculation.

    The "fixed colors" Driver Option may also be of interest to you when using lights.

    In the current implementation, lights only affect faces---lines and edges are drawn in the standard way, with static colors. (Warning: This might change in a future release.)

    Turning off the visibility of a light makes that light cease to exist for purposes of whether or not, or how to perform, a lighting calculation. This may be a convenient way to enter and leave "lighted" mode in your program.

    Turning off the light visibility also keeps a light placed elsewhere in the segment tree (but within the same window) from shining through onto the local geometry. This can be useful for inserting things that don't need to be or shouldn't be lighted, such as annotations, into a lighted window.

    Of the five types of possible light sources listed above, an ambient light is not sufficient to trigger the HOOPS "lighted" mode. If, for some reason, you only want to display the effect of the ambient light, and you need to trigger the system to go into "lighted" mode, just insert a distant light that happens to be black.

    If there is an error the KInsert and QKInsert routines will return a -1.

    SEE ALSO

    Insert_Local_Light, Insert_Distant_Light, Insert_Spot_Light, Set_Rendering_Options, Set_Color, Set_Visibility, Set_Driver_Options, Rotate_Object, Rotate_Object_Offaxis, Renumber_Key.

    Back


    Set_Color

    PURPOSE

    Set_Color is part of the classic HOOPS product---HOOPS A.I.R. provides the additional capabilities described here, including mirror surface properties.

    CALLING SEQUENCE

    Set_Color (color-spec)

    --------------------------------------------------------------------------------
    color-spec    string   A specification for the desired color setting (see details   
                           below).                                                      
    --------------------------------------------------------------------------------
    

    VARIANTS

    UnSet_Color ()

    UnSet_One_Color (which)

    QSet_Color (segment, color-spec)

    QUnSet_Color (segment)

    QUnSet_One_Color (segment, which)

    -----------------------------------------------------------
    segment       string   Name of the segment(s) to be changed.   
    color-spec    string   As above.                               
    which         string   A specific color type to be unset.      
    -----------------------------------------------------------
    

    DETAILS

    Normally only a single color is needed to describe geometry---as in

    		Set_Color("faces=red")
    If lights are present in a scene, however, HOOPS computes the appearance of faces based on the interaction of light with the surface material as viewed by the camera. Since a single color does not fully describe a material's reflecting properties, Set_Color allows faces to have more complicated definitions---as in
    		Set_Color("faces = (diffuse=red,specular=white)").

    The computed appearance of a surface in lighting mode is the sum of independent components: an ambient reflection, a diffuse reflection, a specular reflection, a mirror reflection, and light transmission through the surface. A material is defined by how it affects each of these components. For a mathematical specification of HOOPS lighting see the "technology" section of Set_Rendering_Options.

    Face materials are defined by a comma separated list of properties surrounded by parentheses, as in

    		Set_Color("faces= (property = value, property = value, ...) ").

    When describing a material the following face properties are recognized:

    mirror = color

    The mirror reflectance color of the surface. Whereas a specular reflection considers only direct reflections from point sources of light, a mirror reflection considers indirect reflections. This includes light that would require more than one bounce to reach the camera, as well as reflected images of neighboring surfaces.

    Note that computation of indirect mirror reflections requires an advanced algorithm such as "ray-tracing" (see Set_Rendering_Options). The "standard" rendering method does not calculate mirror reflections. Also note that mirror reflections are perfectly focused (no scattering), and do not depend on the gloss term.

    Most surfaces have mirror and specular colors of the same hue, but not necessarily the same intensity. Highly mirror-like or specular surfaces generally have dim diffuse colors (if any).

    transmission = color

    The surface transparency color. "Surface transparency" refers to passing light through a 2D surface. Future versions of HOOPS A.I.R. might also support an independent "volume transparency" attribute.

    "Faces = (transmission=black)" describes a perfectly opaque surface, "faces = (transmission=white)" describes a perfectly clear material, while "faces= (transmission=green)" describes a surface that is opaque to red and blue, but transparent to green. Note that making surfaces transparent can slow the rendering process, especially when ray-tracing.

    The "standard" rendering method approximates surface transparency with an accuracy that is hardware dependent. Some display devices have hardware to accelerate drawing of transparent surfaces, but allow only a degree of transparency rather than a color (in which case the intensity of color is used, but hue and saturation are ignored). For accurate computation of surface transparency (regardless of the hardware being used), an advanced algorithm such as "ray-tracing" is required.

    Normally, as you increase a material's surface transparency you also lower its diffuse color.

    index of refraction = value

    The degree to which light "bends" its path when entering (or exiting) a transparent material. Useful values range from 1.0 (no bending of light) to 2.0, although any positive value is legal. Normal glass has an index of refraction of 1.5, and water of 1.33.

    Only the "technology = ray-trace" rendering method computes the effects of refraction. All other rendering technologies will ignore "index of refraction".

    The default is "faces = (diffuse= mirror= transmission= black, specular= white, gloss= 5.0, index of refraction = 1.0)".

    All other Set_Color options are fully described in the "Attributes" chapter of the HOOPS Reference Manual.

    NOTES

    Each of the face material components (diffuse, specular, gloss, etc.) inherits separately. It is therefore possible to change the specular color, for example, without modifying the other surface properties.

    Since the illumination of a surface is the combination of several components (diffuse reflection, specular reflection, etc.), it is possible for a surface to be brighter than can be displayed---HOOPS "clamps" such colors to the legal maximum. To minimize the amount of color clamping, surfaces should not be highly reflective in several components at once.

    SEE ALSO

    Set_Color_By_Value, Set_Color_By_Index, Set_Color_Map, Define_Color_Name, Set_Rendering_Options, Insert_Distant_Light, Open_Face, Open_Edge, Open_Vertex.

    Back


    Set_Driver_Options

    PURPOSE

    Provides information to the system about a variety of special device-specific display options. Set_Driver_Options is part of the basic HOOPS product---HOOPS A.I.R. provides the additional capabilities described here.

    CALLING SEQUENCE

    Set_Driver_Options (list)

    -----------------------------------------------------------------------------
    list    string   A quoted string or a string variable containing a list of the   
                     desired option settings.                                        
    -----------------------------------------------------------------------------
    

    VARIANTS

    QSet_Driver_Options (segment, list)

    UnSet_Driver_Options ()

    UnSet_One_Driver_Option (which)

    QUnSet_Driver_Options (segment)

    QUnSet_One_Driver_Option (segment, which)

    ----------------------------------------------------------
    segment    string   Name of the segment(s) to be changed.     
    list       string   As above.                                 
    which      string   A particular driver option to be unset.   
    ----------------------------------------------------------
    

    DETAILS

    The Set_Driver_Options routine is part of the basic HOOPS package; adding the optional HOOPS A.I.R. package provides this additional feature:

    [no] update interrupts [= on/off/unrestricted]

    An update-in-progress will normally, on most systems, interrupt itself and check for enabled user input occasionally during the update. If "significant" input is available (defined as a mouse click or a keyboard button click), the update will be put aside and control will return to the user program.

    In the current implementation, windows that are interrupted during display are fully redrawn in the next update---even if the database changes you make in the interrupt do not affect the interrupted window.

    Turning off update interrupts can be useful (and might be required) during debugging, or when using "*" or "O" selectability. Since the "*" and "O" selectabilities can generate mouse events at a rapid rate, HOOPS might not get a chance to draw a window (due to interruptions) until the mouse comes to rest. When dragging objects it might be advantageous to momentarily disable update interrupts.

    In addition to the usual "on" and "off", the "unrestricted" qualifier is provided for radiosity solutions (see Set_Rendering_Options). "Update interrupts = on" means that HOOPS will not interrupt a radiosity solution until a computation step has completed. The possibly dangerous "unrestricted" option allows HOOPS to interrupt a radiosity solution in the middle of a solution step---causing the entire solution to be reset to 0 percent convergence.

    "Unrestricted" is equivalent to the "on" setting when not performing a radiosity solution.

    An explicit call to Update_Display cannot be interrupted---only routines that rely on Await_Event (such as Pause, Get_Selection, etc.) may be interrupted. The default is "update interrupts".

    All other driver options are fully described in the "Attributes" chapter of the HOOPS Reference Manual.

    NOTES

    Note that using "update interrupts = on" can greatly slow the ray-trace computation. The maximum ray-tracing speed is achieved when you specify the rendering option "ray-trace options = (no special events, display style= sequential raster)" and have the driver option "no update interrupts". With these settings the ray-trace computation can proceed without (possibly costly) interruptions. See the ray-trace "special events" section of Set_Rendering_Options for a way to compromise between flexibility and computation speed.

    RESTRICTIONS

    The double buffering driver option does not cooperate properly with ray tracing. So when ray tracing with HOOPS A.I.R., double buffering should not be used.

    SEE ALSO

    Set_Rendering_Options, Get_Selection.

    Back


    Set_Rendering_Options

    PURPOSE

    Allows you to control how carefully and accurately your scene is drawn, and enable several special drawing effects. Set_Rendering_Options is part of the basic HOOPS product---HOOPS A.I.R. provides the additional capabilities described here, including radiosity and ray-tracing.

    CALLING SEQUENCE

    Set_Rendering_Options (list)

    -------------------------------------------------------------------------
    list    string   A quoted string or a string variable containing a list of   
                     the desired settings.                                       
    -------------------------------------------------------------------------
    

    VARIANTS

    QSet_Rendering_Options (segment, list)

    UnSet_Rendering_Options ()

    UnSet_One_Rendering_Option (which)

    QUnSet_Rendering_Options (segment)

    QUnSet_One_Rendering_Option (segment, which)

    -------------------------------------------------------------
    segment    string   Name of the segment(s) to be changed.        
    list       string   As above.                                    
    which      string   A particular rendering option to be unset.   
    -------------------------------------------------------------
    

    DETAILS

    The Set_Rendering_Options function is part of the basic HOOPS package; adding the optional HOOPS A.I.R. package provides these additional features:

    technology = type

    Selects a rendering algorithm when in lighting mode (see the Insert_(type)_Light routines). When HOOPS detects a light in your scene, it applies a rendering model to determine what color surfaces would appear based on their environment. You can select technologies to model shadows, transparency, refraction, interobject diffuse reflections, etc. Generally, the more complicated the technological model used, the slower the algorithm will be.

    When specifying a technology to the system type can be any of the following:

    STANDARD

    Surfaces are rendered with light that reflects directly off them from point sources to the camera---ignoring the global environment in which the surfaces exist (in the present implementation). Specifically, "Technology = standard" indicates that you do not want the system to compute shadows, transparency, refraction, or interobject reflections---even if the attributes in your scene indicate otherwise---in order to attain the highest drawing speed.

    The standard renderer internally approximates area light sources with spotlights---for accurate area lighting, a radiosity model should be used.

    Note that the "lighting interpolation" rendering option determines how often the standard rendering equation is applied to a given surface facet (no interpolation: once for the surface; Gouraud: once at each vertex; Phong: at each pixel).

    The HOOPS standard technology model is defined as follows:

    where

    = the ambient contribution

    = the diffuse reflection contribution

    = the specular reflection contribution

    The ambient contribution is defined as

    where

    = the diffuse color of the surface

    = the intensity of the ambient light

    The diffuse contribution is defined as

    where

    = the intensity of each light

    = the incident angle of each light from the surface normal

    The specular contribution is defined as

    where

    = the specular color of the surface

    = the angle between the viewpoint ray and the light reflection ray

    = the surface gloss coefficient

    See Set_Color for information on the various surface coefficients listed above.

    RADIOSITY

    Instructs HOOPS to compute interobject (indirect) diffuse reflections, soft shadows, and area light illumination using a radiosity algorithm. Can be used alone or in combination with either "standard", or "ray-trace".

    Note that "diffuse" light reflection is the "opposite" of "shiny" (specular) reflection---the object is fuzzy, the color of the reflected light includes the color of the object, and the light reflected has no directional component.

    The "standard" HOOPS renderer only computes shading of surfaces from direct illumination by point emitters. It does not include any light that would require more than one "bounce" to reach the camera. A full-scale "radiosity" calculation, however, uses a progressive algorithm to model inter-object (indirect) diffuse reflections. A "ray-trace" calculation, for comparison, best models inter-object specular reflections.

    Since the radiosity method only considers diffuse reflections (it ignores specular reflections), and since diffuse reflections have no directional component, the solution is "view independent". Thus, HOOPS allows you to interactively "fly" your camera through the scene without recomputing the radiosity solution.

    If the environment you wish to model has specular reflecting objects, you can combine the radiosity solution with other technologies. For example, "technology = (radiosity, standard)" will first perform a radiosity solution (considering only diffuse reflections), whose resulting surfaces are then drawn on the screen using the "standard" technology model (which adds "direct" specular reflections). Since the standard shader is relatively fast, high-end hardware can still render these scenes interactively.

    "Technology = (radiosity, ray-trace)" will generate the highest quality pictures (at the expense of speed) by taking advantage of both radiosity's interobject diffuse reflections and ray-tracing's transparency and interobject specular reflections. HOOPS first performs a radiosity solution, and then substitutes the resulting diffuse values into the ray-tracing computations.

    Radiosity is a progressive solution in which the energy from light sources is allowed to "flow" (bounce) around your scene. The solution is broken into discrete computation steps, where energy flows from the brightest source not yet considered to the rest of the scene. This allows you to watch the solution improve, with meaningful pictures resulting after only a few computation steps. See the "interim display" and "special events" radiosity options below.

    In the current implementation, the radiosity solution can be cleanly interrupted only between solution steps (which may take a long time to complete)---an update interrupt (see Set_Driver_Options for a full description) that occurs in the middle of a radiosity solution step will reset the solution to the beginning. For this reason, three modes of the "update interrupt" driver option are provided: "off" (the user can not interrupt), "on" (interrupts are allowed only between steps), and "unrestricted" (interrupts are allowed at any time).

    Although the radiosity model ignores non-faceted geometry (i.e. lines, text, markers, etc.), HOOPS will draw them into the resulting radiosity scene (or will be "overlaid" when used in combination with ray-tracing). Note that turning the radiosity option on and off for different parts of a scene is perfectly legal.

    Once you have decided to perform a radiosity solution, you would normally set appropriate "radiosity options" as described below.

    RAY-TRACE

    Instructs HOOPS to compute shadows, transparency, refraction, and interobject (indirect) specular reflections using a ray-tracing algorithm. This algorithm works best with specular environments (shiny surfaces and mirrors) where only point sources of light are used, and with transparent surfaces.

    "Specular" light reflection is the "opposite" of diffuse reflection---the object is hard and shiny, the color of the reflected light depends more on the color of the light than of the object, and the reflected light has a strong directional component. "Specular" means "as in a mirror".

    The "standard" HOOPS lighting model considers only light that reflects directly from a point source off a specular surface to the camera. This reflection approximation does not include any light that would require more than one bounce to reach the eye, nor does it include an actual reflected image of neighboring surfaces as a real-world specular (mirror) reflection would. Specifying "technology = ray-trace" turns on a full-scale ray-tracing calculation that includes all such mirror-like reflections.

    In the ray-tracing algorithm, imaginary "rays" are "shot" from the camera position, through each screen pixel, out into the scene. For each camera ray, a test is performed to see which surface in the scene the ray hits first. At this intersection a lighting calculation is performed, and new "reflection" and "transmission" rays are shot from the intersection point into the scene recursively. Each image pixel is colored according to the energy being received along these rays.

    The "ray-trace" renderer internally approximates area light sources with spot lights---for accurate area lighting, a radiosity model should be used in addition. Note also that non-faceted geometry (markers, text, lines, etc.) is ignored by the ray-trace model, but will be "overlayed" on top of the final ray-traced image. In the current implementation, HOOPS does not perform proper hidden surface removal on this overlayed geometry.

    HOOPS does not support inter-object diffuse reflections that result from the light of an inter-object specular reflection (but the reverse is computed correctly).

    (RADIOSITY, RAY-TRACE)

    HOOPS first performs a radiosity solution, and then substitutes the resulting diffuse values into the ray-tracing computations. See "radiosity" above.

    [no] radiosity options [= (option, option, …)]

    Due to its complexity, the radiosity algorithm requires a large amount of computation. Using "radiosity options" you can guide the solution process to emphasize either speed or accuracy.

    Legal options include

  • convergence goal

  • interim display[s]

  • special events

  • internal subdivision

  • accuracy

  • brightness

  • contrast

  • boundary continuity

  • energy preservation

    The default is "radiosity options = (convergence goal = 50%, interim display, no special events, no internal subdivision, accuracy = 2, brightness = 1.0, contrast = 1.0, no boundary continuity, energy preservation)".

    Full descriptions of these options are as follows:

    convergence goal = value %

    Radiosity is a progressive solution in which the energy from light sources is allowed to "flow" (bounce) around your scene. The solution is broken into discrete computation steps, where energy flows from the brightest source not yet considered to the rest of the scene. After a large number of computation steps, the energy flow reaches a state of equilibrium---the energy entering the scene from light sources is equal to the energy being absorbed.

    Initially zero, convergence is the percentage of the total reflected energy in the environment that has been accounted for at a given point in the solution. Since the algorithm considers the most important energy contributors first, excellent pictures result well before equilibrium (100% convergence).

    If the convergence of the previous radiosity solution step meets or exceeds the "convergence goal", HOOPS considers the solution finished (and no more steps are performed).

    It is perfectly legal to increase "convergence goal" after the goal has been reached---the solution will pick up where it left off. Likewise it is legal to decrease the goal while still actively computing a solution (though your application can only regain control from HOOPS between solution steps, which requires the "special events" option below).

    [no] interim display[s][= on/off]

    Enabling "interim display" causes HOOPS to draw the radiosity scene after each solution step on its way to the "convergence goal". This allows you to watch the picture improve with each step, and possibly halt the solution before the convergence goal has been reached (by setting "convergence goal = 0%", or any value less than the current convergence).

    Since the time required to display a radiosity scene on some display devices can be quite slow, selecting "no interim display" allows the solution steps to proceed unhindered until the convergence limit is reached.

    [no] special events[= on/off]

    Normally when you call Await_Event or Update_Display, HOOPS computes all the radiosity steps necessary to reach the convergence goal, then waits for an event from the user before returning control.

    Enabling "special events" causes HOOPS to queue a "rendering" special event after each radiosity solution step allowing your program to regain control from Await_Event. You could use this to update a status bar as a way to give the user feedback when using "no interim display".

    After Await_Event returns "special" as its event type, you would normally call Show_Special_Event to receive a type and param string. HOOPS identifies the special event as a rendering event (as opposed to other special events) by a type string of "radiosity status".

    The param string further describes the radiosity event in the format "[not] complete, convergence = value%, segment = pathname, steps = integer".

    See the Parse_String utility function for information on extracting specific fields of the param string.

    After each solution step on the way to the convergence goal, the param string will include "not complete" to indicate that the next call to Await_Event will continue the solution. Once the goal has been reached an additional special event is queued that includes the status "complete", meaning the next Await_Event will "block" for input. You could use this completion event, for example, to remove a radiosity status bar.

    Although the beginning of the param string is guaranteed to have this format, future versions of HOOPS might have additional information added to the end of the string. Your Show_Special_Event buffer should be large enough to hold the additional options that might be returned.

    Note that the Get_(type) routines and Update_Display ignore special events. Also note that it is perfectly reasonable to use special events with Await_Event even when you are not using HOOPS to handle mouse or keyboard input (such as with the "disable input" and "use window ID" options of Set_Driver_Options).

    no internal subdivision

    internal subdivision = initial

    internal subdivision = (initial, limit, threshold %)

    Internal subdivision allows the system to cut large surfaces in your scene into smaller pieces for higher quality radiosity solutions. Since the radiosity algorithm computes intensities only at surface vertices, large surfaces may "miss" proper shadows and illumination unless subdivided.

    If a single initial subdivision value is specified, the system will internally subdivide the affected surfaces before starting the radiosity solution. Initial is assumed to be in world coordinates (the requested subdivision occurs after the modelling transformation has been applied to the surfaces)---thus no matter where in your hierarchy you specify subdivisions, they are all in the same units.

    The disadvantage to internal subdivision is that it can greatly increase the computation and memory required to perform a radiosity solution.

    It is perfectly legal (and desirable) to set different subdivision values on different parts of a scene. For example, a high subdivision should be set on the floor of a room (where most shadows fall) compared with that of the walls and ceiling.

    Provided that you guide HOOPS with a good initial subdivision, the system can perform automatic recursive subdivision as the radiosity solution progresses. To enable automatic subdivision, you must specify three parameters: the initial subdivision as described above, the limit of how small surfaces can be subdivided, and the threshold criterion under which the system will recursively subdivide a particular surface. If given without units (currently the only legal choice), limit is specified in the same units as initial. A particular facet will be subdivided if its vertex intensities differ by more than threshold percent.

    Note that automatic subdivision is not "intelligent"---if the vertex intensities of a facet do not exceed threshold the facet will not be subdivided even if it has shadows between the vertices.

    Area light sources (see Insert_Area_Light) are also subdivided according to the "internal subdivision" option. However, subdividing area lights will increase the radiosity computations to a greater extent than an equivalent subdivision of normal geometry.

    accuracy = value

    Suggests how much effort should be applied when computing the illumination or shadow being received by a surface. Setting accuracy too low results in shadow "ghosts" and improper modelling of area light emission. Too high a value can greatly increase the computation time of the radiosity solution.

    It is perfectly legal (and desirable) to set different accuracy values on different parts of a scene. For example, a high accuracy value should be set on the floor of a room (where most shadows fall), whereas a lower value would be sufficient for the walls and ceiling.

    Note that "accuracy" and "internal subdivision" are tightly coupled with respect to generating quality radiosity scenes. Even with a high "accuracy", shadows cannot be properly generated if the surface receiving shadows is not sufficiently subdivided (since intensities are computed only at surface vertices). Conversely, a highly subdivided surface cannot accurately model illumination received from a large area light without sufficient "accuracy".

    Currently, accuracy must be an integer in the range of 1 to 5 (inclusive)---with 5 causing approximately 25 times more computations per vertex than "accuracy = 1".

    brightness = value

    When drawing the scene on the screen, HOOPS automatically scales the intensity of all objects such that the brightest object will have an intensity of 1.0.

    In scenes where there is an object close to a light source, HOOPS' automatic scaling of intensity may make the rest of your scene too dark. The "brightness" option is similar to the brightness knob on a television, and allows you to scale the overall scene brightness up or down.

    If you specify a brightness greater than 1, some object intensities will be "clamped" since they will be scaled beyond the displayable maximum.

    The default is "brightness = 1.0".

    contrast = value

    In scenes where surfaces receive nearly the same amount of light, the picture may not have sufficient dynamic range. The "contrast" option is similar to the contrast knob on a television, and allows you to change the linearity of HOOPS' scaling operation.

    The default is "contrast = 1.0", which provides a linear intensity scaling.

    [no] boundary continuity[= on/off]

    Selecting "boundary continuity" causes the system to automatically detect surface facets that share common edges, and to force the shading to be continuous across the edge. This has the effect of "smoothing" large surfaces that are composed of many facets.

    As with "internal subdivision" and "accuracy", enabling "boundary continuity" can improve image quality, but will slow down the radiosity solution.

    [no] energy preservation[= on/off]

    At any given point in the radiosity solution, HOOPS knows the total reflected energy in the environment that has not been accounted for (using the current "convergence" value for the scene). Setting "energy preservation = on" tells HOOPS to add this "missing" energy as a constant ambient term in your scene so that initial radiosity steps are brighter.

    The disadvantage to enabling "energy preservation" is that you loose some dynamic range (the energy added in makes areas in shadow too bright compared to the light sources). Also, you cannot watch the energy "flow" around your scene in the initial solution steps.

    [no] ray-trace options [= (option, option,)]

    Due to its complexity, the ray-tracing algorithm requires a large quantity of computation. Using "ray-trace options" you can guide the solution process to stress either speed or accuracy.

    Legal choices for "option" include

  • special events,

  • blocking factor,

  • scan-line method,

  • anti-aliasing,

  • bounce limit,

  • required contribution,

  • display style.

    The default is "ray-trace options = (no special events, scan-line method, no anti-aliasing, bounce limit = 5, required contribution = 10%, display style = interlace raster, no blocking)".

    Full descriptions of these options are as follows:

    [no] special events[= on/off]

    Normally when you call Await_Event, HOOPS computes all the scan-lines for the ray-traced image and then waits for an event from the user before returning control.

    Enabling "special events" causes HOOPS to queue a "rendering" special event after each ray-tracing solution step (usually a scan-line---see "blocking" below), allowing your program to regain control from Await_Event. This could be used to update a status bar---especially when using the "image" device driver to ray-trace into an invisible HOOPS image.

    After Await_Event returns "special" as its event type, you would normally call Show_Special_Event to receive a type and param string. HOOPS identifies the special event as a rendering event (as opposed to other special events) by a type string of "ray-trace status".

    The param string further describes the ray-trace event in the format "[not] complete, completed = value%, segment = pathname, steps = integer, intensity = (minimum, maximum)".

    See the Parse_String utility function for information on extracting specific fields of the param string.

    After each ray-traced scan-line is computed, the param string will include "not complete" to indicate that the next Await_Event call will continue the computation. Once each pixel of the image has been computed, an additional special event is queued that includes the status "complete", meaning the next Await_Event will "block" for input. You could use this completion event, for example, to remove a ray-trace status bar.

    Although the beginning of the param string is guaranteed to have this format, future versions of HOOPS might have additional information added to the end of the string. Your Show_Special_Event buffer should be large enough to hold any additional options that might be returned.

    Note that the Get_(type) routines and Update_Display ignore special events. Also note that it is perfectly reasonable to use special events with Await_Event even when you are not using HOOPS to handle mouse or keyboard input (such as with the "disable input" and "use window ID" options of Set_Driver_Options).

    Also note that using "special events = on" can greatly slow the ray-trace computation. The maximum ray-tracing speed is achieved when you specify "no special events", "no blocking", "display style=sequential raster", and have the driver option "no update interrupts". With these settings the ray-trace computation can proceed without interruptions.

    [no] blocking = steps

    The "blocking" option lets you compromise between performance and control by specifying how often you wish to receive special events and how often an update-interrupt may occur. Specifying "blocking = 1" allows a special event or an update interrupt to occur after every scan line (and may double the overall solution time). The higher a steps value used, the more efficient the ray-trace computation will be.

    When steps is greater than one, and "display style= sequential raster", steps ray-trace scan lines are computed in a batch, temporarily deactivating the queuing of special events and "update interrupts" (if enabled).

    With "display style = interlaced raster", the solution progresses as usual (with a special event reported per scan-line), until gaps of steps scan lines or less remain. From this point the gaps are computed in batches as with "sequential raster" above, temporarily deactivating the queuing of special events and "update interrupts" (if enabled).

    [no] scan-line method[= on/off]

    Tells HOOPS to use an optimization based on object coherence. This can increase the speed of the eye-ray surface intersection calculations. Mirror reflections and shadows are computed with the normal ray-trace method.

    The only occasion for not using the scan-line method is when your scene has transparent objects, since the scan-line method is less accurate for transparent objects.

    [no] anti-aliasing[= strategy [= options]]

    "Aliasing" refers to defects in an image that arise from the image being only a sampling of the underlying scene. A very common example in graphics is "staircasing": only a part of a pixel may need to be colored in at the edge of the given polygon, but in normal hardware the whole thing gets colored or doesn't get colored, giving a staircase pixel pattern on the screen as the color overshoots and undershoots.

    "Anti-aliasing" attempts to remove these effects by computing what fractions different surfaces contribute to a pixel's area and then figuring an averaged color for that pixel. Where the edge of a polygon only fills half a pixel's area, the pixel is colored with half the polygon's color.

    With ray-tracing, it is difficult to compute what fraction each surface contributes to a pixel's area (or volume when extruded into space). The strategy parameter selects an algorithm to solve this aliasing problem. Currently the only legal strategy is "super-sample", which shoots multiple rays into the scene for each pixel in a regular grid pattern and averages the resulting contributions.

    With "ray-trace options = (anti-aliasing = super-sample = samples)", the samples parameter describes the minimum number of rays that will be shot per-pixel. Legal values for samples are "1", "4", and "16" with higher values causing more computation, but less aliasing. Beyond this minimum, HOOPS may adaptively sample up to four times as many rays if the light intensity is varying rapidly within a pixel.

    When anti-aliasing is selected, but no strategy is specified, HOOPS defaults to the "super-sample" strategy. When anti-aliasing and "super-sample" are selected but no samples value is specified, HOOPS defaults to "1" sample. If "no anti-aliasing" is selected, HOOPS will not adaptively super-sample.

    bounce limit = limit

    Ray tracing models the scene by shooting rays from the camera's position, through each pixel of the image, into the environment. For each ray, the closest object the ray intersects is computed. At the intersection point a new "reflection" ray is bounced off the surface into the scene (and optionally a "transmission" ray is generated if the surface is transparent). So from each pixel of the scene an inverted tree of reflection and transmission rays is generated.

    "Bounce limit" tells HOOPS to terminate any limbs of the tree that are too deep (i.e. when a ray has bounced around the scene too many times). Without a bounce limit, a ray could bounce around a closed room forever. Lowering the "bounce limit" can significantly speed rendering time, especially for transparent objects where the ray-tree grows geometrically with each level (bounce). Increasing the bounce limit will increase the accuracy of the image, especially in highly specular environments where inter-reflections between objects are complex.

    required contribution = value %

    d to the energy coming in to thn the ray-tree described above, the energy received directly from each light is computed and added to the energy coming in to the surface along the "reflection" and "transmission" rays. Some of this energy is absorbed by the surface at the intersection point, and the remaining energy is sent up the ray-tree towards other (parent) surfaces or the camera (the root of the tree).

    At each new branch of the ray-tree, HOOPS checks what fractional contribution the new branch is contributing to the final pixel's energy. If the new branch's contribution does not meet the "required contribution" threshold, HOOPS stops bouncing rays from that branch even before the "bounce limit" has been reached.

    display style = style [, fill]

    Since ray-tracing can be slow, the user may want a "preview" of the ray-traced scene, so that the update can be interrupted (for example, if the user decides the view isn't quite right). Choosing a "display style" tells HOOPS in what order the pixels of the ray-traced scene should be computed. The legal styles include

    sequential raster

    The solution starts at the bottom of the image and proceeds to the top, one scan-line at a time.

    interlaced raster

    The solution starts with the bottom scan line, and proceeds upward skipping over 256 scan lines at a time, then starts back at the bottom skipping over 128 scan lines, 64, 32, etc., until the image has filled in completely.

    You can optionally specify "fill" to have HOOPS fill in the currently uncomputed pixels with the colors of the closest computed pixel. Using the "fill" qualifier can slow the ray-trace solution due to increased drawing.

    Note that using "display style=interlaced raster" can greatly slow the ray-trace computation. The maximum ray-tracing speed is achieved when you specify the rendering option "ray-trace options=(no special events, display style= sequential raster)" and have the driver option "no update interrupts". With these settings the ray-trace computation can proceed without (possibly costly) interruptions. See the ray-trace "blocking" section for a way to compromise between flexibility and computation speed.

    All other rendering options are fully described in the "Attributes" chapter of the HOOPS Reference Manual.

    NOTES

    When rendering with "technology = standard", it is perfectly legal to have multiple cameras (in different segments) displaying into the same window. When using "technology = ray-trace", however, only one camera can be used to view the scene's geometry. If multiple cameras are displaying into a ray-traced window, HOOPS will only use the camera in effect at the windowed segment.

    Due to ray-tracing's long rendering time, you may be interested in saving the resulting picture to disk for future display. This can be accomplished using the HOOPS "image" driver---see the "Image" device-driver installation guide for details.

    The damage caused by "exposure events" on windowing systems can have adverse effects on ray-traced renderings. This can be avoided on most devices by using the "backing store" driver option (see Set_Driver_Options). Systems that don't support backing store can use the Image device-driver for the same effect.

    RESTRICTIONS

    Cutting planes are ignored by the ray tracer.

    Text cannot be included in ray-traced scenes. To avoid this problem, place text in its own transparent subwindow.

    SEE ALSO

    Set_Driver_Options, Set_Heuristics, Set_Color, Set_Color_By_Value, Set_Color_By_Index, Set_Visibility, Show_Device_Info, Insert_Shell, Insert_Mesh.

    Back


    Set_Visibility

    PURPOSE

    Set_Visibility is part of the basic HOOPS product---HOOPS A.I.R. provides the additional capabilities described here.

    CALLING SEQUENCE

    Set_Visibility (list)

    -----------------------------------------------------------------------------
    list    string   A quoted string or a string variable containing a list of the   
                     desired settings (see below).                                   
    -----------------------------------------------------------------------------
    

    VARIANTS

    QSet_Visibility (segment, list)

    UnSet_Visibility ()

    UnSet_One_Visibility (which)

    QUnSet_Visibility (segment)

    QUnSet_One_Visibility (segment, which)

    --------------------------------------------------------
    segment    string   Name of the segment(s) to be changed.   
    list       string   As above.                               
    which      string   A particular visibility to be unset.    
    --------------------------------------------------------
    

    DETAILS

    The Set_Visibility function is part of the basic HOOPS package. Adding the optional HOOPS A.I.R. package provides this additional feature:

    [no] shadows [= visibility]

    The "standard" HOOPS renderer does not compute shadows. If an advanced renderer is used (such as "technology = radiosity" or "technology = ray-tracing") shadows can be calculated, but at greater computational cost.

    Shadow visibility can be used to reduce a scene's rendering time by selectively disabling shadow computations for part of the scene. It is perfectly legal (and often desirable) to have different shadow visibilities apply to different parts of a scene.

    In order for a shadow to occur there must be

  • a light source (controlled by "shadow emitting" below),

  • a surface for the shadow to fall upon (controlled by "shadow receiving"), and

  • another surface in-between, which blocks the light source and casts the shadow (controlled by "shadow casting").

    The computation for each of these three shadow components can be enabled or disabled with Set_Visibility. Legal values for visibility include combinations of

    on

    Shadows should be computed and displayed. Identical to "shadows = (emitting, receiving, casting)".

    off

    No shadows should be computed or displayed. Identical to "shadows = (no emitting, no receiving, no casting)".

    [no] emitting

    The light sources affected by this attribute can (can not) cause shadows in the scene.

    [no] receiving

    Shadow computations will (will not) be made for the surfaces affected by this attribute.

    [no] casting

    Surfaces affected by this attribute are (are not) allowed to block the light from any of the light sources to any other surface.

    Specifying "shadows" is equivalent to "shadows = on", while "no shadows" is equivalent to "shadows = off".

    All other Set_Visibility options are fully described in the "Attributes" chapter of the HOOPS Reference Manual.

    NOTES

    In the current version, specifying the visibility of "geometry" also applies to shadows.

    SEE ALSO

    Show_(Attribute), Show_One_(Attribute).

    Back


    Show_Area_Light

    PURPOSE

    Returns the definition of an "area light", as referenced by a key (requires A.I.R.).

    CALLING SEQUENCE

    Show_Area_Light (key, count, points, list)

    -----------------------------------------------------------------------------------
    key       HC_KEY         Unique numeric identifier pointing to an area light in the    
                             database.                                                     
    count     integer        Number of valid points in points. Returned to user. Passed    
                             by reference always.                                          
    points    point vector   Vector of x-y-z triplets for the coordinates along the edge   
                             of the area light. (A simple N ¥ 3 array may also be used.    
                             Fortran callers should reverse the subscripts.) Returned to   
                             user. Passed by reference always.                             
    list      string         A quoted string or a string variable containing a list of     
                             options for this specific light. Returned to user.            
    -----------------------------------------------------------------------------------
    

    VARIANTS

    Show_Area_Light_Count (key, count, list)

    ---------------------------------
    key       HC_KEY         As above.   
    count     integer        As above.   
    points    point vector   As above.   
    list      string         As above.   
    ---------------------------------
    

    DETAILS

    This routine returns the definition of the area light that corresponds to the given key. You could use this ability, for example, to place the camera at a particular position with respect to a light, or to realign the light with an object that has moved in the scene. There is no way to edit an existing area light; it is simple enough to remove the light with Delete_By_Key, and then reinsert it at a new position.

    To aid in the allocation of a data structure large enough to receive the array, you may call Show_Area_Light_Count first which returns the number of points in the light.

    The key for the area light might come from Find_Contents (Begin_Contents_Search) or it might have been saved by your program when the area light was created (via KInsert_Area_Light).

    SEE ALSO

    Insert_Area_Light, Begin_Contents_Search, Delete_By_Key, Translate_Object, Compute_Coordinates, Insert_Marker, Set_Selectability.

    Back