[vtkusers] Volume rendering with texture mapping

[Lisa S. Avila]

Hello Dimitris,

At 05:56 AM 2/28/2001, Dimitris Agrafiotis wrote:
>Dear all
>
>There are some things I would like to make clear about texture mapping
>and volume rendering.
>
>1) First of all can I have texture sizes that are not a power of 2?

You should set your target texture size to a power of 2. It should be at 
least as big as one slice (in any direction) of your volume. If it is not, 
it will be changed to meet these conditions. (Actually, you never HAVE to 
set this parameter, it is just there if you want to set it to improve 
performance - see next answer)

>2) I have a volume of size 216x216x183. What target size texture should
>    I use?

256x256 would be fine. It is adjustable because you may find better 
performance at 512x512 since then 4 slice will be sent as one larger 
texture, and some platforms transfer 1 512x512 texture faster than 4 
256x256 textures. Also, if your volume was, for example, 100x100x100, then 
a texture  size of 128x128 would require 100 transfers of 128x128 texels, 
whereas a target texture size of 512x512 would require 4 transfers of 
512x512 texels (1638400 vs. 1048576)

>3) If I use a 256x256 texture size what happens with the extra
>    points? Are they interpolated , do I have to pad my volume with
>     zeroes, or does this happen anyway?

It just uses a subregion of the texture. You don't need to do anything special.

>4) If I intermix the above result with a surface generated from the
>    original 216x216x183 volume will there be any problems?

It will work fine as long as the geometry is opaque.

>5) And finally, when I render the volume with textures, I would like a
>    specific part of the volume (a subvolume - let's say a cube) to be
>    rendered differently (let's say with ray casting or with more
>    samples.) Can I do that, and if yes, what would be the simplest way
>    to do it?

That is tough because it requires combining the renderings in the right 
order - and this may not be possible if the region lies within the volume 
(in other words, the ray going through one pixel has contributions from one 
method, then the other, then the first again) You may be able to do 
something with the CroppingRegionPlanes as long as you know that the 
contribution from one method would always be in front of the other.



Lisa