[vtkusers] [vtk-developers] How to use color mapping for vtkPistonMapper?

Wed Dec 4 07:38:53 EST 2013

Just noticed a mistake in my text after clicking send ...

Erratum : "Decided on Depth Sorting" - instead of depth peeling.

> -----Original Message-----
> From: Biddiscombe, John A.
> Sent: 04 December 2013 13:35
> To: Biddiscombe, John A.; David E DeMarle; Enya Shen
> Cc: vtkdev; vtkusers at vtk.org
> Subject: RE: [vtkusers] [vtk-developers] How to use color mapping for
> vtkPistonMapper?
> 
> https://hpcforge.org/scm/browser.php?group_id=117
> is a project called pv-zoltan
> 
> I needed to do transparent rendering of neuron circuits which are very large
> and complex, depth peeling is one option, but for some of these circuits I had
> to use a machine with no graphics capabilities, so I wanted a software render
> option and decided on depth peeling. see
> ftp://ftp.cscs.ch/out/biddisco/bbp/videos/5k-voltage-differentials.avi skip to
> about 45 seconds in for an example of the data that is interesting - it's just
> under 1 billion triangles, rendered in parallel. Some of the scenes are very
> complex, so for depth peeling, you really need hundreds of layers to be sure
> it's perfect (though nobody would be able to tell the difference).
> 
> What is pv-zoltan : it's a set of classes to allow parallel mesh redistribution
> using the zoltan library from trilinos. Once the mesh is partitioned, I then
> depth sort the triangles and render in parallel with sort last compositing.
> 1) There is a custom depth sort class in the code which generates a depth
> sorted ID list and attaches it to the dataset, then a custom
> vtkPolyDataMapper/Painter which renders using the sorted order (this
> differs from the vtkDepthSortPolyData in vtk which actually sorts the
> polygons (and all cell/point arrays)  and effectively doubles the memory use,
> then renders with the normal polydatamapper/painter).  By generating an Id
> ordering and then painting in that order, we only add 1 int per cell.
> 2) mesh partitioning with zoltan - and some enhancements to the rendering
> front end to bypass the default compositing in paraview and use the KdTree
> from zoltan to do the ordered compositing.
> 3) Once that was working, I wanted to try to do the depth sort on the GPU,
> so I looked at piston and found it to be very easy to modify to suit my needs.
> I have changed the vtkDataSetToPiston class and the vtkPistonMapper
> slightly (and the code will only work with triangle based geometry unless you
> uncomment the triangulation routine somewhere). When the PISTON code
> is enabled, the CPU depth sort is disabled (point 1 above) and instead push
> the dataset to GPU, do depth sort on the fly (some thrust code thrown in
> using thrust::sort_by_key<> and a distance functor) and render in one pass
> effectively. (two loops, but only one render pass).
> 4) There is some code in the colorGPU branch which activates the colour
> table lookup and generation on the GPU as well, but I didn't get time to look
> at it this morning to remind myself of what happens where and when. I seem
> to recall I have a small bug in there which makes the table get regenerated
> more often than it needs to. And possibly more CPU-GPU traffic than strictly
> necessary, but nothing serious.
> 5) Because the transparent rendering uses per vertex opacity - instead of
> using a scalars to colours, we use a new two scalars to colours (originally
> written for the point sprite renderer), this takes one array for scalars and one
> for opacity, so the lookup stuff is a bit more versatile than the standard.
> 6) Everything is handled (rather smoothly I think, even if I do say so myself)
> by the DepthSortRepreseantation which connects everything together. It
> just needs a couple of small fixes for paraview to get working, but most of it
> should compile ok and work - except for the ordered compositing which
> requires some extra info passed via the vtkBoundsExtentTranslator in the
> plugin which holds the region assignments generated by Zoltan and is used to
> send the KdTree to the compositing code in the front end.
> 
> .... currently my depth sort branch is out of date/order, so I won't paste a
> paraview patch. You'd need to just comment out a couple of lines of the
> plugin code. I'd suggest looking  at the piston stuff and having a play with it. I
> can't remember if I added an option to disable the depth sort and only do the
> render on the GPU, the interesting part is where the cuda array handles are
> passed from the dataset after sorting etc and given to OpenGL for rendering,
> most of the piston code itself is irrelevant and it's only the push to gpu and
> pass of handles to GL that is interesting. Many thanks to the original Piston
> developers for showing how to do it.
> 
> NB. running on a single process ought to work, but there may be a gotcha I've
> forgotten about. when I have a few hours spare I'll apply my patches to my
> current paraview tree and see if everything is still working ok and post an
> update.
> 
> JB
> 
> 
> > -----Original Message-----
> > From: vtkusers-bounces at vtk.org [mailto:vtkusers-bounces at vtk.org] On
> > Behalf Of Biddiscombe, John A.
> > Sent: 03 December 2013 15:44
> > To: David E DeMarle; Enya Shen
> > Cc: vtkdev; vtkusers at vtk.org
> > Subject: Re: [vtkusers] [vtk-developers] How to use color mapping for
> > vtkPistonMapper?
> >
> > Yes. I've enhanced the piston mapper and done the lookuptable on the
> GPU.
> > I'm stuck in a terminally dull meeting right now, but once I escape,
> > I'll brush off the code and post a link.
> >
> > JB
> >
> > From: David DeMarle
> > <dave.demarle at kitware.com<mailto:dave.demarle at kitware.com>>
> > Date: Tuesday 3 December 2013 14:47
> > To: Enya Shen
> > <enya.shen2010 at gmail.com<mailto:enya.shen2010 at gmail.com>>
> > Cc: VTK Developers <vtk-developers at vtk.org<mailto:vtk-
> > developers at vtk.org>>, "vtkusers at vtk.org<mailto:vtkusers at vtk.org>"
> > <vtkusers at vtk.org<mailto:vtkusers at vtk.org>>
> > Subject: Re: [vtk-developers] How to use color mapping for
> > vtkPistonMapper?
> >
> > Unfortunately I ran out of time and didn't get around to moving VTK's
> > lookup table over when I originally implemented that class. So, the
> > randow color map you see now is the only option when doing direct GPU
> > to GPU rendering. Unless you hack the class yourself to make the
> > transfer function configurable of course.
> >
> > If anyone out there has an updated implementation (ahem John B.)
> > please direct us to it and we can see about folding your improvements in.
> >
> > thanks
> >
> >
> > David E DeMarle
> > Kitware, Inc.
> > R&D Engineer
> > 21 Corporate Drive
> > Clifton Park, NY 12065-8662
> > Phone: 518-881-4909
> >
> >
> > On Tue, Dec 3, 2013 at 12:24 AM, Enya Shen
> > <enya.shen2010 at gmail.com<mailto:enya.shen2010 at gmail.com>> wrote:
> > Dear all,
> >
> > I try to use vtkPistonMapper, but when I set the color with
> > setColor(double[3]), I got nothing changed.
> >
> > Thanks for any example or advice!
> >
> > Regards,
> > Enya
> >
> > _______________________________________________
> > Powered by www.kitware.com<http://www.kitware.com>
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.vtk.org/mailman/listinfo/vtk-developers
> >
> >
> >
> > _______________________________________________
> > 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