why doesn't it work in the game blender engine?

this may be a naive question but i ask it anyway.
there are so many things that work in the viewport but don’t in the game engine. why is that? i mean one can just press play and the animation of particles, soft bodies etc plays. you can render some nice radiosity (the new radio box thing) but shouldn’t those resulting effects be nice to have in a realtime situation?

just curious, because it seems like it all works in real time almost already… so why not just integrate all this into the game blender and we can take advantage of this game engine built in and the powerful new features.

The rendering part of blender and the game engine part of blender are almost completely separate. Each treats different objects differently. Only meshs, armatures, cameras, and empties work in the game engine as far as I know.

and lamps, but at most 8 can affect a sinlge object [and they only affect objects on a particular layer, and can’t cast shadows]

only uv-mapped textures work, vertex colors work, armatures deform meshes [but not collision bounds], bone children work [with a bit of lag], cameras work, emptys work, ipos work [only loc, rot, and col channels [no dloc, drot, or anything]]…

the game engine is completely different from the rest of blender, it’s written in c++ and maintained by different people. Part of the reason it is seperate is so that it can be seperated easily into the standalone player or the plugin [though a recent version doesn’t exist].

I’m speaking from the point of view of 2.37a, similar is true in 2.40 but things are changing in both directions it seems [more blender features in game engine, and a more seperated game engine]

but why is separate a good thing? i should think that integrating the two very tightly would be better for it as something people can use. keeping the game engine in step with the rest of the program. i for one would love it if i knew anything i could dream up in the viewport i could have rendered in real-time (i mean, within reason of course… i know wosme stuff is not possible) but maintaining them so separately is probably what is killing the engine. don’t you think so?

I agree that the seperation is hurting the game engine, but it also means that it doesn’t bog down the developpement of the render engine.

guess i don’t see why the render engine should be more important than the game engine %|

i hate renders. i waaant real-time! renders are dead. real-time is the future! :<

it is not the render engine, but the modelling and animation system - the core of Blender one might say. as things are the game engine is indeed quite a separate piece of software from it - nothing made to Blender automatically works in the game engine.

there used to be a more integrated GE, called Enji, in Blender … dunno if e.g. particles worked in it (if they existed at that time :o ), but it was much more limited in other ways.

with Ketsji, the current engine, pressing ‘p’ is more like exporting the Blender data to the GE that can then run it. not that much different from using an external engine, like Crystal Space or Ogre, with an exporter or a blend reader (crystalblend).

running a modelling/animation environment or rendering, and running a game are quite different tasks for the computer. i don’t know if such tighter integration you hope for is even theoretically possible, depends on the details of what you wish exactly i guess.

but if you just want games with fancy effects, that is another issue … then you just need an engine with those features, i guess some has particles etc? dunno if the Blender particle code could be used in a game engine … my guess is not, even tho the real-time animation preview of it seems to work well.


here is my opinion as posted on the blender dev forum. maybe some here can add their point of view there. i know this always comes up about the engine but. i would like to see a better, future for this engine than what is happening now.

i know i’m not the first to say it and probably won’t be the last, but…

please don’t let the game engine die!!!

why not re-write the sucker in C and integrate the hell out of it?
is there a good reason why not to do this?

the Blender concept of giving a realtime opportunity is unique, special and , well, a damn good idea!
i worry that what will happen is it will be dropped or thrown out to those who know how to use other game engines, left to the programmers and not given to the people. People who cannot swim through mountains of C++ to make a small real-time project. I am not asking for Half Life 2 quality here… but something that makes sense for those who know the Blender program. Expand the logic brick system! Take a look at something like Quest3D, for example. It shows beautifully the possibilities of visual programming.

The concepts exist, the paradigm exists. Why get caught up in all this rendering stuff all the time. Endlessly improving the render engine and killing the game engine is simply silly. but it shows that when it is known that something can be improved the lovely developers of blender CAN do something about it. So, why not fix this thing? The same team should try to do this, with the same excellent organization and attention to detail… not keep it separate where it may languish and die. Or worse, only be developed to the interests of a few rather than for the public at large.

Womanonfire has a very good point. Game creation has become an exciting art. To find an easy to use program to make video games, such as those you find in blender are extraordinary! There are lots of people out there who want to be able to create worlds you can walk in, travel in, journey through, and be whatever they choose. That’s how I’ve always seen video games, a unique way expressing imagination and adventure and escape. I’m really hoping that blender’s game engine will receive more attention and continue to grow. Especially, with this new crystalblend coming along. :slight_smile:

crystablend implements much of the logicbricks already, and at the conference there was also a presentation of the Girona engine which has nice visual logic editing, as has been posted here in the forum … so it is not going away, but should improve

also the original developer of the engine, Erwin, iirc will be able to put some time soon so we should get some patches with fixes and hopefully the armature support back in the next release … which wont be many months away!

i agree that games are exciting, but dont know if such integration you dream of is possible … depends what you mean exactly


Not sure what you mean by integration. But the GE is currently integrated into blender as a single package.

They have been released side by side. But as the other guy mentioned in the post at blender3d.org. Coders just won’t change sides from coding renderer to GE. It’s due to the fact that most of these guys aren’t getting paid to code. They’re doing it out of their own free time. So lack of interested coders in GE means a slower development pace than the renderer side of blender that has a lot of coders. Just recoding the thing in C won’t make them want to code it more. There’s promising projects going on like CrystalBlend and Erwin’s bullet physics. As for Girona, a complete recode of a GE for blender from scratch.

Yeah the’ve been prior discussions about this subject also. It’s not a matter of diverting man power from renderer to GE, it’s just a matter if they want to code for the GE or not. Plus the 2 things aren’t that similar.

Jason Lin

okay, you’re right. i don’t know much of what it takes to make the engine happen. and i am glad that it does get some attention. i don’t like the idea of using crystal space. but if this girona happens maybe then i can stop complaining.

what i meant by integration is, as close to what you see is what you get as possible.

i just saw all the new features in blender and then the very broken game engine and got all fired up.

been using it for awhile now and i really like blender alot and i wanted to use this GE feature, i have friends that want to use this feature, hey, i’ve got kids that want to use this feature, and it is not at the level of the rest of the program and won’t be any time soon and that is disappointing.

as for if they get paid to code or not… i think they should be paid. but i understand the open source ideals. personally if it would make a better blender and find coders to make blender better in all the ways it should be, i would pay for it.

open source and getting paid are not mutually exclusive.

e.g. several Linux developers are paid by their employers, like IBM and HP and Motorola and whatnot, for their work. also Apple releases their Darwin kernel as open source, and has actually hired FreeBSD core people to work on it. and Safari uses KDE Konqueror KHTML derived code, and Apple’s improvements are put back to the open version (also Nokia uses KHTML nowadays somewhere iirc).

i personally am paid to work on Blender right now. also much of 2.40 was paid work, by Google via the Summer of Code program. but very very much was not, but just done by people because they want and need, and that is great and i definitely dont want to put that down with all this talk about ppl getting paid for open source development!

if there are people willing to pay to get features in Blender, the open source community has established mechanisms for that. like Gnome has a bounty program i think, dunno how that has worked (i dont use gnome nowadays). oh and KDE KOffice or something has now a UI design contest with a 1000 dollar price or so.

i dont know if this has been discussed w.r.t Blender Foundation but it certainly can be at least discussed :slight_smile: (sorry for the stoopid sentences am really tired now)

back to the actual topic, the CrystalBlend integration would be that Crystal Space would be bundled in the Blender release, and integrated so that just by pressing ‘p’ it would run the GE, in the optimal case just like Ketsji is run now. so users would not even have to know it is crystal space, it would just be the Blender GE. and same can be done with Ogre and other graphics renderers if someone prefers them, the CrystalBlend code can be reused in that too (as also Ogre is C++). but this is not very tight integration with Blender in the sense that much of the code to drive the animations etc. would be separate, i guess pretty much like with the current engine.

but your original question is interesting. i did mention that one other old engine, Enji? it was more integrated in Blender than the current Ketsji, and used the same code as Blender itself and ran in Blender afaik (have never seen it, just read once what Ton wrote about it and talked about it with him once, and i was impressed!). if Enji was still there, perhaps even particles might just work there … i dont know. but Enji was really limited, not as much powerful as a GE as Ketsji, but i guess that could have been developed … and perhaps that development would have benefitted the 3d views of the animation/modelling side too? where we need improvements … like getting opengl2 shaders to work etc.

one reason for modelling/animation and GE being separate is the different demands for timing the execution. i mean, in a game you usually want a constant framerate. and usually dont need complex mesh manipulation like extruding capabilities, so can optimize the running. in modelling / animation, you want to see the thing exactly as it is, and have all the complex tools readily available. as you probably know with a big scene and complex operations (like fractal subdivide or whatnot) blender can get really slow, like 1fps, even on a powerful machine. that is the desired behaviour when modelling / animating, but not in a game. so the core of the code and how all the operations are written are different. this is one of the things that makes seamless integration of modelling/animation and gaming … challenging at least, and certainly impossible in the minds of many, and in near future in any case. but i dont think it is absolutely impossible.

i hope i managed to clear the issue up a bit.

thank you for the enthusiasm!


There will be some more improvements to the current Game Engine (Ketsji) soon.

blender materials, opengl2 shaders, armatures

Better integration of Bullet rigidbody dynamics, not all things are hooked up yet.

And some more general bug fixes.


Good to hear you’re still hard at work on the GE :smiley: and we all look forward to your (and others such as Snailrose) improvements.

All the best and plenty of freetime for your Blender GE development in 2006.

Ricky Dee