VolumeViz - Fixed bugs

VolumeViz Fixed Bugs

VolumeViz 7.2

7.2 Final Release

(#1924) VolumeViz nodes do not support the SORTED_LAYERS_BLEND transparency type.
This is a limitation of the algorithm - use DELAYED_SORTED_LAYERS_BLEND instead.
(#1933) It is now possible to use environment variables to specify the texture unit(s) used internally for each kind of shader.
See SoPreferences: IVVR_FIRST_RESERVED_TEXTURE_UNIT, OIV_DELAYED_SORTED_LAYERS_TEXTURE_UNIT, OIV_SORTED_LAYERS_TEXTURE_UNIT, FXVIZ_SHADOW_TEXTURE_UNIT1 and FXVIZ_SHADOW_TEXTURE_UNIT0.
(#2299) On MAC, in some cases Texture3D support was not correctly detected. Same as 2423.
(#2318) wrong auto clip planes when using SoVolumeClippingGroup.
(#2335) Wrong min max was reported during computation of histogram when converting to LDM data using full 32 bits signed int input data.
(#2344) SoTransferFunction changes corrupted SoVolumeRender display depending on the numnbee of significants bits used in the datasets.
(#2369) SoLDMWriter did not work correctly when writing a float dataset with non-zero overlap.
(#2372) SoVolumeRender displayed major artifacts depending on the point of view (camera direction) because of scaling/extent interaction.
(#2384) Tile refinement problems visible on scaled volume data. For example, slices were cut-off when the volume was scaled (volume extent changed) and "equal slice resolution" was used. Same as #2406.
(#2399) In some cases involving PoBaseView, high resolution tiles were unloaded when getting closer to an orthoSlice.
(#2406) Tile refinement problems visible on scaled volume data. For example, slices were cut-off when the volume was scaled (volume extent changed) and "equal slice resolution" was used. Same as #2384.
(#2408) SEGY format 8 data (SIGNED_BYTE), for example Waha8.sgy, was not read correctly.
(#2409) SEGY format import improvement, LDM was not able to detect inline/crossline dimension in some circumstances.
(#2422) SoLDMTopoOctree crashed if not initialized correctly, it now reports an error message without crashing.
(#2423) VolumeViz did not correctly detect 3D texture capability on MacOSX. Same as 2299.
(#2429) In some cases an SoOrthoSlice was rendered inconsistently (brighter) for some slice numbers.
(#2447) When an SoVolumeGroup contained an SoVolumeRender plus an SoVolumeIsosurface and the multiVolumes field was set to TRUE, nothing was rendered.
(#2448) Volume clipping was incorrect when using SoVolumeGroup and multiVolumes set to TRUE.
(#2459) Oblique Slice did not support correctly bump mapping in paging mode.
(#2462) Better support of SEGY file.
(#2464) In some cases a crash occured when enabling fixedResolution with a single SoVolumeData node.
(#2478) Display was not updated when using multiple data range and modifying the first data range .
(#2501) Picking on SoVolumeSkin did not always return the right values.

VolumeViz 7.1

7.1.1 Patch : Bugs fixed as of June 28, 2008

(#2309) The error message "octree depth is too big" appears because VolumeViz octree does not support volume dimension greater than 16384.

7.1 Final release

(#1017) volumeRender shapes were not displayed when one of them is partially outside a PoSceneView.
(#1229) On Solaris, SoVolumeTriangleStripSet turned white if transparent, setDelayedRendering = True, and clipGeometry = False.
(#1243) The LDM password error message shouldn't be displayed when application does not explicitly use LDM mode.
(#1265) The option -O of the method SoConverter::convert did not allow the filename to be a path.
(#1283) Colors did not match at the intersection of two SoObliqueSlice.
(#1466) LDM conversion problems with signed short data. Two volumes with identical voxel values, with one stored using a signed data type and one stored using an unsigned data type, gave different histograms.
(#1486) Incorrect error message (from getTile) when SoVolumeShader was added to the scene after the SoVolumeData nodes (multiVolume mode). Error message should say that this ordering of the nodes is invalid (shader must occur before data nodes) unless the parent node is an SoMultiDataSeparator.
(#1518) SoLDMDataAccess::getData with subvolume could crash if the subvolume was a single voxel (minimum query is a block of 8 voxels). Now returns an error code in the DataInfoBox struct.
(#1585) Changing vertices array in SoVolumeFaceSet::vertexProperty to a bigger one failed.
(#1785) Screen resolution culling was not applied correctly to SoOrthoSlice. When screen resolution culling was enabled, slices would not always refine to full resolution even then there was enough memory available.
(#1794) The LDM converter called the XML callback (setXmlCallback) multiple times. Should only be called once during conversion.
(#1969) Rendering was incorrect if an SoDataCompositor node was under an SoSwitch and the whichChild field was changed to SO_SWITCH_NONE (should be as if the compositor does not exist).
(#1970) Changing the preDefCompositor field of an SoDataCompositor node did not correctly update the rendering.
(#1982) SoVolumeRender did not correctly display a very thin volume (Zdim = 2).
(#2002) Dicom reader didn't search for files relative to the directory containing the list of dcm files (it only searched relative to the working directory of the application).
(#2093) SoTransferFunction was ignored in non-LDM and non-Paging mode.
(#2102) Moving an SoOrthoSlice through the volume was slower in version 6 than in version 5.
(#2110) Non-LDM modes did not update the slice colors when modifying the volume data.
(#2135) SoLDMWriter::initialize(SoVolumeData) could cause a crash and did not correctly copy the input volume characteristics to the output volume.
(#2136) SoLDMWriter::writeSubvolume may generated incorrect data when dimension is not a multiple of the tile size.
(#2136) SoLDMWriter::writeSubvolume generated incorrect data at tile boundaries in some cases.
(#2137) SoLDMDataAccess::getData returned bad data when using a separate data access object initialized using the setDataSet method.
(#2172) Using SoVolumeRender, the volume appeared to flicker and change color when the ROI size changed. This was because the number of "slices" (polygons) drawn to render the volume changed with the size of the ROI. This behavior is still the default for compatibility, but can be overridden using the new field SoVolumeRender::fixedNumSlicesInRoi.
(#2173) Using SoVolumeSkin, LDM did not always load the tiles closest to the viewer first (sometimes tiles farther away were loaded first).
(#2212) SoLDMResourceParameters::getDataSize crashed if called before any dataset was created (now returns a default value).
(#2225) SoVolumeData::updateTilesInTextureMemory crashed in some cases.
(#2228) SoTransferFunction could crash in finishEditing() when using a very large colorMap.
(#2232) Using SoVolumeSkin, LDM sometimes stopped loading when there were no tile borders.
(#2239) In non-LDM/non-Paging mode, SoVolumeData::getVolumeData returned a pointer to the volume data even when the data was read from a file. It should return NULL unless the data was set using a pointer to memory.
(#2240) SoVolumeData::getLdmDataAccess().getData() returned the wrong data in some cases when high resolution data was requested after requested very low resolution data. (Worked correctly in 6.1.2)
(#2246) SoDataSet::setReader could crash if the reader was changed multiple times.
(#2255) Volume geometry could crash in RGBA mode with a very large colormap.
(#2257) In some cases SoOrthoSlice did not refine to the highest resolution possible when border was 0 (incorrect weight assignement and notification).
(#2258) SEGY reader failed to read file correctly when traceHeaderPosition was set before actually reading the file (e.g. immediately after creating the reader).
(#2260) In some cases SoOrthoSlice did not refine to the highest possible resolution when proximity visitor was enabled (gave too high weights to non intersecting tiles).
(#2262) Invalid display of slice may occured when SodataRange::mapOnFullColorRange was set to false.
(#2295) Using GzipDataCompressor compression with LDM, wrote incorrect "zu" compression level outputs in the resulting ldm file.
(#2280) LDM Reader may occured when calling SoVolumeData::setVolumeData with NULL data.
(#2314) VolumeSkin was displayed opaque when transferFunction entries weren't opaque.
(#2325) VolumeRender display was incorrect when setting negative Z scalefactor.
(#2326) Crashed occured on assertion in SoVolumeData if .vol file did not exist.
(#2327) Inside an SoVolumeGroup - Tiles flashed with solid color as they were loaded.
(#2337) OrthoSlice performance drop compared to v5.0.5 has been fixed.
(#2340) Crash may occured when activating and manipulating SoVolumeSkin nodes.

VolumeViz 7.0

Patch 7.0.1 : Bugs fixed as of February 20, 2008

(#2149) Multiple call to VolumeRendering::init VolumeRendering::finish can crash the application.
(#2150) Crash using getData with SbPlane for thin volume where tile dimension are not homogenous.
(#2151) Loading a fake data ldm doesn't work if a real .dat file do not exist.
(#2155) Multiple symbols definition in libMeshViz and libInventorVR on UNIX platform.
(#2158) Bad behavior of custom readers depending on call order of setFilename and setMinResolutionThreshold.
(#2166) Viewer Drawstyle do not work with VolumeViz.
(#2177) setVolumeData do not work properly in ScaleViz mode.
(#2185) SoLDMMultiIOTileManager::getWeight can return bad value when volume size is not a multiple of tile size.
(#2192) Shader crash when applying more than 2 channels on a thin volume.
(#2195) Using thin volume with SoMultiVolumeSeparator doesn't work properly.
(#2200) VolumeSkin is not correctly lighted.

7.0 Final release

(#1623) VolumeViz did not reliably update high resolution tiles. The volume skin did not reliably display full resolution data when the user stopped moving the exclusion ROI with a dragger. Note that full resolution data was displayed at other positions of the ROI, so it should have been possible to display it at all positions of the ROI.
(#1758) The LDM Converter computed an incorrect histogram for float values because of an internally hard-coded value. Now, if the range is not specified, it is estimated by sampling the volume, and then doubled. For example, if the estimated range is [-10,20], the actual range used will be [-25,35]. It is recommended that you specify the floating point range by using the options: -f f -r min max
(#1764) OrthoSlice wasn't displayed at full resolution even if maxMainMemory allowed loading of the data set at full resolution. One had to zoom on the areas displayed with intermediate resolution to get the full resolution. Then after zooming out, the whole orthoslice remains displayed at the full resolution.
(#1790) Slice did not refine reliably. One slice in a 1000^3 volume should require less than 100 MB of memory to load all necessary tiles (technically should require less than 80 MB). But there were still cases where refinement stopped too soon.
(#1838) SoVolumeRender became invisible when enabling MIN_INTENSITY composition.

(#1848) Tiles with the highest resolution were *not* displayed on the OrthoSlice when setMinResolutionThreshold had been called. The behavior was as expected if setMinResolutionThreshold wasn't called.
(#1864) The example simpleShader didn't compile when loading the shader from a file. Same as #1911.
(#1911) Typo in macro in SimpleShader example. SHADER_PATH was declared (line 39) but SHADERS_PATH was used (line 62, 70, 72). It caused compilation failure if you uncommented USE_SHADER_FILE as instructed in line 32.
(#1917) LDM rendering artifacts appeared due to problem with DICOM file reader. (Same as ebug #2006.)
(#1994) SoRayPickAction returned 4 values per displayed volumeSkin voxel depending on which quadrant of the voxel you picked. The probing and display of the volumeSkin voxels weren't homogeneous.
(#1995) The DICOM file reader didn't correctly compute the slice location.
(#2006) Rendering artifacts seen. (Same as ebug 1917.)
(#2011) Volumes having one of their axes longer than the other could disappear depending on the camera position and when multiVolume and SUM_INTENSITY composition were enabled. These volumes became fully transparent when:
- moving around the volume
- setting SoVolumeRender::composition to SUM_INTENSITY
- enabling multi volumes
(#2044) Unexpected black holes were seen when rendering SoVolumeSkin without enabling useRGBA when using VolRend. These artifacts were displayed when the texture interpolation was disabled. When useRGBA was enabled, only the expected black holes remained. Fixed in VolRend demo.
(#2066) Incorrect orthoslice refinement occurred on large volumes.
(#2067) SoVRSegyFileReader::setOutputDataType failed to convert SEG-Y data to the requested type. SEG-Y float data were converted to LDM float data type even when it was requested to convert them to byte or short.
(#2094) SoVolumeData::LDMDataAccess::getData with lines and polylines failed when the line started at the boundaries of the sub-volume.
(#2097) SoVolumeData::LDMDataAccess::getData (with SbLine) failed for valid line definitions.
(#2099) SoVolumeData::getDataSize returned an uninitialized value when called immediately after setting the field SoVolumeData::fileName.

VolumeViz 6.1

Patch 6.1.2: Bugs fixed as of July 19, 2007

(#1608) VolumePro1000 card wasn't recognized by OIV 6.x for VC8. In the OGLinfo program, OIV Extensions tab, the VolumePro board was noted as "not available". [P2]
(#1760) SoVolumeRendering::setMaxMainMemory didn't refresh the scene. SoVolumeData::touch or SoVolumeRender::touch didn't help. It was necessary to rotate the scene to get the expected refresh. [P2]
(#1778) SoROIManip and SoROI disturbed the display of non-VolumeViz shapes. Depending on the camera position, the non-VolumeViz shape could disappear. [P2]
(#1782) Crash when updating a fragment shader in a VolumeShader registering 2 shader objects. The crash happened with VC8, not with VC 7.1. [P2]
(#1830) SoVolumeShader did not work in paging mode. It works now, but multi-data is not supported. A new bug (#1962) has been opened for this issue. [P2]
(#1842) SoVolumeShader didn't support the function VVizComputeVolumeRenderingLighting. The returned value was always 0. [P2]
(#1843) The user's custom shader was ignored when the field SoVolumeRenderingQuality::lighting or preintegrated was modified. [P2]
(#1869) Demo program VolRend crashed when it was run with arguments specified on the command line. [P2]
(#1881) In NON-LDM mode, SoVolumeRender placed the voxels such that the edges of the voxels corresponded to the edge of the volume. Whereas with SoVolumeSkin, the centers of the voxels were placed at the edge of the volume skin. SoVolumeSkin was changed so that it behaves like the SoVolumeRender class in NON-LDM mode. Now in LDM and NON-LDM modes, both SoVolumeRender and SoVolumeSkin place the edges of the voxels at the edges of the volume. [P2]
(#1912) SoVolumeRenderQuality didn't handle SoScale nodes correctly. Lighting was corrupted (too dark) when a non-uniform scale node was applied to an SoVolumeRender node. [P2]
(#1913) Crash when adding SoVolumeShader after the SoVolumeData node. This now works to add a shader for a single volume. However if you want to use multiple data sets, then the shader or data compositor node must be before the SoVolumeData nodes in the scene graph (as shown in the Open Inventor User's Guide). [P2]
(#1914) The last SoDataRange setting was used for all of the volumes. It was not possible to have one data range setting per volume. A new field, dataRangeId, has been added to SoDataRange in order to remove this limitation. [P2]
(#1930) When using shaders and panning through a cube, SoVolumeSkin didn't properly update. SoVolumeRender behaved normally but the skin was only updated every now and then. [P2]
(#1931) Artifacts were seen in SoVolumeSkin rendering when displaying small volumes. It looks like the data had a break. [P2]
(#1935) A VolumeVizLDM FLEXnet license didn't unlock VolumeViz. [P2]

Patch 6.1.1: Bugs fixed as of May 29, 2007

(#1770) Slice geometry was not updated when the volume size changed. If the volume size (geometric extent) was changed dynamically by the application, the volume skin rendering was correctly updated, but the slice geometry was not. [P1]
(#1791) The SoROIManip geometry was not updated when volume size changed. If the volume size (geometric extent) was changed dynamically by the application, the volume skin rendering was correctly updated, but the SoROIManip geometry was not. [P1]
(#1808) After changing the colormap, etc., of an LDM volume and re-loading, the volume was displayed incorrectly because the textures were not being recreated properly. [P1]
(#1813) SoOrthoSlice wasn't displayed under a fastEdit separator. [P1]
(#1844) SoVolumeData crashed when using int32/uint32 data. The crash happened in GTD_UINT_TO_INDEX when numSigbitsPow2 = 0 (numSigbits = 32). [P1]
(#1873) There was sometimes a problem stopping the LDM loader threads in a reasonable amount of time. This was observed when working with a 10 GB volume. [P1]

6.1 Final release

(#1495) The GPU Composition demo didn't work on some machines that seemed to have the necessary OpenGL support.
(#1709) Volume rendered shapes weren't correctly lighted when num render caches was set to 0 and preintegrated lighted rendering was enabled.
(#1722) Incorrect display of volume rendering, volume skin, orthoslice, and oblique slices when tiles were not cubical. It worked with VolumeViz 5.0.5 but not 6.0.1.
(#1771) SoVolumeData::updateRegion did not work correctly in paging mode in Open Inventor 6.0.3.
(#1773) [Linux] IVVR_SEGY_DEBUG caused crash with LDMConverter using Open Inventor 6.0.3.
(#1793) Predefined shader function VVizBumpSlice stopped working in 6.0.3.
(#1798) SORTED_LAYERS_BLEND transparency caused a crash when working with volume skin geometry.

VolumeViz 6.0

Patch 6.0.3: Bugs fixed as of December 4, 2006

No change.

Patch 6.0.2: Bugs fixed as of November 27, 2006

(#1596) SoTransferFunction crashed when the fields SoTransferFunction::predefColorMap and colorMap weren't set. The crash happened in SoTransferFunction::getCMBuffer. [P3]
(#1597) UNSIGNED_SHORT volumes couldn't be displayed when colormap entries > 4096. It worked with VolumeViz 5.x. [P3]
(#1619) When using VolumeVizLDM to load a volume, then using a volume geometry node (e.g., SoVolumeIndexedTriangleStripSet) to construct a surface which was under an SoLevelOfSimplification node, the surface would flicker a few times if rendering strategy was set to "Frame Per Second". [P3]
(#1621) GPU data combining (coblending) failed when a second volume and shader were loaded. When one SoVolumeData was loaded, and before it finished loading, if you inserted a second SoVolumeData and SoVolumeShader, a crash occurred. [P3]
(#1641) It was not possible to pass a 2D texture as a parameter to a volume shader (fragment shader) as a sampler2D parameter. In fact, the transfer function texture image appeared in the texture unit that should contain the application texture image.

Now it is possible to pass a 2D texture to a volume shader. This functionality is interesting because it could be useful to pass a 2D texture image to use as a height field for clipping or to use as a 2D transfer function. [P3]
(#1687) SoVolumeRender crashed when working with volumes of certain sizes, for example SoVolumeData 512^3, signed byte or float. [P3]
(#1692) When the two opposite surfaces of SoROIManip were pulled together by the mouse, they could no longer be separated. Fixed in SoTabPlaneDragger. [P3]
(#1700) Environment variable IVVR_SEGY_USE_FLDR (used with SoVRSegyFileReader) did not work. As a result, the volume dimensions, specifically number of traces per inline, were not detected correctly by the SEGY reader. [P3]

Patch 6.0.1: Bugs fixed as of July 12, 2006

(#1463) There was poor performance or an OpenGL error when handling slim volumes. The bad behavior depended on the graphics board: poor performance on GeForce FX5700, OpenGL error on GeForce FX1000. This problem seemed to occur with slim volumes only when one dimension was inferior to the tile size. [P1]
(#1470) SoVolumeIndexTriangleStripSet crashed if it had fewer than 3 vertices. Note that less than 3 vertices is not valid geometry, but should not crash. [P1]
(#1495) The GPU Composition demo (GPUDataCompose.cxx) didn't work on some machines that seemed to have the necessary OpenGL support. This problem was due to display driver problems (Nvidia) and a problem in the demo itself (on ATI). [P3]
(#1499) The Volrend demo crashed when launched under gdb. The error message was:

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 4077394864 (LWP 17291)] 0xf72f74be in
    SoLDMIOManager::loaderThreadRoutine () from
    $OIVHOME/lib/libInventorVR.so
[P1]
(#1517) SoVolumeData::LDMDataAccess::getData(SbBox3i32) crashed on a null pointer access if called before any other volume query. [P1]
(#1521) In some cases, voxels greater than max data range weren't displayed with the max colormap entry. [P1]
(#1522) Voxels lower than than min data range value were displayed in black when bump mapping was enabled. These voxels were displayed with the first colormap entry when bump mapping was off (enableBumpMapping =FALSE), but they were black when bump mapping was on. The normals weren't being handled correctly. [P1]
(#1525) There were SoVolumeFaceset discontinuities when intersecting ortho slices (SoOrthoSlice). [P1]
(#1539) SoVolumeIsosurface didn't correctly handle SoDataRange. The shape that was displayed was incorrect.
1. When the isovalue was outside the data range, the entire shape was not displayed with the same color (first or last entry of the cmap).
2. When the isovalue was inside the data range, the shapes displayed with or without enabling the data range were different (more voxels were displayed when data range was disabled). [P1]

6.0 Final release

(#836) Non-fully transparent tiles sometimes weren't refined when setIgnoreFullyTransparentTiles was set to TRUE. They were sometimes considered as fully transparent and were ignored during the refinement process of the resolution.
(#924) The SoVolumeData::setReader call needed to invalidate the already loaded data. It does now.
(#1087) SoOxxxSliceDetail::getValueDataPos crashed when called while the volume was still being loaded.
(#1160) There was a crash when reading certain SEGY files in paging mode.
(#1177) When the min and max values of one of the subvolume dimensions were the same, e.g., zmin = zmax, SoVolumeData::getLdmDataAccess().getData returned size of 2 for that dimension. The correct size for that dimension is 1.
(#1224) SoVolumeIndexedFaceSet wasn't displayed if the shape included transparent materials and BLEND or SORTED_LAYERS_BLEND transparency type was enabled.
(#1240) When ortho slices were displayed on two viewers, only one viewer displayed the correct image.
(#1252) The display of an SoOrthoSlice and an SoVolumeSkin crashed when the transparency type SORTED_LAYERS_BLEND was enabled.
(#1266) For some SEGY files, the the LDM converter computed incorrect min/max values.
(#1267) Methods SoXXXSliceDetail::getValue and SoVolumeDetail::getProfileValue only returned int values. Now they can return float values as well.
(#1365) An LDM file crashed in in SoVolumeReader. This crash was fixed.
(#1366) On the border of volumes and in LDM mode, volumeRender colors were interpolated with extra data set to 0. This data is now set to the volume border values to avoid unexpected interpolated colors.
(#1369) The Zmax face of an SoVolumeSkin was incorrectly displayed when the Z size of the tile was equal to the Z volume size.
(#1381) Image update of a volume was sometimes only partial and required the user to click on the view to make it update completely.
(#1382) Loading two large volumes in LDM mode caused a crash.
(#1383) You could not use clip planes (e.g., SoClipPlane) with volume geometry nodes (e.g., SoVolumeIFaceSet) because volume geometry noded used all of the OpenGL clipping planes internally.
(#1384) A random crash was observed when loading multiple volumes in LDM mode.
(#1385) Using a perspective camera, volume update sometimes stopped on some bricks when moving fast. The user had to click on it to make it update. There was no such problem using an orthographic camera.
(#1386) Moving a volume geometry surface (e.g., SoVolumeFaceSet) out of the volume could cause a crash in release mode.
(#1401) The depth buffer was not updated correctly using SoVolumeGroup. Geometry that should have been hidden by the volume group (according to OpenGL depth buffer test) was not always hidden.

VolumeViz 5.0

Patch 5.0.5: Bugs fixed as of October 2, 2005

(#1261) The SoTransferFunction::reMap method didn't map the correct colors when applied to colormaps that were not predefined. Min/max values were interpreted as relative indices (instead of absolute) to the current remap. (Note: The problem still occurs under some circumstances.) This issue was introduced in VolumeViz 5.0.4. [P5]
(#1263) LDM converter always used the first file name defined by option -o as the destination file. This was a problem if the converter was called several times in the same application. [P5]
(#1276) The LDM converter 5.0.4 was able to write to an existing .dat file but was not able to create a new .dat file. This issue was introduced in VolumeViz 5.0.4. [P5]
(#1299) Global opacity (modifying transparency of volume rendering material) did not work correctly on VolumePro boards because of floating point precision problems. [P5]
(#1316) VolumeViz shapes didn't allow data interpolation on graphics cards that don't support the fragment program extension. Data interpolation had been available with OIV 4.0.6. It's available again. [P5]
(#1320) With multiVolumes =TRUE and a flat volume, the picture was incorrect. White pixels become black. [P5]

Patch 5.0.4: Bugs fixed as of June 6, 2005

(#1089) SoVolumeSkinDetail couldn't be accessed in a selection callback. [P4]
(#1114) Strange behavior was observed using setMaxMainMemory with two volumes. It worked correctly if you called fixParams(TRUE). Otherwise, after calling setMaxMainMemory on the second volume, the maxMainMemory parameters had strange values. [P4]
(#1128) Field SoxxxSlice::alphaUse set to ALPHA_AS_IS didn't allow the display of fully transparent SoTransferFunction colors remapped by the user. In AS_IS mode, full transparent colors were displayed opaque. [P4]
(#1130) LDM converter didn't provide the right numSignificantBits on value -32768 for signed 16-bit data (in the LDM file header). [P4]
(#1131) The normal computation of SoxxxSlice nodes was incorrect in some cases. The Z component of the slice normals should have been reversed when the determinant of the current transformation matrix was negative. The fix will allow the expected lighting when a negative scale is applied to slices.
(#1161) When working with volumes having a very small depth, the LDM converter created LDM files that were too large (larger than the input file). [P4]
(#1167) SoLDMConverter generated an invalid output file name when the filename set in option -o was too long. [P4]

Patch 5.0.3: Bugs fixed as of March 11, 2005

(#941) SoOrthoSlice and SoObliqueSlice shapes weren't textured when the scene also included SoIndexedTriangleStripSet shape(s). Only the initial display of ortho/oblique slices was textured in paging mode. None of the ortho/oblique slices were textured in LDM mode. The problem only occurred when transparency was enabled. [P3]
(#978) Enabling paging (SoVolumeData::setPaging(TRUE)) and multiple volumes (SoVolumeGroup::multiVolumes = TRUE) did not work correctly. On some boards, the picture was incorrect (white); on others, the application crashed. [P3]
(#1018) The VolRend demo enabled the SpaceBall device by default. [P3]
(#1020) Starting with OIV 5.0, on systems with no OpenGL acceleration, volumes in paletted mode (SoVolumeData::usePalettedTexture = TRUE) were displayed as a white cube. [P3]
(#1028) LDM conversion of a single-slice volume failed when overlapping was enabled (SoVolumeData::LDMResourceParameter::setOverlapping). [P3]
(#1031) LDM conversion produced a zero numSignificantBits value on 32-bit volumes having data coded on less than 8 bits per channel. [P3]
(#1046) When dealing with large data sets and a small SoRoiManip, moving the SoRoiManip was jerky in constrained mode. [P3]
(#1050) SoVolumeIndexedFaceset crashed when applied to an empty volumeData. [P3]
(#1054) SoObliqueSlice textures were wrong when the ratio ijk/xyz was not 1. In other words when voxels were not cubes but parallelpipeds. [P3]
(#1071) When a volume geometry node, e.g., SoVolumeFaceSet, was placed under an SoLOD or SoLevelofSimplification node and constant frame rate was enabled on the viewer, the scene graph was constantly redrawn even when no user interaction. This could produce visible flicker (switching between low and high resolution children under the SoLOD). [P3]
(#1099) Volumes would not display if loaded while the viewer was in stereo mode. (Loading the volume first, then switching to stereo mode worked fine.) [P3]
(#1103) Volume geometry (SoVolumeFaceSet, etc.) disappeared if there was transparency and rendering was delayed. [P3]
(#1109) [Enhancement] Previously, the LDM reader reported all errors as "File not found". It has been enhanced to clearly say when the read failed because of an XML syntax error or a missing tag in the LDM file header. [P3]

Patch 5.0.2: Bugs fixed as of December 10, 2004

(#724) There was a visual discontinuity in the rendering of some orientations of an oblique slice. To avoid this problem, request interpolation of the data by setting the new environment variable IVVR_OBLIQUESLICE_DATAINTERPOLATION to 1. [P2]
(#893) The AmiraMesh reader (SoVRAmFileReader) handled short data as unsigned short type and ushort data as short type. [P2]
(#894) SoOrthoSlice sometimes worked incorrectly with SoRayPickAction and/or returned incorrect coordinates. [P2]
(#901) [Linux] SoVolumeDetail::getFirstNonTransparentValue gave a segmentation fault. [P2]
(#910) Noticeable seams appeared in the SoVolumeFaceSet texture (paging mode). The same effect was seen with SoVolumeTriangleStripSet. [P2]
(#916) When the ROI manip box became too thin, the region of interest was invalidated and the whole volume was displayed. [P2]
(#917) ROI manip and subvolume boxes became very unstable when you switched from one of them to the other one and then tried to move it. [P2]
(#920) Enabling volume lighting was slow when using the VolumePro board with paging ON. This bug appeared only when IVVR_SLICE_DATA_EXT was set to 1. [P2]
(#923) SoVolumeSkin crashed when applied to an empty SoVolumeData node. SoVolumeSkin is now more robust and simply displays nothing when the volume data node is empty. [P2]
(#930) SoVolumeSkin::useRGBA didn't invalidate the current textures displaying the skin. [P2]
(#932) Similar to eBug #868: volume was incompletely displayed when loaded as a non-LDM file in LDM mode. [P2]
(#934) [Enhancement] A new getData method was added to SoVolumeData::LDMDataAccess, where the SbLine parameter was replaced by an array of SbVec3s values (defining a polyline). [P2]
(#938) The method SoLDMConverter::convert crashed when called twice in the same application. [P2]
(#939) [Windows] SoLDMConverter::convert opened/closed several DOS consoles when application was built in Windows subsystem mode. [P2]
(#946) After you created and deleted an SoVolumeData node, the default main and texture memory values were invalid. [P2]
(#953) If SoVolumeSkin::useRGBA was enabled, the display of a volume skin wasn't updated when the transfer function was changed. [P2]
(#954) If the size of the roiManip manipulator was modified, then black lines appeared on orthoSlices and obliqueSlices clipped by a roiManip in exclusionBox mode. [P2]
(#962) SoLDMConverter crashed if the specified temporary directory did not exist. [P2]
(#970) [Solaris] By default, the LDM converter built a little endian file instead of a big endian file. [P2]
(#971) The LDM reader didn't use the word format tag (big endian or little endian) specified in the LDM header file. It just used the current machine word format. [P2]

Patch 5.0.1: Bugs fixed as of October 8, 2004

(#245) VolumeViz was fetching many more bricks than required. [P1]
(#834) The VolRend demo application didn't restore properly the colormap decoration when the button VolumeRendering>Colormap was switched off/on. This problem went away when eBUG 859 (see Open Inventor page) was fixed. [P1]
(#855) ROIs were sometimes displayed with an unexpected resolution. [P1]
(#856) With IVVR_SLICE_DATA_EXT 1 set and setPaging TRUE, ortho slice images were corrupted. [P1]
(#863) The SEGY file reader in VolumeViz 5.0 did not read files that previously could be read in VolumeViz 5.0 Beta4. [P1]
(#868) Under some circumstances, there was an incomplete update of a volume using SoVolumeData::updateRegions, and the reloading. was extremely slow. [P1]
(#880) [Windows] PrintPreview caused certain geometry nodes (SoOrthoSlice, SoObliqueSlice, SoVolumeSkin) to be rendered incorrectly after the PrintPreview window was closed. [P1]

If you are currently using shared contexts as a workaround, e.g., before the render, you've added:
```
      osr->setShareContext(myViewer->getShareContext());
```
where osr is your offscreen renderer

this is no longer necessary. However, it is still recommended because it allows the display lists and texture objects to be shared between the on-screen and off-screen render context. Depending on your application, this can signficantly improve performance.

NOTE: You must have a graphics card that supports shared contexts to be able to use this feature. It is necessary (but not sufficient) for your card to support Pbuffers.
(#885) Y slice roaming had a significant performance regression. [P1]
(#886) Modifying the color map (SoTransferFunction::colorMap) failed when using SoVolumeGroup if SoVolumeGroup::multiVolumes was TRUE. This worked correctly in OIV5.0 Beta. [P1]

5.0 Final release

(#770) When IVVR_SLICE_DATA_EXT was set, the texturing of the alternate representation of the slice was not correct. The texturing on the slice corresponded to Z interpolation instead of X.
(#771) In paging mode, the SoVolumeSkin was not illuminated when it should have been.

VolumeViz 4.0

Patch 4.0.6: Bugs fixed as of January 20, 2003

(#375) Paletted textures weren't correctly enabled on Linux (and possibly on other UNIX platforms).
(#476) The dynamic modification of the VolumeViz transfer function was based on an obsolete OpenGL extension.
(#699) The clipping slice blocked visibility of volume with ALPHA_AS_IS. When a slice with clipping enabled was rendered before the volume, the volume should have been visible wherever the slice was completely transparent (alpha = 0). This worked for ALPHA_BINARY, but not for ALPHA_AS_IS.

Patch 4.0.5: Bugs fixed as of November 10, 2003

(#522) (Enhancement) Request to be able to specify NEAREST or LINEAR interpolation for volume geometry. Previously volume geometry used only LINEAR interpolation. SoOrthoSlice allowed both LINEAR and NEAREST, and therefore one could get visually different results on an orthoslice and a volume. (Duplicate of #665) [P5]
(#524) The volume geometry texture coords were incorrect. This could be seen by comparing a simple rectangle volume geometry with an orthoslice. [P5]
(#665) (Duplicate of 522) [P5]
(#666) An SoTransform could cause the textures to disappear from an SoVolumeTriangleStripSet. [P5]

Patch 4.0.4: Bugs fixed as of September 19, 2003

No change.

Bugs fixed in patches 1, 2, and 3

(#480) SoVolumeDetail::getFirstNonTransparentValue did not take the ROI into account.
(#523) Orthoslices were not positioned at the center of the voxels they represented. This could be seen when orthoslices on different axes intersected.
(#533) There was a large memory leak in VolViz when caching was turned off. Numerous textures were being created but never deleted.
(#537) SoText2D rendering bug in VolumeViz 4.0 on NuTCRACKER and Win32. SoText2 was ugly (very fragmented) when used with VolumeViz after resizing the window. The problem was related to the GL_UNPACK_ALIGNMENT value.
(#558) Blocky artifacts appeared at the brick boundaries when the volume was automatically subsampled.
(#560) There was a large memory leak when switching between models in the VolRend demo.
(#563) VolumeViz did not correctly support multiple VolumePro boards in the same machine. All multiboard render modes are now supported.

OFFICIAL RELEASE: Bugs fixed as of March 27, 2003

(#166) A GLX error (GLXBadRenderRequest) occurred when the example volRend was remotely displayed on Exceed3D or Reflection servers.
(#167) The volRend example crashed the Reflection server.
(#190) Changing the colors of one SoTransferFunction affected the colors of all other volume visualizations.
(#196) Volume interpolation was not updated for all volume slices (in texture 2D mode). Interpolation changes to this mode affected only the current set of volume slices.
(#201) VolumeViz couldn't render volumes using different transfer functions. All the volumes were displayed with the same colormap (on UNIX of the last volume, on Windows with a gray colormap).
(#202) Volume rendering drew wrong picture if translation or rotation was applied. Bricks were misoriented or missing. If you added a translation or rotation in front of the volume, bricks were misoriented or missing. They would flash on/off or draw in different orientations as you rotated the scene.
(#204) Volumes with size different than 2-of-power-of-n (as 63x63x63) had random noise on the edges of slices (2D textures are used to display volume).
(#239) VolumePro: Data was not loaded if paging enabled and data is in application memory.
(#240) It was not possible to set the page size before the volume was loaded.
(#241) VolumePro: Could not load very large volumes. Large volumes are not automatically subsampled to fit in available VolumePro memory.
(#266) Crash loading 4GB volume.
(#277) VolumePro: Could not display multiple subvolumes on VolumePro. A big white rectangle was displayed.
(#285) Lighting didn't work with VolumePro 1000.
(#324) SoVolumeData was missing some queries. The following set/enable methods didn't have corresponding queries:
void setTexMemorySize(int size);
void setPageSize(int size);
void setPageSize(SbVec3s& size);
void enableSubSampling(SbBool enable);
void enableAutoSubSampling(SbBool enable);
void enableAutoUnSampling(SbBool enable);
void setSubSamplingMethod(SubMethod method);
void setSubSamplingLevel(const SbVec3s& ROISampling,...
(#394) SoVolumeRender node didn't support volume data with Z dimension equal to 2.
(#424) The position of an orthoSlice was incorrect. Considering a volume having 3 slices along the Z axis, slice number 0 (SoOrthoSlice::sliceNumber) was placed at an extremity of the volume (OK). However, slice number 1 was not positioned in the middle of the volume, and slice number 2 was positioned at 2/3 of the volume depth (instead of at the other extremity of the volume).

VolumeViz Fixed Bugs

VolumeViz 7.2

7.2 Final Release

VolumeViz 7.1

7.1.1 Patch : Bugs fixed as of June 28, 2008

7.1 Final release

VolumeViz 7.0

Patch 7.0.1 : Bugs fixed as of February 20, 2008

7.0 Final release

VolumeViz 6.1

Patch 6.1.2: Bugs fixed as of July 19, 2007

Patch 6.1.1: Bugs fixed as of May 29, 2007

6.1 Final release

VolumeViz 6.0

Patch 6.0.3: Bugs fixed as of December 4, 2006

Patch 6.0.2: Bugs fixed as of November 27, 2006

Patch 6.0.1: Bugs fixed as of July 12, 2006

6.0 Final release

VolumeViz 5.0

Patch 5.0.5: Bugs fixed as of October 2, 2005

Patch 5.0.4: Bugs fixed as of June 6, 2005

Patch 5.0.3: Bugs fixed as of March 11, 2005

Patch 5.0.2: Bugs fixed as of December 10, 2004

Patch 5.0.1: Bugs fixed as of October 8, 2004

5.0 Final release

VolumeViz 4.0

Patch 4.0.6: Bugs fixed as of January 20, 2003

Patch 4.0.5: Bugs fixed as of November 10, 2003

Bugs fixed in patches 1, 2, and 3

OFFICIAL RELEASE: Bugs fixed as of March 27, 2003

VolumeViz 3.0