If you can put enough methods in Object to make it a useful interface, polymorphism might work for you. Geometric figures might have a method to draw themselves in a window, they might be able to return a bounding box... Perhaps then you can have a linked list of your objects, but it needs to be the case that most of the code can handle objects just using the Object interface. The sample of code you posted where you tried to set hum->quad is an example of code that needs to know more than the Object interface.
I use polymorphism in very few places. I do it when I can have a factory function that returns a pointer to the base class and no other part of the code needs to know what exact type was returned. If I ever find the need to use dynamic_cast (which is what would allow you to get a more specific pointer from a pointer to Object), I reconsider my design, because the abstraction is not working.
All geometric shapes must be derived from a base class "Object", which will have only virtual functions that operates on the geometric shapes, just as you mentioned: Draw(), Rotate(), Translate() etc... This Object will describe a "protocol" that all those derived geometric shapes must follow. Is it a proper data structure for considering polymorphism? Or is it recommended to create separate linked list for those, I'm trying to avoid this since I was looking at a single volatile structure, in which I just have to add geometry without the need to be concerned about what they actually represent.