[Bf-committers] restore Game Engine project

[Ton Roosendaal]

Hi,

(forgot to reply to this one too!)

On Sunday, Aug 10, 2003, at 03:31 Europe/Amsterdam, Patrick wrote:

>    I've been thinking a lot lately on the speed issues, and I'm not  
> sure that the lack of culling is the only culprit. Having a lot of  
> objects seems really slow regardless of how many polys they are.  If I  
> have 100 cubes all joined into one mesh, it has no trouble running  
> that.  But if I have 100 cubes all seperate objects it really dies.  I  
> think this may be because of how it adds the objects to the scene but  
> I'm not sure.  Ton or carsten, do you know of any other culprits for  
> the game engines aparent lack of speed?

This was the major annoyance the NaN artists were fighting with in the  
current (2.25) engine. Slow downs really go exponentially, and there's  
no simple clue how to fix it, except with a good spatial subdivision  
(culling) system.
It seems to be related to how the internal event system functions, with  
evaluating the sensor-controller-actuator system. Solid itself didn't  
make it slow... but Solid is the major memory & time consumer for the  
initializing phase.

> All throughout game development these past few years, no one has ever  
> really figured out what keeps speed down the most.  There are some  
> guidelines to follow, but sometimes it doesn't really pan out.  I know  
> in my game I've run numerous tests and can't find any surefire speed  
> bottlenecks.  I guess we'll have to keep testing and scanning through  
> the code.

There's also the problem of 'focus' and 'design' here. The person who  
wrote most of the engine (erwin) did an honest attempt to make an  
engine which can function for professional developers as well. For this  
reason he wanted it to be very generic, with no (minimal) dependencies  
on Blender itself.
The main advantage is quite obvious; by not depending on Blender, it  
doesn't work well with Blender either...

>    The modular approach would be desirable I think, and we can start  
> by seperating the game engine out.  The rest of blender would be much  
> harder to do that with :/
> Anyway, I am optomistic about the future of the engine.  I think with  
> some work it could become the premier game engine for hobbyist game  
> designers and proffesional RGD (rapid game development), although I  
> really do hope some more programmers can help us out:)

We can evaluate this topic in the same way we're looking at support for  
Yafray. Our own rendering system doesn't have to compete with this (nor  
with Renderman, etc). For rendering, I think we can find the balance...  
especially when exporting/cooperation works fluently.
Game engines - however different in architecture - also have common  
denominators. We can try to find what's useful to keep in Blender,  
especially when it's closely related to 'providing tools for artists'.  
Then leave most of the final 'media delivery' topics to the more  
specialized software projects.

Apart from the crucial question "what do we want Blender todo" we have  
to cope with the practical question "what can me make Blender todo".  
Accepting & knowing our limitations - both in current code as in  
current team - will help us a lot in moving forward.

-Ton-

------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org