[vtkusers] 3 speed questions

Jonathan Morra jonmorra at gmail.com
Tue Nov 9 23:54:00 EST 2010 

So after some more debugging I've found the following.
1.  When I render the mesh cut on all three planes everything renders fine.
2.  What I want to do is to render the cut plane on two of the views and
render vtkContourWidgets on the third plane
3.  When I turn on the vtkContourWidgets the rendering is very slow in the
other two planes when they render (I have no idea how this is happening).
4.  I'm using a vtkImageActorPointPlacer as the placer to the contour
widgets.  When I change this to a bounded plane point placer the rendering
is fine, but I cannot figure out how to interact with the widgets
5.  I have also tried a vtkFocalPlanePointPlacer, and that didn't work
6.  I was wondering how this could be happening, that when I render on other
planes the speed of that render is affected by the point placer in the
contour plane.

Could vtkImageActorPointPlacer be the cause of my speed issues?  I really
have no idea how this is happening.

On Tue, Nov 9, 2010 at 8:22 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> 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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20101109/1ca93008/attachment.htm>

More information about the vtkusers mailing list