<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Here we only copy definitions that do not already exist so we can realize "overriding operator”.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Ah, ok. Thanks! I guess this feature could be extended to provide a unified API across sessions (kind of like multi-session operators, but maintained by hand).</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> 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. </div></div></div></blockquote><div class=""><br class=""></div><div class="">I think this pattern works well when there is a generic means of accomplishing a task, but derived sessions have more optimized approaches. </div><div class=""><br class=""></div><blockquote type="cite" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Another special case are the Add image and Add auxiliary geometry operator.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Similarly, this pattern works when there is an operation that requires the action of a different operation as a part of its workflow. I don’t think these patterns provide us with a means of exposing our operators to models from different sessions, though (which is a feature that I think would be really cool). The idea of implicitly converting models between sessions would allow operators to convert models prior to execution, but is probably a bad idea (for the reasons Bob and David gave). </div><br class=""><div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Thomas J. Corona, Ph.D.<br class="">Kitware, Inc.<br class="">Senior R&D Engineer<br class="">21 Corporate Drive<br class="">Clifton Park, NY 12065-8662<br class="">Phone: 518-881-4443</div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Jun 20, 2017, at 8:31 AM, Haocheng Liu <<a href="mailto:haocheng.liu@kitware.com" class="">haocheng.liu@kitware.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">Good Morning TJ,</div><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class="gmail_quote">On Mon, Jun 19, 2017 at 10:49 PM, TJ Corona<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:tj.corona@kitware.com" target="_blank" class="">tj.corona@kitware.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><span class="gmail-"><div class=""><blockquote type="cite" class=""><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><div class="">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</div></div></blockquote></div></blockquote><br class=""></div></span><div class="">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.</div><span class="gmail-"><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">I agree with Bob that implicit conversion could be a problem, especially when a similar operation exists in multiple sessions.</div></div></blockquote></div></span><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">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? </div></div></div></div></blockquote><div class="">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(<b class="">smtk::attribute::system</b><span class="Apple-converted-space"> </span>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 <a href="https://gitlab.kitware.com/cmb/smtk/blob/master/smtk/model/Session.cxx#L1048" class="">/smtk/model/Session.cxx#L1048</a> for detail.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div dir="auto" class=""><div class="">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. </div></div></div><span class="gmail-"><div class=""><br class=""></div></span></div></blockquote><div class=""> 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.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><span class="gmail-"><div class=""></div><div class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">But I think it is nice to have a way to perform the conversion. </div></div></blockquote><br class=""></div></span><div class="">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.</div></div></blockquote><div class="">+1. I agree that mesh session would be a nice bridge :) </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><span class="gmail-"><div class=""><br class=""></div><div class=""><div style="word-wrap: break-word;" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">Thomas J. Corona, Ph.D.<br class="">Kitware, Inc.<br class="">Senior R&D Engineer<br class="">21 Corporate Drive<br class="">Clifton Park, NY 12065-8662<br class="">Phone:<span class="Apple-converted-space"> </span><a href="tel:(518)%20881-4443" value="+15188814443" target="_blank" class="">518-881-4443</a></div></div></div><br class=""></span><div class=""><div class="gmail-h5"><div class=""><blockquote type="cite" class=""><div class="">On Jun 19, 2017, at 9:21 PM, David Thompson <<a href="mailto:david.thompson@kitware.com" target="_blank" class="">david.thompson@kitware.com</a>> wrote:</div><br class="gmail-m_-3620146827394373387Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""></div><div class="">Hi TJ,</div><div class=""><br class=""></div><div class="">I agree with Bob that implicit conversion could be a problem, especially when a similar operation exists in multiple sessions.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""> <span class="Apple-converted-space"> </span>David</div><div class=""><br class="">On Jun 19, 2017, at 22:08, Bob Obara <<a href="mailto:bob.obara@kitware.com" target="_blank" class="">bob.obara@kitware.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Does that make sense or am I missing something?</div><div class=""><br class=""></div><div class="">Bob</div><div class=""><br class=""></div><div class=""><br class="gmail-m_-3620146827394373387webkit-block-placeholder"></div><div class=""><div style="font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><div class="">Robert M. O'Bara, MEng.<br class="">Assistant Director of Scientific Computing<br class=""><br class="">Kitware Inc.<br class="">28 Corporate Drive<br class="">Suite 101<br class="">Clifton Park, NY 12065<br class=""><br class="">Phone:<span class="Apple-converted-space"> </span><a href="tel:(518)%20881-4931" value="+15188814931" target="_blank" class="">(518) 881- 4931</a></div><div class=""><br class=""></div></div><br class="gmail-m_-3620146827394373387Apple-interchange-newline"><br class="gmail-m_-3620146827394373387Apple-interchange-newline"></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 19, 2017, at 6:45 PMEDT, TJ Corona <<a href="mailto:tj.corona@kitware.com" target="_blank" class="">tj.corona@kitware.com</a>> wrote:</div><br class="gmail-m_-3620146827394373387Apple-interchange-newline"><div class=""><div style="word-wrap: break-word;" class=""><div class="">Hi all,</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Sincerely,</div><div class="">T.J.</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">Thomas J. Corona, Ph.D.<br class="">Kitware, Inc.<br class="">Senior R&D Engineer<br class="">21 Corporate Drive<br class="">Clifton Park, NY 12065-8662<br class="">Phone:<span class="Apple-converted-space"> </span><a href="tel:(518)%20881-4443" value="+15188814443" target="_blank" class="">518-881-4443</a></div></div></div><br class=""></div>______________________________<wbr class="">_________________<br class="">Smtk-developers mailing list<br class=""><a href="mailto:Smtk-developers@smtk.org" target="_blank" class="">Smtk-developers@smtk.org</a><br class=""><a href="http://public.kitware.com/mailman/listinfo/smtk-developers" target="_blank" class="">http://public.kitware.com/<wbr class="">mailman/listinfo/smtk-<wbr class="">developers</a><br class=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">______________________________<wbr class="">_________________</span><br class=""><span class="">Smtk-developers mailing list</span><br class=""><span class=""><a href="mailto:Smtk-developers@smtk.org" target="_blank" class="">Smtk-developers@smtk.org</a></span><br class=""><span class=""><a href="http://public.kitware.com/mailman/listinfo/smtk-developers" target="_blank" class="">http://public.kitware.com/<wbr class="">mailman/listinfo/smtk-<wbr class="">developers</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></div><br class="">______________________________<wbr class="">_________________<br class="">Smtk-developers mailing list<br class=""><a href="mailto:Smtk-developers@smtk.org" class="">Smtk-developers@smtk.org</a><br class=""><a href="http://public.kitware.com/mailman/listinfo/smtk-developers" rel="noreferrer" target="_blank" class="">http://public.kitware.com/<wbr class="">mailman/listinfo/smtk-<wbr class="">developers</a><br class=""><br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class="">Best regards<div class="">Haocheng</div><div class=""><br class=""></div><div class="">Haocheng LIU</div><div class=""><span style="font-size: 12.8px;" class="">Kitware, Inc.</span><br style="font-size: 12.8px;" class=""><span style="font-size: 12.8px;" class="">R&D Engineer</span><br style="font-size: 12.8px;" class=""><span style="font-size: 12.8px;" class="">21 Corporate Drive</span><br style="font-size: 12.8px;" class=""><span style="font-size: 12.8px;" class="">Clifton Park, NY 12065-8662</span><br style="font-size: 12.8px;" class=""><span style="font-size: 12.8px;" class="">Phone: </span><a href="tel:(518)%20881-4421" value="+15188814443" target="_blank" style="color: rgb(17, 85, 204); font-size: 12.8px;" class="">518-881-4421</a></div></div></div></div></div></div></div></blockquote></div><br class=""></body></html>