py drawing to 3dview (Re: [Bf-committers] User-defined Material Properties)

[Tom M]

Hi Greg,


>  I assume you're directing these comments to me, because its under my old
> thread name.

Actually I don't think they were, the original thread name was
included for continuity.

actually very little in the way of resources has been devoted to the
internal game engine.

>  I just wanted to inform you that someone else should pick up
> the torch because I've decided not to contribute.

That is unfortunate to hear.

> I think the most important thing Blender needs to do right
> now is replace the internal data model with
> an extensible, object oriented design.

It could be, I'm not really in much of a position to offer an opinion on that.

> I also believe strongly that the game
> engine should not be a part of the main Blender project.

For the past three or four releases we have considered making it a
completely external project, since there are only one or two
developers who take an active interest in maintaining the current game
engine.

> That people are devoting tons of energy to the former and not the latter, indicates to me
> that the project is driven by something other than the best interests of the
> end-users.

I think you have misinterpreted things.  CrystalSpace is a completely
seperate project, the primary author of that project would like to
better improve the work flow between the two since those who make
content for his game engine are mostly Blender users.  He is clearly
deeply devoted to the best interests of his users, which is better
integration with their primary content tool - Blender.  He is also
making effort to make it an easy migration path for current Blender
game engine users, since there is currently only one active developer
for the Blender internal engine and his interest is primarily in the
logic and physics systems which could as easily be useful for
CrystalSpace.

> After seeing Blender's internals, I can't put my
> career on the line recommending it.

You of course know your needs best.

>  If Maya can be rewritten, Blender can too. And be done in a way that all
> the old scripts still work the same.

Sure, backwards compatability with scripts is a fairly minor issue,
since the vast majority of useful scripts for Blender are open source
and thus portable with incompatible API changes.

> I know you paid a lot for that C
> program, but now that you have everyone's attention you surely can muster
> the troops for a rewrite. If I were to rewrite Blender, I'd probably end up
> doing it from scratch and then porting pieces over to the new framework. But
> I have a job and don't have time. Its really not a one man project.

It isn't that we 'paid a lot for that C program' - it is that we have
limited developer time and talent, and an even more limited number of
developers who are skilled with the deep guts of Blender.  The
question is, is it a better use of developer talent to extend Blenders
feature set, and occassionaly doing incremental rewrites as needed (ie
the refactor of the animation system and ipo system) or to put other
development on hold to wait for a complete rewrite.  The other core
issue with a complete rewrite is that opensource software has a
history of complete rewrites either failing or taking so long that the
community around them evaporates.  Another issue is that an excellent
C developers capabilities are not directly transferable to a C++
developers.  Thus our current core team could lose quite a bit of
productivity by such a change.

We have considered a rewrite as a long term possibility (Blender 3.0),
but right now I don't think it is overly feasible.

LetterRip