Hi Paul, On Wed, Jan 21, 2009 at 3:05 PM, Paul Melis <p...@science.uva.nl> wrote: >> 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?
Other members of the community suggested GDCM as an option, and I briefly looked at it, but having already written the ITK path, and most of the DCMTK path I stuck with the later routes rather than take on another implemented. Others are welcome to dive in an implement a GDCM plugin. > 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. Good question, GLSL support is essential for any sensible volume rendering, the FixedFunctionTechnique fallback is very basic, and I have no plans on trying to emulate the advanced techniques possible with a pure GLSL path. Within GLSL there are obviously different capabilities w.r.t drivers and hardware, and I must admit I haven't spent time considering how to manage these differences. You might be able to rewrite the shaders to make them more backwards compatible and still retain the existing functionality, or it might be necessary to implement another VolumeTechnique that supports the cards that have GLSL, but not the full capabilities of more modern cards. I'm open to suggestions. For a point of reference I've been developing against Geforce 6 series upwards. > 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. Integration with existing scene graph is pretty straight forward - just add a VolumeTile to the scene graph with the appropriate Locator/Layer/Properties/Technique attached an it'll automatically rendering the volume. No custom OpenGL paths are used, the VolumeTechniques that have been implemented so far both use standard scene graph elements to set up state and rendering primitives, this ensures that it'll play nice with the rest of the OSG. I don't expect future volume rendering techniques to require any custom OpenGL paths either as we already have vertex, geometry and fragment shaders built into the core OSG. It shouldn't be too difficult to integrate ITK with osgVolume, as ITK allows you to adapt external representations of imagery both in and out of ITK. There is an example of this in the dicom plugin's ITK code path. One possibility would be to provide some glue classes in the include/osgVolume header directory to facilitate integration, this would have to be done entirely in the header though as I don't want to add any external dependencies to osgVolume - it's a pure OSG based solution so is easy to port and maintain. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
