You aren’t wrapping a GPL program, you’re wrapping your own project file which is not covered by GPL.
I’ve been using BPPlayer for over 5 years now and he’s been able to solve every problem I’ve encountered so far. Maybe he won’t be around for another 5 years, but then maybe the BGE won’t ether shrugs
Thanks for the info sdfgeoff. I do believe he’s made the right choice. Someone wake me up when 2.8 comes out :]
. His “Interactive Engine” is a layer on top of the viewport and blender depsgraph that allows user input, timed events and so on. All of the rendering, the animations, the modifiers, everything from blender itself will be part of the GE. And really, why does the GE need it’s own renderer and depsgraph? If the one in the viewport isn’t fast enough, isn’t it better to work on improving the ones in blender than to maintain a separate one? In this way, we ensure that the experience using blender is as fast as possible
Here is the main concern. Can you make a great game engine from a renderer/depgraph not totally focused on real “real-time”?
I think that interactive engine will be a great step for interactive scenes but it wont be a real game engine.
The same technique is used in game engines like Unreal and Unity where it is considered real time. I don’t see a difference there. Of course, Eevee is still early in development and is still going to be optimized. It also has future potential which should significantly help the performance, e.g. by using Vulkan.
When it comes to real time applications, the creator always has to make sure to reach the performance target and adjust or simplify the content accordingly.
Totally agree.
But if you look at current development and architecture of BGE and Blender as a tool, then Ton`s idea of future BGE makes sense in long-term perspective.
What I mean is the way how BGE currently works from technical aspect - Blender and BGE are two separate “organisms” controlled by one UI.
The new approach where Blender=BGE keeps game engine up to date whenever there is a change in Blender, without having to code same thing twice to maintain consistency. When developers or artists make something new for BGE it will benefit Blender aswell (and vice versa). I think the idea of blurring the gap between interactivity of a game engine and 3D toolkit is a great idea. This is where the whole industry is going anyway.
There is a downside to this though. Blender and EEVEE is favoring quality over performance, so eyecandy>framerate. EEVEEs task is to provide physically accurate shading and lighting whereby other game engines use more optimized approximations. On one hand this means that BGE-evee will have graphics no other game engines can offer (perfect for real-time scientific simulators), on the other hand, youll need to adjust the quality slider way down to keep 60fps. So here I see UPBGE guys squeezing in as they are working on getting Eevee engine into UPBGE and they are optimizing shaders and approaches for much more interactive use.
Just to be clear, BGE has been a special toolkit for me for over 10 years and there is nothing like it anywhere else. But I have never put BGE in same box with UE, CryEngine, Unity, etc., if so I would have already switched to other game engine. There is no point with competing with those, so the best decision is to go hand in hand together. So in future I see making a complete game in Blender, and it is your choice to play it there or export it to other engine (with all the logic and materials) and publish it for any platform.
I think BGE in future will be great for what it is already - a tool for doing fast prototyping, making simple games, product and architectural visualizations, animated movies, scientific research projects and of course VR experiences.
And I am perfectly fine with this.
There´s is nothing preventing the UPBGE from becoming a permanent fork (ie it´s own entity with DNA in common with Blender). In fact, that might open up more possibilities for the UPBGE team (like stripping away functionality redundant for a game engine and make it more specialized)
That´s just one consideration.
Performance was always an important factor during the development of Eevee and nothing indicates that this is going to change. The same is true for the dependency graph. From my point of view, neither the dependency graph, nor Eevee differ very much from how things are handled on a technical level in game engines.
Could you maybe clarify what you mean with that?
the biggest issue I see is there is no precomputed sample grid nor a node or texture slot system to handle lerping samples
(reflection maps or global illumination light probes)
this hurts EEVEE and the old render.
heavy links ahead
modern technology has already started to blur the line between offline rendering and real time
and recent machine learning development has even came up with AI that can predict results for global illumination, smoke, fluid etc leading to huge savings on precious time for this kind of heavy computations
. Data-Driven Synthesis of Smoke Flows with CNN-based Feature Descriptors
. nvidia AI raytracing in real time
although unrelated to graphics but to give some sense of perspective on the exponential growth in the area of general AI, last year I learned that DeepMind’s AlphaGo beaten a human champion(Lee Sedol) by 4-1 and just a week ago I learned their new AlphaGo Zero beaten that AlphaGo by 100-0 gulp
at this rate of change, I’m sure I won’t be concerning myself with frame rates and performance of EEVEE nor my game in the near future lol
The links about the state of the art stuff is all cool and well, but usually rather useless. To give an example, NVidia has shown breathtaking physics simulations years ago where water and rigidbodies interact. As usual, there is always quite some hype about it. That was several years ago and I haven’t seen a single game yet which actually uses this kind of technology. There are many other examples like this one.
-See people, Martins is still alive! It’s incredible.
The Shader Master, is back…
Ton: Remove the Game Engine? Naahhhh
@WKnight02:
Making the GE more integrated with Blender is nice, but having the possibility to export the game will always be a benefit,
Yup, I probably shouldn’t have put my speculation that export may or may not exist in the first post. It was pure speculation, and wasn’t useful. I won’t remove it now though, as a couple people have mentioned it and so it would look strange.
But, it may well be that someone does write an exporter for the interactive engine - it will just contain most of blender!
@Nick Manchul:
Not quite sure what you’re on about in most of your posts here. And I would not have been surprised if Ton had decided to remove the GE. We went into that meeting expecting to leave five minutes in with a “nup, let’s find something else”
@Ace and BPR:
GPL discussion has it’s own thread stickied in this forum. I doubt GPL will change - as using blender’s depsgraph impies it uses blenders code implies it is GPL.
@billyzill:
Blender’s main target is animation and renders - not games/interactive content.
So, if I’m seeing reading it right, the codebase we refer to as the “Game Engine” is going to be “Repealed and Replaced” in the near future. What looks like it will be replaced with, though, should be the biggest concern of all. The main part is this: Will we still be able to make “games,” with it: …
I don’t see why not. Not all interactive content is games, so I understand your concern, but the impression I got is that that games will still be able to be made with the new system.
Here is the main concern. Can you make a great game engine from a renderer/depgraph not totally focused on real “real-time”?
Bear in mind that the depsgraph is intended to run the BGE viewport, which is at least firm real time. User of blender aren’t going to tolerate click - wait three seconds - see response.
Also, just because you can change the subsurf level while in-game doesn’t mean you should. There will be operations which you shouldn’t do while the game is running if you want to maintain 60FPS. Also, it’s a multithreaded depsgraph, so it will be better than the single we have in the GE currently…
@martins:
Thanks for dropping by.
Blender and EEVEE is favoring quality over performance … So here I see UPBGE guys squeezing in as they are working on getting Eevee engine into UPBGE and they are optimizing shaders and approaches for much more interactive use
Yup. It seems to me that they are focussing on the BSDF matching at the moment, and will optimise later/soon. I sure hope so, as changing materials takes upwards of 30 seconds to recompile shaders on my laptop. Once the shaders are compiled it seems OK though - although performance isn’t stellar.
I had a look the other day and there seems to be a documentation on a method for using EEVEE shader segments inside custom shaders. So hopefully using shadows and such inside custom shaders will be a fair bit easier…
There´s is nothing preventing the UPBGE from becoming a permanent fork (ie it´s own entity with DNA in common with Blender). In fact, that might open up more possibilities for the UPBGE team (like stripping away functionality redundant for a game engine and make it more specialized)
Indeed, but it will quickly become a maintinance headache. 2.8 completely replaces a lot of parts of blender, and to keep BGE up to speed across that jump will be quite hard - but I hope the UPBGE devs do manage it, as a replacement GE is still at least a year away.
Performance was always an important factor during the development of Eevee and nothing indicates that this is going to change.
I hope they can reduce the compile time somewhat. My system isn’t that old, and the time spent compiling shaders makes any sort of iteration on materials extremely time consuming. Mind you, I don’t think my laptop meets the suggested specs - it’s in integrated card and doesn’t support modern OpenGL versions.
@Ace and BPR:
GPL discussion has it’s own thread stickied in this forum. I doubt GPL will change - as using blender’s depsgraph impies it uses blenders code implies it is GPL.
GPL does not cover external data loaded into the EXE
(like BPPlayer)
those files are whatever licence you choose,
people sell bge games on steam this way right now.
think GPL Socket -> non GPL cartridge
Socket will work on any cartridge
end of discussion.
(external files loaded by BPPlayer are not subject to GPL as they are loaded using shared memory space)
just like the way many addons use compiled binary that avoid gpl)
Really great write up about the situation 
Blender and EEVEE is favoring quality over performance
(Speculation warning)
This was a prominent theme from the eevee bcon17 talks, developers seemed more concerned with good looking renders rather than making any compromises to allow for better performance (as other game engines do).
This already suggests a divide between the 2 which cannot be bridged without significant optimization or someway of enabling a ‘realtime’ mode with lower quality (including the compromises the devs don’t want).
Let alone trying to export and run on mobile or shader compilation times when loading a game.
I wouldn’t be expecting a fully functional game engine competitive with UPBGE until late in the 2.8 lifecycle, but I would like to be proven wrong.
In the meeting with Ton, Clement (the Eevee guy) was also present. During the talk, Ton made reference to the performance/appearance tradeoff, and hinted they had received a lot of feedback about it. As such, both Ton and Clement are aware of the issue, and while they did not state it as such, it appears that both of them want the performance to be better. Ton also pointed that Eevee is still relatively young.
From this I speculate that performance will probably be worked on before 2.8 is released. And given that the newer GE is some way off, it should be fast enough by the time we use Eevee as a renderer.
I guess we can only take the game part by the words alone… But I’m still really concerned about this part.
My reason is how the BF developers have heavily shunned this community, which primarily uses the current engine mostly for games. They have equivocated their plans about this engine years on end against our current userbase. The “interactive” part they’ve emphasized to so much of a degree, but I rarely see the communities actually use it beyond the games part. It’s as if they want our users to use it for different reasons (i.e.: Not for games).
I think there is a way to add trust to us that yes, we can make the games like the ones we’ve made already: If the “interactive mode blender game engine” (Maybe we should initialize it as IMBGE) isn’t ready to replace the current one before 2.8 is released, the Foundation should just merge the progress of the UPBGE anyways.
Sure, it would only be a temporary measure, and the UPBGE would be removed once IMBGE is done. However, this would be proof the the foundation actually cares for its user’s needs of the engine, and that the UPBGE would serve as a “check” to show what features the IMBGE would need to bring the userbase as a whole to use it for their purposes - which seems to be primarily to make games right now. 
The interactive mode was suggested because there was barely any development taking place in the game engine. Bringing them closer together was the only chance it had at that time to keep it alive.
The Blender Foundation is interested to work with the UPBGE developers. As far as I understand it, the goal would be to merge UPBGE and replace the BGE and then steadily improve that and bring it closer to Blender, making it the interactive mode. That’s certainly only possible if all involved parties collaborate on that.
I have no idea why there should be a trust issue. Thanks to Ton’s commitment, the game engine still exists. There were several remarks from developers in the previous “Developers: Ask us anything” where they at least hinted that they would prefer to remove the game engine.
As much as that may be ideal, the information given to us paints a very different picture:
As can be seen in the quote at the top, Ton was extremely surprised when we posited the idea that the GE was going to be removed. So at the very least, blender will continue to contain a real-time engine. However, he is aware that the GE was written a long time ago, and hence he wants to create a new game engine. To distinguish it from the old game engine, he called it (in his roadmap post) an interactive engine.
The way this is worded, the developers just want to create a new engine that has the ability to gain all the technologies blender already has. I interpret this as something written almost completely from scratch…
Maybe sdfgeoff can elaborate on this.
I personally would expect the game engine to be wholly replaced. New shaders, no logic bricks, sharing more of Blender’s code - that’s a lot of new stuff that the current BGE doesn’t have or support. It also seems like it’d be unnecessary to try to merge in large portions of UPBGE knowing you have to rip it right back out again in just a few months. It’s good to hear that the BGE might continue to exist in some form, even after all these years, though. Sharing code and being an “interactive engine” sounds like it might be a great way to go.