[vtk-developers] vtkPointCloud remote module

Fri Jan 29 10:42:10 EST 2016

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160129/b2f21870/attachment.html>