- Path sensors core dump
-
Path sensors can core dump during notification, when something
underneath them changes.
Workaround: A corrected routine
is available.
- Wrong aspect ratio in stereo viewing
-
When viewing objects in stereo mode on Indy/Indigo/Indigo2, the aspect
ratio is wrong. Loading a sphere into Inventor and switching to stereo
mode will show a sphere twice as tall as it is wide.
Workaround: Add the following three nodes to any file when you want
to see correct stereo on machine other than RE (RealityEngine doesn't have
this distortion problem).
Note that SceneViewer will strip cameras from file, so this will NOT
work in SceneViewer (ivview is ok). You can however change the SceneViewer
to add those nodes when in stereo mode (use SoXtViewer::isStereoViewing()
to check the mode of the viewer). Also because the camera is supplied in
the scene, you will need to do a viewAll to see the entire scene.
#Inventor V2.0 ascii
Separator {
#
# The scale node will stretch the objects by 2 no matter
# what the camera aspect ratio will be (accomplished by
# scaling the view volume, but not the objects).
#
TransformSeparator {
Scale { scaleFactor 1 2 1 }
PerspectiveCamera {}
}
[... rest of your scene..]
}
- Core dump in SoMFNode
-
Deleting values of an SoMFNode field can cause core dumps.
Workaround: A corrected routine
is available.
- Core dump when using textures
-
The Inventor 2.0 texture code sends an uninitialized variable to
OpenGL as a display list. This can cause core dumps in the OpenGL
display list code.
Workaround:
A corrected routine is available.
- Real-time clock jumpiness:
-
Sometimes when the realTime global field is used for the first time,
it contains an out-of-date value. This can be noticeable when using an
SoOneShot engine, for example. The cause is that realTime is not
updated when nothing is connected from it; when the first connection
is made, the (out-of-date) value in the field is used as is before
update occurs.
Workaround: to make sure realTime is always correct, make a
connection from it to some field. (The field does not ever have to be
used. For example, you could connect it to the field of an SoLabel
node under a disabled SoSwitch).
- SoRotor node weirdness:
-
The SoRotor node can exhibit strange behavior when it represents a
rotation by 0 radians. If the initial rotation has a zero angle, the
SoRotor node will not be able to correctly deduce the axis of
rotation.
Workaround: specify any non-zero angle for the initial rotation
value.
A rotor can also become confused if it updates the rotation field
based on the current time, and the new value represents a rotation by
a multiple of 2*PI radians. When this happens, the SoRotor again
cannot correctly figure out the axis of rotation, and the rotation may
proceed about a different (probably undesired) axis.
-
Bad precedence for Calculator expressions:
-
The ternary ?: operator of the SoCalculator engine is not parsed with
the correct precedence. For example, the expression
"oa = a
< b ? a : b" is incorrectly interpreted as "oa = a
< (b ? a : b)" instead of "oa = (a < b) ? a :
b".
Workaround:
Use parentheses to force the parser to parse the expression correctly.
-
Calculator does not allow a[b]=c expressions
-
The SoCalculator engine does not support assigning to one part of an
array (SGI bug #222734). If using the debug library, a syntax error
will be reported.
Workaround:
Use a ComposeVec3f engine to do this operation.
- SoField::enableConnection() core dumps
-
Calling SoField::enableConnection() on a field that is not connected to
anything will result in a core dump (SGI bug #203988).
Workaround:
Either make sure the field is connected (call SoField::isConnected())
before calling the enableConnection method, or temporarily connect the
field to something, call enableConnection() and then disconnect the
field (if you wish the connection to be disabled the next
time it is connected).
- SoPath::getLength() and SoPath::getTail() errors
-
SoPath::getLength() and SoPath::getTail() can return the wrong answer if the path
contains nodekits and/or hidden children. This happens if nodes are appended between subsequent
calls to getLength or getTail. The returned value can be too large or too far
down the path. This error should never cause a core dump because in the worst
case returned length will be the full path length and the returned tail will
be the tail of the full path.
Workaround:
A patched routine is available.
- SoPickedPoint::getMatrix() error
-
SoPickedPath::getMatrix() can return the wrong answer if the path
contains nodekits and/or hidden children.
This happens because the method
checks if the input node is at the tail of the pick path.
If so, getMatrix applies an SoGetMatrixAction to the entire pick path.
Otherwise it builds a partial path down to the given node.
The method should cast the pick path to an SoFullPath when calling
getTail; otherwise if there is a nodekit along the path it will
incorrectly apply the action to the full path.
Workaround:
A patched routine is available.
- Textures don't show up when printing
-
Textured objects are not textured when rendered to by the
SoOffScreenRenderer (sgi bug #214492).
Workaround:
A corrected routine is available.
- Core dumps with empty primitives
-
Several shape nodes will dump core if given empty coordinates and/or
indices.
Workaround:
Do not create empty coordinates or shapes.
- Level of Detail slowness with culling
-
A bug in Inventor 2.0 causes bounding boxes to be invalidated when
both SoSeparator renderCulling and SoLevelOfDetail nodes are being
used. This causes an object's bounding box to be recalculated every
time a cull or level of detail test is done, resulting in poor
rendering performance.
Workaround:
There is a lighter weight level of detail node available from SGI that
does not need to compute bounding boxes.
- replaceManip with NULL argument
-
A bug in Inventor 2.0 causes replaceManip to do the wrong thing when a nodekit
lies along the path to the manip.
Each type of manipulator has a method replaceManip which takes two arguments.
The second argument is a node to install at the end of the path
(given as the first argument). This new node replaces the manipulator.
An argument of NULL is supposed to cause the method to create a new node for
you. If a nodekit lies along the path, this does not occur and the manipulator
does not get removed. However, if you pass in a non-NULL argument, the
method will behave correctly.
Workaround:
Always pass a non-NULL second argument. For example, use:
myTrackballManip->replaceManip(myPath, new SoTransform);
instead of
myTrackballManip->replaceManip(myPath, NULL);
- ivquicken breaks animating scenes
-
The ivquicken utility can incorrectly transform scenes that contain
animating nodes or engines (SGI bug #212773). The bug shows up in
cases where:
- one transformation node affects two or more objects, and
- an engine or animation node (e.g. rotor) affects some, but not all of the objects.
The objects affected by the transformation node and not by the engine/
animation node will be transformed incorrectly. For example,
in the following scene graph, the translation affects
both the cube and the cone, but the rotor only affects the cube.
The bug will make the cone transform incorrectly:
Separator {
DEF CULPRIT Translation { translation 10 10 10 }
Separator {
Rotor {}
Cube {}
}
Cone {}
}
Workaround:
Rearrange the scene graph such that all transformation nodes that affect
objects with engines/animations affect only those objects.
For example, rearrange the above scene graph as follows:
Separator {
Separator {
DEF CULPRIT Translation { translation 10 10 10 }
Rotor {}
Cube {}
}
Separator {
USE CULPRIT
Cone {}
}
}
- SoPointSet with startIndex problems
-
An
SoPointSet node with a startIndex field
that is not zero will return incorrect normals when generating
primitives or picking. If using the Inventor debugging library
(setenv LD_LIBRARY_PATH /usr/lib/InventorDebug), warnings
will be printed.
Workaround:
A corrected
SoPointSet::generatePrimitives() routine is
available.
IRIS Inventor Release 1.1.2
- Slow rendering animating in a viewer
-
By default, IRIS Inventor's viewers turn on render caching at the top
of the scene graph given to them with the
setSceneGraph()
method. This can cause a severe performance hit due to IRIS GL
display lists being created and destroyed every frame if the scene
graph is being changed every frame. Most commonly, this is due to a
timer or idle sensor that periodically changes the scene to perform
animation.
Workaround:
Call setRenderCaching(FALSE) on the viewer to prevent it from building
a cache at the top of the scene. For best performance, see the
Inventor 1 Performance Tips guide for more information on
how to determine which parts of your scene can be safely cached.
- Gradual application slowdown
-
SoPath objects in Inventor 1 slow down changes to the scene, because
Inventor does some work to find out if the change affects the path.
This can cause some simple algorithms to become N^2 algorithms; for
example, applying an SoSearchAction to the scene and then changing the
node at the tail of every path found is an N^2 algorithm in Inventor
1, because each of the N changes causes all of the N paths to decide
whether or not the change affects them. This can also cause problems
if your applications does not free up SoPaths or SoSearchActions after
it has used them.
Workaround:
If you are modifying all of the objects found by an SoSearchAction,
first add them all to an SoNodeList, then delete the SoSearchAction
(freeing up the SoPaths), and then modify the nodes.
Also, be sure to delete any SoSearchActions or SoPath objects after
you are finished using them.
- Memory leak, application slowdown using SoDetail methods
-
Several methods of SoDetail subclasses call an internal routine that
creates a SoSearchAction but fails to delete it. This causes a large
memory leak (the searchAction, all of the paths it finds, and all of
the nodes on those paths will never be deleted) and will cause the
application to slow down because of the extra paths (SGI bug #213257).
Workaround:
Correct routines for both Inventor 1.0
and Inventor 1.1 are available.
- Bad normals picking IndexedTriangleMesh
-
The picking code for the IndexedTriangleMesh object returns incorrect
normal indices for PER_VERTEX, PER_VERTEX_INDEXED, NONE or DEFAULT
bindings, which can cause a core dump (SGI bug #184448).
Workaround:
If you are getting a core dump, pad the normal's vector field with as
many extra normals as the maximum value in the coordIndex array. In
any case, ignore the normal index or normal returned from picking and
figure out the correct normal from the coordinate index returned along
with the normal binding.
- Memory leak rendering drawstyle LINES Text3
-
The SoText3 node leaks memory every time a renderAction traverses it
and the SoDrawStyle is LINES (SGI bug #162251).
Workaround:
Put the SoText3 node underneath a SoSeparator, call
setRenderCaching(TRUE) for that SoSeparator, and do not change the
Text3 node. This will cause the memory leak to occur only once,
instead of every time the Text3 node is rendered. If the Text3 node
must be changed, or you are frequently changing in and out of LINES
drawStyles, this workaround will not work, in which case you must
either switch to SoText2, upgrade to Inventor 2, or write your own
text node.
- Empty string for Text3 core dump
-
An empty string field for SoText3 nodes will cause them to core dump
(SGI bug #178687).
Workaround:
Remove Text3 objects with empty string fields from the scene.
- DGL errors remote-rendering Text2
-
When rendering remotely (by setting the DISPLAY environment variable),
SoText2 nodes will not be rendered and DGL errors will be displayed
(SGI bug #107024).
Workaround:
There is no workaround for this problem; if you expect your
application to display across the network, you must not use Text2
nodes in your scenes (but this is fixed in Inventor 2, of course).
- Non-printing characters in Text nodes
-
Non-printing characters in Text nodes (e.g. carriage returns) can
cause either bad rendering or, in extreme cases, core dumps (SGI bug
#114139).
Workaround:
Don't put non-ASCII or control characters in the string fields of the
text nodes.
- Picking Text3 with RIGHT/CENTER justification
-
The picking code for Text3 does not take into account RIGHT/CENTER
justification (SGI bug #140499).
Workaround:
Get the bounding box of the text with an SoGetBoundingBoxAction, and
put an invisible cube around the text to be used for picking instead
of the text (put an SoPickStyle node before the text so it isn't
picked also).
- RIGHT/CENTER justification with non-default size Font
-
The justification code for Text3 assumes that a default sized font
(size 10) is being used. Other sizes will cause the justification to
be incorrect (SGI bug #179412).
Workaround:
Use an SoScale node to change the size of 3D text instead of the
SoFont node's size field.
- 2-component textures do not render correctly
-
Two-component (intensity-alpha) textures do not render correctly due
to a bug in the Texture2 node (SGI bug #148707).
Workaround:
Convert your 2-component images to 4-component (RGBA) images.
- Texture2 node memory leak
-
IRIS GL display lists allocated by Texture2 nodes are never freed,
causing memory to be lost. This is only a major problem for
applications that are constantly reading in new textures, either by
deleting and recreating Texture2 nodes with different filenames, or by
changing the filename field of the Texture2 node (SGI bug #149535).
Workaround:
See this file for a workaround if you
cannot upgrade to Inventor 2.
- Incorrect model/blendColor for cached textures
-
The Texture2 node will blindly try to insert tevdef/tevbind calls into
an open IRIS GL display list; however, IRIS GL does not allow those
commands in a display list, so they will be executed immediately
instead of compiled into the list. This can cause incorrect rendering
of future frames (SGI bug #153695).
Workaround:
There is no good workaround for this bug; turning off caching for
textured objects can cause an unacceptable performance decrease, but
it will result in correct rendering.
- Texture model BLEND with 3/4 component images
-
Blended texturing with 3 or 4 component textures is illegal in both
IRIS GL and Open GL. The Inventor 1 Texture2 node silently does
nothing. The Inventor 2 Texture2 node will issue a warning if the
application is linked with the debugging library (SGI bug #175588).
Workaround:
Only use 1 or 2 component textures with BLEND.
- Texture model DECAL with 1/2 component images
-
Decal texturing with 1 or 2 component textures is illegal in both
IRIS GL and Open GL. The Inventor 1 Texture2 node silently does
nothing. The Inventor 2 Texture2 node will issue a warning if the
application is linked with the debugging library (SGI bug #175588).
Workaround:
Only use 3 or 4 component textures with DECAL.
- SbRotation::slerp() incorrect interpolation
-
The SbRotation::slerp() routine can interpolate incorrectly for some
sets of rotations (SGI bug #164588).
Workaround:
This code, from the Inventor 2 slerp routine, can be used instead:
SbRotation
slerp(const SbRotation &rot0, const SbRotation &rot1, float t)
{
const float* r1q = rot1.getValue();
SbRotation rot;
float rot1q[4];
double omega, cosom, sinom;
double scalerot0, scalerot1;
int i;
// Calculate the cosine
cosom = rot0.quat[0]*rot1.quat[0] + rot0.quat[1]*rot1.quat[1]
+ rot0.quat[2]*rot1.quat[2] + rot0.quat[3]*rot1.quat[3];
// adjust signs if necessary
if ( cosom < 0.0 ) {
cosom = -cosom;
for ( int j = 0; j < 4; j++ )
rot1q[j] = -r1q[j];
} else {
for ( int j = 0; j < 4; j++ )
rot1q[j] = r1q[j];
}
// calculate interpolating coeffs
if ( (1.0 - cosom) > 0.00001 ) { // standard case
omega = acos(cosom);
sinom = sin(omega);
scalerot0 = sin((1.0 - t) * omega) / sinom;
scalerot1 = sin(t * omega) / sinom;
} else { // rot0 and rot1 very close - just do linear interp.
scalerot0 = 1.0 - t;
scalerot1 = t;
}
for (i = 0; i < 4; i++) // build the new quarternion
rot.quat[i] = scalerot0 * rot0.quat[i] + scalerot1 * rot1q[i];
return rot;
}
- LayerGroup problems
-
Object under multiple SoLayerGroup nodes are not highlighted
correctly. The selection node renders
all of its children. It then runs through its list of selected
objects, and renders highlights for each object.
If there is a layer group beneath the selection node, the
layer group will be doing zclears between children. So when
the selection node goes to render the highlights, the z buffer
has been cleared, and the highlight will show up on top of
everything (SGI bug #96025).
Workaround:
Pass a NULL highlight style to the selection
node, and register object selected/deselected callbacks. Then when
an object is selected, insert highlight geometry directly into the
scene right next to the selected object. Then the highlight will
be rendered in the same layer as the object. NOTE:
SoLayerGroup was removed from Inventor 2 and replaced with the
SoAnnotation node for this reason.
IRIS Inventor Release 1.0.1
- Writing File nodes corrupting files
-
If a file "a.iv" has an SoFile node in it that refers to file "b.iv"
(i.e.
SoFile { filename "b.iv" }), and either a or b is
ASCII and the other is binary format, then file "b.iv" can be
corrupted or can become completely empty when writing out "a.iv"
(SGI bug #146859).
Workaround:
When using SoFile nodes, make sure all of your files are either ASCII
or binary; do not mix the two.
