[vtkusers] Volume Rendering, cell mode, and rotation optimization - VTK macro bug/issue?

[Richard Frank]

Hi Karthik

Thanks for the explanation.

There are a couple things that I'm a bit confused on.

In vtkSmartVolumeMapper ::ctor	InteractiveUpdateRate is initialized to 1.0


  // If the render window has a desired update rate of at least 1 frame
  // per second or more, we'll consider this interactive
  this->InteractiveUpdateRate = 1.0;

However in the header file the comment is:

/ Description:
  // Get the update rate at or above which this is considered an
  // interactive render.
  // Initial value is 1.0e-5.
  vtkGetMacro( InteractiveUpdateRate, double );

which is a bit confusing since InteractiveUpdateRate is clearly set to 1.0


I wrote out the values to a log file and you are correct that  during the interaction the value of GetDesiredUpdateRate changes...

InteractiveUpdateRate 1
GetDesiredUpdateRate 0.0001
InteractiveUpdateRate 1
GetDesiredUpdateRate 0.0001
InteractiveUpdateRate 1
GetDesiredUpdateRate 0.0001
InteractiveUpdateRate 1
GetDesiredUpdateRate 0.0001
InteractiveUpdateRate 1
GetDesiredUpdateRate 15
InteractiveUpdateRate 1
GetDesiredUpdateRate 15
InteractiveUpdateRate 1
GetDesiredUpdateRate 15
InteractiveUpdateRate 1


So it seems that unless one changes the default behavior of the interactor and mapper by changing InteractiveUpdateRate, rotating a volume will pretty much always (these days) turn on AutoAdustSamplingRate, which will in my experience blur or otherwise distort the rendering as the adjusted sampling rate (distance?) seems pretty low, at least in Cell mode.

This may explain why I don't recall ever seeing a smooth render in other applications - for instance Slicer -  using GPU mode - or any other application that I recall.

But for my purposes, the default behavior is not desirable because it is not a performance issue at all if I turn off the AutoAdjustSampleingRate, and the result is much more appealing visually without the low res sampling rate.

So upping the InteractiveUpdateRate to perhaps at least 30 is probably the solution, as you say. I will give that a try.

I'm sure I'm not the only one who didn't realize this (I'd like ot think so anyways).

Thanks

Rick




as it's
On May 18, 2013, at 11:35 PM, Karthik Krishnan <karthik.krishnan at kitware.com> wrote:

> Rick:
> 
> The DesiredUpdateRate of the render window is a changing quantity. Its usually the same as the StillUpdateRate of the interactor (which defaults to a really low number, implying that the StillRender can take as long as it needs to). 
> 
> During interaction, the interactor style switches the DesiredUpdateRate of the RenderWindow to the interactor's InteractiveUpdateRate, so as to maintain interactivity. At the end of the interaction it switches the DesiredUpdateRate back to the interactor's StillUpdateRate. This results in a coarser render during interaction followed by a high resolution render at the end of the interaction.
> 
> The if-block in the GPURenderMode is consistent with this intent:
>    usedMapper->SetAutoAdjustSampleDistances(
>         ren->GetRenderWindow()->GetDesiredUpdateRate()>=
>         this->InteractiveUpdateRate);
> 
> Its saying: During interaction, adjust the ImageSampling to achieve the interactive frame rate. When not interacting, don't adjust the image sampling.
> 
> I don't see a bug here.  
> 
> What's probably incorrect is the InteractiveUpdateRate which you've set to 1 (ie a frame a second). You want to set that to a much larger number  15 ~ 30.
> 
> Also your check via the debugger was probably done prior to interaction and not during interaction itself, so your conclusions would be misleading.
> 
> Hope this helps
> --
> karthik
> 
>