questions and suggestions for the "direct" package

  1. What are the “tkwidgets” and “wxwidgets” in “direct” for?
  2. What is “controls” folder for?

Also, searching the “direct” package I found some things which seem junk:

  1. The “test” folder.
  2. The “physics” folder
  3. In “directbase”, “TestStart.py” and “ThreeUpStart.py”

There’s also a mirror demo and (part of?) a shadow demo in there.

tkwidgets contains useful widgets that relate to Tkinter and Panda, wxwidgets contains useful widgets that relate to wxPython and Panda. They are quite useful actually for people who use Tkinter or wxPython in conjunction with Panda - for instance, wxwidgets has a class that allows people to easily integrate a Panda display inside their wx window.

controls contains useful classes for controlling an avatar or vehicle in-game. There are some examples on the forums for GravityWalker, I think.

TestStart and ThreeUpStart actually look like useful scripts too. If you run it like this:

python -i TestStart.py

it will open a Python shell, open a Panda window, and create three arrows, each pointed into a certain axis (like you would see in a modeling suite) and drop you back to the Python shell so you can enter Panda commands.
It looks useful for prototyping stuff on the command-line without having to do all that setup yourself every time.
ThreeUpStart looks like it’s particularly intended for particle effects or something like that.

I didn’t know they existed - but I’ll certainly be using them in the future, so in a way I should thank you for bringing it up. :slight_smile:

MirrorDemo and ShadowDemo are examples that show how to create a mirror effect or a shadow effect without the use of shaders.

Just because you don’t know what something does doesn’t mean it’s junk. Just sayin’.

Wouldn’t ‘samples’ be a better place to keep those demos?

Sorry to disagree, but I think that code actually is junk.

It’s all about unmaintained and undocumented code snippets. Those can be useful, but I think there’s a better place for than the official SDK codebase.

That’s OK, you’re entitled to your own opinion. But there are many people relying on at least some of those modules, and I’m not going to remove useful things that are used by people because some other people consider it useless to them or because they don’t understand how it works.

One of the important features of Panda is being able to manipulate the scene graph in-game, both from the Python shell and from tk panels (like nodePath.place()), allowing people to develop their games without having to restart it all the time, and I’m not just going to remove the stuff that makes it easier to do so because somebody thinks it’s junk.

I do notice that this type of workflow isn’t really used by many in the community, so perhaps instead of removing these things, I should spend some effort writing a blog post or making a video tutorial on these tools.

As for moving the ShadowDemo and MirrorDemo to ‘samples’: I’m not sure if they are really sample-quality. I admit that the current location may not be the best place to put it; maybe they should be moved to a direct/src/demos directory or so.

While we’re on it, I was wondering why is the leveleditor kept in the main Panda distribution? It doesn’t seem to work much (at least for me it doesn’t), nor does it seem to have any official documentation on the Panda website. What is the point of keeping it there?

The level editor was recently developed by Disney, as an effort to make a new level editor that would be useful to the community. It just never really got into use because nobody bothered to properly document or popularise it.

Last time I checked the Level editor was just a proof of concept. If it’s complete, I could help documenting it.

Closer to the topic, if the old Level editor which doesn’t work with newer versions of the engine is still in the codebase, maybe it would be good to remove it now, as two level editors might cause confusion.

I would argue that documentation should’ve been done by the editor’s developers themselves. I know writing docs is far from any developers’ favorite tasks, but software can’t be expected to be picked up by the community if this effort isn’t done.

Still, I think the lack of documentation is not necessarily the biggest problem with that editor. The biggest problem is that is simply doesn’t work. For me, it fires up, but the GUI is completely messed up and unresponsive. For others, it simply crashes.

I appreciate the effort of writing the editor, but it looks like it’s never been maintained in any way and stopped working before anyone had a chance of using it. And since it’s undocumented and not working, while the supported level design method is using Blender or Maya, I wouldn’t expect many (or any) volunteers to develop or maintain it.