First, the two primary questions...


What journal articles or 3D Graphics books describe the best methods
for computing a series of polygons that would cut through my data
perpendicular to the direction of view?

What journal articles or 3D Graphics books describe the best methods
for generating texture coordinates for this series of polygons?


Now, the background...


The datasets I will be working with could easily involve Gigabytes
worth of data. The datasets are boxes. They are primarily collected by
a user using a digital camera and taking a picture at different z-stage
positions.

The implementation I eventually use would have to support interactive
rotating by the user, which would involve using a smaller number of
slices during the rotation and then rendering a high-quality version of

the object once the rotation was complete.


Secondary question...


I believe the best technique for rendering 3D Volume datasets to use is
the one described at:

<http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node181.html>

I am assuming that this is the general technique that all
implementations use and the quality of the output depends upon how Step
4 is handled.

     Compute a series of polygons that cut through the data
     perpendicular to the direction of view. Use texture
     coordinate generation to texture the slice properly with
     respect to the 3D texture data.

Would I be correct in this belief and assumption?

"Eric" <ericgorr@gmail.com> wrote in message 
news:1137685542.557061.294090@g47g2000cwa.googlegroups.com...
> First, the two primary questions...
>
>
> What journal articles or 3D Graphics books describe the best methods
> for computing a series of polygons that would cut through my data
> perpendicular to the direction of view?
>
> What journal articles or 3D Graphics books describe the best methods
> for generating texture coordinates for this series of polygons?
>
>
> Now, the background...
>
>
> The datasets I will be working with could easily involve Gigabytes
> worth of data. The datasets are boxes. They are primarily collected by
> a user using a digital camera and taking a picture at different z-stage
> positions.
>
> The implementation I eventually use would have to support interactive
> rotating by the user, which would involve using a smaller number of
> slices during the rotation and then rendering a high-quality version of
>
> the object once the rotation was complete.
>
>
> Secondary question...
>
>
> I believe the best technique for rendering 3D Volume datasets to use is
> the one described at:
>
> <http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node181.html>
>
> I am assuming that this is the general technique that all
> implementations use and the quality of the output depends upon how Step
> 4 is handled.
>
>     Compute a series of polygons that cut through the data
>     perpendicular to the direction of view. Use texture
>     coordinate generation to texture the slice properly with
>     respect to the 3D texture data.
>
> Would I be correct in this belief and assumption?
>

Probably not. Perpendicular slices can give rise to severe aliasing unless 
they are ridiculously close together, if you think about it. Simple slicing 
of a single 3D texture is not a very great way to volume render; there are 
considerably better techniques to introduce lighting and 
pseudo-isosurfacing.
Effectively rendering gigabytes of data is the subject of high-end research. 
(I hope you have a large cluster, and a *lot* of time if you want to build 
this software from "scratch").

I'd recommend that you look at the recent (2003-2005) IEEE Vis proceedings.

go to http://www.computer.org/portal/site/ieeecs/index.jsp and look for 
"vis'05" in the Digital library.

Or consider commercial solutions which you wanot be able to duplicate in a 
year's worth of work -- one example is www.fovia.com , another is from 
www.tgs.com

-jbw

jbwest wrote:
> "Eric" <ericgorr@gmail.com> wrote in message
> news:1137685542.557061.294090@g47g2000cwa.googlegroups.com...
> > Secondary question...
> >
> >
> > I believe the best technique for rendering 3D Volume datasets to use is
> > the one described at:
> >
> > <http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node181.html>
> >
> > I am assuming that this is the general technique that all
> > implementations use and the quality of the output depends upon how Step
> > 4 is handled.
> >
> >     Compute a series of polygons that cut through the data
> >     perpendicular to the direction of view. Use texture
> >     coordinate generation to texture the slice properly with
> >     respect to the 3D texture data.
> >
> > Would I be correct in this belief and assumption?
> >
>
> Probably not. Perpendicular slices can give rise to severe aliasing unless
> they are ridiculously close together, if you think about it. Simple slicing
> of a single 3D texture is not a very great way to volume render; there are
> considerably better techniques to introduce lighting and
> pseudo-isosurfacing.

What are those considerable better techniques?
Can you point to any specific journal articles?

> Effectively rendering gigabytes of data is the subject of high-end research.
> (I hope you have a large cluster, and a *lot* of time if you want to build
> this software from "scratch").

If it truly is this difficult, I will probably just use the technique
of have three sets of texture maps, one for each axis and select a set
based on which axis was pointing most towards the user.

Fairly straightforward and probably good enough.

I merely wanted to try to do better, but large clusters and a lot of
time are simply not part of the equation.

> I'd recommend that you look at the recent (2003-2005) IEEE Vis proceedings.
> go to http://www.computer.org/portal/site/ieeecs/index.jsp and look for
> "vis'05" in the Digital library.

I will take a look.

> Or consider commercial solutions which you wanot be able to duplicate in a
> year's worth of work -- one example is www.fovia.com , another is from
> www.tgs.com

Neither of these systems seem to be supported under MacOSX.

On 19 Jan 2006 07:45:42 -0800, "Eric" <ericgorr@gmail.com> wrote:
>     Compute a series of polygons that cut through the data
>     perpendicular to the direction of view. Use texture
>     coordinate generation to texture the slice properly with
>     respect to the 3D texture data.

Just trying to help in a lazy way. :-D 

Um, Voxels?

<quote>
From Wikipedia, the free encyclopedia.
A voxel (a portmanteau of the words volumetric and pixel) is a volume
element, representing a value in three dimensional space. This is
analogous to a pixel, which represents 2D image data. Voxels are
frequently used in the visualisation and analysis of medical and
scientific data. 
</quote>

Good Luck

"Eric" <ericgorr@gmail.com> wrote in message 
news:1137687601.220688.307470@o13g2000cwo.googlegroups.com...
>
> jbwest wrote:
>> "Eric" <ericgorr@gmail.com> wrote in message
>> news:1137685542.557061.294090@g47g2000cwa.googlegroups.com...
>> > Secondary question...
>> >
>> >
>> > I believe the best technique for rendering 3D Volume datasets to use is
>> > the one described at:
>> >
>> > <http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node181.html>
>> >
>> > I am assuming that this is the general technique that all
>> > implementations use and the quality of the output depends upon how Step
>> > 4 is handled.
>> >
>> >     Compute a series of polygons that cut through the data
>> >     perpendicular to the direction of view. Use texture
>> >     coordinate generation to texture the slice properly with
>> >     respect to the 3D texture data.
>> >
>> > Would I be correct in this belief and assumption?
>> >
>>
>> Probably not. Perpendicular slices can give rise to severe aliasing 
>> unless
>> they are ridiculously close together, if you think about it. Simple 
>> slicing
>> of a single 3D texture is not a very great way to volume render; there 
>> are
>> considerably better techniques to introduce lighting and
>> pseudo-isosurfacing.
>
> What are those considerable better techniques?
> Can you point to any specific journal articles?

One is shear-warp factorization.
http://www-graphics.stanford.edu/software/volpack/

Lots of ways to use shaders to improve image quality;
http://spire.stanford.edu/raptor/

There are lots of ways to skin the cat.

>
>> Effectively rendering gigabytes of data is the subject of high-end 
>> research.
>> (I hope you have a large cluster, and a *lot* of time if you want to 
>> build
>> this software from "scratch").
>
> If it truly is this difficult, I will probably just use the technique
> of have three sets of texture maps, one for each axis and select a set
> based on which axis was pointing most towards the user.
>
> Fairly straightforward and probably good enough.



I'd try that, then, as gigabyte 3D textures gets to be very messy.
You'll find out fast if the sampling aliasing hurts you.




>
> I merely wanted to try to do better, but large clusters and a lot of
> time are simply not part of the equation.
>



You won't get interactive multi-gigabyte rendering otherwise. ...
So, yea, start with 2D slices, quick & real dirty.



>> I'd recommend that you look at the recent (2003-2005) IEEE Vis 
>> proceedings.
>> go to http://www.computer.org/portal/site/ieeecs/index.jsp and look for
>> "vis'05" in the Digital library.
>
> I will take a look.
>
>> Or consider commercial solutions which you wanot be able to duplicate in 
>> a
>> year's worth of work -- one example is www.fovia.com , another is from
>> www.tgs.com
>
> Neither of these systems seem to be supported under MacOSX.
>

This open source one claims to be;
http://homepage.mac.com/rossetantoine/osirix/Index2.html

and this from a university;
http://www.nephrology.iupui.edu/imaging/voxx/

Although I doubt either can handle out-of-core sized volumes.

jbw

jbwest wrote:
> "Eric" <ericgorr@gmail.com> wrote in message
> news:1137687601.220688.307470@o13g2000cwo.googlegroups.com...
> >
> > I merely wanted to try to do better, but large clusters and a lot of
> > time are simply not part of the equation.
> >
>
> You won't get interactive multi-gigabyte rendering otherwise. ...
> So, yea, start with 2D slices, quick & real dirty.

Well, I don't need interactive multi-gigabyte rendering.

When the user clicks on the model and starts rendering, it would be
perfectly fine to sub-sample the data to the point where interactive
rendering would be practical. Then, when the user stops interacting
with the model, to render the highest possible image.

> This open source one claims to be;
> http://homepage.mac.com/rossetantoine/osirix/Index2.html
>
> and this from a university;
> http://www.nephrology.iupui.edu/imaging/voxx/
>
> Although I doubt either can handle out-of-core sized volumes.

Thanks for the two suggestions and for all your other comments.

"Eric" <ericgorr@gmail.com> wrote in message 
news:1137692675.966051.23180@g14g2000cwa.googlegroups.com...
> jbwest wrote:
>> "Eric" <ericgorr@gmail.com> wrote in message
>> news:1137687601.220688.307470@o13g2000cwo.googlegroups.com...
>> >
>> > I merely wanted to try to do better, but large clusters and a lot of
>> > time are simply not part of the equation.
>> >
>>
>> You won't get interactive multi-gigabyte rendering otherwise. ...
>> So, yea, start with 2D slices, quick & real dirty.
>
> Well, I don't need interactive multi-gigabyte rendering.
>
> When the user clicks on the model and starts rendering, it would be
> perfectly fine to sub-sample the data to the point where interactive
> rendering would be practical. Then, when the user stops interacting
> with the model, to render the highest possible image.
>


Good luck. you'll  have to decimate fiercely; there may be no features left 
to be able to see what you are doing, especially when zoomed in.

-jbw


>> This open source one claims to be;
>> http://homepage.mac.com/rossetantoine/osirix/Index2.html
>>
>> and this from a university;
>> http://www.nephrology.iupui.edu/imaging/voxx/
>>
>> Although I doubt either can handle out-of-core sized volumes.
>
> Thanks for the two suggestions and for all your other comments.
> 

JustBoo wrote:
> On 19 Jan 2006 07:45:42 -0800, "Eric" <ericgorr@gmail.com> wrote:
> >     Compute a series of polygons that cut through the data
> >     perpendicular to the direction of view. Use texture
> >     coordinate generation to texture the slice properly with
> >     respect to the 3D texture data.
>
> Just trying to help in a lazy way. :-D
>
> Um, Voxels?
>
> <quote>
> From Wikipedia, the free encyclopedia.
> A voxel (a portmanteau of the words volumetric and pixel) is a volume
> element, representing a value in three dimensional space. This is
> analogous to a pixel, which represents 2D image data. Voxels are
> frequently used in the visualisation and analysis of medical and
> scientific data.
> </quote>

I am uncertain how this relates to computing the series of polygons
(which would strictly be rectangles in my case).

Or, are you suggesting an alternative method of creating millions or
billions of colored cubes? (i.e. Volumn Splatting I believe is the term
here)

On 19 Jan 2006 13:16:17 -0800, "Eric" <ericgorr@gmail.com> wrote:

>JustBoo wrote:
>> Um, Voxels?

>I am uncertain how this relates to computing the series of polygons
>(which would strictly be rectangles in my case).
>
>Or, are you suggesting an alternative method of creating millions or
>billions of colored cubes? (i.e. Volumn Splatting I believe is the term
>here)

Yes. They are used for MRI/Cat scans, Perfect for "slices." I am told
that the newer high-end (gaming) video cards handle large voxel data
sets now without too much trouble. Usually people doing this sort of
thing have access to the high-end hardware. Just a suggestion. <shrug>

"Not all those who wander are lost." - J.R.R. Tolkien

JustBoo wrote:
> On 19 Jan 2006 13:16:17 -0800, "Eric" <ericgorr@gmail.com> wrote:
>
> >JustBoo wrote:
> >> Um, Voxels?
>
> >I am uncertain how this relates to computing the series of polygons
> >(which would strictly be rectangles in my case).
> >
> >Or, are you suggesting an alternative method of creating millions or
> >billions of colored cubes? (i.e. Volumn Splatting I believe is the term
> >here)
>
> Yes. They are used for MRI/Cat scans, Perfect for "slices." I am told
> that the newer high-end (gaming) video cards handle large voxel data
> sets now without too much trouble. Usually people doing this sort of
> thing have access to the high-end hardware. Just a suggestion. <shrug>

So, do you have any specific pointers to journal articles, etc. which
would discuss good algorithms?

"JustBoo" <JustBoo@BooWho.com> wrote in message 
news:hr10t1t5b074p8oodh9qkcjpsolgceohnv@4ax.com...

> Yes. They are used for MRI/Cat scans, Perfect for "slices." I am told
> that the newer high-end (gaming) video cards handle large voxel data
> sets now without too much trouble. Usually people doing this sort of
> thing have access to the high-end hardware. Just a suggestion. <shrug>

Volume rendering using the 3D medical image as a volume
texture and using polygons as the OP suggested works just
fine on standard consumer hardware.  The aliasing problems
are usually because of the slice spacing in the original image,
not because of the polygon spacing.  An MRI can have something
like 5 mm spacing between slices, but 1 mm spacing within a slice.
Resampling a 256x256x32 image to 256x256x256 eliminates a lot
of the visual problems.

Choosing polygons that are always perpendicular to the view
direction does not give enough improvement in visual quality
to justify using them.  Consider avoiding the switching among
the three sets of axis-parallel polygons and just use polygons
for all the axes.  Instead of M polygons for a single axis-parallel
set, use 3*N polygons, N per axis, with 3*N < M.

--
Dave Eberly
http://www.geometrictools.com

Dave Eberly wrote:
> "JustBoo" <JustBoo@BooWho.com> wrote in message
> news:hr10t1t5b074p8oodh9qkcjpsolgceohnv@4ax.com...
>
> Consider avoiding the switching among
> the three sets of axis-parallel polygons and just use polygons
> for all the axes.  Instead of M polygons for a single axis-parallel
> set, use 3*N polygons, N per axis, with 3*N < M.

I'm afraid you're going to have to be more specific here...I don't
follow.

"Eric" <ericgorr@gmail.com> wrote in message 
news:1137710883.322848.269060@g47g2000cwa.googlegroups.com...

> I'm afraid you're going to have to be more specific here...I don't
> follow.

Suppose your volume in space has 0 <= x <= 1,
0 <= y <= 1, and 0 <= z <= 1.  If your are viewing
this cube with view direction (1,0,0), you would use
M square polygons positioned at x = 0 = 0/(M-1),
x = 1/(M-1), x = 2/(M-1), ... , x = 1 = (M-1)/(M-1).
If you rotate the cube so that the y-slices are
more "front facing", you would switch to using M
square polygons positioned at y = 0, y = 1/(M-1),
...., y = 1.  The program logic for switching is based
on looking at the magnitude of the components of the
view direction.

The switching can be quite noticeable, especially if
you have a 256x256x32 image and use 256 polygons
for each of the first two dimensions, but 32 polygons
for the last dimension.

The alternative I suggested is not to switch, but to
choose 3*N square polygons
  x = 0, x = 1/(N-1), ..., x = 1
  y = 0, y = 1/(N-1), ..., y = 1
  z = 0, z = 1/(N-1), ..., z = 1
and always draw these.  If 3*N < M, you will spend
less time drawing, and the switching artifacts do not
exist.  How small you can choose N and still have
reasonable results depends on your image quality.

--
Dave Eberly
http://www.geometrictools.com

Dave Eberly wrote:
> "Eric" <ericgorr@gmail.com> wrote in message
> news:1137710883.322848.269060@g47g2000cwa.googlegroups.com...
>
> > I'm afraid you're going to have to be more specific here...I don't
> > follow.
>
> Suppose your volume in space has 0 <= x <= 1,
> 0 <= y <= 1, and 0 <= z <= 1.  If your are viewing
> this cube with view direction (1,0,0), you would use
> M square polygons positioned at x = 0 = 0/(M-1),
> x = 1/(M-1), x = 2/(M-1), ... , x = 1 = (M-1)/(M-1).
> If you rotate the cube so that the y-slices are
> more "front facing", you would switch to using M
> square polygons positioned at y = 0, y = 1/(M-1),
> ..., y = 1.  The program logic for switching is based
> on looking at the magnitude of the components of the
> view direction.
>
> The switching can be quite noticeable, especially if
> you have a 256x256x32 image and use 256 polygons
> for each of the first two dimensions, but 32 polygons
> for the last dimension.
>
> The alternative I suggested is not to switch, but to
> choose 3*N square polygons
>   x = 0, x = 1/(N-1), ..., x = 1
>   y = 0, y = 1/(N-1), ..., y = 1
>   z = 0, z = 1/(N-1), ..., z = 1
> and always draw these.  If 3*N < M, you will spend
> less time drawing, and the switching artifacts do not
> exist.  How small you can choose N and still have
> reasonable results depends on your image quality.

So, if I understand the method you are suggesting:

The polygons sitting on the x, y and z axis' would intersect with one
another?

If I was looking down the X-axis, I would only have to worry about
drawing the polygons on the x-axis from back to front. Those on the y &
z axis could effectively be drawn in any order. Correct?  If one was
looking from some odd angle, then one would have to determine the
correct back-to-front order for each of the three sets of polygons.

"Dave Eberly" <dNOSPAMeberly@usemydomain.com> wrote in message 
news:TjUzf.3162$vU2.1776@newsread3.news.atl.earthlink.net...
> "JustBoo" <JustBoo@BooWho.com> wrote in message 
> news:hr10t1t5b074p8oodh9qkcjpsolgceohnv@4ax.com...
>
>> Yes. They are used for MRI/Cat scans, Perfect for "slices." I am told
>> that the newer high-end (gaming) video cards handle large voxel data
>> sets now without too much trouble. Usually people doing this sort of
>> thing have access to the high-end hardware. Just a suggestion. <shrug>
>
> Volume rendering using the 3D medical image as a volume
> texture and using polygons as the OP suggested works just
> fine on standard consumer hardware.  The aliasing problems
> are usually because of the slice spacing in the original image,
> not because of the polygon spacing.  An MRI can have something
> like 5 mm spacing between slices, but 1 mm spacing within a slice.
> Resampling a 256x256x32 image to 256x256x256 eliminates a lot
> of the visual problems.
>
> Choosing polygons that are always perpendicular to the view
> direction does not give enough improvement in visual quality
> to justify using them.  Consider avoiding the switching among
> the three sets of axis-parallel polygons and just use polygons
> for all the axes.  Instead of M polygons for a single axis-parallel
> set, use 3*N polygons, N per axis, with 3*N < M.
>
> --
> Dave Eberly
> http://www.geometrictools.com
>
>

Umm, with a multiple-gigabyte dataset, the logical dimensions of the 3D 
texture is on the order of thousandsxthousandsxthousands. Drawing thousands 
of slices is darn slow, real darn slow.  Really really darn slow.  Drawing 
less than thousands of slices in naive slicing gives rise to huge aliasing 
issues. That's why rendering gigabyte datasets is a while new kettle of 
sushi (plus, you have to use out-of-core and multiple pases over subetted 3D 
textures).

"jbwest" <jbwest@comcast.net> wrote in message 
news:EuSdnTM9U6OMtU3eRVn-gg@comcast.com...

> Umm, with a multiple-gigabyte dataset, the logical dimensions of the 3D 
> texture is on the order of thousandsxthousandsxthousands. Drawing 
> thousands of slices is darn slow, real darn slow.  Really really darn 
> slow.  Drawing less than thousands of slices in naive slicing gives rise 
> to huge aliasing issues. That's why rendering gigabyte datasets is a while 
> new kettle of sushi (plus, you have to use out-of-core and multiple pases 
> over subetted 3D textures).

With a multiple-gigabyte dataset, anything you do will be
really really darn slow, including loading the data from disk
to memory.  What point are you trying to make?

Regarding the use of the adjective "huge".  That is an
exaggeration, in my opinion.  I've been doing medical
imaging for a long time, and with reasonably large data
sets.  Aliasing artifacts are always present, but they
are not much of an issue since, as I said, you can
resample the image, increase the polygons to make it
look better, and the frame rate still allows for interactivity.

What it comes down to are concepts already known to
graphics folks:  level of detail, mipmapping.   If you have
a very large data set, you want to display it on a raster
screen, and you want some interactive rate, you reduce
your data.  Typical tradeoff of speed versus quality of
result.

--
Dave Eberly
http://www.geometrictools.com

Dave Eberly wrote:
> "JustBoo" <JustBoo@BooWho.com> wrote in message
> news:hr10t1t5b074p8oodh9qkcjpsolgceohnv@4ax.com...
>


>The aliasing problems
> are usually because of the slice spacing in the original image,
> not because of the polygon spacing.

It is a wrong statement; the correct one is:
The aliasing problems are because of polygon spacing is not small
enough.

It is quite simple to check: set polygon spacing 1/256 of Z-spacing and
aliasing problems will disappear (not very practical).

Curious that you actually suggested to do similar procedure relatively
volume (not camera)

> Resampling a 256x256x32 image to 256x256x256 eliminates a lot
> of the visual problems.

I have seen 1600x1200 VR images from ordinary CT dataset with voxel
size 2.0x0.7x0.7mm without any aliasing artifacts. 

Regards,
Stefan

<stefanbanev@yahoo.com> wrote in message 
news:1137723100.810466.21540@g44g2000cwa.googlegroups.com...
> Dave Eberly wrote:
>>The aliasing problems
>> are usually because of the slice spacing in the original image,
>> not because of the polygon spacing.
>
> It is a wrong statement; the correct one is:
> The aliasing problems are because of polygon spacing is not small
> enough.
>
> It is quite simple to check: set polygon spacing 1/256 of Z-spacing and
> aliasing problems will disappear (not very practical).

Yes, that is a wrong statement *in the context of using hardware
graphics and volume textures*.  The package I contribute to
also has software volume rendering (basic ray tracing, shear-warp
rendering, and a few others), and the image slice spacing is the
main culprit for aliasing in these algorithms.

> Curious that you actually suggested to do similar procedure relatively
> volume (not camera)

My implementation leaves the volume fixed and moves the camera.
The suggestion of rotating the data set was just the "abstract" way
you think about it.

--
Dave Eberly
http://www.geometrictools.com

Dave Eberly wrote:
> <stefanbanev@yahoo.com> wrote in message
> news:1137723100.810466.21540@g44g2000cwa.googlegroups.com...
> > Dave Eberly wrote:
> >>The aliasing problems
> >> are usually because of the slice spacing in the original image,
> >> not because of the polygon spacing.
> >
> > It is a wrong statement; the correct one is:
> > The aliasing problems are because of polygon spacing is not small
> > enough.
> >
> > It is quite simple to check: set polygon spacing 1/256 of Z-spacing and
> > aliasing problems will disappear (not very practical).
>
> Yes, that is a wrong statement *in the context of using hardware
> graphics and volume textures*.  The package I contribute to
> also has software volume rendering (basic ray tracing, shear-warp
> rendering, and a few others), and the image slice spacing is the
> main culprit for aliasing in these algorithms.
>

For shear-warp it is obviously true for ray casting it is not true (for
deep enough super-sampling). The super-sampling has to be adaptive for
each ray to avoid ridiculously high sampling density.

Regards,
Stefan

"Dave Eberly" <dNOSPAMeberly@usemydomain.com> wrote in message 
news:LNWzf.2760$rH5.869@newsread2.news.atl.earthlink.net...
> "jbwest" <jbwest@comcast.net> wrote in message 
> news:EuSdnTM9U6OMtU3eRVn-gg@comcast.com...
>
>> Umm, with a multiple-gigabyte dataset, the logical dimensions of the 3D 
>> texture is on the order of thousandsxthousandsxthousands. Drawing 
>> thousands of slices is darn slow, real darn slow.  Really really darn 
>> slow.  Drawing less than thousands of slices in naive slicing gives rise 
>> to huge aliasing issues. That's why rendering gigabyte datasets is a 
>> while new kettle of sushi (plus, you have to use out-of-core and multiple 
>> pases over subetted 3D textures).
>
> With a multiple-gigabyte dataset, anything you do will be
> really really darn slow, including loading the data from disk
> to memory.  What point are you trying to make?
>

The biggest bottleneck in a naive slice-based 3D texture approach is very 
possibly dense slicing, for these datasets. I/O can be dealt with (and 
overlapped) with well-known means.

  Taking a gigabyte dataset and naively slicing it 256 times can generate 
huge aliasing. Taking a 256x256x256 volume and naively slicing it 256 times 
can *also* give rise to severe artifacts. Consider a nearly horizontal 
feature, maybe gently sloping. Consider a mostly frontal view with some 
elevation. A naive 256 slicer will result in 256 very obvious horizontal 
stair steps. There are ways to slice better, and/or use shaders, to overcome 
these naive slice artifacts without having to slice the volume to a point 
where each pixel scan line on the screen is a slice polygon. That's my only 
point; naive slicing is, well, naive. The OP was asking if naive 3D texture 
vertical slicing was "best". It's probably not.

Other methods, like shear-warp and raytracing hybrids, may well provide 
better quality and performance as compared to naively subsampling a large 
volume, for a subsetted view.

> Regarding the use of the adjective "huge".  That is an
> exaggeration, in my opinion.  I've been doing medical
> imaging for a long time, and with reasonably large data
> sets.  Aliasing artifacts are always present, but they
> are not much of an issue since, as I said, you can
> resample the image, increase the polygons to make it
> look better, and the frame rate still allows for interactivity.
>
 I've been doing seismic imaging for a long time, and the aliasing problems 
are *huge* for us. Our data is at or below nyquist, and slice artifacts look 
like faults -- very bad.  Superslicing is one, fairly inefficient, way. 
There are others that really do away with slice aliasing without having to 
do thousands of slices, like surface reconstruction shaders.

> What it comes down to are concepts already known to
> graphics folks:  level of detail, mipmapping.   If you have
> a very large data set, you want to display it on a raster
> screen, and you want some interactive rate, you reduce
> your data.  Typical tradeoff of speed versus quality of
> result.

Yep, always true, but only after you've exhausted other means to improve the 
speed and quality with superior algo's.

>
> --
> Dave Eberly
> http://www.geometrictools.com
>
> 

How do you ensure correct depth-ordering while blending voxels (texels
actually), when you draw these three intersecting sets of polygons?

-Maniam