[Smtk-developers] ParaView/CMB changes for multiple views

[Haocheng Liu]

Hi David,

On Thu, Jul 6, 2017 at 10:52 AM, David Thompson <david.thompson at kitware.com>
wrote:

> Hi all,
>
> As I work on changes for CMB v5, one of the big features will be for
> ModelBuilder to allow multiple render-views instead of its current practice
> of creating a single default view that cannot be split or changed.
>
> I am thinking about using this opportunity to refactor the ModelBuilder
> code where it was confusing and would appreciate your input. I'll outline
> my plan below:
>
> Currently, CMB is organized as shown in the attached diagram: the
> pqCMBModelManager (which owns the smtk::model::Manager indirectly) creates
> and manages 1 pqSMTKModelInfo per model plus any auxiliary-geometry
> representations that are intended to be separate from the model. The
> pqSMTKModelInfo owns a pqSMTKMeshInfo instance (which owns multiple
> representations for the model's mesh collection) and several
> representations (1 for each separate auxiliary geometry image).
>
I didn't find pqDataRepresentation(instance-glyphs) in pqSMTKModelInfo, I
guess it's still in WIP?
pqDataREpresentation(model) and pqDataRepresentation(selection) actually
point to the same pqDataRepresentation. Paraview has two sources for
pqDataRepresentation, one for selection(We use a vtkSMProxy in
pqSMTKModelInfo to control selection) and another for normal rendering.
Currently in CMB if user makes a selection, we would turn off the selected
entities' visibility first then enable the selection source. See
pqSMTKModelPanel::selectEntityRepresentations() for detail.


>
> I believe that a lot of the code can be simplified by removing the
> pqSMTK*Info and smtkAuxGeoInfo classes (none of which *were*
> representations but which owned representations) in favor of a new
> pqSMTKModelRepresentation class. I have some more due diligence to do:
>
> + it may require a subclass of vtkPVDataRepresentation on the server, but
> we may also be able to get by with just managing multiple proxies to
> existing server-side representations in pqSMTKModelRepresentation.
> + I'm not familiar with the interaction of selection and representations
> and need to ensure we'll be able to continue selecting things in a filtered
> way.
>
See my comment above.

>
> If you can think of other problems with this or have better ideas, please
> let me know.
>
> +1 for this cool idea.

>         David
>
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
>


-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170706/6d1aa09a/attachment.html>