[Bf-committers] Gameengine - ODE and Python
Wed, 30 Jul 2003 12:47:06 +0200 (CEST)
--- Willian Padovani Germano <email@example.com> schrieb:
> Hi, Michael (sorry for another huge email ...)
> Amazing, you uncovered gameengine coding activity : ). Like Patrick, I
> was also thinking that it was dead, dead, dead ...
Yep, I'm happy too!
> On Mon, 2003-07-28 at 07:17, maci_ray wrote:
> > I tried to start there, but the success was quite small. Physics seem
> > work, if I activate phantom, what eleminates the collision (geom)
> For the future, ODE really looks like the way to go.
Can somebody mail me a testfile. Maybe my gameengine use is not right.
> > In the mailing list two other developers came out :-).
> In the middle of a refreshing flood of emails : ). The momentum
> shouldn't be lost now.
Keep it running...
> Consider the Python example, guys: much probably there would be no new
> implementation now if Michel hadn't started it the way he did -- and
> scripting might be a very problematic area of Blender code. Like you
> guys are doing with the gameengine, he studied the embedding code,
> traced clear objectives -- rather ambitious in that moment, more than he
> knew -- and *(important)* announced and gave reports of what he was
As mentioned I decided to bring real Mesh updates to gameengine (that is
what I need most, and what started this thread). For now I clone the NMesh
and Image Module from BPY. Later, when I found the interferences between
BPY and gameengines' C++ Python encapsulation way, BPY can directly be used.
In older gameengine there were AFAIK some dictionary juggeling alorithms.
A question is: Should the replaced mesh appear in blender also (like my old
version which used NMesh directly) or is it just for gameengine?
> The source looks overwhelming when we first look at it. And I knew
> nothing about embedding. But after his initial work, I could simply
> concentrate on the Python/C doc and two Blender files (a DNA header and
> the start of the Object module implementation) and implement a new
> module. From there it was much easier and fun to explore and learn
> about other parts of the Blender source. The same happened with Guignot
> and Jordi.
The gameengine makes it a bit easier. C++ encapsulation and blackboxes helps
IMHO a lot. Polymorphism and so on even further...
> More than a new implementation, his initiative "nurtured" active
> developers for Blender as a whole and in particular for this once
> problematic area, that is now manageable and easier to read / learn
I looked in a bit yesterday. It's really good to read!
> Knowing well the situation with the game engine, maybe we could attract
> people from the ODE community (specially if Blender becomes a good place
> to showcase/test/tweak simulation parameters, for ODE users).
Yes. Gameblender is much better than ODE-drawstuff, what is also not bad.
> As Douglas mentioned, integrating ODE in Blender can bring quite
> interesting possibilities to the program, so this approximation is
Another good thing for ODE would be a really accurate mode (precission instead
of speed, the opposit of the design goal for now) what blender would make a
really professional simulation tool.
> I'm very interested in learning ODE, and about to start studying its
> docs / examples, so I'l be one more willing at least to follow the
> developments and hopefully help a little in the future. I can also help
> with Python, but won't have time for the "ground work" of understanding
> by myself the game engine as a whole, report my findings and from them
> define clear and specific objectives. If an "interest group" is formed,
> things will be easier.
I printed the hole ODE doc an read in 'evening armchair' :-).
> The other issue for some (me included): C++. This site:
> www.bruceeckel.com has a free two volume book on C++ (and also books for
> Java, Python). Personally I enjoy reading his books.
I learned C++ from Bjarne Stroustrups C++ Programming Language Book (in
german). It's quite hard to do, but if you manage your in.
> > I think this would be very bad. I love the way acting as make some
> > objects, meshes and just press P to see what is going on.
> (about stand-alone player). Well, this can probably be done even with a
> separate player: 'P' or a button press would save the current file and
> open the player to run it. This is more about modular design, which may
> be a choice for the future of Blender.
A complete seperated out gameplayer would the common code made more hard to
be managed (I really have to learn english better!!!).
> > > About your diagrams, if you can post them somewhere, I'd be
> interested :).
> > I`ll send them directly to you.
> I got them, thanks a lot : ), they are very helpful. I'm a complete
> newbie at UML diagrams, but willing to learn.
I'm not much further. But I do like nice pictures of software.
> What about suggesting the gameengine as one of the topics for next
> Sunday's irc meeting?
Why not. It's on 16.00 CET I think?
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de