other game engines (was: Re: [Bf-committers] restore Game Engine project)

Gregor Mückl bf-committers@blender.org
Thu, 7 Aug 2003 16:18:40 +0200


Am Donnerstag, 7. August 2003 13:11 schrieb Ton Roosendaal:
> - separating also means allowing to think over support for more engines

Support for other game engines has been mentioned a lot during the last month 
or two in several completely different threads. Currently this is just talk 
and no plan. This *is* an accusation. There are two way possible from here:

1. Develop an C (better C++) interface that enables game engines to interface 
directly with a running instance of blender. This means that blender's own 
game engine would be required to use this interface. I strongly propose a C++ 
interface as this is the only approach to hide away some of the more awkward 
internals of blender like the specialized memory management. And needless to 
mention, that this would be the start of basing the entire blender on a sound 
plugin-based architecture (if one C interface is there people will start to 
demand others... you know the tune ;-).

2. Don't heed other game engines, build a useable and - for a change - 
documented Python API and and force it down the throats of those programmers 
that want to use other game engines with blender. Blender's own game engine 
would remain tightly integrated.

Actually the first way will be the hardest one for everyone involved as game 
engines are anything but exchangeable. Each engine has different features, 
capabilities, limits and requirements, which are mostly embedded into its 
design. Therefore it is hard to design an interface on the "one size fits 
all" approach. Although a indirect coupling using python and a bunch of 
engine-specific tools increases turn around cycles a lot this will most 
likely be the better alternative.

Regardless of which way this is done I'd wish a library of algorithms that 
will common to almost all exporters to come. The top of this list are 
conversion of per-face uv coordinates to per-vertex uv coordinates, 
conversion to left-handed coordinate systems (oh yes, even game engines use 
these!) and triangulation of quads and higher-order polys. 

Adding these as modelling functions is pretty useless because this may mess 
with models to a point that  renders them almost unalterable. And artists 
can't be bothered with most of these technical details, anyway. It's better 
to have the exporters/connectors do these things, so that artists don't have 
to care about this.

Another part of this strategy is a way to place game/engine specific 
information in blender files. I have proposed the property system extensions 
as a solution to this.

I believe that all of the above points (internal game engine development, 
helper library for exporters, storing of meta info in blender) should be 
bundled into a common "interactive 3D" strategy.

Regards,
Gregor