From matthew.bowman at kitware.com Tue Oct 28 16:52:32 2014 From: matthew.bowman at kitware.com (Matthew Bowman) Date: Tue, 28 Oct 2014 16:52:32 -0400 Subject: [Smtk-developers] test message Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Oct 28 16:56:40 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 28 Oct 2014 16:56:40 -0400 Subject: [Smtk-developers] test message In-Reply-To: References: Message-ID: I endorse this message / product. On Tue, Oct 28, 2014 at 4:52 PM, Matthew Bowman wrote: > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > From david.thompson at kitware.com Tue Oct 28 16:14:45 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 28 Oct 2014 16:14:45 -0400 Subject: [Smtk-developers] Mailing Lists for CMB and SMTK and Docs In-Reply-To: <635E4F3E-5F4B-4014-9DDF-8B2D8AC83F41@kitware.com> References: <635E4F3E-5F4B-4014-9DDF-8B2D8AC83F41@kitware.com> Message-ID: <34331F2D-80C2-4CFF-9200-826FE94D7787@kitware.com> > On Oct 28, 2014, at 12:04 PM, Bob O'Bara wrote: > ... > I've also pushed the changes I made to the attribute documentation - I need to work on the Item Defs and the Views. David, is there a way to add subsections to the left hand side so a user could navigate through the doc quickly? Not yet, but it is a requested feature: https://github.com/snide/sphinx_rtd_theme/issues/76 However, I have pushed a small restructure that breaks the section into mutliple pages (files) with a table of contents at the top of the attribute section. Does that help? The restructure also moves things into doc/user (from just having the userguide in doc/) to match the doxygen reference documentation being put in doc/reference. FYI, this required changing some file-internal references (of the form "refname_") to cross-file references (of the form ":ref:`refname`"). The latter is preferable so that if we split things into more files later, the references remain valid. Finally, the commit also includes a new Sphinx extension named findfigure. I've changed the documentation to use the findimage directive instead of image and findfigure instead of figure. This makes it 1. possible to refer to generated figures placed in the build directory and 2. easier to refer to figures without including the relative path to it. Instead of looking for a figure file relative to the current directory, findfigure/findimage look for the file in a search path that includes the current directory PLUS some fixed directories (the doc/userguide/figures directory in the source tree and the toplevel build tree). David From bob.obara at kitware.com Tue Oct 28 21:58:14 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 28 Oct 2014 21:58:14 -0400 Subject: [Smtk-developers] SMTK Master can now process V1 Attribute Files Message-ID: <742C015C-67F3-443D-87E5-6EF77BD6C4DD@kitware.com> I've reinstated the V1 Parser with the following limitations: 1. Model Entity Information is skipped (no problem with Template Files) 2. Attribute are reassigned new IDs since we now use UIDs Also added a new V1 Test Finally I refactored the Parsers so the V2 Parser is derived from the V1 Parser resulting in a lot of copied code being removed. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Oct 30 10:23:38 2014 From: david.thompson at kitware.com (David Thompson) Date: Thu, 30 Oct 2014 10:23:38 -0400 Subject: [Smtk-developers] SMTK python script In-Reply-To: References: Message-ID: Hi Yumin, I'm including this on the devel list because... well, it's a shiny new mailing list. :-) > ... >>> I think an "import" operator may fit better here since we may need to handle other file formats that CMB used to load. >> >> In terms of the SMTK API, I agree that it should be a separate operator. But from the application perspective, a user does not want importing a model to be a multistep operation where first an empty model of the proper type must be created before running the import operator on it. This is complicated by the fact that SMTK provides a list of file extensions that each modeling kernel+engine combination can read (using its "read" operator). How would we handle the file formats added by "import"? > > Perfect timing for this discussion, because I am working on getting vtkCmbMoabReader (with CMake option to build or not) into smtk. I am planning to use the same pattern as the cgm bridge, ie, using the hand-edited Bridge_json.h to add file types supported by this reader (if it is built) to the discrete bridge, then ... > >> I see 2 ways to go about it: >> 1. Keep everything in the "read" operator but find a way to mark some file formats as native and others as "import" formats. The operator would then internally either read or import based on the format. >> > I am leaning toward this approach, since 1. "import" still needs a "read" first, then 2. builds a cmbModel from its output, and finally 3. converts cmbModel to smtkModel. For a cmb file, we only need 1 and 3. Eventually (in the far far future), we could possibly make "import" skip 2 too by directly building an smtkModel from read's output. > > I am not sure what "mark file formats" as native and import will help, the read operator will still need separate logic to handle the "import" file formats like 2dm, 3dm, map, poly, vtk, exo, etc. The benefit would be that users understand 1. They will not necessarily be able to save changes back in the original file format. 2. Not all of the features in the original file format are necessarily supported. Also, it lets the application choose a better default kernel if one supports a format natively while another can only import the format. >> 2. Add an "import" operator and include information about it in the Bridge's metadata. Then the application would know which bridge to create for the desired format and to use the "import" operator instead of "read". > > This seems to move more logic to application. Yes, but it makes an important distinction, plus it keeps the read operator smaller and more focused. It would not be a lot more code. The JSON for the bridge would change from something like: { "kernel": "cgm", "engines": [ { "name": "ACIS", "filetypes": [ ".iges (Initial Graphics Exchange Specification)", ".igs (Initial Graphics Exchange Specification)", ".sat (Standard ACIS Text)", ".sab (Standard ACIS Binary)" ] }, // ... ] } to { "kernel": "cgm", "engines": [ { "name": "ACIS", "filetypes": [ ".sat (Standard ACIS Text)", ".sab (Standard ACIS Binary)" ], "importformats": [ ".iges (Initial Graphics Exchange Specification)", ".igs (Initial Graphics Exchange Specification)" ] }, // ... ] } We could just have BridgeRegistrar::bridgeFileTypes and BRepModel::bridgeFileTypes return StringData instead of a StringList (i.e., a map from string->vector instead of a vector) with "read" returning the list of kernel-native formats and "import" returning the list of files that can be read via the "import" operator. This also lets us deal with "write" and "export" down the road. What do you think? David From david.thompson at kitware.com Thu Oct 30 10:45:30 2014 From: david.thompson at kitware.com (David Thompson) Date: Thu, 30 Oct 2014 10:45:30 -0400 Subject: [Smtk-developers] SMTK Dashboard Message-ID: <78E95C84-8112-456E-878E-8A71F2AF3B11@kitware.com> Hi all, Some warnings and test problems have crept into the dashboard. I've fixed the easy warnings, but am less sure how to fix: 1. This warning: > /.../smtk_src/smtk/extension/qt/qtAssociationWidget.cxx: In member function ?QList > smtk::attribute::qtAssociationWidget::processDefUniqueness(const smtk::model::ModelEntity&, smtk::attribute::System*)?: > /.../smtk_src/smtk/extension/qt/qtAssociationWidget.cxx:420:17: warning: declaration of ?smtk::attribute::System* attSystem? shadows a parameter [-Wshadow] It looks like a real issue to me and not a false positive. 2. The test failures on endor. They all look to be Python failures: > Not able to import smtk library. You might need to: > - Use the PYTHONPATH variable to point to the smtk python lib > - And/or use the LD_LIBRARY_PATH variable to point to the shiboken libraries Can anyone take a look at these? Thanks, David From robert.maynard at kitware.com Thu Oct 30 10:46:29 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 30 Oct 2014 10:46:29 -0400 Subject: [Smtk-developers] SMTK Dashboard In-Reply-To: <78E95C84-8112-456E-878E-8A71F2AF3B11@kitware.com> References: <78E95C84-8112-456E-878E-8A71F2AF3B11@kitware.com> Message-ID: I will look at the shadow warning. On Thu, Oct 30, 2014 at 10:45 AM, David Thompson wrote: > Hi all, > > Some warnings and test problems have crept into the dashboard. I've fixed the easy warnings, but am less sure how to fix: > > 1. This warning: > >> /.../smtk_src/smtk/extension/qt/qtAssociationWidget.cxx: In member function ?QList > smtk::attribute::qtAssociationWidget::processDefUniqueness(const smtk::model::ModelEntity&, smtk::attribute::System*)?: >> /.../smtk_src/smtk/extension/qt/qtAssociationWidget.cxx:420:17: warning: declaration of ?smtk::attribute::System* attSystem? shadows a parameter [-Wshadow] > > It looks like a real issue to me and not a false positive. > > > 2. The test failures on endor. They all look to be Python failures: > >> Not able to import smtk library. You might need to: >> - Use the PYTHONPATH variable to point to the smtk python lib >> - And/or use the LD_LIBRARY_PATH variable to point to the shiboken libraries > > Can anyone take a look at these? > > Thanks, > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From yumin.yuan at kitware.com Thu Oct 30 11:11:20 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Thu, 30 Oct 2014 11:11:20 -0400 Subject: [Smtk-developers] SMTK python script In-Reply-To: References: Message-ID: On Thu, Oct 30, 2014 at 10:23 AM, David Thompson wrote: > Hi Yumin, > > I'm including this on the devel list because... well, it's a shiny new > mailing list. :-) > > Right, I was too focused to see the shiny new list :) > > ... > >>> I think an "import" operator may fit better here since we may need to > handle other file formats that CMB used to load. > >> > >> In terms of the SMTK API, I agree that it should be a separate > operator. But from the application perspective, a user does not want > importing a model to be a multistep operation where first an empty model of > the proper type must be created before running the import operator on it. > This is complicated by the fact that SMTK provides a list of file > extensions that each modeling kernel+engine combination can read (using its > "read" operator). How would we handle the file formats added by "import"? > > > > Perfect timing for this discussion, because I am working on getting > vtkCmbMoabReader (with CMake option to build or not) into smtk. I am > planning to use the same pattern as the cgm bridge, ie, using the > hand-edited Bridge_json.h to add file types supported by this reader (if it > is built) to the discrete bridge, then ... > > > >> I see 2 ways to go about it: > >> 1. Keep everything in the "read" operator but find a way to mark some > file formats as native and others as "import" formats. The operator would > then internally either read or import based on the format. > >> > > I am leaning toward this approach, since 1. "import" still needs a > "read" first, then 2. builds a cmbModel from its output, and finally 3. > converts cmbModel to smtkModel. For a cmb file, we only need 1 and 3. > Eventually (in the far far future), we could possibly make "import" skip 2 > too by directly building an smtkModel from read's output. > > > > I am not sure what "mark file formats" as native and import will help, > the read operator will still need separate logic to handle the "import" > file formats like 2dm, 3dm, map, poly, vtk, exo, etc. > > The benefit would be that users understand > 1. They will not necessarily be able to save changes back in the original > file format. > 2. Not all of the features in the original file format are necessarily > supported. > > Also, it lets the application choose a better default kernel if one > supports a format natively while another can only import the format. > > Yes, I understand the benefits of differentiating "import" and "native" file formats from user's perspective. I was inferring to the implementation of the handle-all-formats "read" operator without an "import" operator. In any case, the application should probably give some hints on "read" vs "import". > >> 2. Add an "import" operator and include information about it in the > Bridge's metadata. Then the application would know which bridge to create > for the desired format and to use the "import" operator instead of "read". > > > > This seems to move more logic to application. > > Yes, but it makes an important distinction, plus it keeps the read > operator smaller and more focused. Agreed, but I would rather the Bridge handle logics to do "read" vs "import", meaning the application code should just tell the bridge to load a model given a file name. We could add some UI hints (coming from bridge) in file open dialog so that user knows "imported" vs "native" file formats. > It would not be a lot more code. The JSON for the bridge would change from > something like: > > { "kernel": "cgm", > "engines": [ > { > "name": "ACIS", > "filetypes": [ > ".iges (Initial Graphics Exchange Specification)", > ".igs (Initial Graphics Exchange Specification)", > ".sat (Standard ACIS Text)", > ".sab (Standard ACIS Binary)" > ] > }, // ... > ] > } > > to > > { "kernel": "cgm", > "engines": [ > { > "name": "ACIS", > "filetypes": [ > ".sat (Standard ACIS Text)", > ".sab (Standard ACIS Binary)" > ], > "importformats": [ > ".iges (Initial Graphics Exchange Specification)", > ".igs (Initial Graphics Exchange Specification)" > ] > }, // ... > ] > } > > We could just have BridgeRegistrar::bridgeFileTypes and > BRepModel::bridgeFileTypes return StringData instead of a StringList (i.e., > a map from string->vector instead of a vector) with "read" > returning the list of kernel-native formats and "import" returning the list > of files that can be read via the "import" operator. This also lets us deal > with "write" and "export" down the road. > > What do you think? > That looks good to me. I could use the map to add UI hints of "import" vs "native" Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Oct 31 12:14:22 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 31 Oct 2014 12:14:22 -0400 Subject: [Smtk-developers] Question about tessellation info Message-ID: <11F0BE18-3488-4D39-A7B9-8F86E99F02DF@kitware.com> Hi all, Yumin has pointed out that some VTK cell types (quads, polygons, polyvertices, polylines, triangle strips) are not supported in SMTK's Tessellation structure yet. I am working on adding support for them but have a couple of ways to proceed: 1. Keep things compatible with Three.js' model format ( https://github.com/mrdoob/three.js/wiki/JSON-Model-format-3 and https://github.com/mrdoob/three.js/wiki/JSON-Geometry-format-4 ) at the expense of increasing storage by forcing some cell types (polygons, polylines, polyvertices, triangle strips, but NOT quads) to be converted into multiple entries in smtk::model::Tessellation. 2. Add some non-Three.js-compatible connectivity entry types to keep things VTK-compatible. This would be slightly more efficient for some cell types in the vtkSMTK classes for desktop display via VTK. Any opinions? Thanks, David