[Bf-committers] Gameengine - ODE and Python

maci_ray bf-committers@blender.org
Wed, 30 Jul 2003 12:47:06 +0200 (CEST)

 --- Willian Padovani Germano <wgermano@ig.com.br> schrieb:
> Hi, Michael (sorry for another huge email ...)

Hi Willian

> 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
> to
> > work, if I activate phantom, what eleminates the collision (geom)
> stuff.
> 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
> doing.

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
> from.

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
> desirable.

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