[Paraview-developers] IceT compositing in paraview

[Biddiscombe, John A.]

Ken

>
If I understand correctly, you are looking to either turn off the IceT compositing since you are doing it yourself or to use IceT to composite using your custom operator.
<

yes that's about right.

>
IceT supports a mode that will in effect turn off compositing. I think the ParaView representation/view classes support turning this on for the case when geometry is collected. Utkarsh would know better than me how to turn this on in ParaView.
<.

Good. turning it off would be one way to go and is probably the easiest method. It will still leave us with a 'poor' implementation using MPIReduce, but at least there's not a second composite step. The downside is that it precludes the possibility that we might combine the splotch render with another dataset rendered using standard mappers. currently I set the z position of the generated image to the far clipping plane and then other geometries are overlaid on top, this is the best I can hope for without a lot of complex depth tests which would require a mapper having access to multiple datasets.
If turning off the compositing is easy then we'll do that for now, but ...

>
The second mode of using IceT with your custom composite operation is not directly supported, yet. Currently IceT only supports the hard coded operations of Z compare and alpha blending. That said, adding a custom compositing mode should be pretty straightforward. I'd be willing to add that core capability to IceT if someone else was willing to add corresponding changes to the ParaView code.
<

OK, this would be great although I suspect my issue from above, that combining the splotch render with another dataset would break mixing of those datasets. I knew that this would be a problem, but I secretly hoped that you'd suggest some other method. I tried fooling iceT by manually calling IceTSetCompositeMode etce tc, but didn't have any luck. If Utkarsh knows how to disable the compositing then I may be able to modify the technique to achive something interesting.

new idea :
What about this : the blend operator is something like pix1*alpha + pix2*(1-alpha). if order was not important, would it be doable for us to premultiply each pixel by N(=numranks), set alpha for each pixel to 0.5 and then we'd get 1/N contributions all equally weighted and scaled by N to bring back the original image? I could reuse the zoltan partiioning stuff I worked on before to do an efficient redistribution and then use a standard blend mode and bypass the paraview data redistribution using our kdtree from zoltan. This ought tow work. I'll give it a try. Mind you if the blend operation is different, then I may need a new plan...

thanks for the feedback

JB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20140730/ecb2d7f0/attachment.html>