I want full control of the panda3d technology, but without the global variables. I know about the man page about creating the window manually, but its not quite enough.
The globals are making writing my app very different than how I would write it if there was an API for creating resources.
Has anyone built an example where panda3d doesn’t have the big DirectStart implication and, ALSO, one that doesn’t have the panda base import *?
Right, as GrizzLyCRO points out, you don’t have to import DirectStart; instead, you can simply inherit from ShowBase and instantiate it when you’re ready.
ShowBase will still stuff a lot of things in the builtins dictionary, and you can’t really prevent this. (Unfortunately, a fair amount of existing Python code within the Panda3D source tree assumes these things exist, so it’s a bit troublesome to remove them, and no one has offered to do the work yet.) But you can pretend that they’re not there, and unless you want to use the same builtin names for yourself, they won’t cause you any trouble.
Or you could use the lower-level interfaces directly, entirely skipping the “direct” tree and all that it offers.
Yes! rdb, I definitely want to know how to get to those low-levels.
drwr, Grizzly, those are definitely a step in the right direction, but I want more control than even that.
Have any of you seen any examples or manuals about using the low-levels directly? I was thinking that I’d just have to avoid the “direct” libraries and use panda directly. Is that how?
*edit: i guess thats exactly what you said, heh. Now I just need to find a good reference on the panda tree so I can plan how to use it.
One easy thing to do is to look at ShowBase.py and see what it does. Then do the same thing, but more cleanly.
I thought to do a similar thing (look what ShowBase does and reimplement it more cleanly)… As drwr and rbd mentioned, many parts of Panda’s Python-level depend on ShowBase, so you’ll have to, basically, understand the whole Panda3D Python code and rewrite+debug a significant amount of it. That seems just too much work for one person :"/
Moreover, another downside of this is that you won’t benefit from any improvements done on Python level by Panda developers. I want my efforts to be aligned with the huge work done by community, so I had no choice but do everything on top of ShowBase.
I suppose many people dislike the way current Python part of Panda3D is structured, but resolving that problem requires a concentrated effort on part of core developers… Though it would be much easier to contribute to the engine if it was built in a strictly modular approach =)
I’d argue that it’s doable. ShowBase is packed with all kinds of features that you probably don’t need, so you would only have to implement the parts that are necessary for your use-case.
But yeah, it does require a significant bit more work in certain aspects. For instance, there is no FilterManager (yet) in C++.
I’d also argue that an incremental approach would work too. You can do just enough to satisfy your needs for now, and then gradually add more features over time.
You don’t have to be shut out of the rest of Panda development by making a modular startup script–I’d like to see a modular startup script make its way into the source tree, so I’d be very happy if the community developed one. We’d be happy to accept your submission for inclusion into cvs.
The fact that this is best handled by several people working together shouldn’t be a deterrent either. There are several people here on the forums, aren’t there?