associating with blender would mean gpl, and he doesnt want that.
I have a question for your lighting system.
It’s a form off SSGI, so it’s only screen space, right?
So if a light source moves out of the camera’s viev it won’t be contributing light to the scene or not?
This will be less of a problem in a scene where you a huge amount of lights sources ( read > emmisive materials that cast light ), so if one moves out of the camera’s view another one somewhere else will move into the view.
BUT if you have a scene with only a few lights, because you want a darker atmosphere, will this cause problems because there are no light sources in the camera’s view most of the time?
hey! yes of course, it is an effect that is achieved by exploiting the screen space data, therefore it has its limitations. It should be considered as an additional tool to the classic (deferred) lighting system provided. For primary light sources it is better to use the classic system. The emissivity / SSGI is useful, on the other hand, for minor light sources in terms of intensity and possibly numerous (for example, candles, particles, or even large surfaces whose emissivity is not too high. In the presence of many light sources, in any case, the limitations are not very noticeable. Actually if you have a scene with only one light source that has to radiate the whole room and you choose to use the SSGI emissivity, then you will notice that limitation, but it is not the correct approach, you should use a traditional light source and then the SSGI will go to realize its bounces, (also, for some problematic cases it is possible to dynamically play a bit with the general ambient light or use classic lights to simulate the general ambient light…)
Unfortunately, in realtime computer graphics, an equally high-performance solution, which perfectly calculates the lighting for you, does not yet exist…
1 Like
I’m so happy to be able to read these posts about rendering from you! : D When I cannot find whitepapers which describe graphics, I just have to guess how something was made - with this we get to hear it from the developer himself : D
Hmmmm… Seems to me like you have solved half of the equation, i.e. everything that is in front of the camera, with really cool emissivity to boot! This is basically perfect for most AAA games - in most games nighttime is basically just a blue “sun” instead of a yellow one, so there is lots of light in screenspace even during the dark hours.
Jovlem’s post makes me wonder though. Perhaps the technique could be augmented, by rendering things outside the camera at a drastically lower resolution and virtualize bounces from that. Sort of like a minimalistic biased reflection probe.
Edit: Clarity.
Thanks for the nice words. what you say could be feasible but at what price? Here are used many buffers that we already have available, the depthBuffer and the normal buffer for example, but not only. Calculating new versions of these buffers for the data outside the camera frustum has a considerable cost. And in any case, even assuming you have these extra buffers ready, the calculations to achieve the GI would increase.
Wow I am missing your thread for your dev, lopas you are very good ! ^^
If I understand you don’t want to make GPL, why you don’t make a rewrite to make your game engine as closed source ? Can you make your own game engine from inspirartion of Godot ? It is MIT license 
so are you looking for it ?
Otherwise Good luck and keep it up ! ^^
Me too I wanna to make my game engine from Blender to make a “BGE 2” in more modern but now i still am studying for C, C++ and Python ^^ so I will make freely to everyone (GPL of course!)
Hello , thank you, when releasing a game, you may be forced to release the source code of your game if your scripts use GPL licensed modules (all modules of the bge/upbge practically… bge, mathutils etc…) So I want sabge not to use GPL libraries, to give the possibility who creates a game to decide whether or not to release their sources. Consequently Sabge will have to be closed source in order to guarantee the protection systems (encryption) applied to the games that are not open source.
Good luck with your studies too!
In other words: GPL is so “free” that you are forced to keep it free.
Therefore, in order to avoid to be forced, you have to get to a restricted license to give real freedom to users.
Unintuitive but real!
GPL is not a good license for a game engine, it is way to restrictive for that particular use case, if you want a truly free license go for a MIT type license instead.
here is a good example:
Ok I have read the license GPL 3, it can be make even in private use, sell in commercial but at the same license
You can’t make only closed source cause Blender itself is fully GPL in whole source code with other license addition too.
As I said you need to create from scratch your closed source without depend to Blender… Same to edderkop, your only option is MIT license you can make whatever your project 
Sabge is actually built from scratch, it doesn’t depend on the blender source code nor was the blender source code used to write the sabge source code. My problem only concerned the mathutils library that I had integrated into the project as it is covered by the GPL license, but now it has been replaced with my own, so the problem is solved
1 Like
Great ! Got it
So you want to sell your game engine ? Or it will be free ?!
Keep it up lopas ! ^^
I wonder if you’re still planning to integrate this tightly with Blender, because its use of the term ‘bge’ tells people that the entire process of exporting the scene and launching the engine will happen just by pressing ‘P’.
The graphics look nice, but do note that an engine is a lot more than just graphics, people don’t want to make tech demos or walkthroughs they want to make games.
One final note, I would be very cautious about using Mario in your promotional material, as Nintendo has a reputation of being incredibly litigious over any use of their characters (even a one level demo can get you a note from their lawyers).
3 Likes
The engine will simply be called “sabge” as an invented word that means nothing, so there will be no explicit references to the bge, meaning that the term “stand alone blender game engine” will no longer exist. This is because many things have changed from what was the original idea of the project and also to avoid misunderstandings since I am in no way linked to the sources of the bge.
It will simply be an engine whose API will resemble that of the bge in many respects and which will exploit specific plugins to exchange data such as meshes, armatures, animations, etc, with blender.
Then we will use the editor I am developing to actually build a game.
From this point of view there is no need to worry, at the level of logic and physics you can do everything you do with the bge, indeed I feel safe in saying that some systems such as that of the animations of the characters, or some things concerning physics are certainly better than those implemented in the bge (or at least that’s my point of view)
This is something that I have already heard often, but until I distribute a game, or sell the game engine using mario to promote it, I do not think I take any risks. I’m using the super mario character just to do some personal tests of game engine and nothing more 
@lopas
That’s great you advanced as far this great little engine ( and great to see there will be any GPL license terms unlike Upbge)
I’m working on commercial stuff, but i would be happy to try making a small game using Sabge on my free time 
Does it have some game objects system we can stack to make sort of prefabs ? Or it is not necessary ?
Do you plan some level editor helper ? For example expose variables scripts with UI inputs , sliders or buttons to edit values ? perhaps scripts are sufficient ?
Keep up the good work 
About the level editing I’ll take the simplest way for the moment, so there will be a blender plugin that simply exports instance files.(pos,ori,size) so a sabge’s scenario will read these files and performs the spawn of the assets associated.
This way you will be able to create the scenarios for sabge using blender and a bit of logic.
For the logic I am writing the node editor which will be useful for creating prefabs objects too (i call them assets).
I started working on this editor a few days ago so I’m still a little behind. I was playing experiments on the appearance of logicNodes…
… it is not a new thing for me, I had already done it in java so I should be able to proceed quite quickly…(i wish ^^)
This was the old one in Java. I just have to rebuild it in Python developing my own GUI system using openGL this because I want the editor to be able to directly read python scripts (or python + c) which also contains the data needed to visualize the node inside the editor.
1 Like
Nice to finally see some of the engine’s UI, keep up the great work
WASD for nav
middlemouse for panning
mouse wheel for zoom
Q/E keys for smooth zoom
right mouse:select/deselect
MKey: minimize/expand node
GKey: grab node (move node) (like blender)
…these are the commands made so far
the node builds itself (procedurally) when adding/removing sockets and at the same time changes the shape of the collision
added support for different themes
1 Like
sabge’s logic nodes editor - day 4
3 Likes
The editor is almost finished, I have implemented the functions for saving and loading the networks and I still have to make the system to export single nodes as custom logical components after code injection.
I optimized the rendering system, using a fast 2D frustumCulling and a LoD system (according to the camera zoom) for the nodes viz
Furthermore, the window updates only when a command occurs or for some frames after we have given a command.
so i think / hope this editor will be light enough for any computer
3 Likes