Blender Developers Blog

I too would love to have a Blender game engine. But removing it was the right (though painful) decision. It caused a code maintenance nightmare by duplicating and reimplementing a lot of other code, and removing it makes adding new things to Blender much easier (like Interactive Mode).

Back when I was using 3D Studio Max, I wished it had a fast sleek efficient minimal game engine runtime called "3D Studio Min", but that never panned out either.

https://blender.stackexchange.com/questions/106972/what-will-happen-with-blender-2-8-game-engine

>As for the reasons for removal we can conclude it was an old and aging component, it was largely unmaintained, suffered from several bugs and limitations, and the Blender Foundation probably lacked the energy, motivation and manpower to maintain it properly.

>"Adding new things to Blender gets much easier that way. The Blender Internal code started in early 90s. Over 25 years old! Functionally, EEVEE can (and will) completely replace it." -Ton Roosendaal

>It was also very architecturally outdated, lagged severely behind the current industry standards and modern technologies in many ways, it would be very hard to bring it up to date. Modernizing it or introducing new features would end up being more work than a full rewrite from scratch. [...]

>What About Forking It?

>UPBGE is a third party fork, whose objective is updating and modernizing the BGE with better technologies and features, with the end goal of eventually merging it back…

> A massive subset of Firefox devs are Linux users.

No, they are not. A massive subset of Firefox devs are Apple users. For Linux, the occasional Redhat or SuSE dev does the most-needed fixing.

> Those features are missing largely because they are hard to implement reliably on Linux and customers (who are largely not Linux users) won't feel the impact.

Neither of these are true. It does make easier rationalizing Linux mistreatment, though.

If there was no impact, the equivalent functionality would not be needed to be implemented under other OS-es either. You have bugzilla full of feedback, that it does have an impact.

It also makes Linux itself look worse, compared to other systems.

> There are often flags you can set to try and use them on Linux, YMMV.

I know, that you can force OMTC, for example. I've been doing that for years, with zero bugs. Why can't Mozilla do that by default? They haven't reviewed the situation for years, that's how much they care.

Also, for example, the EGL situation (needed for Wayland, obviously Wayland apps cannot use GLX without X11) was purely Firefox problem, not the driver stack one. (Worked on by Redhat dev).

> If you try doing much hardware graphics (let alone game development) for Linux end-users you'll understand why features like OMTP or OMTC are late to ship on that platform, if ever.

Mesa is one of best of breed drivers, especially compared to some drivers you can find on other platforms. See here:…

Does anyone know about good books that discuss the various design decisions behind the "kernel graph"? (https://code.blender.org/wp-content/uploads/2021/04/cycles_x_kernel_graph.png)

I mean, I recognize that its the "graphics pipeline", but there's all sorts of performance discussion points. You want the data to be in a particular form as it traverses the graph. The various bits of the graph want to be "pipelinable", and parallelized if possible (possibly executing on a 'Remote' GPU). The data may-or-may not be local to a certain location. (Ex: data in DDR4 will need to be transferred to GPU, and back. Or if you're in a render-farm situation, you may need to TCP-send the data to the remote computer before that computer can move forward with its rendering).

And of course: all of those need to be balanced out with the featureset of the underlying program. Anyone can make a fast "sphere-only" renderer/raytracer, but Blender supports many different types of meshes, NURBS, and other features, which is probably the bulk of the complexity.

-----------

The depreciation of the OpenCL kernels is a bit sad, but understandable to anyone who has actually worked with OpenCL vs CUDA vs ROCm. The OpenCL kernels in Blender are particularly weirdly coded, so throwing them away might be the best option.

Blender is shaping up to be the best open source project I've seen in my 20 years of tech, and I'm comparing this with many other large ones I've used, like Linux kernel or various distros, FreeBSD, Kubernetes and so on. They do everything so well, even the releases, I think it beats the paid competition now or will soon do in feature parity and ease of use. As of Blender 2.8 the UI is fantastic.

This update comes with many geometry node improvements which continue the trend of making Blender the premium non-destructive modelling solution. I'm in particular interested in seeing how 6900 XT and regular M1 (in Mac mini form) will perform under Metal with 3.1 and macOs 12.3. I was a long time Radeon VII user on Mac but before 3.0 the stability and performance was just not there so I've moved my Blender experiments to Windows and Nvidia which works spectacularly but I'm not fussed about booting win just for Blender. Sadly I don't think AMD is bringing HIP for their older, pre-6000 GPUs https://code.blender.org/2021/11/next-level-support-for-amd-gpus/

This is a relatively tame update, but the roadmap for the near future is really exciting, with stuff like Simulation Nodes (which already has a usable experimental branch) and Blender Apps (https://code.blender.org/2022/11/blender-apps)

I'm not a programmer so I struggled with the fundamental concepts a bit when learning Geometry Nodes, but it's been the best new addition to my life in a long time. I think I haven't watched any TV show in a year or two because I prefer to spend my time fiddling with GN and answering people's questions about it on Blender Stack Exchange (found out that it's a fantastic way to learn—they're like little prompts leading you to discover areas you hadn't even realized existed). Blender community is so big, creative, enthusiastic, and helpful—you go on Blender-Twitter and it's people making playful/interesting stuff all day and sharing how they did it. I can't stop gushing about it to anyone who'd listen.

To rotate the view in SolveSpace, you need any one of these:

* a keyboard's shift key and a right mouse button, or
* a middle mouse button, or
* a 3D mouse.

I've done some work in SolveSpace with a Wacom tablet, by binding the stylus's buttons to the middle and right mouse buttons. SolveSpace is a pretty simple program, so you don't need to dig deep through the UI to get to all the functions. Lost of the often-used functions have keyboard shortcuts, but I don't think there is anything that is only accessible through the keyboard.

Depending on what you aim to do, you might be interested in keeping up with Blender's currently-in-development tablet mode:

https://code.blender.org/2025/07/beyond-mouse-keyboard/