[vtk-developers] Unstructured Volume Rendering Mesa support

[Randall Hand]

This, along with the patch, posted as Bug 3097:
http://www.vtk.org/Bug/bug.php?op=show&bugid=3097&pos=0

On 4/4/06, Randall Hand <randall.hand at gmail.com> wrote:
>
> Well, I'll admit that I made that statement based on the fact that the
> vtkVolumeRenderingFactory seems to have no knowledge of the other volume
> renderers.
>
> From my tests:
>     * The new vtkProjectedTetrahedraMapper runs in approx 9s with good
> results.
>     * Simply s/vtkProjectedTetrahedraMapper/vtkUnstructuredGridVolumeZSweepMapper/g
> and running takes 18minutes, and gives good results.
>     * Then simply %s/ZSweep/RayCast/g and running takes about 18seconds,
> and gives ok results (I do get a render, but there seems to be a degenerate
> case error along the axes.. I get blank 1-pixel lines on the horizontal &
> vertical at the exact center of the image).
>
> So I was mistaken on that at least :)  Odd how the other two can magically
> make the Mesa/OpenGL switch but the projectedTet can't.  Oh well.  How do
> you want the patch?
>
>
> On 4/4/06, Lisa Avila <lisa.avila at kitware.com> wrote:
>
> >
> > Hi Randall,
> >
> > I will handle the patch. Yes - this was a known problem that was
> > (admittedly quite low down) on my "to do" list - thank you for taking the
> > time to make the fix.
> >
> > You say that "none of the new unstructured volume renderers properly
> > support Mesa" - have you encountered problems with more than just the PT
> > mapper? I believe the ray caster works (uses the same code - structured and
> > unstructured - to display the results), and the ZSweep mapper uses this code
> > as well. Please let me know if you are having problems with those classes.
> >
> > Lisa
> >
> >
> >
> >
> > At 09:26 AM 4/4/2006, Randall Hand wrote:
> >
> > (For those of you who've dug through this already on the vtk-users, I am
> > sorry.  Just want to make sure the right people get their eyeballs on this).
> >
> > I've been trying to do some volume rendering on an in-house dataset and
> > it's been giving me nothing but trouble.  I finally broke down and wrote a
> > simple driver app to do nothing but volume rendering & save the result to a
> > PNG on disk, and came to a few surprising conclusions.  Basically,
> > vtkProjectedTetrahedraMapper doesn't work with mangled mesa.  I can remove
> > the "UseMesaClasses" from the beginning of the code and everything works
> > just fine but it does throw a window on the screen.  Add them back, and all
> > I get is empty space for outputs.
> >
> > Ok, after alot of digging I found the problem. It seems that none of the
> > new unstructured volume renderers properly support Mesa. My best guess is
> > that it was setting up the scene with mangled-mesa contexts, and then the
> > Volume Rendering was using true OpenGL.  Every command probably returned an
> > error (no GL context), but nothing checks it, so it rendering blindly &
> > ignorant of what was going on.
> >
> > After alot of work, I managed to apply the same structure as the other
> > objects to the vtkProjectedTetrahedraMapper successfully. There is now a
> > vtkProjectedTetrahedraMapper that, with the help of the
> > vtkVolumeRenderingFactory, can properly instantiate either a
> > vtkOpenGLProjectedTetrahedraMap
> > per or a vtkMesaProjectedTetrahedraMapper.  >From the testing I've done
> > here (with the hello-world code shown originally), I've been able to switch
> > between the two pretty easily and get almost identical results.  There are a
> > few discrepancies, but since this is a hardware accelerated version it's
> > very susceptible to the fine variations between how Mesa emulates the
> > hardware and various hardware platforms actually work.
> >
> > So, who @Kitware do I need to talk to to get this patch back to
> > mainstream?  I plan to file a bug on it, with code attached, tomorrow
> > morning when I return to the office.  This is a little larger patch that I
> > usually deal with (4 new files, extensive changes to a few others), so
> > what's the preferred format for a patch this size?  I know there's a command
> > with 'cvs diff' to get "patch"-style diffs, which seems the best option, but
> > I always forget it...
> >
> >
> > --
> > Randall Hand
> > Visualization Scientist,
> > ERDC-MSRC Vicksburg, MS
> > Homepage: http://www.yeraze.com
> > _______________________________________________
> > vtk-developers mailing list
> > vtk-developers at vtk.org
> >  http://www.vtk.org/mailman/listinfo/vtk-developers
> >
>
>
>
> --
> Randall Hand
> Visualization Scientist,
> ERDC-MSRC Vicksburg, MS
> Homepage: http://www.yeraze.com
>



--
Randall Hand
Visualization Scientist,
ERDC-MSRC Vicksburg, MS
Homepage: http://www.yeraze.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20060405/2f38add0/attachment.html>