[vtkusers] 3 speed questions

David Gobbi david.gobbi at gmail.com
Tue Nov 9 11:22:16 EST 2010 

Hi Jonathan,

Since your mesh is generated from the image, my guess is that every
time the Slice is changed, the vtkImageData object is modified.  This
will result in undesired re-execution of the pipeline.

Your pipeline has one vtkImageData being fed into three separate
pipelines, correct?  One pipeline per view?  Because the VTK imaging
pipeline is a "streaming" pipeline in VTK-speak, each pipeline
consumer will request an UpdateExtent before calling for a pipeline
update.  The problem is that, if each consumer (i.e. view) requests a
different UpdateExtent, then the vtkImageData object will be modified
during each pipeline execution.

The typical workaround for this is to call UpdateWholeExtent() on any
image data that is going to be fed into multiple pipelines.  That way,
every UpdateExtent that is requested will fit within the currently
allocated Extent for the image.

I'm not saying that this is definitely going to solve the problem, but
the scenario that I describe above is a fairly common one.

To debug unwanted pipeline executions, I usually take a very primitive
approach to debugging... I add print statements to the Execute methods
of the filters that I suspect are being called at the wrong times, and
then run my program from a terminal.

  David

On Tue, Nov 9, 2010 at 8:55 AM, Jonathan Morra <jonmorra at gmail.com> wrote:
> My data is about 512*512*100 and the meshes are contained within the data.
>  The thing that was weird to me is that the render speed is the same whether
> or not I decimate the mesh.  I tried decimating the mesh by .999 and the
> speed was just as slow.  How can I inspect my pipeline for
> any weirdness that I might be doing?
>
> On Mon, Nov 8, 2010 at 8:59 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> Hi Jonathan,
>>
>> Turning on wireframe will usually slow down the rendering (but in this
>> case, since you are rendering just 2D contours, it might not make a
>> difference).
>>
>> But I suspect that it isn't the rendering itself that is slowing you
>> down, I think that the slowdown is the result of undesired VTK
>> pipeline execution within the Render call.  The reason I say this is
>> that modern 3D graphics cards can draw over 100 million triangles per
>> second, and assuming that your voxel data is around 256*x256*256, your
>> meshes will have approximately 500000 triangles and your graphics card
>> will be able to draw them at over 200 frames per second.
>>
>> So either your meshes are much larger than my estimate, or else
>> something is happening in the VTK pipeline to cause the mesh to be
>> re-generated at every render.
>>
>>  David
>>
>> On Mon, Nov 8, 2010 at 9:15 PM, Jonathan Morra <jonmorra at gmail.com> wrote:
>> > Is there anything I can do to speed up the Render time?
>> >
>> > On Mon, Nov 8, 2010 at 8:13 PM, Karthik Krishnan
>> > <karthik.krishnan at kitware.com> wrote:
>> >>
>> >> On Tue, Nov 9, 2010 at 2:54 AM, Jonathan Morra <jonmorra at gmail.com>
>> >> wrote:
>> >> > More information that I've found about the first issue I reported.
>> >> >  I've
>> >> > been narrowing down the issue, and the issue appears to be with
>> >> > vtkImageViewer2.SetSlice(int slice).  This method is very slow when
>> >> > I'm
>> >> > rendering a vtkPolyData that represents a mesh (whether it's cut or
>> >> > not
>> >> > is
>> >> > actually irrelevant)
>> >>
>> >> Contrary to what you assume, It is relevant. The SetSlice method
>> >> internally invokes render, so as to update the display in response to
>> >> changes. A "Render" implies that everything displayed on this
>> >> renderwindow is re-rendered. This includes the rendering the polydata.
>> >> If uncut, it can be slow depending on the number of cells. If cut, it
>> >> can take time to update the cutter, since the cut-function (plane) has
>> >> been translated.
>> >>
>> >> > and fast when I'm rendering either nothing or a
>> >> > vtkPolyData that represents a stack of 2D contours.  Does this help
>> >> > at
>> >> > all?
>> >>
>> >> Indeed, as mentioned above, there is no cutting to perform here.
>> >> Rendering a bunch of 2D contours is probably faster than rendering
>> >> your entire mesh.
>> >>
>> >> >
>> >> > On Mon, Nov 8, 2010 at 10:26 AM, Jonathan Morra <jonmorra at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Thanks for your response.  It turns out on my machine that that
>> >> >> initialization is too slow.  What's happening is the following
>> >> >> 1.  The user click indicating that they want to try a contour
>> >> >> 2.  A new vtkContourWidget is made with the dijkstra interpolator.
>> >> >> 3.  The contour widget is initialized as I described above with just
>> >> >> two
>> >> >> points.  Adding that second point is where the slowdown occurs.
>> >> >> As far as point 2, I am initializing a contour widget with the
>> >> >> output
>> >> >> of
>> >> >> vtkCutter, but I am subsampling when I do that (I take 7% of the
>> >> >> points), so
>> >> >> I only have a handful of control points.  Is there a way to
>> >> >> frontload
>> >> >> the
>> >> >> load time so I only have to do it once as opposed to every time a
>> >> >> user
>> >> >> wants
>> >> >> to draw a contour?  That is simply too slow for my application.
>> >> >> Also do you have any idea why rendering the meshes is slow?  Could
>> >> >> it
>> >> >> be
>> >> >> related to the point order, or is is something else?
>> >> >> On Sat, Nov 6, 2010 at 8:54 AM, Karthik Krishnan
>> >> >> <karthik.krishnan at kitware.com> wrote:
>> >> >>>
>> >> >>> On Tue, Nov 2, 2010 at 6:31 AM, Jonathan Morra <jonmorra at gmail.com>
>> >> >>> wrote:
>> >> >>> > on vtkDijkstraImageContourLineInterpolator and am able to
>> >> >>> > successfully
>> >> >>> > create the contour widget with live wire interpolation. However,
>> >> >>> > when I
>> >> >>> > first initialize the contour with the following code it is very
>> >> >>> > slow
>> >> >>> >     // For now, we're just initializing the data with
>> >> >>> >     // the point that was clicked
>> >> >>> >     vtkPoints points = new vtkPoints();
>> >> >>> >
>> >> >>> >     // The initial data MUST be at least a "line"
>> >> >>> >     // by giving the same point twice we are effictively creating
>> >> >>> > a
>> >> >>> > zero
>> >> >>> >     // length line
>> >> >>> >     points.InsertNextPoint(lastContourControlPoint);
>> >> >>> >     points.InsertNextPoint(lastContourControlPoint);
>> >> >>> >     vtkPolyData initialData = new vtkPolyData();
>> >> >>> >     initialData.SetPoints(points);
>> >> >>> >     contourWidget.Initialize(initialData, 0);
>> >> >>> > The line that is slow is the last line.  The weird part is that
>> >> >>> > if I
>> >> >>> > do
>> >> >>> > not
>> >> >>> > use live wire, and just use the default Bezier curve
>> >> >>> > interpolation
>> >> >>> > the
>> >> >>> > initialization is instant.
>> >> >>>
>> >> >>> Yes. There are 2 issues here.
>> >> >>>
>> >> >>> 1. The dijkstra interpolator is a bit slow to start with, since
>> >> >>> during
>> >> >>> the time of initialization, it builds the adjacency information.
>> >> >>> But
>> >> >>> that's not a big deal when you are drawing on an image. The very
>> >> >>> first
>> >> >>> line segment placement is a bit slow (~3 seconds). After that its
>> >> >>> fast
>> >> >>> and interactive.
>> >> >>>
>> >> >>> 2. The real issue, I think, here is the fact that you are
>> >> >>> initializing
>> >> >>> the contour with the contour with lots of control points. How many
>> >> >>> of
>> >> >>> them are there ? As I understand, you are generating these control
>> >> >>> points from the output of vtkCutter ? Perhaps you want to sample
>> >> >>> the
>> >> >>> input polyline and then feed those sample points as the control
>> >> >>> points.
>> >> >>>
>> >> >>> Thanks
>> >> >>> --
>> >> >>> karthik
>> >> >>
>> >> >
>> >> >
>> >
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Please keep messages on-topic and check the VTK FAQ at:
>> > http://www.vtk.org/Wiki/VTK_FAQ
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://www.vtk.org/mailman/listinfo/vtkusers
>> >
>> >
>
>

More information about the vtkusers mailing list