<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="margin: 0px; line-height: normal;" class="">Models, Meshes, and Attributes</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">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. </div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">Now there are some commonality in the way these three resources work (and yes I’m purposely using that term):</div>
<ul class="">
<li style="margin: 0px; line-height: normal;" class="">All three use UUIDs to refer to a component within the resource</li>
<li style="margin: 0px; line-height: normal;" class="">These UUIDs are persistent </li>
<li style="margin: 0px; line-height: normal;" class="">All three use UUID’s to refer to components in other resources</li>
</ul><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">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.</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">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.</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">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.</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">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.</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" 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:</div>
<ul class="">
<li style="margin: 0px; line-height: normal;" class="">Given a UUID return the corresponding model collection, mesh collection, or attribute system</li>
<li style="margin: 0px; line-height: normal;" class="">Given a UUID Pair return the model entity, mesh entity, attribute</li>
<li style="margin: 0px; line-height: normal;" class="">Track where these reside (i.e. the URL’s associated with them)</li>
</ul><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">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.</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">Overall this change will make things more uniform and hopefully simpler to use when dealing with 2 or 3 different resources.</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">Let me know what you think.</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">Bob</div><div style="margin: 0px; line-height: normal; min-height: 14px;" class=""><br class=""></div><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Robert M. O'Bara, MEng.<br class="">Assistant Director of Scientific Computing<br class=""><br class="">Kitware Inc.<br class="">28 Corporate Drive<br class="">Suite 101<br class="">Clifton Park, NY 12065<br class=""><br class="">Phone: (518) 881- 4931</div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>