[vtk-developers] vtkPointCloud remote module

Fri Jan 29 11:08:11 EST 2016

Ken-

I am totally with you. I am writing some simple stuff at the moment like
VoxelGrid as sort of a "drop-in" replacements for PCL workflows; mostly to
get my head around the challenges and serve as a stop gap until our better
stuff comes along. I really like your idea and I do plan to implement this;
it's really not too hard to do from what I understand and given the pieces
available in VTK.

So I'll wrap up this simple VoxelGrid and then take a crack at the beast
you've envisioned. The two major pieces seems to be 1) create a class that
builds the hierarchical structure, and 2) write a reader/writer pair that
can perform associated IO. In an earlier email you mentioned a PTS reader
that you made improvement to; is this a good exemplar data format or do you
have a better starting point?

It seems I have a homework assignment for the weekend :-)

Best,
W

On Fri, Jan 29, 2016 at 10:42 AM, Ken Martin <ken.martin at kitware.com> wrote:

> Nice, can I make a specific request Will? :-) Part of what I want to do
> for large point clouds is something like the following:
>
> 1) Open a VTK multipiece file and read in the bounding boxes of the pieces
> (but not the data)
>
> 2) Read in the first piece and use it for rendering
>
> 3) In the background read in more pieces, as they are loaded make them
> available to the mapper
>
> 4) The mapper based on the current camera parameters and bounding boxes of
> the pieces intelligently selects what pieces to render. This provides a
> happy fast interactive experience leading to world peace.
>
> For this to work well my thought was to have the pieces be broken up in a
> special way sort of like an octree but a spatial hash etc would be just as
> good as long as it is hierarchical and structured. Think of breaking up the
> volume into 1 + 8 + 64 pieces. The first piece contains ~1/73 of the data
> covering the entire bounding box. The next eight pieces also each contain
>  about 1/73 of the data each constrained by their octant of the bounding
> box. Same idea for the next 64 boxes, they are just one level further
> down.  This would work really well for a smart mapper providing fast first
> render plus fast LOD/subsequent renders. I can implement 1-4 pretty
> quickly.
>
> But .... for it to work I need someone to create the 73 piece file the
> right way. (it does not have to be 73, and clearly some of those 73 will be
> empty, it just needs to be hierarchical and structured so that a group of
> pieces can be represented at a lower level of detail by some other piece)
> My gut feeling was to have the LOD pieces use actual points of the dataset
> (not centroids or similar) that way as more pieces are loaded we are just
> providing more detail, not replacing fake data (centroids) with real data.
> But really either approach is pretty easy to implement in the mapper. The
> latter approach just means the entire dataset footprint is larger because
> some of the points are not part of the full res dataset because you
> generated them.
>
> I could be totally off base but that was my gut feeling on rendering > 2GB
> point clouds in a nice zippy manner.
>
> TLDR: I want someone to write a filter/writer subclass to create a special
> 73 piece vtk file :-)
>
> Ken
>
>
>
>
>
> On Fri, Jan 29, 2016 at 10:06 AM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> Geoff-
>>
>> I knocked out a vtkVoxelGrid last night, it seems to work great. It's
>> threaded and seems to be fast.
>>
>> Question for you before I push the work to the repository: averaging
>> points in each bin provides a nice subsampled point position. But what do
>> you think we should do for attributes (e.g., scalars, vector, etc.)? These
>> could be averaged too. There are however other options like finding the
>> closest point to the subsampled point and using those attribute values, or
>> if you want to get really fancy, using an interpolation kernel to
>> interpolate to the subsampled point.
>>
>> Thoughts?
>> W
>>
>> On Thu, Jan 28, 2016 at 10:03 AM, Will Schroeder <
>> will.schroeder at kitware.com> wrote:
>>
>>> Thanks for the feedback. I have some downsampling filters in the works
>>> now, I'll let you know when I have something ready.
>>>
>>> BTW we are on a similar path. PCL is awesome, but we have some common
>>> workflows that would be better served with more compact software
>>> environments, and with minimal IO and/or data transfer. So we're trying to
>>> knock of a small kernel of capability to achieve this.
>>>
>>> Best,
>>> W
>>>
>>> On Thu, Jan 28, 2016 at 9:56 AM, Geoff Wright <gpwright at gmail.com>
>>> wrote:
>>>
>>>> Hi Will,
>>>>
>>>> This is good to see.  I'm currently using VTK to generate surfaces from
>>>> some point cloud data.  I have some initial pre processing steps that I use
>>>> PCL (point cloud library) for, and then a vtk stage that converts PCL point
>>>> cloud into vtkPolyData/vtkPoints.  It would be great to eliminate the
>>>> PCL dependency and use exclusively vtk.  My point cloud data grows
>>>> very large over time with a lot of redundant points so its very important
>>>> to downsample them onto uniform spacing (
>>>> http://docs.pointclouds.org/trunk/classpcl_1_1_voxel_grid.html )
>>>> before processing them in vtk.  Would it make sense to add something like
>>>> this to your library?
>>>>
>>>> Geoff
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 28, 2016 at 9:12 AM Will Schroeder <
>>>> will.schroeder at kitware.com> wrote:
>>>>
>>>>> FYI- I have committed an initial set of filters for performing point
>>>>> cloud processing. Any feedback or suggestions are welcome as this is an
>>>>> initial prototype. The work is currently available as a remote module to
>>>>> VTK (vtkPointCloud) via this repository:
>>>>> https://gitlab.kitware.com/vtk/point-cloud.git
>>>>>
>>>>> A couple of notes:
>>>>> + Right now I am using vtkPolyData to represent the point cloud via a
>>>>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to
>>>>> save on memory.
>>>>> + The classes will process as input any vtkPointSet dataset
>>>>> + There is a general framework for filtering point clouds via the
>>>>> class vtkPointCloudFilter. Besides their filtered cloud output, these
>>>>> filters also have an optional, second output which contains any points
>>>>> removed from the input.
>>>>> + Current filters include vtkRadiusOutlierRemoval,
>>>>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an
>>>>> implicit function). Some of  these names are inspired by PCL
>>>>> <http://pointclouds.org/> names.
>>>>> + All filters are threaded using vtkSMPTools using a threaded locator
>>>>> (vtkStaticPointLocator) so I believe that this is relatively fast, although
>>>>> I have not done much testing.
>>>>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken
>>>>> wrote that is very fast.
>>>>>
>>>>> As usual comments and suggestions are requested. In particular any
>>>>> suggestions for other filters to write are welcome (to round out some of
>>>>> the core functionality). The repository is in flux as I try crazy ideas and
>>>>> try to educate myself, so be forewarned.
>>>>>
>>>>> Best,
>>>>> W
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Search the list archives at:
>>>>> http://markmail.org/search/?q=vtk-developers
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>
>>>>>
>>>
>>>
>>> --
>>> William J. Schroeder, PhD
>>> Kitware, Inc. - Building the World's Technical Computing Software
>>> 28 Corporate Drive
>>> Clifton Park, NY 12065
>>> will.schroeder at kitware.com
>>> http://www.kitware.com
>>> (518) 881-4902
>>>
>>
>>
>>
>> --
>> William J. Schroeder, PhD
>> Kitware, Inc. - Building the World's Technical Computing Software
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> will.schroeder at kitware.com
>> http://www.kitware.com
>> (518) 881-4902
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>

-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160129/cd032f45/attachment-0001.html>