Hi,
I started a diagram (Inkscape) of some of the Panda basics. I am still in the early stages of learning and this helps me to capture important info in an ‘at-a-glance’ kind of way.
I hope others may find this helpful. It’s on version 1 at the moment and I will keep hacking at it when I get time.
Hey, that’s great! Gives people a good structured overview over the most fundamental concept of Panda3D.
Note that the new doxygen reference (which will soon replace the current apiref) also shows inheritance diagrams: panda3d.org/dox/python/html/ … aNode.html
But for other concepts than inheritance, your diagrams could be very helpful for learning Panda3D.
Is what I was trying to say. I think instancing makes things get tricky in that department – but I could be wrong and be using old information.
My meaning was that one should keep the Python variable (reference) in order to get access to a PandaNode, I was not talking about attributes on the node/nodepath.
The whole idea of instancing is (afaik) that the actual animated model has multiple parent nodes. Those parent nodes represent the individual instances, which are all reparented to render.
Could be wrong though.
\d is accurately quoting a line in the manual, which is itself technically accurate though a little confusing. There’s no unambiguous way to convert from a PandaNode to a NodePath in the presence of instancing: in this case the PandaNode corresponds to many different NodePath’s, each one representing a different instance (i.e. a different parent somewhere in the chain to the root). In the absence of instancing, of course, NodePath(node) is absolutely unambiguous and easy to do.
I’d make a distinction between a plain but non-empty NodePath (e.g. NodePath(‘dummy’)) and an empty NodePath (e.g. NodePath()). The former NodePath contains a reference to a node which has no special properties. The latter contains no node at all. An empty NodePath is kind of like a NULL pointer. Certain operations, like np.find(), return an empty NodePath for failure; and certain other operations, like np.setPos(other, pos) treat an empty NodePath as a special input.
a very nice idea!
i wish i had such diagrams when i started with panda.
few suggestions:
don’t confuse people with subclassing at first. just tell that there are different node types.
empty nodes should be rather called “blank panda nodes” or “nodes not holding any objects”, so that people don’t get the impression they’re useless. also they’re only as long empty as you don’t reparent anything to them. you can still attach new nodes to empty nodes and set attributes on them (which are inherited and therefor very important). render is a good example of an “empty” node.
the explanation of ShowBase is very confusing. i think it might be better to not mention inheritance or instancing. explain it very abstracted first and dig deeper afterwards. you call it “vodoo global variables” and i think it’s very good for the beginning ^^. it’s like magic you get used to first and explain afterwards. how about explaining the base as “the base of a program” which has everything you need inside or something like that?
the last picture seems to make a distinction between ‘render’ or ‘camera’ and ‘NodePaths’, but in real those are also only nodepaths.
something for the future: try to separate code and panda’s nodes. for me it was very hard to think in multiple dimensions at the same time in the beginning.
i like the idea of suitcases you used:
a nodepath is a handle to a suitcase (=node). empty nodepaths are handles to empty suitcases and ‘really empty’ nodepaths are like handles without any suitcases.
also i very much like the idea of separating python classes and logical node hierarchies by colors (yellow = python, black = panda nodes)
Good point. I am still in the process of making a precis of the manual, so this is very much a working draft. How well it ends depends on my time and energy. But I will try.
I think this reflects my own confusion! I don’t like it either and plan to refine it – a lot.
Ah. Yes. I was having a hard time drawing a scene graph really – it’s such a mix of classes vs objects vs nodes.
What is a SG really? If I say they are all PandaNodes, then I can’t include ‘render’ (for example) in the illustration. If I show ‘blank-node’ → ‘nodepath render’ it may get confusing. Let me have another look.
My idea for that SG pic was to get an instant ‘aha’ for what nodePaths are – a list of handles (flat) pointing into a tree of nodes.
Can you point me to what you mean? I don’t quite see it.
Now this one I could claim credit for and come-across as being really clever – but it’s a total fluke! Please I am interested in your insight here. If you can explain then I will adopt the idea. My colouring was more to do with visual focus than some meta split between concepts.
Thanks for the feedback. I have made notes of your suggestions.
\d
A Scene Graph is a collection of PandaNodes. Anyone can create a new scene graph by creating a new node and attaching other nodes to it. “render” is just another node created by ShowBase and passed to base.camNode.setScene.
Very nice diagram. I can see a lot of effort went into it. I can turn this into a downloadble .pdf If someone can tel me where to upload it so that it is accessable to the other pandaheads.
python classes usually consist of some others it inherits from. this is why e.g. ModelRoot is also a ModelNode which in turn is an extended PandaNode which inherits… you get the idea.
this is the one tree. although quite linear, it might be confusing for newcomers.
the other tree is panda’s node tree where render and render2d are the top nodes (or ‘trunks’ if you think of them as trees). this tree consists of PandaNodes, which are derived from classes and therefor from the other tree. and if you think that is not confusing yet, then you might guess yet another layer in the game code. so in conclusion: the coder uses python classes (which inherit from each other as explained above) in his own classes to form the virtual render node tree. the best thing you can make to not get confused is holding all these layers or dimensions (call it however you want) separated. don’t ever mix the idea of your code hierarchy with the virtual nodes hierarchy.
I tried to incorporate all the advice so far; thanks for all the feedback.
When the ‘tut’ is a little more developed I will make a PDF of it.
Is there anywhere I can place the source SVG files that won’t die when my personal hosting dies? I’d hate to do all this and then have it go offline someday. I can’t upload a tarball to the wiki, so I can’t store it there…
Great! One thing, you have called NodePath() a “really empty Node.” This is not true however, because there is no Node. NodePath() is an empty NodePath, which means that it doesn’t point to any node at all, and any operations (like setPos) will be invalid.
On the other hand, NodePath("") does create a PandaNode, and the NodePath will be pointing to that PandaNode.
Right, and I’d recommend avoiding the use of the word “empty” to refer to anything other than a “really empty” NodePath, to avoid confusion. We use the phrase “empty NodePath” throughout Panda, and in methods like nodePath.isEmpty(); the word “empty” in the context of NodePaths has always meant a NodePath that contains no node.
I suggest the word “dummy” or “plain” instead to refer to a PandaNode that has no remarkable properties.
I made a change to the ‘really empty’ section. Not sure if I can keep everyone happy, but I am going with ‘empty nodepath’ when it’s NodePath() and ‘empty’ when it’s NodePath(“foo”).
New diagram up too.
Is there a better lic. than cc by nc sa? I can change it to what Panda-ites prefer.
I think this reflects my own confusion! I don’t like it either and plan to refine it – a lot.