<div dir="ltr"><div><div><div><div><div><div><div>Hi all,<br><br></div>I have a series (in the end, probably hundreds) of roughly cylindrical volumes. Each volume represent ~0.1-1 meter of a rock core. Together the volumes form the complete (~500 m) rock core. Each volume is stored in a HDF5-file, and I've implemented a basic VTK reader class to load a volume from such a file.<br><br></div>I now need to provide a sideways-scrollable view of these rock cores, where at any time only 1-3 meter (depending on zoom) is visible, as shown in the attached rough sketch.<br><br></div>(As a side note: The original plan was for our software to also provide a (semi-)automatic way of orienting/positioning the pieces of the broken core, so they fit together the way they're supposed to (the way they sat in the mountain), but because of the problems with rendering multiple volumes which intersect in 3D space, we've postponed that idea for now and will render each volume disjoint from the others.)<br><br></div>What I'm pondering now is how to best set up a VTK pipeline to drive this view. The volumes are quite high res (~4000x250x250 voxels per meter), so not much more than what is currently shown in the view can be kept in memory.<br><br></div>My first idea is to have a set of reader + ExtractVOI pairs, and based on the currently shown section of the core, configure them as necessary to load the required extents of the volume(s). The set of such reader + ExtractVOI pairs (source paths into the pipeline so to speak) would need to be dynamic, since along some sections of the core, it is broken up into many small volumes (requiring more reader + ExtractVOI pairs), and sometimes consists of fairly large 1 meter chunks (requiring fewer reader + ExtractVOI pairs).<br><br></div>First of all, does this idea sound sane? At any point in time, I would then have maybe 3-4 reader + ExtractVOI pairs, each giving rise to a volume, and each having their own volume property + mapper and all being rendered by the same renderer.<br><br></div><div>The only other solution I've thought of would be to make a special reader that works with multiple files, and which, based on the requested extent loads data from these files. I would then only have a single ExtractVOI which extracts the required volume, and the reader takes care of loading the required data to form a volume based on what is currently in view. But I'm not sure I like this idea because I think down the road I'd like it to be multiple volumes, not just one.<br><br></div><div>Another question is interactivity: I realize that it's probably unrealistic to have a scrollbar the way I've drawn it in the sketch, since loading the volumes will be quite intensive and block the UI for a while, which would make the scrolling operation "jerky". I've read that there are some problems with putting parts of a VTK pipeline in a separate thread, but is there any way threading could help me out here? If not, I think I'll go with simpler left/right buttons, which would move the view by some fixed amount. I think then the user would be more forgiving with the UI blocking for a short while while the new volume data is loaded.<br><br></div><div>I'm very grateful for any advice here, as I'm new to VTK. Has anyone done something similar to this before?<br><br></div><div>Cheers,<br></div><div>Elvis<br></div></div>