[Smtk-developers] Thoughts on attributes, meshes and models

[Bob Obara]

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: <http://public.kitware.com/pipermail/smtk-developers/attachments/20160501/c49f5234/attachment.html>