Entity sets - containment and parent-child

[Mark Beall]

As the, fairly obvious, followup to my last email, since iRel already  
admits to the fact that there is a special relation between the mesh  
and the model (cf. iRel_createVtxAndAssociate, etc.) and has stated  
requirements on that relation (it must be between the geometry and  
mesh instance in that order), why not just create a special type of  
relation in iRel that represents that. For example:

void iRel_createGeomMeshAssociation(...,iBase_instance geom,  
iBase_instance mesh, ... options ..., iRel_GeomMeshHandle *rel);

options here would say what directions you want the relation to support

void iRel_getGeomMeshAssociation(...,iRel_GeomMeshHandle rel,  
iBase_EntityHandle modelEnt, iBase_EntitySetHandle *meshEnts);

void iRel_getMeshGeomAssociation(..., iRel_GeomMeshHandle rel,  
iBase_EntityHandle meshEnt, iBase_EntityHandle *geomEnt);

maybe some other functions to create or release the relation in one  
direction or the other (possibly instead of the options on creation)

and the iRel_createVtxAndAssociate etc. functions take in a  
iRel_GeomMeshHandle

Discussion points:

- Yes, it's less generic, however it's already not generic in the  
interface, for iRel_createVtxAndAssociate to work, the relation has to  
be created in a certain way. This way it's enforced (rather than just  
documented).

- If some application wants this relation, they want this relation,  
not something else.

- It avoids the discussion about whether or not it's necessary to be  
able to change a generic entity-set relation to an entity-both  
relation (or whatever) and gives the functionality for the case it's  
obviously needed.

- Rather than figuring out how classification should be implemented  
(tags, entity-both relations) it's a generic expression of that  
relation that can be implemented in different ways.

Just my thoughts on this...

mark

On Nov 17, 2009, at 6:05 PM, Mark Beall wrote:

>
> On Nov 17, 2009, at 5:01 PM, Tim Tautges wrote:
>
>> Mark Beall wrote:
>>>>
>>>> Here's an example:  Suppose you're doing swapping, or any other  
>>>> topological modification to a mesh.  Chances are excellent that  
>>>> you only want to do the 2-2 swap on the surface if both surface  
>>>> faces classify on the same model face.  Now, if you've got an  
>>>> entity-entity relation giving you classification, that's an easy  
>>>> test.  On the other hand, if you've got a geometric entity-mesh  
>>>> set relation, you have to find out which set a mesh face is in,  
>>>> which can only be done through an exhaustive search of faces.  So  
>>>> the higher memory (e-e) relation is much lower CPU.
>>> Right, sorry, I was thinking about the entity sets in the wrong  
>>> way (somehow my brain was thinking that the switch_order argument  
>>> would magically do this, but that's not what it does).
>>> So then createAssociation(model,mesh) should create a entity-set  
>>> relation and createAssociation(mesh,model) should create a  
>>> different entity-entity relation. Of course, in our  
>>> implementation, these are really just things that are pretending  
>>> to be relations and entity sets, but that doesn't really matter.
>>
>> Note that as currently spec'd, relations are two-way, so I suspect  
>> having a mesh/geometry entity/entity-type relation wouldn't be much  
>> good, since each geometry entity would only be related to one mesh  
>> entity (which couldn't be an entity set, since those are different  
>> things in the iMesh interface).
>>
>
> Well, the entity set - model entity direction of the other relation  
> wouldn't be very useful either. Perhaps it could be of some use if  
> the actual implementation of classification is done using entity  
> sets, but if an application relies on that it's probably not going  
> to work if the implementation is different (for us, the "entity set"  
> in this case will actually be a pointer to an iterator, it won't be  
> the same iterator each time, so that relation wouldn't be useful for  
> much).
>
> It would seem to be nicest if classification was represented by a  
> single relation, but the useful information here (what mesh entities  
> are classified on a model entity and what model entity is a mesh  
> entity classified on) are each one direction of two different  
> relations.
>
> mark
>