Why not? i thought Interrogate does all the wrapper generation automatically. Are you guys perhaps artificially restricting access to some performance critical areas of the engine for python users?
I think this does more bad than good in my case. Youre saying that the egg loader does an automatic sorting. This means that with my current code no one will be able to use a generated character with a loaded egg animation and vise versa and would leave people who want to achieve a similar task wondering what they did wrong.
I think I understand why you put the resorting in the egg loader though.
I could try to store the data needed for making the characterJoints/XfmTables in a list and create the actual joints/tables later based on their names? But it would be really nice to have a .sortDescendants() though
There are many, many class methods within Panda objects. Many of them are not intended for the application programmer’s use, so we don’t bother to expose them to Python–doing so would only lead to confusion. Originally, it was not intended that an application programmer would even be able to construct AnimBundles directly; the intended design was that the application programmer should always go through the egg loader. At some point, we relaxed that design, and exposed a few more methods, but we overlooked sortDescendants(). I am correcting that oversight now, but you’ll have to build your own Panda (or rely on the buildbot release) to pick up the fix yourself.
It should be really easy to do this in Python. This is the sort of thing that Python is naturally good at.
I don’t think i completely agree with you on the matter of not exposing some methods to Python though. I do agree that most users do not need that much control and they might just get confused, but if they are writing code, they should understand the risks. I don’t think C++ users are always smarter than Python users, so I don’t think the same methods would never confuse C++ users.
And you see that you can’t really know exactly which methods wouldn’t be used in practice.
I don’t think you are going to change the whole design because of this post. I’m just interested in knowing why you should restrict users of one language just because its a slower and simpler one. The features list said "Automatically-generated wrappers expose full functionality of the engine. ". I know you are doing this for us, but…
No, it’s not that we’re restricting interfaces from the “simpler and slower” language. The entire public interface to Panda really is available to Python and C++ programmers equally. (Actually, it’s the C++ programmers who suffer here, if anyone, because some of Panda’s public interface is written in Python and therefore not available to C++.)
We’re just omitting the private interface from Python. Methods that are only meant to be called internally are, of course, not part of the public interface, and not exposed to Python. (They’re not supposed to be available to C++ users, either, but sometimes due to pragmatic design decisions, they are visible anyway. That’s a different discussion.)
Anyway, this deliberate hiding of internal methods is one of the design features of object-oriented programming; it is called “information hiding” and is generally considered a good idea.
There is room for some debate as to which methods are intended to be part of the public interface and which methods are only meant to be called internally. That is what happened in this case: we changed our minds at some point, and declared certain methods “public” instead of private. We simply overlooked one of the useful methods.
Right, this is one of those methods that had to be declared public due to pragmatism, not because it was intended to be provided to C++ programmers. So it happens to be callable by accident, not by design.
Unrelated,
How does the buildbot work?
There seems to be two new builds for Linux distros since May 1st, but the are no Windows versions and the previous Windows version was generated just a day before the final one. Are the builds generated manually or is there an issue with the buildbot?
The format I’m importing has points which are used as camera targets. Those “points” also animate like bones. Should I create bones from them and set the bones as camera targets in-game, or can you have non-bone xfm tables or the like?
Yes, you should use joints for this. As I just said, the purpose of a joint is to play back the data in an xfm table. There is no other object in Panda that has this function.
I’m not sure what your question is directed at. Is there some additional functionality that you are hoping to find in some class other than a joint? Is there any reason to avoid using joints?
If you didn’t want to use joints for some reason, you could do the same thing with lots of other mechanisms, but they wouldn’t involve creating an AnimChannelMatrixXfmTable.
