The amount of inherited functions is very large, usability problem. about panda3d HOT 8 OPEN

Usually, ShowBase is not what you need to explore, it is a common template for creating an application. Also, if you are directly interested in camera methods, then there is a structured API for this.

https://docs.panda3d.org/1.10/python/reference/panda3d.core.Camera

from panda3d.

Even that core object still has 434 methods, and it is also doing things like 'getNestedVertices'.

I feel like there is an implicit, undocumented design philosophy at work that I'm not getting, which would be good to know for developing with panda.

from panda3d.

This is the PandaNode method

Camera > LensNode > PandaNode

https://docs.panda3d.org/1.10/python/reference/panda3d.core.PandaNode#panda3d.core.PandaNode.getNestedVertices

from panda3d.

On a C++ wrapper class, about half of those methods will just be camel-case aliases for other methods. Those will probably be removed in 2.0.

from panda3d.

One thing that might be worth mentioning regarding "Camera", specifically, is that at its core it's... just a node in the scene-graph, like any other. It can be moved, scaled, rotated, reparented, and so on and so forth. Hence it has access to all of the methods of a node in the scene-graph, even if in some cases those have little effect or return only basic data.

This also means that one might expect, when searching the scene-graph, to potentially encounter the camera--and want the standard functions and methods to still be present and operative, even if they do little. (Ideally without having to explicitly check whether the current node is a camera.)

As to using "dir"... I'm curious, if I may: why do that, rather than check the API pages? The latter would provide the methods specific to a given class, and can be followed back through its inheritance to whatever level is called for.

As for how--speaking for myself--I handle this complexity, I suppose that the answer is simply that I look for what I want, when I want it, via the API or the forums; I don't really need the majority of methods at any given time.

And furthermore, knowing (to some degree) the inheritance of a given class allows me to think about it in the manner appropriate: e.g. Given a Camera, I might adjust its lens as a Camera, move it as a PandaNode, etc.

from panda3d.

As to using "dir"... I'm curious, if I may: why do that, rather than check the API pages?

It is easier to type dir(myobject) and running my program than opening the API, searching for the correct class name and then scrolling through the list. I generally don't have the API open when do I things. It is often too hard to navigate and not very useful. It also doesn't contain the same information as the objects themselves. It has it's upsides, like the documentation text, but it's not the first choice when I'm looking for information.

I'm not saying anything against the standard methods, it's more about everything being available from everywhere.

E.g. whether something can be be done via. [only camera.lens.method] or [camera.method or camera.lens.method or showbase.method or all of them] is a choice. I don't like the later option, and I'm wondering if there was a specific reason for it or if it just evolved to be this way.

It's not really about the camera that was just an example. Directgui objects have similar issues, but those are an easy target so I figured I shouldn't use them as an example.

from panda3d.

It is easier to type dir(myobject) and running my program than opening the API, searching for the correct class name and then scrolling through the list.

Interesting! I think that for me it's the opposite: I find it far more convenient to do the search and get nicely-formatted data, complete with inheritance -graphs and -links, than to parse through the text-only output of "dir".

Or I suppose that I might put it this way: it's easier to get data from "dir", but easier--to my mind--to make use of the data from the API.

Anyway, thank you for answering my question!

It's not really about the camera that was just an example.

Ah, I see!

E.g. whether something can be be done via. [only camera.lens.method] or [camera.method or camera.lens.method or showbase.method or all of them] is a choice.

Yes, I think that I see better now what you're saying.

Hmm...

I can't speak to the history of the engine--remember that its early developers are likely not around on this site these days.

I imagine that the "showbase." paradigm was simply a matter of convenience: a way of having quick-and-easy access to things that were used often and in many places (such as "render"). (And without having to pass them around as parameters to everything, or search the scene-graph, etc.)

And I daresay that similar is true of other such cases. For example, the NodePath class provides access to a number of things that are technically aspects of its contained node, I believe. But it's more convenient to access things from the NodePath--which one tends to have easy access to anyway--than by dotting every single time to reach the actual node in question.

(All of that said, some of what you highlighted isn't really related to that. For example, the "Camera" class having a method for rotating textures is, I think, primarily a consequence of the fact that cameras are scene-graph nodes in Panda; it's not a result of a proliferation of means of accessing methods, just of inheritance.)

from panda3d.

I think if anything, we should have more specific issues for more specific areas to redesign, such as NodePath. NodePath is a particularly large class with many methods to mutate the state, but most of these methods are also following a general pattern and classes that inherit from it should not exist in the first place.

If you have specific ideas for a NodePath redesign, feel free to open an issue suggesting it, though I think the cost far outweighs the benefit of significantly overhauling NodePath.

The problem is already significantly reduced when we drop camelCase aliases as well as getters/setters in favour of property interfaces, because that would reduce:

node.clearName()
node.clear_name()
node.hasName()
node.has_name()
node.setName()
node.set_name()
node.getName()
node.get_name()

down to just node.name.

from panda3d.