Things that (could) drive you away from panda?

So we could all add things that we dislike about panda (this is not feature requests topic)

  1. Collision solids are not animated via bones

  2. Lack of world editor (this came to me only after i used torque…)

  3. GUI toolkit (i dont like dgui, it has too many quirks)[/list]

  1. So you can’t expose the joints and reparent collision nodes to them? I don’t see why that wouldn’t work.

  2. There are various editors around on the forums. It’s just very difficult to design a universal editor for a general-purpose engine like Panda3D.

I personally don’t think we really need an editor, as anything that can be done with an editor can be done in the modeling tool or with interactive debugging. We’ll probably have COLLADA integration in 1.8, so it’ll be even easier to synchronise your scenes between your modeling tools and Panda3D.

  1. I hear you. We’ll probably integrate a GUI engine like CEGUI in a future release of Panda3D, but this would need to be carefully thought out.

My two problems are keyboard input, and the GUI.

Built in key polling would be great.

We already support key polling through the lower-level interfaces, e.g:

if base.mouseWatcherNode.isButtonDown(KeyboardButton.pageUp()):
    print "page up is currently pressed"

Whats so bad about DGUI?

  1. Incomplete shader generator (texture state change, fog) and no way to add a shader without breaking what was already generated.

  2. Shader Generator’s shadow is only good for a spotlight.

  3. Bug with mopaths (should start and end in the same place)

  4. some things only in Python (not like I care as a Python user)

Thats all I can remember. Other than that, its the best choice.

Same as Anon - the shader genrator should handle some more basic stuff out of the box.

What really bugs me is the pipline. Maya seams to be the only one that can export all things, with Blenders chicken one the 2nd place.

I’ve got a project waiting on the shelf until I can export animations, morphs and multiple Uv sets from my modelling program.

You could try building a custom exporter with only the features you need.
The EGG-building stuff in Panda is pretty easy to use and fast.

I second the shader generator to some extend. It’s good for the most basic things, but it would be nice if it was more flexible. Luckily, that’s planned for 2.0, so I’m fine with the current state for now.

I can’t understand, though, why people have so little love for DirectGUI. Sure, it lacks in several areas, most notably: no windows ootb (although, it’s damn easy to write) and long text rendering (where you have to choose between long loading or low framerate), but outside of that I find it a very nice and flexible tool to work with. Even for some large and complex interfaces.

That’s why I hope that, if DGUI is to be dropped, it’s not gonna happen before 2.0.

So it will finally be possible to work with Blender 2.5, or will there still be some unsupported things?

Sure I can write my own game framework when I’m at it. I’m not that good, don’t have that much free time… and then there’s the collada support in the works that will solve all problems (when its done… I dare not to say if it’s done).

I’m aiming to support as much of the format as possible.

DGUI is not likely to be removed before Panda 2.

Ok, so just one informational question, when can we expect the 1.8?

Couple of months, probably.

I’d say lack of GUI systems is the least of Panda3D’s problems. There are so many more or less evolved GUI systems that users wrote it’s hard to pick one.

What could drive me away from Panda … not too much since it would be a lot of work to transfer to a different scripting language for example. Other than that 1) less liberal Panda3D licence; 2) a different SDK/engine moves to a liberal licence; 3) a different SDK/engine has a good Mac version; 4) more awesome Panda stuff that doesnt work on Macs than it already has.

Here we go:

  • Lack of a recent stable release (I have shadow and packp3d issues with 1.7.1)
  • Buggy shadows. If there’s going to be such a cool feature, it had better work :stuck_out_tongue:
  • Panda games can’t be in Linux package repos, as Panda isn’t in any repo. Including Panda in a source package won’t work, AFAIK
  • Lack of out-of-the-box threading support (I’ve had to use threads in my Panda-based GDK to run Lua scripts)
  • A good GUI toolkit. DirectGUI just doesn’t cut it, in addition to being unintuitive. No simple list boxes, notebooks, menus, or the like.

BTW, CEGUI would be a good replacement for DirectGUI.

Please, define “recent” and “stable”, imho 1.7.1 is recent and “reliable”! :slight_smile:
Every program has some issues and you need to wait the next release to get these fixed, and Panda isn’t an exception. What Panda does better is to provide a daily build, so you don’t need to wait the next release to start working with the fixed set of features.

Please don’t disinform! :slight_smile: You can absolutely provide packages containing your games!

Really? I don’t use that, but I read that it was here.

Well, making stable releases is hard work, I do agree though.
Perhaps more people could test the build bot versions of panda more often and report bugs more.

You can package your app into .deb files (ubuntu/debian) using pdeploy. (More on it in the manual)

IMO this is more of a Python problem. Threading in Python is plain bad. Panda already uses multi-threading for most things internally, it’s just that Python threading is a really bad move. (Look into the Python GIL, in short it’s pretty bad performance wise)

I completely disagree with replacing DirectGui as a whole. DirectGui has amazing support for doing anything you want, surely it’s a rough rock to understand, though.

I would probably be driven away from panda if DirectGui was gone, or I would use an older version that still had it.
IMO DirectGui may be very “unintuitive” if you put it that way, if you work hard enough with it it works REALLY well.

I honestly think it could use improvements, and higher-level approaches to using it, however.

P.S. I’d like to see pdeploy work for me in the near future :slight_smile:
Even then though with the minor bugs etc, Panda is the best Python game engine I’ve seen.
~powerpup118

Well, I did try pdeploy a while ago, but it didn’t work, so I haven’t looked at it since.
And concerning DirectGUI: I’d rather not spend time on writing theming and widget code, and instead focus upon game mechanics.

A lot of problems with pdeploy were fixed in 1.7.1. If you still have problems with it, please report them, and we can help you out with them.

Well testing and reporting bugs is one thing but now we get to a point which drove me away from Irrlicht and could drive me away from panda too: As far as I can tell the focus lies more on adding new features than fixing bugs. Futhermore existing interfaces are not documented exhaustingly to avoid trouble due to missing info about expected formats all aviable keywords etc.
But a big plus is the kind and very fast support :slight_smile: .

This seems a very important point. I like the Drupal’s management of this aspect: they release the new version only when there are no critical bugs (obviously, with the exception of security-related issues, in this case you can’t wait so much).

It seems that Panda has a similar management (some bugs are picked for the next release, others not). Maybe the problem is that developers and community have a different view of what is “critical”.

Maybe a sort of feedback (like a rating) on the bugs could be interesting for developers, so they can perceive if the community considers a specific bug very important. Anyway, the last words on these decisions belong to developers (obviously, they know the roadmap, and for them the community is only one of the stakeholders, so they have to deal with all of them and balance their efforts).