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.<br><br>From my tests:<br>    * The new vtkProjectedTetrahedraMapper runs in approx 9s with good results.
<br>    * Simply s/vtkProjectedTetrahedraMapper<div style="direction: ltr;">/vtkUnstructuredGridVolumeZSweepMapper/g and running takes 18minutes, and gives good results.<br>   
* 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).
<br><br>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?</div><br><br><div><span class="gmail_quote">On 4/4/06, <b class="gmail_sendername">Lisa Avila</b> <<a href="mailto:lisa.avila@kitware.com">lisa.avila@kitware.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="direction: ltr;">

<br>
Hi Randall,<br><br>
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. <br><br>
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.<br><br>
Lisa</div><div style="direction: ltr;"><span class="e" id="q_10a651fd143d321c_1"><br><br>
<br><br>
At 09:26 AM 4/4/2006, Randall Hand wrote:<br>
</span></div><div style="direction: ltr;"><blockquote type="cite" cite="http://"></blockquote></div><div style="direction: ltr;"><span class="e" id="q_10a651fd143d321c_3">(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).<br><br>
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. <br><br>
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.  <br><br>
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<br>
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. <br><br>
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...<br><br>
<br>
-- <br>
Randall Hand<br>
Visualization Scientist, <br>
ERDC-MSRC Vicksburg, MS<br>
Homepage: <a href="http://www.yeraze.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.yeraze.com</a> <br></span></div><div style="direction: ltr;">
_______________________________________________<br>
vtk-developers mailing list<br>
<a href="mailto:vtk-developers@vtk.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">vtk-developers@vtk.org</a><br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.vtk.org/mailman/listinfo/vtk-developers</a>


</div></blockquote></div><br><br clear="all"><br>-- <br>Randall Hand<br>Visualization Scientist, <br>ERDC-MSRC Vicksburg, MS<br>Homepage: <a href="http://www.yeraze.com">http://www.yeraze.com</a>