From bob.obara at kitware.com Sun May 1 16:27:36 2016 From: bob.obara at kitware.com (Bob Obara) Date: Sun, 1 May 2016 16:27:36 -0400 Subject: [Smtk-developers] Thoughts on attributes, meshes and models Message-ID: Models, Meshes, and Attributes I?ve been having a couple discussions with the team on some of the conceptualization issues within SMTK. Naming that models, meshes, and attributes tend to be ?managed? somewhat differently with the toolkit. Both models and meshes have managers that can be used to track them while the attribute system does not. All three can refer to components in each other (models can have meshes and attributes, attributes can have items that refer to model and mesh elements and in addition the system maintains the associates between attributes and model entities. Meshes are classified on model entities and though presently there are no direct connections between attributes and meshes I think there will be once we begin to model spatial and temporal fields based on meshes. Now there are some commonality in the way these three resources work (and yes I?m purposely using that term): All three use UUIDs to refer to a component within the resource These UUIDs are persistent All three use UUID?s to refer to components in other resources Now the two existing managers (model and mesh) provide ways of mapping UUIDs to the appropriate components (Attribute System also provides a mechanism but as mentioned previously its not truly a manager). The model manager is giving the UUID of the model entity itself and directly maps its to the object while the mesh manager uses two UUID?s (one for the mesh collection and one for the mesh entity). The mesh manager therefore is a collection of mesh collections while the model manager contains the UUIDs of every model entity for all models currently loaded into the system. What I propose is to make all three systems look identical. This means that the attribute system will get a manager and the three managers behave similarly when it comes to accessing components. Personally I prefer the mesh manager way of doing things (yes it takes two lookup and you need to store two keys but it has the benefit of easy maintenance - for example its very quick to delete a mesh collection while deleting large models will take time. Also it lets the mesh collection decide how best to access its mesh entities. So what I propose is to add the concept of a model collection (which represents all the model information read in from a file). The collection will have a UUID and will provide the model entity lookup currently being done in the model manager. The attribute system likewise will also get a UUID and an attribute manager that will provide access to all the attribute systems stored. From what I see the model manager class will probably become the model collection class and we will need to create a new model manager class. If we do this a funny thing happens - from the 10,000? view all three managers will look the same by providing the following: Given a UUID return the corresponding model collection, mesh collection, or attribute system Given a UUID Pair return the model entity, mesh entity, attribute Track where these reside (i.e. the URL?s associated with them) So in theory if we consider model collections, mesh collections and attribute systems are resources then we could have a resource manager that contains a model manager, mesh manager, and attribute manager and it could return a resource (and resource component) given a UUID (or UUID pair) - assuming these top classes are derived from an Resource class and the components are derived from Resource Component - I think the only change is that the UUID component would be ?owned? by these base classes. Overall this change will make things more uniform and hopefully simpler to use when dealing with 2 or 3 different resources. Let me know what you think. Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Wed May 11 10:07:43 2016 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 11 May 2016 10:07:43 -0400 Subject: [Smtk-developers] Trying to create a page on the SMTK Wiki In-Reply-To: References: <38B4973D-FDBE-4730-81BD-679991E8D471@kitware.com> Message-ID: Thanks Jake, How this can be scheduled soon since as of right now you can create Wiki Pages on our GitLab. 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 May 10, 2016, at 3:44 PMEDT, Jake Stookey wrote: > > It looks like this was patched a week ago: > > "Creating wiki pages no longer results in an HTTP 500 error" > > https://about.gitlab.com/2016/05/03/gitlab-8-dot-7-dot-2-released/ > > We will need to upgrade Gitlab to apply the patch. I will schedule an upgrade. > > Jake > > On Tue, May 10, 2016 at 3:27 PM, Bob Obara > wrote: > When trying to create a new page on CMB/SMTK gitlab?s wiki I get: > > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Wed May 18 14:33:44 2016 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 18 May 2016 14:33:44 -0400 Subject: [Smtk-developers] Using SuperBuilder in Developer Mode with SMTK Message-ID: Hi All, I?ve done a clean SuperBuild with cmb and smtk develop set to true. I builds fine but when I try to build SMTK against it (using the smtk config file generated by the superbuild) I get : CMake Deprecation Warning at /Applications/CMake-3.5.app/Contents/share/cmake-3.5/Modules/Qt4Macros.cmake:487 (message): The qt4_use_modules function is obsolete. Use target_link_libraries with IMPORTED targets instead. Call Stack (most recent call first): smtk/extension/qt/CMakeLists.txt:114 (qt4_use_modules) CMake Deprecation Warning at /Applications/CMake-3.5.app/Contents/share/cmake-3.5/Modules/Qt4Macros.cmake:487 (message): The qt4_use_modules function is obsolete. Use target_link_libraries with IMPORTED targets instead. Call Stack (most recent call first): smtk/extension/qt/testing/cxx/CMakeLists.txt:20 (qt4_use_modules) CMake Deprecation Warning at /Applications/CMake-3.5.app/Contents/share/cmake-3.5/Modules/Qt4Macros.cmake:487 (message): The qt4_use_modules function is obsolete. Use target_link_libraries with IMPORTED targets instead. Call Stack (most recent call first): smtk/extension/qt/testing/cxx/CMakeLists.txt:66 (qt4_use_modules) Should I be getting this warning? Thanks! Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed May 18 15:20:28 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 18 May 2016 15:20:28 -0400 Subject: [Smtk-developers] Using SuperBuilder in Developer Mode with SMTK In-Reply-To: References: Message-ID: <82B80559-79E4-4148-8E1B-E95538995CA1@kitware.com> These deprecation warnings are to be expected as SMTK is using CMake functions that are being phased out. We need to change our CMake code if we want these warnings to go away. Sent from my iPhone > On May 18, 2016, at 2:33 PM, Bob Obara wrote: > > Hi All, > > I?ve done a clean SuperBuild with cmb and smtk develop set to true. I builds fine but when I try to build SMTK against it (using the smtk config file generated by the superbuild) I get : > > > CMake Deprecation Warning at /Applications/CMake-3.5.app/Contents/share/cmake-3.5/Modules/Qt4Macros.cmake:487 (message): > The qt4_use_modules function is obsolete. Use target_link_libraries with > IMPORTED targets instead. > Call Stack (most recent call first): > smtk/extension/qt/CMakeLists.txt:114 (qt4_use_modules) > > > > CMake Deprecation Warning at /Applications/CMake-3.5.app/Contents/share/cmake-3.5/Modules/Qt4Macros.cmake:487 (message): > The qt4_use_modules function is obsolete. Use target_link_libraries with > IMPORTED targets instead. > Call Stack (most recent call first): > smtk/extension/qt/testing/cxx/CMakeLists.txt:20 (qt4_use_modules) > > > > CMake Deprecation Warning at /Applications/CMake-3.5.app/Contents/share/cmake-3.5/Modules/Qt4Macros.cmake:487 (message): > The qt4_use_modules function is obsolete. Use target_link_libraries with > IMPORTED targets instead. > Call Stack (most recent call first): > smtk/extension/qt/testing/cxx/CMakeLists.txt:66 (qt4_use_modules) > > > > > Should I be getting this warning? > > Thanks! > > 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 > > > > > _______________________________________________ > 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 Wed May 25 15:43:22 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 25 May 2016 15:43:22 -0400 Subject: [Smtk-developers] Default color Message-ID: <4B6A7157-0839-41F3-BEE3-1B58EDC8B457@kitware.com> Hi Bob, If you are going to have the model manager assign a default color, I would do it in this method void Manager::prepareForEntity(std::pair& entry) of the model manager. It should be called every time an entity is added to the manager. David