Hi Robert,

Robert Osfield wrote:
Over the last ten days I've been pulling together parts of my work on
volume rendering to create a usable osgVolume NodeKit.  The osgVolume
NodeKit is still in it's infancy, but should be have enough features
for end users to start trying it out.  This rev of osgVolume will be
the base for the next stable OSG-2.8 release, and should provide the
basic framework for us to start building on more advanced and scalable
features once 2.8 is out the door.

The basic ideas behind osgVolume is that a osgVolume::Volume group
node decorates all the tiles in a volume, the tiles are represented by
osgVolume::VolumeTile nodes that are non-intersecting bricks.  Each
tile has an its imagery associated with it attached via an
osgVolume::Layer, this might be a CompositeLayer if you have multiple
attributes, or a single ImageLayer.  The layers and tiles are located
in space via osgVolume::Locator which is a effectively 4x4 transform
matrix that positions the local 0,0,0 to 1,1,1 coords of the tile or
layer into the 3D model coords.  How the basic rendering algoirithm
used to render tiles is provided the VolumeTechnique that is attached
to the VolumeTile, currently there is the FixedFunctionTechnique and
RayTracedTechnique, and rendering hints/options within these
techniques are controlled via osgVolume::Property objects that are
attached the the imagery layers.
Nice! I just quickly tried to digest the above, but it sounds like a sensible way of organizing the concepts involved.
The number of classes at play may at first seem a bit bewildering, but
hopefully one you start diving into code it'll become obvious how they
all fit together.  The classes have been put together to make it
possible to extend osgVolume to handling lots of custom rendering
techniques, and also to scale the size of imagery that we can tackle.
For instance it should be possible with this NodeKit to build paged
volumes leveraging osgVolume::VolumeTile coupled with PagedLOD, much
in the same way that you can built paged terrain databases that couple
osgTerrain::TerrainTile with PagedLOD.


-- osgVolume features that are now checked into svn/trunk are:

   Dicom loader (DCMTK or ITK based)
I think I saw you mention at one point that GDCM might also be included as a loader? The reason I ask is that ITK is a fairly large dependency, while DCMTK doesn't seem to be developed anymore (the latest release I know of is from 2005), while GDCM is actively developed. Or does ITK use GDCM under the hood?
   Support for non power of two textures + compressed textures.

   Support for 4D texture via osg::ImageSequence

   Support for rendering techniques (selected by osgVolume::Properties
+ osgVolume::VolumeTechnique ) :

         osgVolume::FixedFunctionTechnique : basic fixed function
path, screen aligned image stack, with alpha function support for
clipping out fragments.

         osgVolume::RayTracedTechnique : ray tracing using GLSL shaders:

              support for transfer functions with ability to either do
pre-computed or computed in shaders

              basic intensity rendering +  with alpha function support
for clipping out fragments.

              lit intensity rendering +  with alpha function support
for clipping out fragments.

              lit iso surface rendering (value controllable interactively)

              maximum image project rendering +  with alpha function
support for clipping out fragments.

    Support for properties switch for switching between different
properties/rendering techniques.

    Support for interactively adjusting iso surface values,
transparency, sample density and alpha function, and switching of
properties via event callback
    that can be attached to the volume tiles.
What's the requirements for all these features in terms of GPU being used? I tried a previous version from SVN some time ago and got an error during shader compilation that my card (FX5200) doesn't support while loops.
The osgvolume example illustrates how to set up osgVolume::Volume +
VolumeTile nodes, along with selection of the osgVolume::Property
objects that inform the rendering backend what type of rendering is
required

-- Features not yet included:

Features that aren't included yet is support for mixing polygonal
models with the ray traced volumes, and handling of multiple
intersecting volume image layers.  The osgVolume class design will
support both these key features but right now the shaders aren't in
place to support these rendering techniques.

Also not tackled yet is tiling of the volume, again the class design
does support this, but I haven't yet attempted building a volume from
many tiles - currently I've just focused on a volume containing a
single tile.

I have lots of ideas in this direction so if you're interested I can expand.

-- Ready for testing an feedback!
This is fantastic work! I've been doing volume rendering mostly with VTK, but VTK is really hard to integrate with other rendering packages (e.g. OSG) as its use of OpenGL is spaghetti-strewn throughout its classes and there's no clean encapsulation of OpenGL state. If the OSG volume rendering manages to approach the VTK level (which shouldn't be that hard) we would have a nice alternative.

Paul

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to