Could Eevee Next allow for consistent 60fps again?

Game Engine Game Engine Support and Discussion
1

TLDR: In 2.79 you could run a complex armature, put in a lot of geometry, and have no performance drop due to the fact that the render engine was optimised for performance. The Eevee engine we now have allows for beautiful graphics, but at the cost of laggy games, and no amount of sophistication in CPU power can help. Only a complete rewrite of the render engine would allow for proper 60fps again and smooth performance while being easy on the player and to work with. This could happen with Eevee Next.

Long version: 2.79/0.2x used a less powerful, but more optimised rendering engine that prioritised speed over graphics, allowing for 60 frames, even with a very complex armature and CPU-based skinning.

In 3.0, performance regressed very sharply due to a new cutting edge render engine called Eevee, which was primarily to update Blender so it could render beautiful animations with realism and advanced shaders in mind.

But the developers probably did not anticipate this would be bad for a game engine when putting the render engine in, but since they had no choice, they put it in anyway since they have to build UPBGE from Blender source code. The UPBGE internal player (and it’s external player), are based largely on Blender 2.79’s code, and must be updated to accommodate the latest version of UPBGE.

The combination of a sophisticated render engine designed solely for animation rendering, and a player that dates back from 2.79 puts a major strain on performance, since the original Eevee was never designed to be used as a game engine. Combine the extreme slowdown of bones in Eevee, and the result can be a flipbook-like experience.

But with Eevee Next, this could maybe change. GPU-based displacement is coming, which could result in a large performance boost. This won’t completely eradicate the performance problem - armatures will still be an issue with the current implementation of the modifier. Eevee Next could also change other things which will allow for a lot more performance improvements too.

And lastly, openGL. This outdated language is likely the reason for UPBGE’s extremely variable performance. While it will be changed to Vulkan/Metal in the future (possibly 4.0?), this will come at the cost of not being able to write openGL shaders anymore, so we will likely need a different shading language for writing with. But it will help increase performance a lot, and for the first time ever, UPBGE will be able to take advantage of M1/M2 chips using Metal, which will make it more like Unity.

1 Like
2

As Blender is a DCC creation app, and not a game - I fail to see the connection. Quality of render output is more important than max live FPS playback in the viewport.

Yes, I’m aware of UPBGE; perhaps whomever is in charge of that fork is the person that game authors should be lobbying, to fork/rewrite the renderer to work better for game purposes.

2 Likes
3

“Realtime rendering” is the scope of blender 4.1 project

we have also the potential for baked animations,
GPU armature skinning is the biggest missing feature we have in 4x and beyond atm.

4

Some of us have been trying to tell the UPBGE guys this for years, the response I get every time is that UPBGE will hopefully become fast enough to be viable by the time your project is ready to ship. It is a shame because the BGE always had that potential due to its zero I/O nature (just press P, could it be any simpler)?

Instead, it is the Godot engine taking the crown as the engine of choice for those who want to stay with FOSS. It is also not the fastest out there, but the renderer was created with games in mind, and it does show. Much of the UPBGE userbase actually uses the older version with the renderer based on the work done for Yo Frankie! (before it was replaced).

5

the thing works really well right now and its supposed to get quite a bit faster
(non blocking render soon also!)

this is using heavy volumetrics and 4 blur nodes / heavy composition

this is eevee-next*

vulkan is now testable but not usable really yet*

eevee gets more fps (40+ more) but can’t do soft shadow like eevee-next or gpu displace / global illumination

its a amazing render now and it will only get better (its technically not done even)

1 Like
6

Only problem is that I cannot get a macOS version of UPBGE 0.4. To think UPBGE cannot take advantage of a powerful processor shocks me. All the other game engines can, even Range can!

7

But, I use UPBGE 0.36.2 (It’s the only version I have on macOS), and it does not have the 40+fps improvement you mentioned, just 5+fps, which is negligible. The old render engine, even if it didn’t allow for great graphics was superior in performance so why break it? Makes me sad…

8

There is a metal version of eevee on the way, you have been told like 10-15 times.

your PC is not really using most of its power in openGL mode*
same with vulkan,

1 Like
9

Sorry. I use Apple. I should have said “Apple Silicon” as in processor. This is a very, VERY fast processor, with little power consumption. I lost hope a little bit there, because UPBGE never takes proper advantage of the processor’s power and efficiency. I don’t use a PC but a Mac instead so I will have to wait longer for UPBGE 0.4+ stable/development. A proper Mac app is designed to take advantage of the CPU/GPU and hardware like a well-oiled machine. A System on chip is much harder for some apps like UPBGE to use.

10

Mac has crippled opengl for years

Metal is the only fast way to use mac, they designed it that way.

Older macs are still handycapped.

"
When it comes to interacting with hardware, userland code can interact with a driver exactly and only to the extent that the operating system allows it.

When you talk to OpenGL on MacOS, first and foremost you are talking to MacOS. Your OpenGL function call goes into the operating system. The OS then translates that GL function call into an internal API implemented by graphics driver makers, which the OS then calls. Any results are translated from those internal driver APIs and forwarded back to you.

You never talk directly to the graphics driver; MacOS always sits as the intermediary between you. Graphics drivers on MacOS don’t contain OpenGL implementations; MacOS itself has an implementation, but part of it gets provided by graphics drivers."

11

This would explain “UNSUPPORTED (log once): POSSIBLE ISSUE: Unit GLD [NUMBER] is unloadable and bound to [variable], using zero texture as a result” perfectly.

It results in the vertex shader being unusable, rendering as either black or a solid colour as it has no texture to assign, while 2D filters are unaffected due to the fact that they use the screen and are based on GPU to create the overlay.

Integrating the Metal API into Blender as you pointed out would eliminate this issue entirely on macOS, and speed up both Blender and UPBGE and reduce crashing.

This would also help with Eevee Next’s performance gains, which is coming eventually to macOS, but does not have Metal support yet, hence the “no shader buffers” error.

Until we macOS users are able to get Metal support into UPBGE, a small amount of Python functions like ImageMirror are off-limits as they use GLSL to render the reflection which does not work with the current M1/M2 chips as they no longer are programmed with GLSL in mind. Some textures (and refraction in Glass BDSF) don’t work right either due to this, which is solvable via Metal.

While Metal does work (kind of) in UPBGE right now, it will freak out and crash due to the fact that it is not fully coded in yet, and it will take until a certain Blender version for UPBGE to fully take advantage of this pipeline without crashing.

12

Eevee Next is available for testing right now, you can do any speed comparisons you want :slight_smile:

1 Like
13

Link please :smiley: :raised_hands:

14

Eevee next is available in experimental builds because it is still experimental, so do not get too excited there are many things that need finishing. It is not in 4.1 anymore because 4.1 is now beta.
You need to download 4.2 alpha to test it out.

1 Like
15

Thanks buddy - I thought the UPBGE version using eevee next had already been released :smiley:

16

I’m on Apple Silicon, so I will need to wait. I’m waiting for the stable release because it won’t have a higher crash rate like the beta.

Not sure how long I’ll need to wait…

17

I do not use UPBGE but a quick look at their page says;

UPBGE 0.42 Alpha is based on Blender 4.2 source

That means that UPGE Alpha is also experimental, and based on an experimental build (Alpha) of Blender.

The planned release schedule for 4.2 stable release is July 16, 2024, (as long as it is not delayed) so be patient. There is a lot of work to do yet.

2 Likes
18

Thanks for the wonderful news - once upon a time UPBGE eevee was also an experimental version - now many people are doing their projects on it, even taking into account that the fittings do not give 100% performance during animations - I hope that we will see eevee next in conjunction with a volcano and good animation speed - I would also like to fix a small bug shadow rendering - at a great distance from the center of the scene, a noise appears that constantly moves, creating not very pleasant sensations for the viewer

1 Like
19

New commits that are exciting,

Pcf shadows

Fix pcf shadow bleed

Faster mesh and normal extraction

20

This is good news - do I understand you correctly that now there is no shadow noise on objects at any distance from the center of the stage and from the lighting source? before that, I tried various ways to remove this noise and even assembled a shader on the nodes, which added a shadow for my ships according to the vector from the light source, since the shadow from the sun at a great distance gave an unpleasant shadow noise