<div dir="ltr">Hi Dave,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 10, 2015 at 3:05 PM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Yumin,<br>
<span class=""><br>
>> I am for eliminating the code duplication. Is the desire really to not require SMTK or to not require people to use ModelBuilder to load a CMB file?<br>
><br>
> This is really not related to ModelBuilder. I was talking about loading a mesh (.3dm) or points (.pts) file directly into paraview, which is a common usecase for some users. This usecase really just needs cmbVTKExtension, not smtk or smtkVTKExt. Ideally, we could have a package of paraview with just cmbVTKExtension as a plugin.<br>
<br>
</span>Yes, but is there a reason the plugin should not be part of SMTK instead of part of CMB?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Well, conceptually there are some classes in cmbVTKExt that are not related to simulation at all, so they do not fit inside smtk. However, we could separate those out, and only move those related to simulation over to smtk. I don't have objection to that. Frankly, I will love to see some classes in cmbVTKExt are built outside of cmb and smtk, so that they can be linked from cmb and smtk separately. For example, MeshViewer can just linked against this library without requiring smtk.</div><div><br></div><div>Yumin</div></div></div></div>