[Smtk-developers] An idea for connecting SMTK sessions

Tue Jun 20 09:31:00 EDT 2017

Good Morning TJ,

On Mon, Jun 19, 2017 at 10:49 PM, TJ Corona <tj.corona at kitware.com> wrote:

> I’m not sure if having the model be implicitly being created is a good
> idea since the conversion may result in a loss of information
>
>
> That’s true: I guess only some sessions would be able to convert back and
> forth without loss. Any implicit operations that resulted in an assumption
> of information or a loss of information would definitely be a bad thing.
>
> I agree with Bob that implicit conversion could be a problem, especially
> when a similar operation exists in multiple sessions.
>
>
> Also true. This gets to the heart of one of the design patterns in SMTK
> that I don’t quite understand, though: how do we better exploit the common
> interface of the default session to construct operators that span multiple
> derived sessions?
>
I believe the current logic is that first we create operators for the
default session and store them in the class variable
defaultSession->m_operatorSys(*smtk::attribute::system* type). Next let's
say we want to create a discrete session, we would then initialize discrete
session operators and append dafault session's operators to
discreteSession->m_operatorSys. Here we only copy definitions that do not
already exist so we can realize "overriding operator". You can take a look
at /smtk/model/Session.cxx#L1048
<https://gitlab.kitware.com/cmb/smtk/blob/master/smtk/model/Session.cxx#L1048>
for
detail.

The option of extending operators across sessions via implicit conversions
> is probably the wrong path, but I think that the problem it addresses is
> worth considering. Encompassing meta-operators that manually call their
> derived counterparts could work, but it seems like there is opportunity
> here for a more elegant solution.
>
>  There is no implicit conversions here for extending operators across
sessions actually. For now I think the only operator which has inheritance
is the EntityGroupOperator. Discrete session has its own derived version.
Another special case are the Add image and Add auxiliary geometry operator.
Add image operator has its own sbt file and internally it's using Add
auxiliary geometry operator to load an image.

> But I think it is nice to have a way to perform the conversion.
>
>
> Me too! I’ve been thinking about the conversion between the mesh session
> and VTK in a similar context. We discussed wrapping SMTK mesh objects as
> zero-copy VTK objects, and I’d like to give that a try when I get a chance.
> Perhaps a similar paradigm could exist between some of the sessions.
>
+1. I agree that mesh session would be a nice bridge :)

>
> Thomas J. Corona, Ph.D.
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4443 <(518)%20881-4443>
>
> On Jun 19, 2017, at 9:21 PM, David Thompson <david.thompson at kitware.com>
> wrote:
>
> Hi TJ,
>
> I agree with Bob that implicit conversion could be a problem, especially
> when a similar operation exists in multiple sessions.
>
> But I think it is nice to have a way to perform the conversion. In fact,
> the ERDC CS session has an operator for converting any non-parametric model
> into a model in that session. If we come up with a convention, we should
> make sure that operator is brought along for the ride.
>
>     David
>
> On Jun 19, 2017, at 22:08, Bob Obara <bob.obara at kitware.com> wrote:
>
> Wouldn’t  the conversion to/from pair just be in a  separate plugin (since
> it would need to be built against a pair of sessions)?  In this case the
> conversion operators would be added to the corresponding sessions when the
> plugin is loaded.  I’m not sure if having the model be implicitly being
> created is a good idea since the conversion may result in a loss of
> information) - explicit conversion at least would inform the user of the
> conversion limitations - now a workflow that requires such a conversion
> (for example going from a polygonal planar model to a 3d non-planar
> discrete model after applying an elevation field) would be able to apply it
> implicitly when going from one task in the workflow to another since the
> workflow designer would have factored in the conversion issues when
> designing the workflow.
>
> Does that make sense or am I missing something?
>
> Bob
>
>
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
>
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
>
> Phone: (518) 881- 4931 <(518)%20881-4931>
>
>
>
>
> On Jun 19, 2017, at 6:45 PMEDT, TJ Corona <tj.corona at kitware.com> wrote:
>
> Hi all,
>
> I have an idea, and I’d like to know what everyone thinks. We currently
> have multiple sessions with different backings, and each of these sessions
> have a different set of operators that it can perform. To my understanding,
> if a user wants to cross from session to session, they currently have to do
> so manually (i.e. create a working model in one session, open the model in
> a new session and perform the operation). What if we created “bridges”
> between sessions that facilitated to/from operations for each session pair,
> and then made these conversions implicit during model manipulation in
> ModelBuilder? For example, we create a bridge between the polygon and mesh
> sessions that describe how to convert a model of one type to the other
> (going from polygon to mesh would imply an implicit meshing operation, and
> going from mesh to model would imply an extraction of vertices, edges and
> faces in the mesh session to construct a polygon model). This way, a user
> could create a polygon model and then perform any of the meshing operations
> on it without having to know what session currently backs their model. Is
> this crazy?
>
> Sincerely,
> T.J.
>
> Thomas J. Corona, Ph.D.
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4443 <(518)%20881-4443>
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
>
>
> _______________________________________________
> 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/20170620/fda8c2df/attachment-0001.html>