[vtkusers] 3 speed questions

[Jonathan Morra]

I just figured out the issue with 1. and 2. from my original email.  First,
I want to thank everyone that helped me out.  The solution was twofold.
1.  It would appear that the vktImageActorPointPlacer can be slow (at least
it is for me).  I switched over to the vtkFocalPlanePointPlacer, which works
fine for my situation because I know that contours are contained within one
plane.
2.  I was updating the other two views while editing the contour.  This was
a huge slowdown for me.  Now, when I edit a contour I don't update the other
two views, and everything is very fast.

Thanks again for all the help.

I'm still working on the Dijkstra interpolator initializaiton time, but
hopefully I'll get that soon too.

On Tue, Nov 9, 2010 at 8:54 PM, Jonathan Morra <jonmorra at gmail.com> wrote:

> 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/20101111/818b7085/attachment.htm>