Cédric Brun wrote: > Using it for quite a bit of time now I think it would be great to improve > it > in these ways: > > - a default collision system. I mean if I don't want to handle > collision Soya should provide a way to tell "If XX collide with YY then call > this method" . Soya is high level but not concerning collisions. Using > raypicking is never "trivial" and lead to many errors. > If I had my way, the physics engine would be more strongly integrated into Soya and used for all collisions. > - exporting meshes from blender to cal3d and/or soya is not trivial > right now and many issues are open. > Physics parameters would be nice too. Unfortunately I don't know anything about writing Blender plugins. It would be much easier for me to write an importer from another format that included all the information we need, or from some generic XML format. > - Because the high level is a strong point, I think Soya should > provide > high-level API for most of the game programming concerns. I mean default > classes for controllers, for cinematics (perhaps here being able to re-use > blender could be great)... > I'm not sure how easy it is to embed Blender in Python, but I'm doubtful. Blender has its own game engine built in, and the MakeHuman project has abandoned Blender in favor of writing their own GUI for some reason. > - perhaps it lack a bit of documentation...Or perhaps the website > don't > push the documentation. Pydoc should be available from the website and the > soya wiki should be the main area for documentation.. > I completely agree. Unfortunately, most programmers are more interested in writing code than documentation. > - concerning deployment, I think packaging is the distribution > responsibility, but it could be great, and not difficult to provide pre-built > static packages. I mean for example, a package with everything needed for > linux (libs, python modules), windows or macosx (.app) . I did one already > for linux, a cmg package (klik system) and a pure binary one. > This takes volunteers, since the primary developers tend to be on Linux systems. I have built packages for Windows before but it's hard work. I use Debian and Ubuntu and Soya is already packaged for these systems. I've given up maintaining a build environment for Soya on Windows, primarily because of the unfortunate situation that Python 2.4 is built with non-free software, and a lot of the stuff I use under Python on Windows requires 2.4. > - concerning technicals aspects, pyrex don't seem very maintained. This combined with the fact that Pyrex doesn't allow one to build smaller objects without making them separate modules makes Pyrex something of a pain. Unfortunately, however, I *hate* C++ even though I use it for a living. Outside of work I avoid C++ at all costs. Programming in C++ is simply not pleasurable to me, and C++ programmers tend not to be Python programmers and vice versa, hence a 3d engine for Python should be written in a Pythonic language. Ultimately, I'd like to write a 3d engine in pure Python and hope PyPy can accelerate it enough to be useful. > Exports > scripts in blender neither (soya or cal3d). Perhaps it could be time to > re-use another c++ engine just as Dunk said. It could provide an high quality > backend, but more of that less things to maintain. I think it would be great > to maintain just a good API using ogre, or crystal space.. I tried Ogre for > example, and I have to say that on my low end system (PIII 500/ savage card) > it is a lot faster than soya, for a great graphical quality.. > See my previous post about C++ developers not being Python developers and vice versa. None of the existing C++ engines as far as I know has a decent Python interface, and where Python interfaces exist they tend to be for scripting only and your main loop must still be in C++. The one where this may not be the case is OpenSceneGraph, but I haven't looked at OSG much lately.
signature.asc
Description: OpenPGP digital signature
