[vtkusers] Customized Volume Rendering, and Camera Vision

[David.Pont at ForestResearch.co.nz]

Jeffrey Meng <mengjinjie at gmail.com> wrote on 23/03/2005 09:44:31:

> Thanks a bunch. Please see my comments below:
>
> > The need to mark points that have been seen is sounding like a ray
tracing
> > problem, because you must correctly determine points occluded from each
> > view position. This would be a bit slow just for one view position, and
> > quite a big problem for a moving camera (many view points).
> >
> > vtkPicker and more specifically vtkCellPicker 'shoot' a ray from the
camera
> > to the focal point in the scene and determine what was intersected. A
quick
> > peek at the code shows this is done brute force: each cell is tested
with
> > IntersectWithLine, and the closest intersection is remembered.
>
> I understand vtkCell::IntersectWithLine sure is a good tool to find
> visuiable cell.
> But I have been trying to:
>
> 1. How to iterate through the cell level? (From vtkMapper? vtkActor?)
>
> 2. Even I could get the cell level, how could I change the color of
> the cell? (vtkCell doesn't
> provide such function)

from a vtkActor you can get the vtkMapper and then get the vtkDataSet. From
a vtkDataSet you can get at cells, points and scalars. Dont worry, this is
standard vtk stuff, many many many vtk classes do exactly this sort of
thing, so there are ample examples.

>
> 3. Even if I could set color for the cell, I still have to override
> Render or function like that to achieve my purpose.
>

The critical question at this point is, do you want to:
A. have the user interactively control the camera, so the camera path is
dynamic and the 'color' for a cell will change when it is seen ?
OR:
B. pre-specify the camera path and have code to digest that to produce one
final data set colored as seen/unseen ?

Option A means doing something like vtkFollower, a subclass of vtkActor,
which implements a Render method, ie you get to do something at/before
rendering. I am not sure about changing scalar data at that point, would
have to be careful about the sequence of events and pipeline update stuff,
but it should be fine(?).
Option B means deriving a subclass of vtkPolyDataToPolyDataFilter, ie takes
a polydata input and outputs a polydata, with new scalars. This is much
more classic vtk pipeline filter stuff, no worries at all, just need a way
of feeeding the filter a list of camera positions and orientations, then go
have a coffee and wait for the final result to be rendered. Actually you
could probably set it up to render after each step, more fun to watch, less
time for coffee ;-)

   Dave P.

> > Assuming you could specify the camera path and orientation at a set of
> > discrete steps (more steps = more accurate and slower) you could write
a
> > class to do this as follows:
> > 1  Initialise scalars to 0s
> > 2  for each camera position
> > 3    for each point in dataset
> > 4      if point p1 inside camera view frustrum
> > 5        for each cell in dataset (watch out for own cell)
> > 6          if line from p1 to camera position 'intersects' cell
> > 7            break out of cell loop, this point is occluded
> > 8          if point was not occluded
> > 9            set its scalar to 1, it was visible
> >
> > At 4 you could avoid processing points where scalar is already 1
> > At 9 you could set scalar to integer representing camera position in
> > sequence, giving points that were seen and at which step.
>
> Thanks for the pseduo code, I will digest it when I am home.
>
> > This simplistic approach sounds quite easy to do, (vtkCell has
> > IntersectWithLine for the critical test) but it would certainly not be
> > fast. If you wanted this to happen interactivly you would not
pre-specify
> > camera path but find a way to get render events and process the dataset
at
> > each render. Take a look at how vtkFollower knows the camera has moved,
or
> > look at AddObserver stuff?
> > Note the end result would be accurate only to the resolution of points
in
> > the dataset, ie the exact boundary of visible/not on cell faces is not
> > determined. More points (see vtkLinearSubdivisionFilter...) would give
more
> > accuracy, (and slower speed).
> >
> > A vtkLookupTable with opacity 0 (or < 1) for scalar=0 could be one
useful
> > way to view the result, pieces not seen would disappear (or be
lighter).
>
> Speed is not the major concern at this point, I will have to make it
> happen before doing
> any improvement or optimization.
>
> >    Dave P.
>
> Thank you for your help again, and please continue to help. :)
> _______________________________________________
> This is the private VTK discussion list.
> Please keep messages on-topic. Check the FAQ at: http://www.vtk.
> org/Wiki/VTK_FAQ
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers