[Paraview] [Paraview-developers] (Ordered) Compositing question.

Biddiscombe, John A. biddisco at cscs.ch
Mon Nov 19 11:07:56 EST 2012


Utkarsh


Look at vtkStructuredGridVolumeRepresentation, It passes a  "ExtentTranslator" to the view. The view uses the extent translator to build the KdTree. That's one of specifying the cuts. You can indeed provide a custom extent translator or if need be, that API can be extended to pass some other data-structure to extract the relevant information for ordered compositing.

That's magic - thanks. I shall see if I can work out how to fudge that for my purposes.

And ...
For using opacity with polygonal data, simply go to the lookup table editor dialog and (in the advanced mode) you'll see a checkbox to "Enable Opacity Function". Check that and you can specify the opacity function.

OK, I actually wanted to apply a (user defined, but at compile time probably) function to the scalars and use that as a per vertex opacity (It will be an equation relating multiple scalar fields together). I'll repurpose some more code from the point sprite plugin as it does something a bit like that with the transfer function stuff. I guess that's actually what the new lookup table code is doing internally with the opacity feature, just mapping it through the LUT rather than a user function. I think when Stephane implemented that part of the point sprite stuff he used a 1D transfer function for the opacity mapping. I'll  sort that out. The hard part will be fooling the composiing methinks.

Thanks to both of you. I'll have more questions later ...

JB

Utkarsh

On Mon, Nov 19, 2012 at 10:49 AM, Biddiscombe, John A. <biddisco at cscs.ch<mailto:biddisco at cscs.ch>> wrote:
Thanks Ken,

My suspicions are confirmed. I had a poke around with the ordered compositing code (vtkOrderedCompositeDistributor et al) and saw that the BSP cuts from the D3 filter are set to match those from the PKDTree internally. I notice that in the BSPcuts code it says
  // Description:
  //   Initialize the cuts with arrays of information.  This type of
  //   information would be obtained from a graph partitioning software
  //   package like Zoltan.

Do you know if there exists such an example. I am infact partitioning the data using Zoltan and have the exact bounds etc of the partitions, so I can work out what to pass into the BSPcuts  class and could potentially fool the IceT composiining into using my partitions. Can you point me to any crucial function that I must call. Is it sufficient to do a SetCuts on the compositing code - which class do I need to take control of?).

I shall create a custom representation to handle the depth sort. I've done the same some time ago for the point sprite renderer so I'll manage that ok, but I'll need to override the IceT compositing pass too as alluded to above , so any pointers welcome. (Could I somehow subclass on of the painters for the IceT pass and set the cuts to what I've got, then proceed as usual?)

Thanks

JB

From: Moreland, Kenneth [mailto:kmorel at sandia.gov<mailto:kmorel at sandia.gov>]
Sent: 19 November 2012 16:13
To: Biddiscombe, John A.
Cc: paraview-developers at paraview.org<mailto:paraview-developers at paraview.org>; paraview at paraview.org<mailto:paraview at paraview.org>
Subject: Re: [Paraview-developers] (Ordered) Compositing question.

You are correct in that if you disable ordered composite it will disabled the distribution and the composite ordering. The problem is that the geometry distribution also creates a k-d tree structure that the compositing uses to determine the visibility order. So it would not be sufficient to simply have geometry that is in non-overlapping pieces. You would also have to provide some meta-structure that could be used to determine an appropriate ordering given a viewpoint. Even if you had that, there is no mechanism to feed that to the compositor in the view. I can't think of any way of doing that that would not be a huge hack.

As far as I know, there is no support for the DepthSortPolyData filter. You would probably have to create a custom representation to support that.

I believe the transparent lookup table for poly data is supported in 3.98, but to be honest I have not yet tried it.

-Ken

Sent from my iPad so blame autocorrect.

On Nov 19, 2012, at 3:46 AM, "Biddiscombe, John A." <biddisco at cscs.ch<mailto:biddisco at cscs.ch>> wrote:
I have geometry distributed into parallel pieces such that they are non overlapping and therefore compositing should only need to use a back to front sort last frame buffer operation with no redistribution of geometry.

I'm worried that when I turn on transparency, paraview will try to redistribute my data, even though I have already partitioned it nicely for this. I'd like to use ordered sort last compositing at the top level, and use DepthSortPolyData on each node (no depth peeling for now) to ensure I get a true image. What isn't clear to me is if I "disable ordered compositing" if this disables the transfer of geometry AND also disables the ordered compositing necessary for correct transparent blending (I may be confused here about the blend modes used or the term "ordered compositing" as used in the docs).

Is there written down anywhere a complete description of the pipelines used by the various rendering modes so that I can be sure the pipeline is doing what I want. I can create a custom representation which does what I want, but it'll take time and if the existing mechanism support it, I shouldn't need to.

Also, I specifically want to use a transparent lookuptable, does the newer paraview 3.98 have anything to support this. I thought I'd seen a thread about this recently, but cannot find it now.

In summary : For the rendering, I'd like Ordered sort-last compositing, no geometry redistribution, Depth sort of polygons on each node. Transparent lookup table.

What settings should I use :)

Thanks

JB

--
John Biddiscombe,                        email:biddisco @.at.@ cscs.ch<http://cscs.ch>
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07<tel:%2B41%20%2891%29%20610.82.07>
Via Trevano 131, 6900 Lugano, Switzerland   | Fax:  +41 (91) 610.82.82<tel:%2B41%20%2891%29%20610.82.82>

_______________________________________________
Paraview-developers mailing list
Paraview-developers at paraview.org<mailto:Paraview-developers at paraview.org>
http://public.kitware.com/mailman/listinfo/paraview-developers

_______________________________________________
Powered by www.kitware.com<http://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 ParaView Wiki at: http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20121119/9e1ff904/attachment-0001.htm>


More information about the ParaView mailing list