Core Data vector modeling query
-
Using an analogy, I'm trying to model a 'vector' using CD. I have a
Vector entity, which has 2 to-one relationships to a VectorEnpoint
entity. The VectorEndpoint entity describes how the Vector is
connected at one end to other entities in the model
Vector:
source -> to-one -> VectorEndpoint
target -> to-one -> VectorEndpoint
I need a VectorEndpoint entity because the definition of the 'end' of
each vector is not straightforward.
My query is how should I model the inverse of these 'source' and
'target' relationships?
VectorEndpoint:
vector -> to-one -> Vector
simply doesn't work because the Vector entity has 2 relationships
which ideally need inverses (I can only choose 'source' or 'target' as
the inverse).
One possible solution I can think of involves having different
entities for each end. I'm pondering if this is going to be a suitable
solution for my task. It does seem a little wrong, intuitively at least.
AbstractVectorEndpoint:
(abstract + common data)
VectorSourceEndpoint:
vector -> to-one -> Vector (source)
VectorTargetEndpoint:
vector -> to-one -> Vector (target)
Any thoughts or pointers? -
I use Core Data to store large amounts of 3D vector data. I solved your problem in the following way:
I have a "Vector3D" entity that you can think of as an "end point" in your model. My Vector3D entity has x,y,z attributes.
I have a "Vector3DReference" entity.
Vector3D has a "to many" relationship to Vector3DReference which has a "to one" relationship to Vector3D. I can ask any Vector3D for all of its references, and I can as a reference for its Vector3D.
Vector3DReference is abstract. I have derived Vector3DReference for all of the cases where I have other entities with relationships to Vector3DReference. For example, I have a Billboard entity that has a "to one" relationship to BillboardAnchorVector3DReference which has a reciprocal "to one" relationship back to Billboard.
It is common in 3D systems to have a large collection or database of points/vectors and then reference the points/vectors for index or ID. E.g. consider multiple triangles that all share a vertex. When the vertex changes, all of the triangles that share the vertex are updated. Sharing vertex data also reduces the storage required vs. lots of copies of the vertex.
-
As another refinement, store all of your end points as an array of float. Store the array in NSData. Have an entity called EndPointStorage that has an NSData attribute, endpoints.
The Vector3DReference entity can then have an integer attribute called endPointIndex. Use endPointIndex to lookup the end point in the EndPointStorage.endpoints.
-
On 1 Dec 2008, at 15:59, Erik Buck wrote:
> I use Core Data to store large amounts of 3D vector data. I solved
> your problem in the following way:
>
> I have a "Vector3D" entity that you can think of as an "end point"
> in your model. My Vector3D entity has x,y,z attributes.
>
> I have a "Vector3DReference" entity.
>
> Vector3D has a "to many" relationship to Vector3DReference which has
> a "to one" relationship to Vector3D. I can ask any Vector3D for all
> of its references, and I can as a reference for its Vector3D.
>
> Vector3DReference is abstract. I have derived Vector3DReference for
> all of the cases where I have other entities with relationships to
> Vector3DReference. For example, I have a Billboard entity that has
> a "to one" relationship to BillboardAnchorVector3DReference which
> has a reciprocal "to one" relationship back to Billboard.
>
> It is common in 3D systems to have a large collection or database of
> points/vectors and then reference the points/vectors for index or
> ID. E.g. consider multiple triangles that all share a vertex. When
> the vertex changes, all of the triangles that share the vertex are
> updated. Sharing vertex data also reduces the storage required vs.
> lots of copies of the vertex.
It's most common for 3D apps to pack the vertecies into arrays, and
then create index arrays that index into the vertex/normal/tex coord
arrays to get at the data. These can then be uploaded so that all the
lookups etc happen on the graphics card, and no data need be fetched
from system memory when you try to draw.
You should look at glVertexArray and related functions.
Bob -
Thanks Erik,
On 01 Dec 2008, at 4:59 PM, Erik Buck wrote:
> Vector3DReference is abstract. I have derived Vector3DReference for
> all of the cases where I have other entities with relationships to
> Vector3DReference. For example, I have a Billboard entity that has
> a "to one" relationship to BillboardAnchorVector3DReference which
> has a reciprocal "to one" relationship back to Billboard.
As I understand it, your model is equivalent to the example I gave of
using distinct entity types for each 'endpoint' (as I described it).
I'm still pondering if that's going to work for me, I suspect I should
just try it and see what becomes a problem.
That old adage "every problem in computer science can be solved with
another layer of indirection" comes to mind.
> It is common in 3D systems to have a large collection or database of
> points/vectors and then reference the points/vectors for index or
> ID. E.g. consider multiple triangles that all share a vertex. When
> the vertex changes, all of the triangles that share the vertex are
> updated. Sharing vertex data also reduces the storage required vs.
> lots of copies of the vertex.
Thomas Davie wrote:
> It's most common for 3D apps to pack the vertecies into arrays, and
> then create index arrays that index into the vertex/normal/tex coord
> arrays to get at the data. These can then be uploaded so that all
> the lookups etc happen on the graphics card, and no data need be
> fetched from system memory when you try to draw.
>
> You should look at glVertexArray and related functions.
I seem to have completely made a muck up of using an analogy. I'm not
dealing with 3D data at all, though I can see the similarities between
that and my domain. Vector may have been then wrong term to use, I'm
really dealing with a directional, anchored-at-both-ends, link between
two entities.
Thanks for the help guys.
