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