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.<div>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.</div>
<div>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.</div><div><br></div>
<div>Thanks again for all the help.</div><div><br></div><div>I'm still working on the Dijkstra interpolator initializaiton time, but hopefully I'll get that soon too.<br><br><div class="gmail_quote">On Tue, Nov 9, 2010 at 8:54 PM, Jonathan Morra <span dir="ltr"><<a href="mailto:jonmorra@gmail.com">jonmorra@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So after some more debugging I've found the following.<div>1. When I render the mesh cut on all three planes everything renders fine.</div>
<div>2. What I want to do is to render the cut plane on two of the views and render vtkContourWidgets on the third plane</div>
<div>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).</div><div>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</div>
<div>5. I have also tried a vtkFocalPlanePointPlacer, and that didn't work</div><div>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.</div>
<div><br></div><div>Could vtkImageActorPointPlacer be the cause of my speed issues? I really have no idea how this is happening.</div><div><div></div><div class="h5"><div><br><div class="gmail_quote">On Tue, Nov 9, 2010 at 8:22 AM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jonathan,<br>
<br>
Since your mesh is generated from the image, my guess is that every<br>
time the Slice is changed, the vtkImageData object is modified. This<br>
will result in undesired re-execution of the pipeline.<br>
<br>
Your pipeline has one vtkImageData being fed into three separate<br>
pipelines, correct? One pipeline per view? Because the VTK imaging<br>
pipeline is a "streaming" pipeline in VTK-speak, each pipeline<br>
consumer will request an UpdateExtent before calling for a pipeline<br>
update. The problem is that, if each consumer (i.e. view) requests a<br>
different UpdateExtent, then the vtkImageData object will be modified<br>
during each pipeline execution.<br>
<br>
The typical workaround for this is to call UpdateWholeExtent() on any<br>
image data that is going to be fed into multiple pipelines. That way,<br>
every UpdateExtent that is requested will fit within the currently<br>
allocated Extent for the image.<br>
<br>
I'm not saying that this is definitely going to solve the problem, but<br>
the scenario that I describe above is a fairly common one.<br>
<br>
To debug unwanted pipeline executions, I usually take a very primitive<br>
approach to debugging... I add print statements to the Execute methods<br>
of the filters that I suspect are being called at the wrong times, and<br>
then run my program from a terminal.<br>
<font color="#888888"><br>
David<br>
</font><div><div></div><div><br>
On Tue, Nov 9, 2010 at 8:55 AM, Jonathan Morra <<a href="mailto:jonmorra@gmail.com" target="_blank">jonmorra@gmail.com</a>> wrote:<br>
> My data is about 512*512*100 and the meshes are contained within the data.<br>
> The thing that was weird to me is that the render speed is the same whether<br>
> or not I decimate the mesh. I tried decimating the mesh by .999 and the<br>
> speed was just as slow. How can I inspect my pipeline for<br>
> any weirdness that I might be doing?<br>
><br>
> On Mon, Nov 8, 2010 at 8:59 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>> wrote:<br>
>><br>
>> Hi Jonathan,<br>
>><br>
>> Turning on wireframe will usually slow down the rendering (but in this<br>
>> case, since you are rendering just 2D contours, it might not make a<br>
>> difference).<br>
>><br>
>> But I suspect that it isn't the rendering itself that is slowing you<br>
>> down, I think that the slowdown is the result of undesired VTK<br>
>> pipeline execution within the Render call. The reason I say this is<br>
>> that modern 3D graphics cards can draw over 100 million triangles per<br>
>> second, and assuming that your voxel data is around 256*x256*256, your<br>
>> meshes will have approximately 500000 triangles and your graphics card<br>
>> will be able to draw them at over 200 frames per second.<br>
>><br>
>> So either your meshes are much larger than my estimate, or else<br>
>> something is happening in the VTK pipeline to cause the mesh to be<br>
>> re-generated at every render.<br>
>><br>
>> David<br>
>><br>
>> On Mon, Nov 8, 2010 at 9:15 PM, Jonathan Morra <<a href="mailto:jonmorra@gmail.com" target="_blank">jonmorra@gmail.com</a>> wrote:<br>
>> > Is there anything I can do to speed up the Render time?<br>
>> ><br>
>> > On Mon, Nov 8, 2010 at 8:13 PM, Karthik Krishnan<br>
>> > <<a href="mailto:karthik.krishnan@kitware.com" target="_blank">karthik.krishnan@kitware.com</a>> wrote:<br>
>> >><br>
>> >> On Tue, Nov 9, 2010 at 2:54 AM, Jonathan Morra <<a href="mailto:jonmorra@gmail.com" target="_blank">jonmorra@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > More information that I've found about the first issue I reported.<br>
>> >> > I've<br>
>> >> > been narrowing down the issue, and the issue appears to be with<br>
>> >> > vtkImageViewer2.SetSlice(int slice). This method is very slow when<br>
>> >> > I'm<br>
>> >> > rendering a vtkPolyData that represents a mesh (whether it's cut or<br>
>> >> > not<br>
>> >> > is<br>
>> >> > actually irrelevant)<br>
>> >><br>
>> >> Contrary to what you assume, It is relevant. The SetSlice method<br>
>> >> internally invokes render, so as to update the display in response to<br>
>> >> changes. A "Render" implies that everything displayed on this<br>
>> >> renderwindow is re-rendered. This includes the rendering the polydata.<br>
>> >> If uncut, it can be slow depending on the number of cells. If cut, it<br>
>> >> can take time to update the cutter, since the cut-function (plane) has<br>
>> >> been translated.<br>
>> >><br>
>> >> > and fast when I'm rendering either nothing or a<br>
>> >> > vtkPolyData that represents a stack of 2D contours. Does this help<br>
>> >> > at<br>
>> >> > all?<br>
>> >><br>
>> >> Indeed, as mentioned above, there is no cutting to perform here.<br>
>> >> Rendering a bunch of 2D contours is probably faster than rendering<br>
>> >> your entire mesh.<br>
>> >><br>
>> >> ><br>
>> >> > On Mon, Nov 8, 2010 at 10:26 AM, Jonathan Morra <<a href="mailto:jonmorra@gmail.com" target="_blank">jonmorra@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> Thanks for your response. It turns out on my machine that that<br>
>> >> >> initialization is too slow. What's happening is the following<br>
>> >> >> 1. The user click indicating that they want to try a contour<br>
>> >> >> 2. A new vtkContourWidget is made with the dijkstra interpolator.<br>
>> >> >> 3. The contour widget is initialized as I described above with just<br>
>> >> >> two<br>
>> >> >> points. Adding that second point is where the slowdown occurs.<br>
>> >> >> As far as point 2, I am initializing a contour widget with the<br>
>> >> >> output<br>
>> >> >> of<br>
>> >> >> vtkCutter, but I am subsampling when I do that (I take 7% of the<br>
>> >> >> points), so<br>
>> >> >> I only have a handful of control points. Is there a way to<br>
>> >> >> frontload<br>
>> >> >> the<br>
>> >> >> load time so I only have to do it once as opposed to every time a<br>
>> >> >> user<br>
>> >> >> wants<br>
>> >> >> to draw a contour? That is simply too slow for my application.<br>
>> >> >> Also do you have any idea why rendering the meshes is slow? Could<br>
>> >> >> it<br>
>> >> >> be<br>
>> >> >> related to the point order, or is is something else?<br>
>> >> >> On Sat, Nov 6, 2010 at 8:54 AM, Karthik Krishnan<br>
>> >> >> <<a href="mailto:karthik.krishnan@kitware.com" target="_blank">karthik.krishnan@kitware.com</a>> wrote:<br>
>> >> >>><br>
>> >> >>> On Tue, Nov 2, 2010 at 6:31 AM, Jonathan Morra <<a href="mailto:jonmorra@gmail.com" target="_blank">jonmorra@gmail.com</a>><br>
>> >> >>> wrote:<br>
>> >> >>> > on vtkDijkstraImageContourLineInterpolator and am able to<br>
>> >> >>> > successfully<br>
>> >> >>> > create the contour widget with live wire interpolation. However,<br>
>> >> >>> > when I<br>
>> >> >>> > first initialize the contour with the following code it is very<br>
>> >> >>> > slow<br>
>> >> >>> > // For now, we're just initializing the data with<br>
>> >> >>> > // the point that was clicked<br>
>> >> >>> > vtkPoints points = new vtkPoints();<br>
>> >> >>> ><br>
>> >> >>> > // The initial data MUST be at least a "line"<br>
>> >> >>> > // by giving the same point twice we are effictively creating<br>
>> >> >>> > a<br>
>> >> >>> > zero<br>
>> >> >>> > // length line<br>
>> >> >>> > points.InsertNextPoint(lastContourControlPoint);<br>
>> >> >>> > points.InsertNextPoint(lastContourControlPoint);<br>
>> >> >>> > vtkPolyData initialData = new vtkPolyData();<br>
>> >> >>> > initialData.SetPoints(points);<br>
>> >> >>> > contourWidget.Initialize(initialData, 0);<br>
>> >> >>> > The line that is slow is the last line. The weird part is that<br>
>> >> >>> > if I<br>
>> >> >>> > do<br>
>> >> >>> > not<br>
>> >> >>> > use live wire, and just use the default Bezier curve<br>
>> >> >>> > interpolation<br>
>> >> >>> > the<br>
>> >> >>> > initialization is instant.<br>
>> >> >>><br>
>> >> >>> Yes. There are 2 issues here.<br>
>> >> >>><br>
>> >> >>> 1. The dijkstra interpolator is a bit slow to start with, since<br>
>> >> >>> during<br>
>> >> >>> the time of initialization, it builds the adjacency information.<br>
>> >> >>> But<br>
>> >> >>> that's not a big deal when you are drawing on an image. The very<br>
>> >> >>> first<br>
>> >> >>> line segment placement is a bit slow (~3 seconds). After that its<br>
>> >> >>> fast<br>
>> >> >>> and interactive.<br>
>> >> >>><br>
>> >> >>> 2. The real issue, I think, here is the fact that you are<br>
>> >> >>> initializing<br>
>> >> >>> the contour with the contour with lots of control points. How many<br>
>> >> >>> of<br>
>> >> >>> them are there ? As I understand, you are generating these control<br>
>> >> >>> points from the output of vtkCutter ? Perhaps you want to sample<br>
>> >> >>> the<br>
>> >> >>> input polyline and then feed those sample points as the control<br>
>> >> >>> points.<br>
>> >> >>><br>
>> >> >>> Thanks<br>
>> >> >>> --<br>
>> >> >>> karthik<br>
>> >> >><br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>> ><br>
>> > Visit other Kitware open-source projects at<br>
>> > <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>> ><br>
>> > Please keep messages on-topic and check the VTK FAQ at:<br>
>> > <a href="http://www.vtk.org/Wiki/VTK_FAQ" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
>> ><br>
>> > Follow this link to subscribe/unsubscribe:<br>
>> > <a href="http://www.vtk.org/mailman/listinfo/vtkusers" target="_blank">http://www.vtk.org/mailman/listinfo/vtkusers</a><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>