[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vtk-developers
Subject:    Re: [vtk-developers] Unstructured Volume Rendering Mesa support
From:       "Randall Hand" <randall.hand () gmail ! com>
Date:       2006-04-05 19:08:44
Message-ID: b02264720604051208t11d3c159n47b02464b1036690 () mail ! gmail ! com
[Download RAW message or body]

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@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@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@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

[Attachment #3 (text/html)]

This, along with the patch, posted as Bug 3097: <a \
href="http://www.vtk.org/Bug/bug.php?op=show&amp;bugid=3097&amp;pos=0">http://www.vtk.org/Bug/bug.php?op=show&amp;bugid=3097&amp;pos=0</a><br><br><div><span \
class="gmail_quote"> On 4/4/06, <b class="gmail_sendername">Randall Hand</b> &lt;<a \
href="mailto:randall.hand@gmail.com">randall.hand@gmail.com</a>&gt; \
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;"><span class="q">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>&nbsp;&nbsp;&nbsp; * The new \
vtkProjectedTetrahedraMapper runs in approx 9s with good results. \
<br>&nbsp;&nbsp;&nbsp; * Simply s/vtkProjectedTetrahedraMapper<div style="direction: \
ltr;">/vtkUnstructuredGridVolumeZSweepMapper/g and running takes 18minutes, and gives \
                good results.<br>&nbsp;&nbsp;&nbsp;
* 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 &amp; vertical at the exact center of the image).
<br><br>So I was mistaken on that at least :)&nbsp; Odd how the other two
can magically make the Mesa/OpenGL switch but the projectedTet can't.&nbsp;
Oh well.&nbsp; How do you want the patch?</div><br><br></span></div><div \
style="direction: ltr;"><div></div><div style="direction: ltr;"><span class="q"><span \
class="gmail_quote">On 4/4/06, <b class="gmail_sendername">Lisa Avila </b> &lt;<a \
href="mailto:lisa.avila@kitware.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">lisa.avila@kitware.com</a>&gt; wrote:</span> \
</span></div><div style="direction: ltr;"><span class="e" \
id="q_10a657a22e5b38a4_3"><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 &quot;to do&quot; list - thank you for
taking the time to make the fix. <br><br>
You say that &quot;none of the new unstructured volume renderers properly
support Mesa&quot; - 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><br><br>
<br><br>
At 09:26 AM 4/4/2006, Randall Hand wrote:<br>
</span></div><div style="direction: ltr;"><blockquote \
type="cite"></blockquote></div><div style="direction: ltr;"><span>(For those of you \
who've dug through this already on the vtk-users, I am sorry.&nbsp; 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.&nbsp; I finally broke down and
wrote a simple driver app to do nothing but volume rendering &amp; save
the result to a PNG on disk, and came to a few surprising
conclusions.&nbsp; Basically, vtkProjectedTetrahedraMapper doesn't work
with mangled mesa.&nbsp; I can remove the &quot;UseMesaClasses&quot; from
the beginning of the code and everything works just fine but it does
throw a window on the screen.&nbsp; 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.&nbsp; Every command probably
returned an error (no GL context), but nothing checks it, so it rendering
blindly &amp; ignorant of what was going on.&nbsp; <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.&nbsp; &gt;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.&nbsp; 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?&nbsp; I plan to file a bug on it, with code attached,
tomorrow morning when I return to the office.&nbsp; 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?&nbsp; I know there's a command with 'cvs diff' to get
&quot;patch&quot;-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></span></div><div style="direction: ltr;"></div></div><div \
style="direction: ltr;"><span class="e" id="q_10a657a22e5b38a4_5"><br><br \
clear="all"><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>

</span></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>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic