On 16/10/2014 at 19:33, xxxxxxxx wrote:
I can tell you almost have the full picture, but are fuzzy with the various relationships between the class hierarchies and the type values across the various objects. I agree it's a bit confusing, it took me some time to sort it out. Here's what I found:
- PolygonObject is a child class of PointObject, which is a child class of BaseObject. Spheres are instantiated as BaseObjects, and so do not contain any PolygonObject data. This affects the RayObjects in the same way, that is, in terms of not having PolygonObject data when they are of sphere type.
- RayObject is a struct that can be instantiated and does not inherit from anything. Its data members are used or ignored depending on on how its data member called 'type' is set. If it's of type polygon, several of its pointer data members are used to access data needed to represent it. If it's of type sphere, the pointer data members only required for polygons are set to null because they are not needed. That is, for some reason, there are no 'RayBaseObject' / 'RayPolygonObject' classes to mirror the BaseObject / PolygonObject relationship.
In your example:
Cone and Cube are instantiated PolygonObject objects, and Null is an instantiated BaseObject. Therefore, the RayObjects for Cone and Cube are set to the polygon type, and the RayObjects point to PolygonObjects that contain the required data to represent them (polymorphism is used through BaseObject pointers). You happen to be able to use GetUp() and GetCacheParent(), simply because the PolygonObjects exist at all.
As for the Sphere, it is represented as a BaseObject and its RayObject equivalent is set to type sphere, which does not point to any PolygonObjects because it does not need any polygon data, only the RayObject::mp to represent the center of the sphere, and its radius, represented by RayObject::rad.x and RayObject::rad.y. It's not really an "other strange thing", as what is really the 'oddball' RayObject is the polygon type, because it's the only type that needs to point to PolygonObject data, unlike sphere, sky, and floor. It's probably not an optimization, but simply a consequence of polygons requiring more data than the other types.
Therefore, if you absolutely need to retrieve tags, or do anything else that requires your sphere to have PolygonObject data representing it to get the connection, then you most likely have to convert it to a polygon, as you state. Otherwise, there's nothing to make the connection you get with polygon type objects, because the data that creates the connection simply doesn't exist for spheres. Perhaps this clarifies how you have to conceptualize these various objects, and you'll find a different solution that is less 'hacky', as you state.
I hope that helps!