[Smtk-developers] Changes to model manager

[Robert Maynard]

Sorry I am confused this time.

Since MeshSets are never stored in the underlying file how is SMTK
going to reconstruct the MeshSets?

On Wed, Sep 20, 2017 at 12:02 PM, David Thompson
<david.thompson at kitware.com> wrote:
> Hi Rob,
>
> Thanks for mentioning this. I did not mean to be confusing, but was talking about our plans going forward: we will be making smtk::mesh::Collection inherit smtk::common::Resource. Resources each have a URL and reference components by UUID. So we will probably have to store a map from MeshSet IDs (integers) to UUIDs. SMTK will only present those MeshSets with UUIDs assigned to them as components of the resource.
>
> I agree that MeshSet might be better named View.
>
>         David
>
>> Just a clarification.
>>
>> smtk::mesh::MeshSets are never stored in files and don't have UUIDS.
>> Recently I have come to regret that name for the class as it really
>> should be named something like smtk::mesh::View.
>>
>> The reason for this is that a smtk::mesh::MeshSets reference numerous
>> meshes from the underlying database, which might or might not have the
>> optional UUID field. That is why the
>> smtk::mesh::MeshSets::modelEntityIds() returns a vector of UUIDS which
>> doesn't need to be the same length as smtk::mesh::MeshSets::size()
>>
>> On Fri, Sep 15, 2017 at 2:43 PM, David Thompson
>> <david.thompson at kitware.com> wrote:
>>> Hi all,
>>>
>>> I've just merged changes to the model system into SMTK master; they are significant enough to warrant this e-mail. These changes are work towards SMTK 2.0 and particularly toward making the mesh, model, and attribute systems more consistent:
>>>
>>> + smtk::model::Manager now inherits smtk::common::Resource, just as smtk::attribute::Collection does. This means each model manager has a UUID and a URL (location) indicating where it is on disk.
>>>
>>> + smtk::model::Manager now stores smtk::model::Entity instances by mapping UUIDs to shared pointers instead of directly to instances. This is necessary because:
>>>
>>> + smtk::model::Entity now inherits smtk::common::ResourceComponent, just as smtk::attribute::Attribute does. ResourceComponents are managed via shared pointers and store their UUID directly.
>>>
>>> At some point,
>>>
>>> + smtk::model::Manager will be renamed smtk::model::Collection to match the attribute system.
>>> + smtk::mesh::Collection will inherit smtk::common::Resource.
>>>
>>> This way, each of the 3 main systems in SMTK (model, mesh, attribute) will each have resources (things stored in files) named Collection which contain components (model entities, mesh sets, attribute instances) that are all referenced by UUID.
>>>
>>> This merge also removes sparsehash storage as an option. We weren't using it, we weren't testing it, and it has different semantics than std::map for when iterators are invalidated. If anyone is really interested in it, speak up soon and we can revert it -- but I would prefer not to.
>>>
>>>        David
>>> _______________________________________________
>>> Smtk-developers mailing list
>>> Smtk-developers at smtk.org
>>> http://public.kitware.com/mailman/listinfo/smtk-developers
>