So you can’t expose the joints and reparent collision nodes to them? I don’t see why that wouldn’t work.
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.
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.
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’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.
Please, define “recent” and “stable”, imho 1.7.1 is recent and “reliable”!
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! 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
Even then though with the minor bugs etc, Panda is the best Python game engine I’ve seen.
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.
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 .
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).