[Bf-committers] Re: [Crystalblend-main] Crystal Space, CrystalBlend, GameEngine: Discussion and Plans

[Greg MacDonald]

Hi lukep,

Imho depends of what you call properties and where you want them. in the
> other thread you were speaking of adding them to blender core, CS
> discussions are about game engine, which is mostly already a separate world.
>

I'm talking about named and categorized general properties on every data
block. Someone responded seemingly disappointed that his engine wouldn't
work with Blender as CS will. Imho the game engine isn't seperate enough if
he's having these issues.

Jorrit was speaking of self-describing things, iow object model classes.
> This is bound to lead nowhere outside of game engine, as only this part
> follow an object model (others are written in C++ but in the end, fill core
> C structs like nurbana or the fluid sim. Even the python API will have to
> drop its info in C structs, and as such will loose any polymorphism or
> object related characteristic).
> But for the game engine, this approach certainly fits in.
>

Why couldn't this approach work for Blender's core?

For core data structures, they are organized in a kind of database, in the
> sense that libdatas are split by kind and each can refer to others (see
> http://blender3d.org/cms/Blender_Architecture.336.0.html). So adding user
> datas is possible, provided we add a new libbdata kind to hold them. A
> pointer to this struct in each data block you want to add properties and you
> are done. However you have now to devise some kind of registration and
> provide way of edit and vizualise those. I oversimplify, but this part is
> certainly feasible provided it is well coded (we are touching very sensitive
> datas at the hearth)
>
> For generalized plugins, remember blender is C program and that it means
> hooks points, indirections and other no so nice to code things cleanly and
> fast.
>

I undertstand Blender's architecture. That's what I'm concerned about. My
question is why not rewrite the core internals in C++? (We can keep the cool
parts, like sdna.) I think such a thing would facilitate writing a plugin
architecture that allows someone to create new object types and merge gui
elements into the main interface. We could of course do everything in C with
hooks, but that would be spaghetti and incredibly confusing. More
importantly, hooks aren't extensible. No one can anticipate how someone
might want to add to Blender.

I would be willing to contribute to such an effort. And if its too big for
just one person, we could create the design, then put out a call for
participation... I for one think this would be a huge effort and am
overwhelmed with the idea of doing it alone.

All my whining is stemming from one main problem I'm having, that I believe
a lot of people are facing when trying to add to Blender. I found it very
easy to edit the code directly using the architecture guide. And I got to
the point where I had several new object types with custom representations
in the 3D View. It was beautiful, fully integrated, and I was very pleased.
But then I was told that Ton has said in the past that additions specific to
the vis sim industry would never be accepted into the main tree. I can't
offer my own special distributions forever by constantly patching Blender
everytime a new version comes out. So I'm currently trying to do everything
in BPython and I'm finding it a restrictive and disappointing experience,
which is a shame because python is such a joy to program in.

I didn't mean to rudely divert the CS discussion as I have. CS looks like an
incredible project. I responded here because I think the game engine would
probably benefit from an object oriented data model. We should probably
start a new thread if I'm about to be taken to school. :)

Respectfully,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20051017/31978a6b/attachment.htm