... | ... | @@ -47,4 +47,22 @@ In terms of the definition for the association - this could be stored in the Att |
|
|
|
|
|
OK - so if you agree with the above design, I have a conceptual question. As you know SMTK consists of three resources (meshes, models, attributes). One could suggest that instead of saying an attribute is associated with a model entity, it could be associated with a part of a resource. This would mean you could associated an attribute to part of mesh or even to another attribute. Another suggestion would be to take this even further, that is to save an association is a bi-directional relationship between any two resource components (so a mesh set could be associated with a model entity, or a model entity could be associated with an attribute etc..
|
|
|
|
|
|
I don't want to support something just be complete so I would only entertain this extension iff someone can come up with good use cases showing the need for this. |
|
|
\ No newline at end of file |
|
|
I don't want to support something just be complete so I would only entertain this extension if someone can come up with good use cases showing the need for this.
|
|
|
|
|
|
|
|
|
---
|
|
|
## Questions/Comments (john 06-Jan-3017)
|
|
|
|
|
|
Just to make sure I got it:
|
|
|
* Does the new/proposed class replace the ModelEntityItem currently used to represent associations in the Attribute class?
|
|
|
* And there are no proposed changes to smtk::model?
|
|
|
|
|
|
One thing that is convenient for testing export scripts is that we always get the model entities back in the same order from the ModelEntityItem returned by Attribute::associations(). That might be tricky with the new class.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|