Hi!
for building a game, I think to create a class inherited by CollisionNode to manage the units’ informations. Than I attach a Model to my CollisionNode.
I’m not sure that I would do it this way, but you could choose this approach.
Note that if you inherit from CollisionNode, you also inherit from ReferenceCount, and you thus inherit all of the rules that go along with this. In particular, you can’t do:
MyObject myObject;
And you must instead do:
PT(MyObject) myObject = new MyObject;
You are also inheriting from TypedObject which means you should probably also follow Panda’s TypedObject convention, which means defining get_class_type(), init_type(), get_type(), and force_init_type(), as you see virtually every Panda class doing. Also ensure that you call your own class’s init_type() method sometime at startup (as Panda generally does in the config_blah.cxx file).
If you don’t manage the TypedObject interface, then myObject->get_type() will return CollisionNode instead of MyObject. You won’t be able to ask node->is_of_type(MyObject::get_class_type()). You won’t be able to use DCAST(MyObject, node) to perform a type-safe cast to MyObject.
This probably won’t bother you though, if you don’t actually care to use those interfaces. Nothing within Panda will care.
I cannot possible answer your second question; there is no “best” solution for such a broad question. My personal preference would generally be to create the game structures in my own code, and have pointers into the PandaNodes they reference, rather than tying it so intimately into the scene graph; but there are pros and cons of both approaches, and subclassing is sometimes the right answer.
Note that you need to call MyObject::init_type() at static init time (or in any case, before you start using your object) to initialise the type system properly.
CollisionNodes are hidden by default. You’ll need to call show_through() on the child node if you want to make it show up anyway. Alternatively, you can call show() on the node itself, but this’ll make the debug visualisation for the solids show up too.
PT() is an automatic pointer for objects that inherit from ReferenceCount. It automatically increases the reference count when you create one and it decreases it when it goes out of scope, making sure that objects automatically get cleaned up when there are no references to them anymore. You should use them to refer to reference counted objects (including PandaNode derivatives). Be sure not to attempt to delete objects that inherit from ReferenceCount.
DCAST is a macro for objects that inherit from TypedObject that performs safe typecasting.
I’m not sure if that is the problem here though, because you haven’t elaborated on “doesn’t work”. What doesn’t work? Does it crash? Does it show an error?
the problem isn’t resolved if i use PT instead of *.
There’re no crash. this’s not work: if i click on the sphere, in the terminal is printed 0. if i use CollisionNode instead of MyObject, in the terminal is printed 1…
why?
PS: ok, i understand but it doesn’t work… i try to move MyObject::init_type method at the beginning of the main and than of open_framework call, but the problem’s not resolved… where am i wrong?
PS2: and is not a register problem: i print obj->get_type().get_name() and it is “MyObject”. and obj->get_type().get_parent_class(0).get_name() is “CollisionNode”.