<div dir="ltr">In VTK/Graphics/Testing/CMakeLists.txt, the list of header files occurring after the VTK_GRAPHICS_EXPORT symbol is a list of "exceptions". Add your new header file to that list since it does not declare a class that derives from vtkObject.<div>
<br></div><div>HTH,</div><div>David</div><div><br><br><div class="gmail_quote">On Thu, Aug 28, 2008 at 3:57 PM, Dean Inglis <span dir="ltr"><<a href="mailto:dean.inglis@camris.ca">dean.inglis@camris.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Hi,<br>
<br>
In doing the PIMPL'ng I wrote vtkDijkstraGraphInternals.h<br>
to contain stl containers used be classes vtkDijkstraGraphGeodesicPath<br>
and vtkDijkstraImageGeodesicPath. Im getting HeaderTesting-Graphics<br>
is failing for continuous build Darwin-ppc-cocoa-java:<br>
<br>
Use export macro: VTK_GRAPHICS_EXPORT<br>
<br>
File: /Users/kitware/Dashboards/My<br>
Tests/VTK-cont/Graphics/vtkDijkstraGraphInternals.h does not define any<br>
classes<br>
<br>
File: /Users/kitware/Dashboards/My<br>
Tests/VTK-cont/Graphics/vtkDijkstraGraphInternals.h has 2 includes:<br>
24: #include <vtkstd/vector><br>
25: #include <vtkstd/map><br>
<br>
File: /Users/kitware/Dashboards/My<br>
Tests/VTK-cont/Graphics/vtkDijkstraGraphInternals.h has non-portable<br>
include(s):<br>
24: #include <vtkstd/vector><br>
25: #include <vtkstd/map><br>
File: /Users/kitware/Dashboards/My<br>
Tests/VTK-cont/Graphics/vtkDijkstraGraphInternals.h does not have type macro<br>
Should be:<br>
vtkTypeRevisionMacro(, );<br>
File: /Users/kitware/Dashboards/My<br>
Tests/VTK-cont/Graphics/vtkDiscreteMarchingCubes.h does not define PrintSelf<br>
method:<br>
File: /Users/kitware/Dashboards/My<br>
Tests/VTK-cont/Graphics/vtkHyperOctreeDepth.h does not define PrintSelf<br>
method:<br>
File: /Users/kitware/Dashboards/My<br>
Tests/VTK-cont/Graphics/vtkHyperOctreeLimiter.h does not define PrintSelf<br>
method:<br>
<br>
There were warnings:<br>
* No PrintSelf method<br>
<br>
There were errors:<br>
* Multiple includes<br>
* Non-portable includes<br>
* No type macro<br>
* No class defined<br>
<br>
<br>
Any ideas on how to fix this????<br>
<br>
thanks,<br>
Dean<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Amy Squillacote [mailto:<a href="mailto:ahs@cfdrc.com">ahs@cfdrc.com</a>]<br>
Sent: August-28-08 8:49 AM<br>
To: Karthik Krishnan<br>
Cc: Dean Inglis; <a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a>; 'Will Schroeder'<br>
Subject: Re: [vtk-developers] perf improvements to vtkDijkstra* classes<br>
<br>
Yes, the input type can absolutely be overwritten using<br>
FillInputPortInformation. For an example, see vtkContourFilter.<br>
<br>
- Amy<br>
<br>
Karthik Krishnan wrote:<br>
> Hi Dean:<br>
><br>
> Thanks a lot for the contrib.<br>
><br>
> I took a look at vtkDijkstraImageGeodesicPath and the first input<br>
> polydata is required but isn't used. The second input (cost function<br>
> image) is the one used.<br>
><br>
> I think you can have a class deriving from vtkPolyDataAlgorithm that<br>
> has its first input as something other than vtkpolydata. This can be<br>
> done by overriding the method FillInputPortInformation and having the<br>
> first input be a vtkImageData. Can't it ?<br>
><br>
> If not, maybe we should change vtkGeodesicPath to derive from<br>
> vtkAlgorithm.<br>
><br>
> The other changes to vtkDijkstraGraphGeodesicPath look great.<br>
><br>
> Thanks<br>
> --<br>
> karthik<br>
><br>
> Dean Inglis wrote:<br>
>><br>
>> Hi Will,<br>
>><br>
>> thanks! Been having some fun here.<br>
>><br>
>> Hi Karthik,<br>
>><br>
>> I made a separate header file: vtkDijkstraGraphInternals that contains<br>
>><br>
>> all the replacement stl containers so that<br>
>> vtkDijkstraGraphGeodesicPath and vtkDijkstraImageGeodesicPath<br>
>><br>
>> have access. I left the implementation of the binary heap as is in<br>
>> vtkDijkstraGraphGeodesicPath<br>
>><br>
>> with the exception that it now uses stl containers. I broke the cost<br>
>> function into "static"<br>
>><br>
>> and "dynamic" parts so that edge costs can be calculated more<br>
>> efficiently. I have also<br>
>><br>
>> taken the liberty to rename internal containers from things like<br>
>> this->f to this->OpenVertices<br>
>><br>
>> as given in vtkDijkstraGraphInternals (see below). I will wait till<br>
>> tomorrow to commit in<br>
>><br>
>> case you have any reservations or would like to discuss.<br>
>><br>
>> thanks,<br>
>><br>
>> Dean<br>
>><br>
>> ------------------------------------------------------------------------<br>
>><br>
>> *From:* Will Schroeder [mailto:<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>]<br>
>> *Sent:* August-26-08 5:14 PM<br>
>> *To:* <a href="mailto:dean.inglis@camris.ca">dean.inglis@camris.ca</a><br>
>> *Cc:* Karthik Krishnan<br>
>> *Subject:* Re: [vtk-developers] perf improvements to vtkDijkstra*<br>
>> classes<br>
>><br>
>> I have no objections and have been doing similar things to other VTK<br>
>> classes. Great work!<br>
>> W<br>
>><br>
>> 2008/8/26 Dean Inglis <<a href="mailto:dean.inglis@sympatico.ca">dean.inglis@sympatico.ca</a><br>
>> <mailto:<a href="mailto:dean.inglis@sympatico.ca">dean.inglis@sympatico.ca</a>>><br>
>><br>
>> Is there any interest in (or objections to) PIMPL'ing some (or all) of<br>
>><br>
>> the storage containers in vtkDijkstraGraphGeodesicPath?<br>
>><br>
>> In a test class, I have reimplemented vtkDijkstraGraphGeodesicPath<br>
>><br>
>> using the following substitutions and noticed substantial (qualitative)<br>
>><br>
>> speed gains in interactivity:<br>
>><br>
>> 1) - change containers f and s to vector<bool><br>
>><br>
>> 2) - change containers pre, Heap, and p to vector<int><br>
>><br>
>> 3) - change container for cost; d, to vector<float><br>
>><br>
>> 4) - change container for Adjacency from an array of vtkIdList* to<br>
>><br>
>> vector<map<int,float>> for unique insertion of vertex id's and<br>
>><br>
>> associated edge costs<br>
>><br>
>> Probably most of the improvement comes from item 4) since<br>
>><br>
>> you can pre-calculate all edge costs at the time of constructing<br>
>><br>
>> the adjacency array, which only needs to be done when the input<br>
>><br>
>> changes (not when start and end vertices change).<br>
>><br>
>> Dean<br>
>><br>
>><br>
>> _______________________________________________<br>
>> vtk-developers mailing list<br>
>> <a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a> <mailto:<a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a>><br>
>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> William J. Schroeder, PhD<br>
>> Kitware, Inc.<br>
>> 28 Corporate Drive<br>
>> Clifton Park, NY 12065<br>
>> <a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a> <mailto:<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>><br>
>> <a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br>
>> 518-371-3971 (phone and fax)<br>
>><br>
><br>
<br>
--<br>
Amy Squillacote Phone: (256) 726-4839<br>
Computer Scientist Fax: (256) 726-4806<br>
CFD Research Corporation Web: <a href="http://www.cfdrc.com" target="_blank">http://www.cfdrc.com</a><br>
215 Wynn Drive, Suite 501<br>
Huntsville, AL 35805<br>
<br>
<br>
_______________________________________________<br>
vtk-developers mailing list<br>
<a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a><br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
</blockquote></div><br></div></div>