From david.thompson at kitware.com Mon Nov 3 21:36:51 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 3 Nov 2014 21:36:51 -0500 Subject: [Smtk-developers] Question about tessellation info In-Reply-To: <11F0BE18-3488-4D39-A7B9-8F86E99F02DF@kitware.com> References: <11F0BE18-3488-4D39-A7B9-8F86E99F02DF@kitware.com> Message-ID: Hi all, I've pushed changes to the smtk/model/Tessellation class *and* the test data repo. The JSON storage for tessellation information has changed. It is mostly compatible with ThreeJS but extends the format to include support for polylines and vertex cells. Be aware that any JSON files you have outside of the SMTKTestData repo will probably cause trouble for the modified vtkModelSource/vtkModelMultiBlockSource classes. Yumin, I've also updated the discrete bridge to take advantage of the new tessellation format... please verify that it works for you in ModelBuilder. David > 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 From david.thompson at kitware.com Mon Nov 3 21:42:31 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 3 Nov 2014 21:42:31 -0500 Subject: [Smtk-developers] Documentation update Message-ID: <71CEADFD-F6BD-43CE-9D9A-A7868CA84229@kitware.com> Hi all, SMTK documentation is now available on ReadTheDocs.org: http://smtk.readthedocs.org/ http://smtk.readthedocs.org/en/latest/doc/reference/smtk/html/classes.xhtml Some trickery was involved in running Doxygen without CMake and make. Eventually, we should just have readthedocs.org download Doxygen-generated tag+XML files from a real build. But that will require hosting a real build's output somewhere public on the net. Right now, the documentation is generated using my github clone of SMTK because the official public repo (git://www.kitware.com/SMTK.git) appears to be updated once per day and does not provide web hooks that can trigger regeneration of the documentation. David From yumin.yuan at kitware.com Mon Nov 3 22:49:52 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Mon, 3 Nov 2014 22:49:52 -0500 Subject: [Smtk-developers] Question about tessellation info In-Reply-To: References: <11F0BE18-3488-4D39-A7B9-8F86E99F02DF@kitware.com> Message-ID: Hi Dave, On Mon, Nov 3, 2014 at 9:36 PM, David Thompson wrote: > Hi all, > > I've pushed changes to the smtk/model/Tessellation class *and* the test > data repo. The JSON storage for tessellation information has changed. It is > mostly compatible with ThreeJS but extends the format to include support > for polylines and vertex cells. Be aware that any JSON files you have > outside of the SMTKTestData repo will probably cause trouble for the > modified vtkModelSource/vtkModelMultiBlockSource classes. > > Thanks. I know that's tons of work. > Yumin, I've also updated the discrete bridge to take advantage of the new > tessellation format... please verify that it works for you in ModelBuilder. > > I merged your changes with my local smtk branch which contains the vtkCmbMoabReader, and now I can load a moab (.exo) file into ModelBuilder(v4) with its geometry shown. Unfortunately, parts of the geometry are misplaced. Also, now the geometry of cmb files is not displayed properly (actually, most of the geometry is missing). In my local branch, I added the "import" of vtk files in discrete bridge, it is now broken too with similar problem as loading cmb files. I can show you the problem tomorrow morning if you have time. Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Nov 4 09:10:28 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 4 Nov 2014 09:10:28 -0500 Subject: [Smtk-developers] Question about tessellation info In-Reply-To: References: <11F0BE18-3488-4D39-A7B9-8F86E99F02DF@kitware.com> Message-ID: <9ECC5A63-D38B-414C-ACDD-956B834EBF7A@kitware.com> >> I've pushed changes to the smtk/model/Tessellation class *and* the test data repo. ... >> Yumin, I've also updated the discrete bridge to take advantage of the new tessellation format... please verify that it works for you in ModelBuilder. >> > > I merged your changes with my local smtk branch which contains the vtkCmbMoabReader, and now I can load a moab (.exo) file into ModelBuilder(v4) with its geometry shown. Unfortunately, parts of the geometry are misplaced. A picture is worth a thousand words. > Also, now the geometry of cmb files is not displayed properly (actually, most of the geometry is missing). In my local branch, I added the "import" of vtk files in discrete bridge, it is now broken too with similar problem as loading cmb files. > > I can show you the problem tomorrow morning if you have time. Yup, just give me a call. David From yumin.yuan at kitware.com Tue Nov 4 09:56:15 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Tue, 4 Nov 2014 09:56:15 -0500 Subject: [Smtk-developers] Fwd: Question about tessellation info In-Reply-To: References: <11F0BE18-3488-4D39-A7B9-8F86E99F02DF@kitware.com> <9ECC5A63-D38B-414C-ACDD-956B834EBF7A@kitware.com> Message-ID: Should have replied to all. ---------- Forwarded message ---------- From: Yumin Yuan Date: Tue, Nov 4, 2014 at 9:52 AM Subject: Re: Question about tessellation info To: David Thompson Hi Dave, On Tue, Nov 4, 2014 at 9:10 AM, David Thompson wrote: > >> I've pushed changes to the smtk/model/Tessellation class *and* the test > data repo. ... > >> Yumin, I've also updated the discrete bridge to take advantage of the > new tessellation format... please verify that it works for you in > ModelBuilder. > >> > > > > I merged your changes with my local smtk branch which contains the > vtkCmbMoabReader, and now I can load a moab (.exo) file into > ModelBuilder(v4) with its geometry shown. Unfortunately, parts of the > geometry are misplaced. > > A picture is worth a thousand words. > > Attached (Fig 1) is screenshot of a .exo file, a cube with 6 faces, among which 2 were misplaced. > > Also, now the geometry of cmb files is not displayed properly (actually, > most of the geometry is missing). In my local branch, I added the "import" > of vtk files in discrete bridge, it is now broken too with similar problem > as loading cmb files. > > > > I can show you the problem tomorrow morning if you have time. > > Yup, just give me a call. > > > Fig 2 and 3 are cmb files. Looks like only one triangle is showing for each face. Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Fig 1 .exo file.png Type: image/png Size: 57095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Fig 2 smooth_surface.cmb.png Type: image/png Size: 20269 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Fig 3 test2D.cmb.png Type: image/png Size: 16839 bytes Desc: not available URL: From david.thompson at kitware.com Tue Nov 4 12:38:27 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 4 Nov 2014 12:38:27 -0500 Subject: [Smtk-developers] Fwd: Question about tessellation info In-Reply-To: References: <11F0BE18-3488-4D39-A7B9-8F86E99F02DF@kitware.com> <9ECC5A63-D38B-414C-ACDD-956B834EBF7A@kitware.com> Message-ID: <432D09D5-E291-4849-8AE4-1CDA4329BAB7@kitware.com> Hi Yumin, Thanks for running through the debugger with me. I've pushed the change that we made to get things working plus some more verbose error reporting. David > On Tue, Nov 4, 2014 at 9:10 AM, David Thompson wrote: > >> I've pushed changes to the smtk/model/Tessellation class *and* the test data repo. ... > >> Yumin, I've also updated the discrete bridge to take advantage of the new tessellation format... please verify that it works for you in ModelBuilder. > >> > > > > I merged your changes with my local smtk branch which contains the vtkCmbMoabReader, and now I can load a moab (.exo) file into ModelBuilder(v4) with its geometry shown. Unfortunately, parts of the geometry are misplaced. > > A picture is worth a thousand words. > > > Attached (Fig 1) is screenshot of a .exo file, a cube with 6 faces, among which 2 were misplaced. > > > Also, now the geometry of cmb files is not displayed properly (actually, most of the geometry is missing). In my local branch, I added the "import" of vtk files in discrete bridge, it is now broken too with similar problem as loading cmb files. > > > > I can show you the problem tomorrow morning if you have time. > > Yup, just give me a call. > > > > Fig 2 and 3 are cmb files. Looks like only one triangle is showing for each face. > > Yumin > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From david.thompson at kitware.com Wed Nov 5 18:57:56 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 5 Nov 2014 18:57:56 -0500 Subject: [Smtk-developers] CGM stuff in master Message-ID: Hi all, I've pushed some changes to master that get the CGM bridge working (with caveats) and add some operators (create a sphere with a given radius, center, and optional inner diameter to make a shell; create a prism given a height, a number of sides, and major+minor radii; and perform a boolean union on a set of bodies), also with caveats. If people are really interested, I'll discuss the caveats. But before you complain, please take a look at the shiny pictures! Next up is getting these operators exposed in CMB as right now they are just being tested as part of SMTK (run "./bin/test-operators -help" when building with CGM enabled). And then removing some of the caveats. David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 6.13.39 PM.png Type: image/png Size: 40314 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 6.55.32 PM.png Type: image/png Size: 61219 bytes Desc: not available URL: From yumin.yuan at kitware.com Wed Nov 5 22:01:01 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Wed, 5 Nov 2014 22:01:01 -0500 Subject: [Smtk-developers] CGM stuff in master In-Reply-To: References: Message-ID: Hi Dave, Great, and that is indeed very shiny! With your changes to smtk-cgm, the cmb_v4 (ModelBuilder) can now load the 62_shaver1.brep file (see attached, and it is pretty shiny too). Now we need to somehow get your shiny sphere and prism operations exposed in CMB. Yumin On Wed, Nov 5, 2014 at 6:57 PM, David Thompson wrote: > Hi all, > > I've pushed some changes to master that get the CGM bridge working (with > caveats) and add some operators (create a sphere with a given radius, > center, and optional inner diameter to make a shell; create a prism given a > height, a number of sides, and major+minor radii; and perform a boolean > union on a set of bodies), also with caveats. > > If people are really interested, I'll discuss the caveats. But before you > complain, please take a look at the shiny pictures! > > Next up is getting these operators exposed in CMB as right now they are > just being tested as part of SMTK (run "./bin/test-operators -help" when > building with CGM enabled). And then removing some of the caveats. > > David > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 6.13.39 PM.png Type: image/png Size: 40314 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 6.55.32 PM.png Type: image/png Size: 61219 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmb_v4_cgm.png Type: image/png Size: 109641 bytes Desc: not available URL: From david.thompson at kitware.com Wed Nov 5 23:50:57 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 5 Nov 2014 23:50:57 -0500 Subject: [Smtk-developers] CGM stuff in master In-Reply-To: References: Message-ID: Hi Yumin, > ... With your changes to smtk-cgm, the cmb_v4 (ModelBuilder) can now load the 62_shaver1.brep file ... Great! > Now we need to somehow get your shiny sphere and prism operations exposed in CMB. I think the tricky part for the geometry creation operations like those will be deciding which bridge to target. Have you started on the toolbar buttons for operators yet? We need them to react to the current selection by highlighting themselves if they can be associated with the selection. David From bob.obara at kitware.com Wed Nov 5 23:58:16 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 5 Nov 2014 23:58:16 -0500 Subject: [Smtk-developers] CGM stuff in master In-Reply-To: References: Message-ID: <6B68D5A0-4217-4714-9B3A-A973DFE704C8@kitware.com> 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 On Nov 5, 2014, at 11:50 PM, David Thompson wrote: > Hi Yumin, > >> ... With your changes to smtk-cgm, the cmb_v4 (ModelBuilder) can now load the 62_shaver1.brep file ... > > Great! > >> Now we need to somehow get your shiny sphere and prism operations exposed in CMB. > > I think the tricky part for the geometry creation operations like those will be deciding which bridge to target. One idea is to have the bridges displayed in the model view similar to the way ParaView displays the various ParaView Servers connected to it. The user could then select the bridge and request a new model to be created from it. Bob > > Have you started on the toolbar buttons for operators yet? We need them to react to the current selection by highlighting themselves if they can be associated with the selection. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Nov 7 21:30:07 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 7 Nov 2014 21:30:07 -0500 Subject: [Smtk-developers] Bridges and descriptive phrases Message-ID: <6E19AFC6-083D-445E-8C9F-535CFCC98AF8@kitware.com> Hi Yumin, I've merged in some code that goes a little further than what we talked about as far as displaying bridge sessions in the Qt tree view. Instead of just adding a new subclass of DescriptivePhrase, I made bridges entities just like ModelEntity, Face, Edge, etc. There is a new class, smtk::model::BridgeSession, that is a Cursor subclass. You can get an array of all the bridge sesssion in a Manager with smtk::model::Manager::Ptr mgr; BridgeSessions sessions = mgr->allSessions(); and it will list models assigned to it: ModelEntities models = sessions[0].models(); This is used to present models as children of bridge sessions in DescriptivePhrase hierarchies. The BridgeSession class also provides some convenience methods for accessing bridge information. See smtk/bridge/cgm/testing/python for some examples. Please let me know if you have any problems using this to present bridges in the Qt tree view in ModelBuilder. David From david.thompson at kitware.com Sat Nov 8 19:22:30 2014 From: david.thompson at kitware.com (David Thompson) Date: Sat, 8 Nov 2014 19:22:30 -0500 Subject: [Smtk-developers] SMTK code review, more Remus debugging Message-ID: <57FE0590-C2D7-4E62-8FC7-834E5AB9618C@kitware.com> Hi Rob, If you have a minute, could you take a look at smtk/smtk.py on the stage/smtk-remote-python branch? It has some changes that load the bridge Python-libraries when the main smtk module is loaded (inside try:except: clauses so that missing/broken bridges do not disable SMTK). It also has the advantage of putting the bridge modules at smtk.bridge.cgm smtk.bridge.remote instead of other places like the current bridge modules. I'm asking you for the review because you were the last one to touch the modules (getting cgmSMTKPython into the smtk::bridge::cgm C++ namespace instead of cgmsmtk::cgm). Thanks, David From robert.maynard at kitware.com Mon Nov 10 09:17:25 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 10 Nov 2014 09:17:25 -0500 Subject: [Smtk-developers] SMTK code review, more Remus debugging In-Reply-To: <57FE0590-C2D7-4E62-8FC7-834E5AB9618C@kitware.com> References: <57FE0590-C2D7-4E62-8FC7-834E5AB9618C@kitware.com> Message-ID: Overall the branch looks good to me. I might have missed it but when a bridge starts a server how do you capture and advertise what the endpoint back to that server is? In smtk/common/Paths.cxx Have you thought about simplifying the OS includes, maybe to something like: #ifdef __APPLE__ # include "smtk/common/PathsHelperMacOSX.h" #elif defined(__CYGWIN__) //cygwin also defines _WIN32 so it most come first # include "smtk/common/PathsHelperUnix.h" #elif defined(_WIN32) # include "smtk/common/PathsHelperWindows.h" #else # include "smtk/common/PathsHelperUnix.h" #endif On Sat, Nov 8, 2014 at 7:22 PM, David Thompson wrote: > Hi Rob, > > If you have a minute, could you take a look at smtk/smtk.py on the stage/smtk-remote-python branch? It has some changes that load the bridge Python-libraries when the main smtk module is loaded (inside try:except: clauses so that missing/broken bridges do not disable SMTK). > > It also has the advantage of putting the bridge modules at > > smtk.bridge.cgm > smtk.bridge.remote > > instead of other places like the current bridge modules. > > I'm asking you for the review because you were the last one to touch the modules (getting cgmSMTKPython into the smtk::bridge::cgm C++ namespace instead of cgmsmtk::cgm). > > Thanks, > David From david.thompson at kitware.com Mon Nov 10 12:03:20 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 10 Nov 2014 12:03:20 -0500 Subject: [Smtk-developers] SMTK code review, more Remus debugging In-Reply-To: References: <57FE0590-C2D7-4E62-8FC7-834E5AB9618C@kitware.com> Message-ID: <0A94FCBC-1083-4181-B3A3-ECC42B6CAF8A@kitware.com> > Overall the branch looks good to me. I might have missed it but when a > bridge starts a server how do you capture and advertise what the > endpoint back to that server is? It's easy to miss and only minimally functional, but when RemusBridgeConnection::connectToServer is followed by a call to bridgeNames(), the BridgeRegistrar is told of new bridges; the smtk::function that the BridgeRegistrar is given to create a bridge will create a RemuteRemoteBridge configured to that endpoint. (I use smtk::function there so that I can pass in a functor that knows the proper endpoint and worker info to use.) The problems I'm having now are 1. The unit test works from a command line but not from ctest (unitRemusBridgeConnection starts a process-local server -- which finds a remus-worker file, starts the worker specified by the test, and runs a "read" operation on a test file via the worker). CTest fails to import things properly and I haven't figured out what's different about the environment variables that's causing the issue 2. The following Python script now runs on the branch but hangs because the worker turns into a zombie process immediately. import smtk rbc = smtk.bridge.remote.RemusBridgeConnection.create() rbc.addSearchDir('/usr/local/var/smtk/workers') rbc.connectToServer('local', 50505) print smtk.model.Manager.bridgeNames() sess = mgr.createSession('smtk::model[cgm{OpenCascade}]') I haven't had a chance to debug in detail and think the SC demo is more important at the moment. > In smtk/common/Paths.cxx Have you thought about simplifying the OS > includes, maybe to something like: ... I like that it's simpler but prefer to keep the headers ordered with highest sanity at the top and no repetition. :-) Thanks, David From robert.maynard at kitware.com Mon Nov 10 12:13:26 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 10 Nov 2014 12:13:26 -0500 Subject: [Smtk-developers] SMTK code review, more Remus debugging In-Reply-To: <0A94FCBC-1083-4181-B3A3-ECC42B6CAF8A@kitware.com> References: <57FE0590-C2D7-4E62-8FC7-834E5AB9618C@kitware.com> <0A94FCBC-1083-4181-B3A3-ECC42B6CAF8A@kitware.com> Message-ID: Okay that makes sense. After you are finished the demo / SC we both should have time to sit down and figure out the remus zombie issue. On Mon, Nov 10, 2014 at 12:03 PM, David Thompson wrote: >> Overall the branch looks good to me. I might have missed it but when a >> bridge starts a server how do you capture and advertise what the >> endpoint back to that server is? > > It's easy to miss and only minimally functional, but when RemusBridgeConnection::connectToServer is followed by a call to bridgeNames(), the BridgeRegistrar is told of new bridges; the smtk::function that the BridgeRegistrar is given to create a bridge will create a RemuteRemoteBridge configured to that endpoint. (I use smtk::function there so that I can pass in a functor that knows the proper endpoint and worker info to use.) > > The problems I'm having now are > > 1. The unit test works from a command line but not from ctest (unitRemusBridgeConnection starts a process-local server -- which finds a remus-worker file, starts the worker specified by the test, and runs a "read" operation on a test file via the worker). CTest fails to import things properly and I haven't figured out what's different about the environment variables that's causing the issue > > 2. The following Python script now runs on the branch but hangs because the worker turns into a zombie process immediately. > > import smtk > rbc = smtk.bridge.remote.RemusBridgeConnection.create() > rbc.addSearchDir('/usr/local/var/smtk/workers') > rbc.connectToServer('local', 50505) > print smtk.model.Manager.bridgeNames() > sess = mgr.createSession('smtk::model[cgm{OpenCascade}]') > > I haven't had a chance to debug in detail and think the SC demo is more important at the moment. > > >> In smtk/common/Paths.cxx Have you thought about simplifying the OS >> includes, maybe to something like: ... > > I like that it's simpler but prefer to keep the headers ordered with highest sanity at the top and no repetition. :-) > > Thanks, > David From david.thompson at kitware.com Tue Nov 11 15:38:15 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 11 Nov 2014 15:38:15 -0500 Subject: [Smtk-developers] Q: Tool vs workpiece Message-ID: <71E498C1-A2A6-4B45-A939-FB2252DCD23D@kitware.com> Hi Bob, Do you have a strong preference for whether the tool or the workpiece are associated with the boolean operators (as opposed to being items owned by the operator)? If you don't, I do. I am a subject-verb-object kind of a guy, and think of the subject as the piece that stays around afterwards (so pronouns can reference it)... so I vote for associating the workpiece to an operator and then adding the tool to the operator. Thanks, David From david.thompson at kitware.com Tue Nov 11 16:37:32 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 11 Nov 2014 16:37:32 -0500 Subject: [Smtk-developers] Q: Either-or combinations of attribute items Message-ID: Hi all, I believe I've heard that you can specify some items in an attribute can depend on others being present (or perhaps excluding the presence of others). Is that the case? The CGM "brick" operator takes in *either* a width, height, and depth *or* a center point, 3 axes, and a length along each axis. Is there a good way to constrain an attribute to accept one case or the other? Is this presented in the GUI as a separate tab or radio buttons (or something else)? If you let me know I will try adding something relevant to the user's guide. Thanks, David From bob.obara at kitware.com Tue Nov 11 17:03:22 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 11 Nov 2014 17:03:22 -0500 Subject: [Smtk-developers] Q: Either-or combinations of attribute items In-Reply-To: References: Message-ID: <264C24BD-E60C-4CAE-9689-7CF8C1667CA0@kitware.com> Yes you can do this by using conditional items. Here is roughly how you do it: 0 Width Height Depth 1 Center Axes Lengths 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 On Nov 11, 2014, at 4:37 PM, David Thompson wrote: > Hi all, > > I believe I've heard that you can specify some items in an attribute can depend on others being present (or perhaps excluding the presence of others). > > Is that the case? The CGM "brick" operator takes in *either* a width, height, and depth *or* a center point, 3 axes, and a length along each axis. Is there a good way to constrain an attribute to accept one case or the other? Is this presented in the GUI as a separate tab or radio buttons (or something else)? > > If you let me know I will try adding something relevant to the user's guide. > > Thanks, > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Tue Nov 11 17:36:21 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Tue, 11 Nov 2014 17:36:21 -0500 Subject: [Smtk-developers] Q: Either-or combinations of attribute items In-Reply-To: <264C24BD-E60C-4CAE-9689-7CF8C1667CA0@kitware.com> References: <264C24BD-E60C-4CAE-9689-7CF8C1667CA0@kitware.com> Message-ID: BTW, the UI will display this as a combo box with Enum entries ("Axis aligned", "General"), and when an entry is selected in the combo box, a widget with specified items for that Enum value will be shown under the combo. Yumin On Tue, Nov 11, 2014 at 5:03 PM, Robert Michael O'Bara < bob.obara at kitware.com> wrote: > Yes you can do this by using conditional items. > > Here is roughly how you do it: > > > > > > > > > > > > > > > > > > > 0 > > Width > Height > Depth > > > > 1 > > Center > Axes > Lengths > > > > > > 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 > > > > > On Nov 11, 2014, at 4:37 PM, David Thompson > wrote: > > Hi all, > > I believe I've heard that you can specify some items in an attribute can > depend on others being present (or perhaps excluding the presence of > others). > > Is that the case? The CGM "brick" operator takes in *either* a width, > height, and depth *or* a center point, 3 axes, and a length along each > axis. Is there a good way to constrain an attribute to accept one case or > the other? Is this presented in the GUI as a separate tab or radio buttons > (or something else)? > > If you let me know I will try adding something relevant to the user's > guide. > > Thanks, > David > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Nov 11 17:53:58 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 11 Nov 2014 17:53:58 -0500 Subject: [Smtk-developers] Q: Either-or combinations of attribute items In-Reply-To: References: <264C24BD-E60C-4CAE-9689-7CF8C1667CA0@kitware.com> Message-ID: <421861AA-E973-4DCB-96E2-EC3ED441783F@kitware.com> > BTW, the UI will display this as a combo box with Enum entries ("Axis aligned", "General"), and when an entry is selected in the combo box, a widget with specified items for that Enum value will be shown under the combo. Nice. Now I just need an easy way to access the resulting parameters. I had added methods to Attribute to find items of the correct type: DoubleItem findDouble(const std::string& itemName); IntItem findInt(const std::string& itemName); // and so on... This has been really useful in smtk/model so far; I can write AttributePtr result; if (result->findInt("outcome")->value() == OPERATOR_SUCCESS) // ... instead of many lines of code to find the number of items, iterate until I find one of the given name, and downcast it to the proper type. Now I need some way to access children the same way. Does anyone have a preferred method for doing this? I could add methods of the same name to ValueItem so that (for Bob's example), one could descend the tree manually: AttributePtr brickOp; brickOp->findInt("Specification Mode")->findDouble("Width"); but this doesn't take active vs inactive children into account. An extra parameter might indicate whether findDouble searched all children or just the active children. Also, the above would not find granchildren without a full specification of the "path". It might be preferable to write brickOp->findDouble("Width", ACTIVE_CHILDREN); // or NO_CHILDREN or ALL_CHILDREN for the 2nd argument instead of brickOp->findInt("Specification Mode")->findDouble("Width"); Any opinions? Does search order (depth-first vs breadth-first) make a big difference to anyone (assuming the first match is returned)? Thanks, David From bob.obara at kitware.com Tue Nov 11 18:06:54 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 11 Nov 2014 18:06:54 -0500 Subject: [Smtk-developers] Q: Either-or combinations of attribute items In-Reply-To: <421861AA-E973-4DCB-96E2-EC3ED441783F@kitware.com> References: <264C24BD-E60C-4CAE-9689-7CF8C1667CA0@kitware.com> <421861AA-E973-4DCB-96E2-EC3ED441783F@kitware.com> Message-ID: <2041E45A-C1B9-4521-845F-AA4A914E3BF1@kitware.com> I wonder if we need a find method that is template based - like the addItemDefinition method in Definition.h ? Then we have one method that will automatically deal with new item definition types typedef smtk::attribute::IntItem IntComp; typedef smtk::attribute::DoubleItem DoubleComp; typedef smtk::attribute::StringItem StringComp; typedef smtk::attribute::ValueItem ValueComp; typedef smtk::attribute::Item AttComp; attribute->find("Specification Mode")->find("Height") ? Also note that the above would core dump if the first find fails. 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 On Nov 11, 2014, at 5:53 PM, David Thompson wrote: >> BTW, the UI will display this as a combo box with Enum entries ("Axis aligned", "General"), and when an entry is selected in the combo box, a widget with specified items for that Enum value will be shown under the combo. > > Nice. Now I just need an easy way to access the resulting parameters. I had added methods to Attribute to find items of the correct type: > > DoubleItem findDouble(const std::string& itemName); > IntItem findInt(const std::string& itemName); > // and so on... > > This has been really useful in smtk/model so far; I can write > > AttributePtr result; > if (result->findInt("outcome")->value() == OPERATOR_SUCCESS) > // ... > > instead of many lines of code to find the number of items, iterate until I find one of the given name, and downcast it to the proper type. Now I need some way to access children the same way. Does anyone have a preferred method for doing this? I could add methods of the same name to ValueItem so that (for Bob's example), one could descend the tree manually: > > AttributePtr brickOp; > brickOp->findInt("Specification Mode")->findDouble("Width"); > > but this doesn't take active vs inactive children into account. An extra parameter might indicate whether findDouble searched all children or just the active children. Also, the above would not find granchildren without a full specification of the "path". It might be preferable to write > > brickOp->findDouble("Width", ACTIVE_CHILDREN); > // or NO_CHILDREN or ALL_CHILDREN for the 2nd argument > > instead of > > brickOp->findInt("Specification Mode")->findDouble("Width"); > > Any opinions? Does search order (depth-first vs breadth-first) make a big difference to anyone (assuming the first match is returned)? > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Nov 11 18:16:57 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 11 Nov 2014 18:16:57 -0500 Subject: [Smtk-developers] Q: Either-or combinations of attribute items In-Reply-To: <2041E45A-C1B9-4521-845F-AA4A914E3BF1@kitware.com> References: <264C24BD-E60C-4CAE-9689-7CF8C1667CA0@kitware.com> <421861AA-E973-4DCB-96E2-EC3ED441783F@kitware.com> <2041E45A-C1B9-4521-845F-AA4A914E3BF1@kitware.com> Message-ID: <12120D9D-F19C-4898-A8BD-C0D2DC59C00E@kitware.com> > I wonder if we need a find method that is template based - like the addItemDefinition method in Definition.h ? I would have preferred to do things that way but my shiboken-fu was not up to getting the templated method wrapped (last year). I'm happy to switch the API now. > ... Also note that the above would core dump if the first find fails. Yes, but for things like the operators where the attribute items are fixed, I am willing to omit the NULL-pointer checking in favor of legibility. Also, now that I am exploring conditional children, I see that ValueItem.cxx says: void ValueItem::updateActiveChildrenItems() { ... // Note that for the current implementation only value items with 1 // required value is support for conditional children. // Check to see if the index is valid ... } and sure enough, when I call setDiscreteIndex() on the "Specification Mode" item, it returns success but then shows 0 active children. Is this expected? I've modified all of the items so they have valid defaults... do they have to be non-default to be considered active? Thanks, David From yumin.yuan at kitware.com Tue Nov 11 19:20:30 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Tue, 11 Nov 2014 19:20:30 -0500 Subject: [Smtk-developers] Bridges and descriptive phrases In-Reply-To: <6E19AFC6-083D-445E-8C9F-535CFCC98AF8@kitware.com> References: <6E19AFC6-083D-445E-8C9F-535CFCC98AF8@kitware.com> Message-ID: Dave, I have something working, and also have something "crashing" inside cgm. Things work for: * one bridge session with multiple read operators: each model from "read" will show as children of the same "bridge session". This works for both cgm and discrete bridges. * For cgm bridge, after "read", the "create prism/sphere" will work ONLY if I start a new bridge-session, which means the "prism/sphere" model will show as children of the New session. The following will crash inside cgm: * For cgm bridge, after "read", the "create prism/sphere" will crash inside cgm if I use the same bridge-session of "read", and I verified that GeometryModifyTool::instance() was NOT null. Here is the trace of crash ... (It doesn't seem to help) Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: EXC_I386_GPFLT Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libcgm.0.dylib 0x000000011ec78754 GeometryModifyTool::prism(double, int, double, double) + 214 1 libcgmSMTK.dylib 0x000000011e992972 smtk::bridge::cgm::CreatePrismOperator::operateInternal() + 1730 (CreatePrismOperator.cxx:81) 2 libSMTKCore.dylib 0x00000001074b9229 smtk::model::Operator::operate() + 137 (Operator.cxx:74) 3 libModelBridge_Plugin.dylib 0x0000000107b6677a vtkModelManagerWrapper::ProcessJSONRequest() + 6522 Thanks, Yumin On Fri, Nov 7, 2014 at 9:30 PM, David Thompson wrote: > Hi Yumin, > > I've merged in some code that goes a little further than what we talked > about as far as displaying bridge sessions in the Qt tree view. Instead of > just adding a new subclass of DescriptivePhrase, I made bridges entities > just like ModelEntity, Face, Edge, etc. > > There is a new class, smtk::model::BridgeSession, that is a Cursor > subclass. You can get an array of all the bridge sesssion in a Manager with > > smtk::model::Manager::Ptr mgr; > BridgeSessions sessions = mgr->allSessions(); > > and it will list models assigned to it: > > ModelEntities models = sessions[0].models(); > > This is used to present models as children of bridge sessions in > DescriptivePhrase hierarchies. The BridgeSession class also provides some > convenience methods for accessing bridge information. See > smtk/bridge/cgm/testing/python for some examples. > > Please let me know if you have any problems using this to present bridges > in the Qt tree view in ModelBuilder. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Nov 12 09:10:47 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 12 Nov 2014 09:10:47 -0500 Subject: [Smtk-developers] Bridges and descriptive phrases In-Reply-To: References: <6E19AFC6-083D-445E-8C9F-535CFCC98AF8@kitware.com> Message-ID: <5DA09412-C9E6-44C6-BADE-1F310799BA6A@kitware.com> Hi Yumin, You're right, without any debug information like a line number, the stack trace doesn't tell me anything. I'll try building CMBv4 again today but if you get a debug build of CGM going, that would be great, too. David Sent from my iPad > On Nov 11, 2014, at 19:20, Yumin Yuan wrote: > > Dave, > > I have something working, and also have something "crashing" inside cgm. > > Things work for: > * one bridge session with multiple read operators: each model from "read" will show as children of the same "bridge session". This works for both cgm and discrete bridges. > * For cgm bridge, after "read", the "create prism/sphere" will work ONLY if I start a new bridge-session, which means the "prism/sphere" model will show as children of the New session. > > The following will crash inside cgm: > * For cgm bridge, after "read", the "create prism/sphere" will crash inside cgm if I use the same bridge-session of "read", and I verified that GeometryModifyTool::instance() was NOT null. Here is the trace of crash ... (It doesn't seem to help) > > Exception Type: EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: EXC_I386_GPFLT > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libcgm.0.dylib 0x000000011ec78754 GeometryModifyTool::prism(double, int, double, double) + 214 > 1 libcgmSMTK.dylib 0x000000011e992972 smtk::bridge::cgm::CreatePrismOperator::operateInternal() + 1730 (CreatePrismOperator.cxx:81) > 2 libSMTKCore.dylib 0x00000001074b9229 smtk::model::Operator::operate() + 137 (Operator.cxx:74) > 3 libModelBridge_Plugin.dylib 0x0000000107b6677a vtkModelManagerWrapper::ProcessJSONRequest() + 6522 > > Thanks, > Yumin > >> On Fri, Nov 7, 2014 at 9:30 PM, David Thompson wrote: >> Hi Yumin, >> >> I've merged in some code that goes a little further than what we talked about as far as displaying bridge sessions in the Qt tree view. Instead of just adding a new subclass of DescriptivePhrase, I made bridges entities just like ModelEntity, Face, Edge, etc. >> >> There is a new class, smtk::model::BridgeSession, that is a Cursor subclass. You can get an array of all the bridge sesssion in a Manager with >> >> smtk::model::Manager::Ptr mgr; >> BridgeSessions sessions = mgr->allSessions(); >> >> and it will list models assigned to it: >> >> ModelEntities models = sessions[0].models(); >> >> This is used to present models as children of bridge sessions in DescriptivePhrase hierarchies. The BridgeSession class also provides some convenience methods for accessing bridge information. See smtk/bridge/cgm/testing/python for some examples. >> >> Please let me know if you have any problems using this to present bridges in the Qt tree view in ModelBuilder. >> >> David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Nov 12 12:59:28 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 12 Nov 2014 12:59:28 -0500 Subject: [Smtk-developers] Q: default for vector value possible? Message-ID: Hi all, I have an attribute item defined like this 1.0,0.0,0.0 but when I create an instance of the attribute and examine its value, I get: >>> ax0 = smtk.attribute.to_concrete(att.find('axis 0')) >>> [ax0.value(i) for i in range(3)] [1.0, 1.0, 1.0] Is there a way to provide a default for each of the required values? Thanks, David From david.thompson at kitware.com Thu Nov 13 14:49:00 2014 From: david.thompson at kitware.com (David Thompson) Date: Thu, 13 Nov 2014 14:49:00 -0500 Subject: [Smtk-developers] New CGM operators Message-ID: <0519C950-E72B-403C-A7A4-3B4074C5A0C7@kitware.com> Hi all, I've added a batch of new CGM operators to SMTK (and fixed a few things in the process). The operators include: - create vertex - create edge (straight, arc, ellipse, parabola, hyperbola... but only straight and arc are tested) - create face (planar or "best fit" -- which is a synonym for planar as far as I can tell) - create cylinder - create brick - create sphere - create prism - union (a boolean, but only tested in a simple case) - read (from a file supported by CGM) There are examples of the operators in the smtk/bridge/cgm/testing/python directory. Some notes: 1. The "create brick" operator is interesting because it demonstrates conditional items. 2. the "union" operator is interesting because it expects the models you wish to unite to be associated with it rather than passed in via an smtk::attribute::ModelEntityItem. 3. The edge and face creation operators currently take vertices and edges to connect as input items, but will probably move to using an association in the future. 4. Yumin has discovered that the union operator exposes an issue in the model manager... the result of the operation does not appear to be properly transcribed when using a forwarding bridge. 5. Some of the operator XML descriptions are marked as requiring a "b" association. This is a new type of association and indicates that the operator should be associated to a bridge session. Creation operators in general should have this type of association so that the user can choose which session/kernel to use. David PS. As an example, the Python script below created the 4 vertices, 6 edges, and 3 faces in the screenshot. import smtk mgr = smtk.model.Manager.create() sess = mgr.createSession('cgm') brg = sess.bridge() def setCoord(x,v): for i in range(len(v)): x.setValue(i,v[i]) def setEntitiesByIndex(p,ep,v): for i in range(len(ep)): p.setValue(i, v[ep[i]]) verts = [] edges = [] faces = [] volus = [] # Create vertices pcoords = [ (0,0,0), (1,0,0), (0,1,0), (0,0,1)] crv = sess.op('create vertex') x = crv.findAsDouble('point') c = crv.findAsInt('color') c.setValue(0, 1) for pt in pcoords: setCoord(x,pt); verts.append(crv.operate().findModelEntity('vertex').value(0)) # Create edges epts = [(0,1), (0,2), (0,3), (1,2), (1,3), (2,3)] cre = sess.op('create edge') t = cre.findAsInt('curve type') t.setValue(0,6) # 6 == line segment in OpenCascade v = cre.findAsModelEntity('vertices') x = cre.findAsDouble('point') c = cre.findAsInt('color') c.setValue(0, 2) for epair in epts: setEntitiesByIndex(v,epair,verts) if epair == (2,3): # Make the last edge an arc: t.setValue(0,1) # 1 == arc setCoord(x,[0,0.6,0.6]) # third point on arc edges.append(cre.operate().findModelEntity('edge').value(0)) # Create faces fedg = [ (12, 0, 3, 1), (12, 0, 4, 2), (16, 1, 5, 2) ] # (16, 3, 5, 4) # <-- OpenCascade cannot infer that this face should be cylindrical crf = sess.op('create face') t = crf.findAsInt('surface type') t.setValue(0, 12) e = crf.findAsModelEntity('edges') c = crf.findAsInt('color') c.setValue(0, 3) for face in fedg: e.setNumberOfValues(len(face)-1) setEntitiesByIndex(e,face[1:],edges) t.setValue(face[0]) # These values are OpenCascade enum values. faces.append(crf.operate().findModelEntity('face').value(0)) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SMTK geometry creation.png Type: image/png Size: 15267 bytes Desc: not available URL: From david.thompson at kitware.com Thu Nov 13 15:08:15 2014 From: david.thompson at kitware.com (David Thompson) Date: Thu, 13 Nov 2014 15:08:15 -0500 Subject: [Smtk-developers] Associating entities vs adding items Message-ID: <1A0F8AB1-43B0-4EDB-A527-99643A8918B2@kitware.com> Hi all, Yumin and I were discussing CMBv4 and Yumin mentioned that while attributes can indicate the type of entities they may be associated with, there is no way to describe limits on the number of entities (e.g., a subtract operator may support only a single workpiece at a time, but the GUI cannot infer that too many models are selected for the subtract operator). One way we might accommodate storing extra information about associations is to ditch the way associations are currently stored and create a special ModelEntityItem that is marked as the attribute's associations. Instead of ... we would have ... Any opinions? David From bob.obara at kitware.com Thu Nov 13 15:18:23 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Thu, 13 Nov 2014 15:18:23 -0500 Subject: [Smtk-developers] Associating entities vs adding items In-Reply-To: <1A0F8AB1-43B0-4EDB-A527-99643A8918B2@kitware.com> References: <1A0F8AB1-43B0-4EDB-A527-99643A8918B2@kitware.com> Message-ID: <5016F9EE-D7D4-4D66-BCC1-601170716430@kitware.com> I don't see how this would resolve anything - The simplest solution would be to have a property on the definition indicating the max number of model entities the attribute could be associated with. Give me a call and we can discuss this. 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 On Nov 13, 2014, at 3:08 PM, David Thompson wrote: > Hi all, > > Yumin and I were discussing CMBv4 and Yumin mentioned that while attributes can indicate the type of entities they may be associated with, there is no way to describe limits on the number of entities (e.g., a subtract operator may support only a single workpiece at a time, but the GUI cannot infer that too many models are selected for the subtract operator). > > One way we might accommodate storing extra information about associations is to ditch the way associations are currently stored and create a special ModelEntityItem that is marked as the attribute's associations. Instead of > > > > ... > > > > we would have > > > > > ... > > > > > Any opinions? > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Thu Nov 13 17:01:57 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Thu, 13 Nov 2014 17:01:57 -0500 Subject: [Smtk-developers] New CGM operators In-Reply-To: <0519C950-E72B-403C-A7A4-3B4074C5A0C7@kitware.com> References: <0519C950-E72B-403C-A7A4-3B4074C5A0C7@kitware.com> Message-ID: That's great, Dave. I updated a few things from cmb_v4, and here is what I got: * Creating Prism, Brick, Cylinder are working, see attached screenshot. * Creating sphere return a sphere, sort of (see attached ) * Creating Vertex, Edge, Face did not work for me. No geometry returned, and sometime crash. I believe the crashes were from cgm, and I don't have useful backtrace info from the crash. Yumin On Thu, Nov 13, 2014 at 2:49 PM, David Thompson wrote: > Hi all, > > I've added a batch of new CGM operators to SMTK (and fixed a few things in > the process). The operators include: > > - create vertex > - create edge (straight, arc, ellipse, parabola, hyperbola... but only > straight and arc are tested) > - create face (planar or "best fit" -- which is a synonym for planar as > far as I can tell) > - create cylinder > - create brick > - create sphere > - create prism > - union (a boolean, but only tested in a simple case) > - read (from a file supported by CGM) > > There are examples of the operators in the smtk/bridge/cgm/testing/python > directory. > > Some notes: > > 1. The "create brick" operator is interesting because it demonstrates > conditional items. > 2. the "union" operator is interesting because it expects the models you > wish to unite to be associated with it rather than passed in via an > smtk::attribute::ModelEntityItem. > 3. The edge and face creation operators currently take vertices and edges > to connect as input items, but will probably move to using an association > in the future. > 4. Yumin has discovered that the union operator exposes an issue in the > model manager... the result of the operation does not appear to be properly > transcribed when using a forwarding bridge. > 5. Some of the operator XML descriptions are marked as requiring a "b" > association. This is a new type of association and indicates that the > operator should be associated to a bridge session. Creation operators in > general should have this type of association so that the user can choose > which session/kernel to use. > > David > > PS. As an example, the Python script below created the 4 vertices, 6 > edges, and 3 faces in the screenshot. > > import smtk > mgr = smtk.model.Manager.create() > sess = mgr.createSession('cgm') > brg = sess.bridge() > > def setCoord(x,v): > for i in range(len(v)): > x.setValue(i,v[i]) > > def setEntitiesByIndex(p,ep,v): > for i in range(len(ep)): > p.setValue(i, v[ep[i]]) > > verts = [] > edges = [] > faces = [] > volus = [] > > # Create vertices > pcoords = [ (0,0,0), (1,0,0), (0,1,0), (0,0,1)] > crv = sess.op('create vertex') > x = crv.findAsDouble('point') > c = crv.findAsInt('color') > c.setValue(0, 1) > for pt in pcoords: > setCoord(x,pt); > verts.append(crv.operate().findModelEntity('vertex').value(0)) > > # Create edges > epts = [(0,1), (0,2), (0,3), (1,2), (1,3), (2,3)] > cre = sess.op('create edge') > t = cre.findAsInt('curve type') > t.setValue(0,6) # 6 == line segment in OpenCascade > v = cre.findAsModelEntity('vertices') > x = cre.findAsDouble('point') > c = cre.findAsInt('color') > c.setValue(0, 2) > for epair in epts: > setEntitiesByIndex(v,epair,verts) > if epair == (2,3): > # Make the last edge an arc: > t.setValue(0,1) # 1 == arc > setCoord(x,[0,0.6,0.6]) # third point on arc > edges.append(cre.operate().findModelEntity('edge').value(0)) > > # Create faces > fedg = [ > (12, 0, 3, 1), > (12, 0, 4, 2), > (16, 1, 5, 2) > ] > # (16, 3, 5, 4) # <-- OpenCascade cannot infer that this face should be > cylindrical > crf = sess.op('create face') > t = crf.findAsInt('surface type') > t.setValue(0, 12) > e = crf.findAsModelEntity('edges') > c = crf.findAsInt('color') > c.setValue(0, 3) > for face in fedg: > e.setNumberOfValues(len(face)-1) > setEntitiesByIndex(e,face[1:],edges) > t.setValue(face[0]) # These values are OpenCascade enum values. > faces.append(crf.operate().findModelEntity('face').value(0)) > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SMTK geometry creation.png Type: image/png Size: 15267 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cgm-create-ops.png Type: image/png Size: 102628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cgm-sphere.png Type: image/png Size: 42411 bytes Desc: not available URL: From yumin.yuan at kitware.com Thu Nov 13 17:32:02 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Thu, 13 Nov 2014 17:32:02 -0500 Subject: [Smtk-developers] New CGM operators In-Reply-To: References: <0519C950-E72B-403C-A7A4-3B4074C5A0C7@kitware.com> Message-ID: Just to clarify, I was running from ModelBuilder_v4, which uses cmbForwardingBridge to launch the cgm operators and collects their results, then uses paraview's rendering framework to display the geometry. So this is not exactly the same flow as Dave uses. My flow includes UI components and extra paraview proxy layers. On Thu, Nov 13, 2014 at 5:01 PM, Yumin Yuan wrote: > That's great, Dave. > > I updated a few things from cmb_v4, and here is what I got: > > * Creating Prism, Brick, Cylinder are working, see attached screenshot. > * Creating sphere return a sphere, sort of (see attached ) > * Creating Vertex, Edge, Face did not work for me. No geometry returned, > and sometime crash. I believe the crashes were from cgm, and I don't have > useful backtrace info from the crash. > > Yumin > > On Thu, Nov 13, 2014 at 2:49 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi all, >> >> I've added a batch of new CGM operators to SMTK (and fixed a few things >> in the process). The operators include: >> >> - create vertex >> - create edge (straight, arc, ellipse, parabola, hyperbola... but only >> straight and arc are tested) >> - create face (planar or "best fit" -- which is a synonym for planar as >> far as I can tell) >> - create cylinder >> - create brick >> - create sphere >> - create prism >> - union (a boolean, but only tested in a simple case) >> - read (from a file supported by CGM) >> >> There are examples of the operators in the smtk/bridge/cgm/testing/python >> directory. >> >> Some notes: >> >> 1. The "create brick" operator is interesting because it demonstrates >> conditional items. >> 2. the "union" operator is interesting because it expects the models you >> wish to unite to be associated with it rather than passed in via an >> smtk::attribute::ModelEntityItem. >> 3. The edge and face creation operators currently take vertices and edges >> to connect as input items, but will probably move to using an association >> in the future. >> 4. Yumin has discovered that the union operator exposes an issue in the >> model manager... the result of the operation does not appear to be properly >> transcribed when using a forwarding bridge. >> 5. Some of the operator XML descriptions are marked as requiring a "b" >> association. This is a new type of association and indicates that the >> operator should be associated to a bridge session. Creation operators in >> general should have this type of association so that the user can choose >> which session/kernel to use. >> >> David >> >> PS. As an example, the Python script below created the 4 vertices, 6 >> edges, and 3 faces in the screenshot. >> >> import smtk >> mgr = smtk.model.Manager.create() >> sess = mgr.createSession('cgm') >> brg = sess.bridge() >> >> def setCoord(x,v): >> for i in range(len(v)): >> x.setValue(i,v[i]) >> >> def setEntitiesByIndex(p,ep,v): >> for i in range(len(ep)): >> p.setValue(i, v[ep[i]]) >> >> verts = [] >> edges = [] >> faces = [] >> volus = [] >> >> # Create vertices >> pcoords = [ (0,0,0), (1,0,0), (0,1,0), (0,0,1)] >> crv = sess.op('create vertex') >> x = crv.findAsDouble('point') >> c = crv.findAsInt('color') >> c.setValue(0, 1) >> for pt in pcoords: >> setCoord(x,pt); >> verts.append(crv.operate().findModelEntity('vertex').value(0)) >> >> # Create edges >> epts = [(0,1), (0,2), (0,3), (1,2), (1,3), (2,3)] >> cre = sess.op('create edge') >> t = cre.findAsInt('curve type') >> t.setValue(0,6) # 6 == line segment in OpenCascade >> v = cre.findAsModelEntity('vertices') >> x = cre.findAsDouble('point') >> c = cre.findAsInt('color') >> c.setValue(0, 2) >> for epair in epts: >> setEntitiesByIndex(v,epair,verts) >> if epair == (2,3): >> # Make the last edge an arc: >> t.setValue(0,1) # 1 == arc >> setCoord(x,[0,0.6,0.6]) # third point on arc >> edges.append(cre.operate().findModelEntity('edge').value(0)) >> >> # Create faces >> fedg = [ >> (12, 0, 3, 1), >> (12, 0, 4, 2), >> (16, 1, 5, 2) >> ] >> # (16, 3, 5, 4) # <-- OpenCascade cannot infer that this face should be >> cylindrical >> crf = sess.op('create face') >> t = crf.findAsInt('surface type') >> t.setValue(0, 12) >> e = crf.findAsModelEntity('edges') >> c = crf.findAsInt('color') >> c.setValue(0, 3) >> for face in fedg: >> e.setNumberOfValues(len(face)-1) >> setEntitiesByIndex(e,face[1:],edges) >> t.setValue(face[0]) # These values are OpenCascade enum values. >> faces.append(crf.operate().findModelEntity('face').value(0)) >> >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SMTK geometry creation.png Type: image/png Size: 15267 bytes Desc: not available URL: From david.thompson at kitware.com Fri Nov 14 11:35:24 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 14 Nov 2014 11:35:24 -0500 Subject: [Smtk-developers] New CGM operators In-Reply-To: References: <0519C950-E72B-403C-A7A4-3B4074C5A0C7@kitware.com> Message-ID: Hi Yumin, > * Creating sphere return a sphere, sort of (see attached ) Hehe. That is actually a nice sphere, as long as you don't care about chord error being about 10% of the diameter. You can change it by calling Bridge* cgmBridge; cgmBridge->setup("tessellation maximum relative chord error", "0.01"); cgmBridge->setup("tessellation maximum angle error", "5"); The first parameter is a fraction of the diameter of all geometry in the bridge session used to bound chord error. The second parameter is an angle in degrees and is the maximum difference between the linear/triangular approximation and the true geometry at each tessellation point (as I understand the CGM/OCC documentation). The only problem is that I have not updated the cmbForwardingBridge and vtkSMModelManagerProxy to forward these calls over the client/server connection. But it should not be difficult. Note that both the parameter name and value are strings at this point. > * Creating Vertex, Edge, Face did not work for me. No geometry returned, and sometime crash. I believe the crashes were from cgm, and I don't have useful backtrace info from the crash. OK. I will try to replicate and see what's up. David From david.thompson at kitware.com Fri Nov 14 12:33:00 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 14 Nov 2014 12:33:00 -0500 Subject: [Smtk-developers] Q: Either-or combinations of attribute items In-Reply-To: <12120D9D-F19C-4898-A8BD-C0D2DC59C00E@kitware.com> References: <264C24BD-E60C-4CAE-9689-7CF8C1667CA0@kitware.com> <421861AA-E973-4DCB-96E2-EC3ED441783F@kitware.com> <2041E45A-C1B9-4521-845F-AA4A914E3BF1@kitware.com> <12120D9D-F19C-4898-A8BD-C0D2DC59C00E@kitware.com> Message-ID: <0B7BCDCF-2B95-44BB-8715-87685D323BB7@kitware.com> Hi all, >> I wonder if we need a find method that is template based - like the addItemDefinition method in Definition.h ? > > I would have preferred to do things that way but my shiboken-fu was not up to getting the templated method wrapped (last year). I'm happy to switch the API now. The Attribute class has changed like so: * The find(const std::string& name) method now takes an extra argument to indicate whether items with children should have their children searched. ItemPtr find(const std::string& name, SearchStyle style = ACTIVE_CHILDREN); ConstItemPtr find(const std::string& name, SearchStyle style = ACTIVE_CHILDREN) const; * There now a templated variant of the call: template typename T::Ptr findAs( const std::string& name, SearchStyle style = ACTIVE_CHILDREN); The existing findInt(), findDouble(), ... have **not** been removed. They are wrapped by shiboken and greatly reduce the amount of typing required in both C++ and Python. In C++, you can use att->findInt("outcome") instead of using smtk::attribute::IntItem; att->findAs("outcome"); In Python, you can use att.findInt('outcome') instead of smtk.attribute.to_concrete(att.find('outcome')) * The shiboken bindings provide additional methods named find() that do not require the second argument (shiboken does not handle default parameters properly). We can make further changes as needed, but this gets things working for the CreateBrickOperator so I am happy to let sleeping dogs lie. David From david.thompson at kitware.com Fri Nov 14 12:56:07 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 14 Nov 2014 12:56:07 -0500 Subject: [Smtk-developers] Associating entities vs adding items In-Reply-To: <5016F9EE-D7D4-4D66-BCC1-601170716430@kitware.com> References: <1A0F8AB1-43B0-4EDB-A527-99643A8918B2@kitware.com> <5016F9EE-D7D4-4D66-BCC1-601170716430@kitware.com> Message-ID: <1973CE1B-F10C-422D-81AE-E2006CA6B0AE@kitware.com> Hi all, > I don't see how this would resolve anything - The simplest solution would be to have a property on the definition indicating the max number of model entities the attribute could be associated with. > > Give me a call and we can discuss this. Apparently I was able to communicate better over the phone than e-mail. :-) We will use a ModelEntityItemDefinition owned by each Definition to describe possible associations and a ModelEntityItem owned by each corresponding Attribute to store the actual list of associated entities. The API to Attribute for associating entities will stay the same but use these instances underneath the hood to do the work (eliminating duplicate code). The XML for indicating associations will change from having an XML attribute of AttDef named "Associations" to a child element of AttDef named "Associations". It will be parsed as if it were a ModelEntityItemDefinition. Its absence indicates that attributes are not allowed to have associations of any type. So, will become A similar change will be made for specifying attribute instances in XML. By making the ModelEntityItem and ModelEntityItemDefinition instances available from the Attribute and Definition (respectively), the GUI panels can also add UI elements corresponding to associations. This is important for SMTK operators since currently things like the "union" operator do not provide any way to change or set the workpieces to process. These changes should go in next week some time. David >> Yumin and I were discussing CMBv4 and Yumin mentioned that while attributes can indicate the type of entities they may be associated with, there is no way to describe limits on the number of entities (e.g., a subtract operator may support only a single workpiece at a time, but the GUI cannot infer that too many models are selected for the subtract operator). >> >> One way we might accommodate storing extra information about associations is to ditch the way associations are currently stored and create a special ModelEntityItem that is marked as the attribute's associations. Instead of >> >> >> >> ... >> >> >> >> we would have >> >> >> >> >> ... >> >> >> >> >> Any opinions? >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers > From david.thompson at kitware.com Mon Nov 17 11:29:13 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 17 Nov 2014 11:29:13 -0500 Subject: [Smtk-developers] Exodus bridge Message-ID: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> Hi Yumin, I've pushed a simple example bridge to SMTK master that uses VTK's Exodus reader to read side and node set information in as groups. No cells (volumes/faces/edges/vertices) are included, but the blocks and sets have tessellation information. You can do this: import smtk mgr = smtk.model.Manager.create() sess = mgr.createSession('exodus') rdr = sess.op('read') rdr.findAsFile('filename').setValue('can.ex2') res = rdr.operate() me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) print '\n'.join([x.name() for x in me.groups()]) which will print this: Unnamed block ID: 1 Type: HEX Unnamed block ID: 2 Type: HEX Unnamed set ID: 4 Unnamed set ID: 1 Unnamed set ID: 100 Because each group has a Tessellation associated with it you should be able to render the side and node sets as well as element blocks. There are a few things left to do and then we will have an end-to-end example of simulation preparation using (unaltered) Exodus files. 1. Verify that the vtkModelMultiBlockSource properly includes the tessellation information attached to the side and node sets. 2. Add properties to the groups from the Exodus reader's metadata (describing set IDs). 3. Adapt an exporter to the new model. I can do #1-2, but will need some help with #3. David From yumin.yuan at kitware.com Mon Nov 17 11:41:38 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Mon, 17 Nov 2014 11:41:38 -0500 Subject: [Smtk-developers] Exodus bridge In-Reply-To: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> References: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> Message-ID: This is great, Dave. I can certainly help with the exporter part. I will call you to discuss a bit. Yumin On Mon, Nov 17, 2014 at 11:29 AM, David Thompson wrote: > Hi Yumin, > > I've pushed a simple example bridge to SMTK master that uses VTK's Exodus > reader to read side and node set information in as groups. No cells > (volumes/faces/edges/vertices) are included, but the blocks and sets have > tessellation information. You can do this: > > import smtk > mgr = smtk.model.Manager.create() > sess = mgr.createSession('exodus') > rdr = sess.op('read') > rdr.findAsFile('filename').setValue('can.ex2') > res = rdr.operate() > me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) > print '\n'.join([x.name() for x in me.groups()]) > > which will print this: > > Unnamed block ID: 1 Type: HEX > Unnamed block ID: 2 Type: HEX > Unnamed set ID: 4 > Unnamed set ID: 1 > Unnamed set ID: 100 > > Because each group has a Tessellation associated with it you should be > able to render the side and node sets as well as element blocks. There are > a few things left to do and then we will have an end-to-end example of > simulation preparation using (unaltered) Exodus files. > > 1. Verify that the vtkModelMultiBlockSource properly includes the > tessellation information attached to the side and node sets. > 2. Add properties to the groups from the Exodus reader's metadata > (describing set IDs). > 3. Adapt an exporter to the new model. > > I can do #1-2, but will need some help with #3. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Nov 17 17:43:07 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 17 Nov 2014 17:43:07 -0500 Subject: [Smtk-developers] Exodus bridge In-Reply-To: References: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> Message-ID: Hi all, I've merged some changes to master that store element block, side set, and node set IDs on the SMTK model entities. So, in Python you can # ... load file as in script below ... result = rdr.operate() model = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) for group in model.groups(): print group.name(), group.stringProperty('exodus type'), group.integerProperty('exodus id') and get Unnamed block ID: 1 Type: HEX ['element block'] [1] Unnamed block ID: 2 Type: HEX ['element block'] [2] Unnamed set ID: 4 ['side set'] [4] Unnamed set ID: 1 ['node set'] [1] Unnamed set ID: 100 ['node set'] [100] I am about halfway through modernizing the Hydra Python exporter script to use the new model. Once I'm done and Yumin has the association widget working we should have an end-to-end demo. (!!!) David > ... > I can certainly help with the exporter part. I will call you to discuss a bit. > > Yumin > > On Mon, Nov 17, 2014 at 11:29 AM, David Thompson wrote: > Hi Yumin, > > I've pushed a simple example bridge to SMTK master that uses VTK's Exodus reader to read side and node set information in as groups. No cells (volumes/faces/edges/vertices) are included, but the blocks and sets have tessellation information. You can do this: > > import smtk > mgr = smtk.model.Manager.create() > sess = mgr.createSession('exodus') > rdr = sess.op('read') > rdr.findAsFile('filename').setValue('can.ex2') > res = rdr.operate() > me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) > print '\n'.join([x.name() for x in me.groups()]) > > which will print this: > > Unnamed block ID: 1 Type: HEX > Unnamed block ID: 2 Type: HEX > Unnamed set ID: 4 > Unnamed set ID: 1 > Unnamed set ID: 100 > > Because each group has a Tessellation associated with it you should be able to render the side and node sets as well as element blocks. There are a few things left to do and then we will have an end-to-end example of simulation preparation using (unaltered) Exodus files. > > 1. Verify that the vtkModelMultiBlockSource properly includes the tessellation information attached to the side and node sets. > 2. Add properties to the groups from the Exodus reader's metadata (describing set IDs). > 3. Adapt an exporter to the new model. > > I can do #1-2, but will need some help with #3. > > David > From yumin.yuan at kitware.com Mon Nov 17 17:55:47 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Mon, 17 Nov 2014 17:55:47 -0500 Subject: [Smtk-developers] Exodus bridge In-Reply-To: References: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> Message-ID: On Mon, Nov 17, 2014 at 5:43 PM, David Thompson wrote: > Hi all, > > I've merged some changes to master that store element block, side set, and > node set IDs on the SMTK model entities. So, in Python you can > > # ... load file as in script below ... > result = rdr.operate() > model = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) > for group in model.groups(): > print group.name(), group.stringProperty('exodus type'), > group.integerProperty('exodus id') > > and get > > Unnamed block ID: 1 Type: HEX ['element block'] [1] > Unnamed block ID: 2 Type: HEX ['element block'] [2] > Unnamed set ID: 4 ['side set'] [4] > Unnamed set ID: 1 ['node set'] [1] > Unnamed set ID: 100 ['node set'] [100] > > Nice! > I am about halfway through modernizing the Hydra Python exporter script to > use the new model. Once I'm done and Yumin has the association widget > working we should have an end-to-end demo. (!!!) > > The association widget is working now. I have to change the template file a little bit. Associations="f" ==> Associations="g" // for group Associations="r" ==> Associations="m" // for model to assign material, I guess the "Exodus" reader-parser did not construct a volume. Caveat, there are some runtime warnings from cmb_v4 related to "duplicate command function". I think this is happening when loading CMB_plugin, and erdcAppCommon is also linking against CMB_plugin. I will track this down later. Yumin David > > > ... > > I can certainly help with the exporter part. I will call you to discuss > a bit. > > > > Yumin > > > > On Mon, Nov 17, 2014 at 11:29 AM, David Thompson < > david.thompson at kitware.com> wrote: > > Hi Yumin, > > > > I've pushed a simple example bridge to SMTK master that uses VTK's > Exodus reader to read side and node set information in as groups. No cells > (volumes/faces/edges/vertices) are included, but the blocks and sets have > tessellation information. You can do this: > > > > import smtk > > mgr = smtk.model.Manager.create() > > sess = mgr.createSession('exodus') > > rdr = sess.op('read') > > rdr.findAsFile('filename').setValue('can.ex2') > > res = rdr.operate() > > me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) > > print '\n'.join([x.name() for x in me.groups()]) > > > > which will print this: > > > > Unnamed block ID: 1 Type: HEX > > Unnamed block ID: 2 Type: HEX > > Unnamed set ID: 4 > > Unnamed set ID: 1 > > Unnamed set ID: 100 > > > > Because each group has a Tessellation associated with it you should be > able to render the side and node sets as well as element blocks. There are > a few things left to do and then we will have an end-to-end example of > simulation preparation using (unaltered) Exodus files. > > > > 1. Verify that the vtkModelMultiBlockSource properly includes the > tessellation information attached to the side and node sets. > > 2. Add properties to the groups from the Exodus reader's metadata > (describing set IDs). > > 3. Adapt an exporter to the new model. > > > > I can do #1-2, but will need some help with #3. > > > > David > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Nov 17 21:55:34 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 17 Nov 2014 21:55:34 -0500 Subject: [Smtk-developers] Exodus bridge In-Reply-To: References: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> Message-ID: <4842C793-90AC-4248-A838-97CD6D0B5770@kitware.com> Hi Yumin, You are correct; the Exodus bridge doesn't create faces or volumes inside the groups. However it does mark the groups as MODEL_DOMAIN or MODEL_BOUNDARY depending on whether they contain volumes or faces/edges/nodes, respectively. We could (1) change the bridge to create either a single volume or face per group; or (2) add some logic to associations so that they pay attention to group constraint bits like those above; or (3) do #2 but with dimension-specific constraint bits (like "this group may only hold 1-d and 2-d cells"). It would not be simple to change the bridge to expose every element side or node as a separate model entity because the numbering in Exodus files is painfully complex. At that point, we are better off reviving more discrete model functionality from v3 to v4. David > On Nov 17, 2014, at 17:55, Yumin Yuan wrote: > > > >> On Mon, Nov 17, 2014 at 5:43 PM, David Thompson wrote: >> Hi all, >> >> I've merged some changes to master that store element block, side set, and node set IDs on the SMTK model entities. So, in Python you can >> >> # ... load file as in script below ... >> result = rdr.operate() >> model = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >> for group in model.groups(): >> print group.name(), group.stringProperty('exodus type'), group.integerProperty('exodus id') >> >> and get >> >> Unnamed block ID: 1 Type: HEX ['element block'] [1] >> Unnamed block ID: 2 Type: HEX ['element block'] [2] >> Unnamed set ID: 4 ['side set'] [4] >> Unnamed set ID: 1 ['node set'] [1] >> Unnamed set ID: 100 ['node set'] [100] >> > > Nice! > >> I am about halfway through modernizing the Hydra Python exporter script to use the new model. Once I'm done and Yumin has the association widget working we should have an end-to-end demo. (!!!) >> >> > > The association widget is working now. I have to change the template file a little bit. > Associations="f" ==> Associations="g" // for group > Associations="r" ==> Associations="m" // for model to assign material, I guess the "Exodus" reader-parser did not construct a volume. > > Caveat, there are some runtime warnings from cmb_v4 related to "duplicate command function". I think this is happening when loading CMB_plugin, and erdcAppCommon is also linking against CMB_plugin. I will track this down later. > > > Yumin > >> David >> >> > ... >> > I can certainly help with the exporter part. I will call you to discuss a bit. >> > >> > Yumin >> > >> > On Mon, Nov 17, 2014 at 11:29 AM, David Thompson wrote: >> > Hi Yumin, >> > >> > I've pushed a simple example bridge to SMTK master that uses VTK's Exodus reader to read side and node set information in as groups. No cells (volumes/faces/edges/vertices) are included, but the blocks and sets have tessellation information. You can do this: >> > >> > import smtk >> > mgr = smtk.model.Manager.create() >> > sess = mgr.createSession('exodus') >> > rdr = sess.op('read') >> > rdr.findAsFile('filename').setValue('can.ex2') >> > res = rdr.operate() >> > me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >> > print '\n'.join([x.name() for x in me.groups()]) >> > >> > which will print this: >> > >> > Unnamed block ID: 1 Type: HEX >> > Unnamed block ID: 2 Type: HEX >> > Unnamed set ID: 4 >> > Unnamed set ID: 1 >> > Unnamed set ID: 100 >> > >> > Because each group has a Tessellation associated with it you should be able to render the side and node sets as well as element blocks. There are a few things left to do and then we will have an end-to-end example of simulation preparation using (unaltered) Exodus files. >> > >> > 1. Verify that the vtkModelMultiBlockSource properly includes the tessellation information attached to the side and node sets. >> > 2. Add properties to the groups from the Exodus reader's metadata (describing set IDs). >> > 3. Adapt an exporter to the new model. >> > >> > I can do #1-2, but will need some help with #3. >> > >> > David >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Mon Nov 17 23:17:56 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Mon, 17 Nov 2014 23:17:56 -0500 Subject: [Smtk-developers] Exodus bridge In-Reply-To: References: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> Message-ID: Hi John and Dave, The current "Export Simulation" is going through vtkPythonExporter, which is adding some python paths and also using vtkCMBModelWrapper to set up GridInfo stuff. The python-path part could be common to all bridges, but the vtkCMBModelWrapper-related GridInfo should be part of the discrete bridge. This means we can't use current "Export" framework for exodus-bridge. One way to do the "Export" for exodus-bridge is to add an ExportSimOperator. Actually all bridges probably should have this operator, and for discrete bridge, this new operator can just use vtkPythonExporter. Yumin On Mon, Nov 17, 2014 at 5:55 PM, Yumin Yuan wrote: > > > On Mon, Nov 17, 2014 at 5:43 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi all, >> >> I've merged some changes to master that store element block, side set, >> and node set IDs on the SMTK model entities. So, in Python you can >> >> # ... load file as in script below ... >> result = rdr.operate() >> model = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >> for group in model.groups(): >> print group.name(), group.stringProperty('exodus type'), >> group.integerProperty('exodus id') >> >> and get >> >> Unnamed block ID: 1 Type: HEX ['element block'] [1] >> Unnamed block ID: 2 Type: HEX ['element block'] [2] >> Unnamed set ID: 4 ['side set'] [4] >> Unnamed set ID: 1 ['node set'] [1] >> Unnamed set ID: 100 ['node set'] [100] >> >> > Nice! > > >> I am about halfway through modernizing the Hydra Python exporter script >> to use the new model. Once I'm done and Yumin has the association widget >> working we should have an end-to-end demo. (!!!) >> >> > > > The association widget is working now. I have to change the template file > a little bit. > Associations="f" ==> Associations="g" // for group > Associations="r" ==> Associations="m" // for model to assign material, I > guess the "Exodus" reader-parser did not construct a volume. > > Caveat, there are some runtime warnings from cmb_v4 related to "duplicate > command function". I think this is happening when loading CMB_plugin, and > erdcAppCommon is also linking against CMB_plugin. I will track this down > later. > > > Yumin > > David >> >> > ... >> > I can certainly help with the exporter part. I will call you to discuss >> a bit. >> > >> > Yumin >> > >> > On Mon, Nov 17, 2014 at 11:29 AM, David Thompson < >> david.thompson at kitware.com> wrote: >> > Hi Yumin, >> > >> > I've pushed a simple example bridge to SMTK master that uses VTK's >> Exodus reader to read side and node set information in as groups. No cells >> (volumes/faces/edges/vertices) are included, but the blocks and sets have >> tessellation information. You can do this: >> > >> > import smtk >> > mgr = smtk.model.Manager.create() >> > sess = mgr.createSession('exodus') >> > rdr = sess.op('read') >> > rdr.findAsFile('filename').setValue('can.ex2') >> > res = rdr.operate() >> > me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >> > print '\n'.join([x.name() for x in me.groups()]) >> > >> > which will print this: >> > >> > Unnamed block ID: 1 Type: HEX >> > Unnamed block ID: 2 Type: HEX >> > Unnamed set ID: 4 >> > Unnamed set ID: 1 >> > Unnamed set ID: 100 >> > >> > Because each group has a Tessellation associated with it you should be >> able to render the side and node sets as well as element blocks. There are >> a few things left to do and then we will have an end-to-end example of >> simulation preparation using (unaltered) Exodus files. >> > >> > 1. Verify that the vtkModelMultiBlockSource properly includes the >> tessellation information attached to the side and node sets. >> > 2. Add properties to the groups from the Exodus reader's metadata >> (describing set IDs). >> > 3. Adapt an exporter to the new model. >> > >> > I can do #1-2, but will need some help with #3. >> > >> > David >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Mon Nov 17 23:20:06 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Mon, 17 Nov 2014 23:20:06 -0500 Subject: [Smtk-developers] Exodus bridge In-Reply-To: <4842C793-90AC-4248-A838-97CD6D0B5770@kitware.com> References: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> <4842C793-90AC-4248-A838-97CD6D0B5770@kitware.com> Message-ID: Hi Dave, On Mon, Nov 17, 2014 at 9:55 PM, David Thompson wrote: > Hi Yumin, > > You are correct; the Exodus bridge doesn't create faces or volumes inside > the groups. However it does mark the groups as MODEL_DOMAIN or MODEL_BOUNDARY > depending on whether they contain volumes or faces/edges/nodes, > respectively. We could (1) change the bridge to create either a single > volume or face per group; or (2) add some logic to associations so that > they pay attention to group constraint bits like those above; or (3) do #2 > but with dimension-specific constraint bits (like "this group may only hold > 1-d and 2-d cells"). > > It would not be simple to change the bridge to expose every element side > or node as a separate model entity because the numbering in Exodus files is > painfully complex. At that point, we are better off reviving more discrete > model functionality from v3 to v4. > > I agree, and (2) or (3) options above sound reasonable to me. Yumin > David > > On Nov 17, 2014, at 17:55, Yumin Yuan wrote: > > > > On Mon, Nov 17, 2014 at 5:43 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi all, >> >> I've merged some changes to master that store element block, side set, >> and node set IDs on the SMTK model entities. So, in Python you can >> >> # ... load file as in script below ... >> result = rdr.operate() >> model = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >> for group in model.groups(): >> print group.name(), group.stringProperty('exodus type'), >> group.integerProperty('exodus id') >> >> and get >> >> Unnamed block ID: 1 Type: HEX ['element block'] [1] >> Unnamed block ID: 2 Type: HEX ['element block'] [2] >> Unnamed set ID: 4 ['side set'] [4] >> Unnamed set ID: 1 ['node set'] [1] >> Unnamed set ID: 100 ['node set'] [100] >> >> > Nice! > > >> I am about halfway through modernizing the Hydra Python exporter script >> to use the new model. Once I'm done and Yumin has the association widget >> working we should have an end-to-end demo. (!!!) >> >> > > > The association widget is working now. I have to change the template file > a little bit. > Associations="f" ==> Associations="g" // for group > Associations="r" ==> Associations="m" // for model to assign material, I > guess the "Exodus" reader-parser did not construct a volume. > > Caveat, there are some runtime warnings from cmb_v4 related to "duplicate > command function". I think this is happening when loading CMB_plugin, and > erdcAppCommon is also linking against CMB_plugin. I will track this down > later. > > > Yumin > > David >> >> > ... >> > I can certainly help with the exporter part. I will call you to discuss >> a bit. >> > >> > Yumin >> > >> > On Mon, Nov 17, 2014 at 11:29 AM, David Thompson < >> david.thompson at kitware.com> wrote: >> > Hi Yumin, >> > >> > I've pushed a simple example bridge to SMTK master that uses VTK's >> Exodus reader to read side and node set information in as groups. No cells >> (volumes/faces/edges/vertices) are included, but the blocks and sets have >> tessellation information. You can do this: >> > >> > import smtk >> > mgr = smtk.model.Manager.create() >> > sess = mgr.createSession('exodus') >> > rdr = sess.op('read') >> > rdr.findAsFile('filename').setValue('can.ex2') >> > res = rdr.operate() >> > me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >> > print '\n'.join([x.name() for x in me.groups()]) >> > >> > which will print this: >> > >> > Unnamed block ID: 1 Type: HEX >> > Unnamed block ID: 2 Type: HEX >> > Unnamed set ID: 4 >> > Unnamed set ID: 1 >> > Unnamed set ID: 100 >> > >> > Because each group has a Tessellation associated with it you should be >> able to render the side and node sets as well as element blocks. There are >> a few things left to do and then we will have an end-to-end example of >> simulation preparation using (unaltered) Exodus files. >> > >> > 1. Verify that the vtkModelMultiBlockSource properly includes the >> tessellation information attached to the side and node sets. >> > 2. Add properties to the groups from the Exodus reader's metadata >> (describing set IDs). >> > 3. Adapt an exporter to the new model. >> > >> > I can do #1-2, but will need some help with #3. >> > >> > David >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Wed Nov 19 20:58:55 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 19 Nov 2014 19:58:55 -0600 Subject: [Smtk-developers] Exodus bridge In-Reply-To: References: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com> <4842C793-90AC-4248-A838-97CD6D0B5770@kitware.com> Message-ID: <0B83742B-3E2F-45B0-9141-B6D05A701332@kitware.com> If I understand you correctly, Actually the association should pay attention to the group bits. 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 On Nov 17, 2014, at 10:20 PM, Yumin Yuan wrote: > Hi Dave, > > On Mon, Nov 17, 2014 at 9:55 PM, David Thompson wrote: > Hi Yumin, > > You are correct; the Exodus bridge doesn't create faces or volumes inside the groups. However it does mark the groups as MODEL_DOMAIN or MODEL_BOUNDARY depending on whether they contain volumes or faces/edges/nodes, respectively. We could (1) change the bridge to create either a single volume or face per group; or (2) add some logic to associations so that they pay attention to group constraint bits like those above; or (3) do #2 but with dimension-specific constraint bits (like "this group may only hold 1-d and 2-d cells"). > > It would not be simple to change the bridge to expose every element side or node as a separate model entity because the numbering in Exodus files is painfully complex. At that point, we are better off reviving more discrete model functionality from v3 to v4. > > > I agree, and (2) or (3) options above sound reasonable to me. > > Yumin > > David > > On Nov 17, 2014, at 17:55, Yumin Yuan wrote: > >> >> >> On Mon, Nov 17, 2014 at 5:43 PM, David Thompson wrote: >> Hi all, >> >> I've merged some changes to master that store element block, side set, and node set IDs on the SMTK model entities. So, in Python you can >> >> # ... load file as in script below ... >> result = rdr.operate() >> model = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >> for group in model.groups(): >> print group.name(), group.stringProperty('exodus type'), group.integerProperty('exodus id') >> >> and get >> >> Unnamed block ID: 1 Type: HEX ['element block'] [1] >> Unnamed block ID: 2 Type: HEX ['element block'] [2] >> Unnamed set ID: 4 ['side set'] [4] >> Unnamed set ID: 1 ['node set'] [1] >> Unnamed set ID: 100 ['node set'] [100] >> >> >> Nice! >> >> I am about halfway through modernizing the Hydra Python exporter script to use the new model. Once I'm done and Yumin has the association widget working we should have an end-to-end demo. (!!!) >> >> >> >> The association widget is working now. I have to change the template file a little bit. >> Associations="f" ==> Associations="g" // for group >> Associations="r" ==> Associations="m" // for model to assign material, I guess the "Exodus" reader-parser did not construct a volume. >> >> Caveat, there are some runtime warnings from cmb_v4 related to "duplicate command function". I think this is happening when loading CMB_plugin, and erdcAppCommon is also linking against CMB_plugin. I will track this down later. >> >> >> Yumin >> >> David >> >> > ... >> > I can certainly help with the exporter part. I will call you to discuss a bit. >> > >> > Yumin >> > >> > On Mon, Nov 17, 2014 at 11:29 AM, David Thompson wrote: >> > Hi Yumin, >> > >> > I've pushed a simple example bridge to SMTK master that uses VTK's Exodus reader to read side and node set information in as groups. No cells (volumes/faces/edges/vertices) are included, but the blocks and sets have tessellation information. You can do this: >> > >> > import smtk >> > mgr = smtk.model.Manager.create() >> > sess = mgr.createSession('exodus') >> > rdr = sess.op('read') >> > rdr.findAsFile('filename').setValue('can.ex2') >> > res = rdr.operate() >> > me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >> > print '\n'.join([x.name() for x in me.groups()]) >> > >> > which will print this: >> > >> > Unnamed block ID: 1 Type: HEX >> > Unnamed block ID: 2 Type: HEX >> > Unnamed set ID: 4 >> > Unnamed set ID: 1 >> > Unnamed set ID: 100 >> > >> > Because each group has a Tessellation associated with it you should be able to render the side and node sets as well as element blocks. There are a few things left to do and then we will have an end-to-end example of simulation preparation using (unaltered) Exodus files. >> > >> > 1. Verify that the vtkModelMultiBlockSource properly includes the tessellation information attached to the side and node sets. >> > 2. Add properties to the groups from the Exodus reader's metadata (describing set IDs). >> > 3. Adapt an exporter to the new model. >> > >> > I can do #1-2, but will need some help with #3. >> > >> > David >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Nov 20 20:21:32 2014 From: david.thompson at kitware.com (David Thompson) Date: Thu, 20 Nov 2014 20:21:32 -0500 Subject: [Smtk-developers] Exodus bridge and SMTK improvements Message-ID: Hi Yumin (et al.), You should update SMTK if you update CMBv4 and vice-versa. I've pushed some changes to SMTK and CMBv4 that improve the appearance of the association widget with the Hydra template. Now, only the groups of interest (i.e., Exodus blocks for volumetric attributes; side and/or node sets for boundary attributes) appear in the association widget. (See first screenshot.) This makes some changes to how the XML reader and writer handle the "Associations" and "MembershipMask" attributes. Instead of parsing the value as a series of 1-letter codes assigned to different entity types, they are decomposed into tokens that are translated into bit values. Now any bit value in smtk/model/EntityTypeBits.h can be expressed in an association or membership mask. See the unitEntity test in SMTK and the Hydra template in CMBv4 for examples. Note that not every possible old-style bit-value is supported by the reader, but most common ones should be accepted (those ordered from lowest-dimension to highest-dimension or vice-versa). The bottom 2 screenshots show how the Exodus bridge properly indicates the embedding dimension of the underlying dataset (2-d vs 3-d). David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-20 at 8.18.04 PM.png Type: image/png Size: 122282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-20 at 8.13.54 PM.png Type: image/png Size: 42168 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-20 at 8.12.05 PM.png Type: image/png Size: 58849 bytes Desc: not available URL: From yumin.yuan at kitware.com Fri Nov 21 09:16:28 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Fri, 21 Nov 2014 09:16:28 -0500 Subject: [Smtk-developers] Exodus bridge and SMTK improvements In-Reply-To: References: Message-ID: Excellent! That looks great. I will be working on adding visibility support in the tree view. Yumin On Thu, Nov 20, 2014 at 8:21 PM, David Thompson wrote: > Hi Yumin (et al.), > > You should update SMTK if you update CMBv4 and vice-versa. > > I've pushed some changes to SMTK and CMBv4 that improve the appearance of > the association widget with the Hydra template. Now, only the groups of > interest (i.e., Exodus blocks for volumetric attributes; side and/or node > sets for boundary attributes) appear in the association widget. (See first > screenshot.) > > This makes some changes to how the XML reader and writer handle the > "Associations" and "MembershipMask" attributes. Instead of parsing the > value as a series of 1-letter codes assigned to different entity types, > they are decomposed into tokens that are translated into bit values. Now > any bit value in smtk/model/EntityTypeBits.h can be expressed in an > association or membership mask. See the unitEntity test in SMTK and the > Hydra template in CMBv4 for examples. Note that not every possible > old-style bit-value is supported by the reader, but most common ones should > be accepted (those ordered from lowest-dimension to highest-dimension or > vice-versa). > > The bottom 2 screenshots show how the Exodus bridge properly indicates the > embedding dimension of the underlying dataset (2-d vs 3-d). > > David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-20 at 8.13.54 PM.png Type: image/png Size: 42168 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-20 at 8.18.04 PM.png Type: image/png Size: 122282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-20 at 8.12.05 PM.png Type: image/png Size: 58849 bytes Desc: not available URL: From david.thompson at kitware.com Fri Nov 21 18:35:29 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 21 Nov 2014 18:35:29 -0500 Subject: [Smtk-developers] CGM operators Message-ID: <95795A0C-9CCB-44BB-90ED-2569F86184D1@kitware.com> Hi all, I've pushed a fix to the CGM read operator so that it will read IGES files now (without requiring you to use the read operator and specifying the "filetype"). I haven't been able to track down why "create sphere" crashes frequently... yet. David From david.thompson at kitware.com Mon Nov 24 11:53:51 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 24 Nov 2014 11:53:51 -0500 Subject: [Smtk-developers] More CGM operations Message-ID: <11B5D645-63A3-4F45-BD4F-D9B14B2F3D0E@kitware.com> Hi all, I've merged a branch to SMTK master that 1. fixes (one but not all) issue with the "create sphere" operator (the center parameter was being ignored by CGM) 2. adds a "translate" operator 3. adds a "rotate" operator The cgmTransforms test is a good example of how to use the operators. David From david.thompson at kitware.com Mon Nov 24 18:47:16 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 24 Nov 2014 18:47:16 -0500 Subject: [Smtk-developers] Model association changes Message-ID: <2BC1B7F3-5557-43F4-805E-22FD7EFB98E3@kitware.com> Hi all, I've pushed a first batch of changes to treat associations as special ModelEntity{ItemDefinition,Item} instances. This was done so that attributes can specify the number of associated entities as well as their type. For example, it is possible for attributes representing SMTK model operators to indicate that only a single model may serve as the workpiece (say, for a subtraction operator). The effects of this are that now 1. Instead of smtk::attribute::Definition owning a BitFlags integer that serves as the association mask, it owns a ModelEntityItemDefinition instance. 2. Instead of the *XML attribute* named Associations, the element may have a child tag named . It is processed as if it were a tag inside (but it resides directly inside the tag, not as a child to ). An example is: group|domain|volume ... Note the MembershipMask value may be specified numerically as a decimal number encoding flags or as a string like the example above. See smtk/model/Entity.cxx for details on string processing. 3. Checks on entity associations are now implemented where previously they were not. Be aware that you may have issues to address. Several tests (and the test data repo) were updated to verify the checks on whether an association is valid or not. The work will not be complete until Attribute instances use a ModelEntityItem to hold the set of associated model entities. At that point, the membership testing code that is part of ModelEntityItem will also be used for associations. If you have any issues, please let me know. David From david.thompson at kitware.com Tue Nov 25 19:58:41 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 25 Nov 2014 19:58:41 -0500 Subject: [Smtk-developers] Model association changes In-Reply-To: <2BC1B7F3-5557-43F4-805E-22FD7EFB98E3@kitware.com> References: <2BC1B7F3-5557-43F4-805E-22FD7EFB98E3@kitware.com> Message-ID: <73AF311E-8870-42A2-86C0-132E14FA87C6@kitware.com> > I've pushed a first batch of changes to treat associations as special ModelEntity{ItemDefinition,Item} instances. ... The second (and hopefully final) batch of changes has been pushed. > ... This was done so that attributes can specify the number of associated entities as well as their type. For example, it is possible for attributes representing SMTK model operators to indicate that only a single model may serve as the workpiece (say, for a subtraction operator). ... This should also make it much simpler to expose associations in the GUI since now they can be treated as just another item belonging to the attribute. David From david.thompson at kitware.com Wed Nov 26 17:34:55 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 26 Nov 2014 17:34:55 -0500 Subject: [Smtk-developers] Session bug Message-ID: <8048D52A-6D0C-4CDF-BF92-1E6BA4541CAF@kitware.com> Hi Bob and Yumin, I've pushed some changes to SMTK (today) and CMBv4 (yesterday) that fix problems with closing bridge sessions. At least for me, ModelBuilder can now open a file, close the file (Cmd-W), and open another file without crashing. David From bob.obara at kitware.com Thu Nov 27 22:06:46 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Thu, 27 Nov 2014 22:06:46 -0500 Subject: [Smtk-developers] Q: default for vector value possible? In-Reply-To: References: Message-ID: <2F65F363-5864-4494-841F-6FDFC18C8D70@kitware.com> Hi David, No - it would be relatively simple to put this in but care needs to be taken to keep things consistent when the item definition is modified: The item must be non-extensible When the Number of min required values is modified, the default array would also need to be updated In the case of an extensible I'm guessing that the default array must be of size 1 and represents the value of newly added values. Does this make sense? 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 On Nov 12, 2014, at 12:59 PM, David Thompson wrote: > Hi all, > > I have an attribute item defined like this > > > 1.0,0.0,0.0 > > > but when I create an instance of the attribute and examine its value, I get: > >>>> ax0 = smtk.attribute.to_concrete(att.find('axis 0')) >>>> [ax0.value(i) for i in range(3)] > [1.0, 1.0, 1.0] > > Is there a way to provide a default for each of the required values? > > Thanks, > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Thu Nov 27 22:07:42 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Thu, 27 Nov 2014 22:07:42 -0500 Subject: [Smtk-developers] Q: Tool vs workpiece In-Reply-To: <71E498C1-A2A6-4B45-A939-FB2252DCD23D@kitware.com> References: <71E498C1-A2A6-4B45-A939-FB2252DCD23D@kitware.com> Message-ID: <152F7D0A-6787-409C-916D-121F8DCDBC18@kitware.com> Thats my mindset as well. 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 On Nov 11, 2014, at 3:38 PM, David Thompson wrote: > Hi Bob, > > Do you have a strong preference for whether the tool or the workpiece are associated with the boolean operators (as opposed to being items owned by the operator)? > > If you don't, I do. I am a subject-verb-object kind of a guy, and think of the subject as the piece that stays around afterwards (so pronouns can reference it)... so I vote for associating the workpiece to an operator and then adding the tool to the operator. > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Nov 28 22:13:56 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 28 Nov 2014 22:13:56 -0500 Subject: [Smtk-developers] Documentation table changes Message-ID: Hi all, I've found a fix for the problem Bob had with reStructuredText tables being much wider than the browser page in the HTML version. Now it is best if you do not manually break long lines in table cells by starting a new paragraph. (It is fine if you really want to start a new paragraph, but don't break sentences up.) I've pushed changes to the attribute documentation. See here for an example: http://smtk.rtfd.org/en/latest/userguide/attribute/file-syntax.html#attdef-element-format All that was required was a small addition to the CSS used to stop "responsive" tables from allowing really wide pages (in doc/.static/theme-overrides.css). Also, text in table cells is now top-aligned instead of vertically centered. David From david.thompson at kitware.com Thu Nov 20 20:53:18 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 21 Nov 2014 01:53:18 -0000 Subject: [Smtk-developers] Normals on CAD models Message-ID: Hi Bob, I've pushed a branch ("polynormals") to SMTK/stage that runs vtkPolyDataNormals on tessellation information returned by CGM (well, and other bridges, too). However, I haven't merged it to master because it slows things down pretty tremendously. A flashy picture of the cylinder head is attached, though. You can see that the triangulation is still coarse but a lot of the shading is smooth. There are seams at face boundaries (as expected because vtkPolyDataNormals doesn't know the true curvature). David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-20 at 8.46.15 PM.png Type: image/png Size: 415012 bytes Desc: not available URL: