[vtkusers] Re: stereo rendering with volumepro1000, not working properly?

[Lisa Avila]

Hello Dan,



>OK..... so when will it be there in CVS for met to download, or where do 
>it get it otherwise?

Ken Martin made this fix on the branch - I'll have to check with him about 
the timing of moving it into the main tree. Again, this won't help you 
until the VolumePro mapper is extended.


>>In VTK stereo is performed with an off-axis (sheared) projection matrix 
>>applied to the current camera matrix.
>
>so its not really 2 different camera positions? Its some other cleverer 
>way of doing it I didn't realise....

After you apply the stereo transform you essentially have two different 
camera positions - but the Position ivar in vtkCamera is not changed (and 
this is what drives the matrix passed to VLI)


>the volumepro1000 now has a perceptive mode which is supported by vli3 on 
>linux and works in vtk, but not for zooming, only rotation, it seems, at 
>the moment.

It is actually rendering in parallel. I assume when you "zoom" all the 
other objects in your scene do get bigger / smaller, but the VolumePro 
rendered volume does not, right? The reason is that it is being rendered in 
parallel, and the change in view angle that is occurring during zooming (or 
the change in position that occurs during a dolly) do not affect the 
parallel rendering. When "zooming" in parallel, the parallel scale is changed.


>>Also - you should not be using a perspective matrix with a VolumePro 
>>mapper - it should be spewing out a bunch of warnings, although I believe 
>>it will go ahead and render the image anyway pretending it has a parallel 
>>viewing matrix. This will not be correct - you are rendering one object 
>>in the scene with a different viewing matrix than all the others.
>
>I guess now it does do perspective, but actually VTK does send error 
>messages I if I remember, complaining about the camera needing to be 
>parallel. but it still works in perspective, at least for rotation. We 
>changed  the default camera to parallel in our volumepro1000 module for 
>Mayavi. But you can change it to perspective and the view changes 
>appropriately.

VLI may handle perspective, but the VTK mapper for the VolumePro 1000 does 
not. Therefore I again recommend that you avoid perspective when using the 
VolumePro from VTK unless you first modify the mapper to support this.


>So you are saying that the volume pro1000 mapper is now outdated and it 
>needs to be updated for new vli3 and volumepro1000 capabilities, like 
>perspective and others.

Yes - the VolumePro 1000 mapper is now outdated. We have not done any 
active development on this class for at least a couple of years.


>I have the perspective option, it works.
>
>Surely its best to fix vtkvolumepromapper1000 so that all users can more 
>easily see the benefits of the new vli3 and vp1000 hardware functions? 
>Especially since VTK is supposed to be fully compatible with 
>volumepro.....right... sure I read that somewhere.... or was it the other 
>way around?

It would be great if someone who is actively working with VTK and the 
VolumePro 1000 could update the mapper for the new functionality. We do not 
have any plans to do this at this time. Since not everyone has the 
perspective option this would have to be done in a way that worked for both 
folks who do have it and those who don't.


>I only run windows under emulation in extreme "last resort" situations. I 
>use OSX and linux because I am an academic scientist and it makes more 
>sense not to rely on windows to give me viruses and blue screens. We are 
>open source developers trying to lever the best performance out of 
>inexpensive consumer hardware, which includes VP1000 in this case. The 
>board is not that expensive. Macs are cheap, powerful and very reliable. 
>Linux is very cheap / free and can be extremely fast. Windows isn't.

I think I will just avoid commenting on the Windows vs. Linux arguments.... 
this thread will never end otherwise! :-)

>I'm sure a volview2.0 version for OSX would be snapped up by academics!

We do have plans for this later this year.

>Can you really get "interactive full resolution frame rates" with 3D 
>texture mapping or ray casting in volpro2.0 for an 8 bit scalar data set 
>of 512x512x100-512? We are microscopists, so detail and resolution are 
>everything.

We do not attempt to render all the data at high resolution during 
interaction - that is how we get interactive performance. For 8 bit data we 
tend to drop down to about 256x256x128 (approximately that many voxels) of 
data when we do 3D texture mapping during interaction. This is something 
that fits on a 64MB graphics card - many cards are 128 or even 256MB now so 
this can probably be increased. When the interaction stops, the full 
resolution image is rendered in software which generally takes a few 
seconds or so (but could be more or less depending on your data size, 
screen resolution, processor type, number of processors, etc.) Many of the 
rendering methods in VTK have the ability to trade off quality for speed 
(use decimation to reduce the number of polygons, reduce image sampling 
rate for ray casting, reduce the number of texture rendering for a texture 
mapped volume rendering approach, reduce the volume size for the VolumePro 
mapper, etc).  Even for the VolumePro support in VolView 1.3 we used a 
multi-resolution approach since our board (with the "old" hardware and the 
"old" vli - this may be better now) could only provide at most one or two 
frames per second for the full size data into a full size window with 
512x512x256 or so data.


Lisa