just finished implementing the shadows for skinned meshes. Ok the shadows for sunLamp and spotLamp, now we are working on the shadows for pointLamp
You can also create new bricks logic containing that sophisticated features.
Visual scripting is not exclusive, you can also code.
This is clear for what people the engine is adressed.
I donāt have issues doing code for specific things, but i got some minimal expectations, for example a good level editor.
Iāll wait until Sabge gets released and propose a level editor, it could be a very interesting game engine.
Does the engine already supports light probes for materials rendering ?
Do you plan a global illumination ?
Something like Blender irradiance volume baking, or something more advanced perhaps.
In fact the goal is to merge the pythonComponent system with the logicBricks system
yes, I would advise those who do not have a good relationship with the code to not consider sabge until it is equipped with a level editor and visual programming system
Equirectangular maps are supported in the PBR material shader as IBL and specular reflections.
At the moment iām more focused on techniques that do not need the baking of special textures in order to have good looking graphics suitable for dynamic scenes and real time light changes.
Thanks to some useful comments here on the forum I thought to rewrite the Sabgeās lamps system. Now Sabge can manage up to 256 lamps simultaneously, just as if these lamps were common objects. Adding or removing a lamp is as simple as doing spawAsset (ā¦) / endObject (). Each lamp influences any object in the scene. They can be generated as premade assets or procedurally simply attaching to a generic object added to the scene the preferred lamp component among sun, spot, spotSquare, point, for each of these types of lamps it is also possible to generate shadows.
Later I will think about supporting other types of lampsā¦
Currently, sabge, mounts a forward rendering engine so we have to keep in mind that having 256 lamps at the same time could be heavy for our gpu!
PBR material shader and shadows improvements using Percentage closer filtering applied on the contours of the shadows only
In order to test/debug Sabge, iām creating this super mario demo. This morning i started creating the simplest of super marioās enemies. At the moment I donāt have any 3D animations for him, just this spritesā anim about the eyes that open and close, so as soon as I want to take a break from coding, iāll open blender and iāll fun creating by my own some animations for this goomba to import in Sabge. I specify that I donāt want to create a complete game, just a little number of levels in order to exhaustively test the functionalities of this ge. Iām using this demo also to make a series of tutorials that will be published when i release the first versione of this game engine. However, please donāt be in a hurry for it, Iām alone and I want to do things right, Sabge must be properly tested and accompanied by the necessary support material before it will be out
stress test (without special optimizations):
sideFlip / sideJump / airKick
(still a little bit to improve)
looks very cool. You made the music ?
Yes, i use it in my game, but i was thinking about an improved one. For exemple, when idling, the camera can rotate all around, when moving it comes behind, etc . Basicaly, linking the actuator to 1 or 2 paramters like the action actuator already does.
looking foward further progress of your engine
these more specific features at the moment do not have a high priority as they can be implemented easily by the game-dev, however as soon as I happen to write them in some demo/game, I will take into consideration the fact of writing them directly in the camera API in order to make them already available
Thank you!, the one in the video is not mine, it is a remake of a soundtrack from donkey kong (if I remember correctly) I liked it so I put it as a background for the current scenario, but sometimes I change so I donāt get boredā¦
i usually watch videos without sound, but i went back and had a listen. donkey kong had some of the best soundtracks, i recognised the tune instantly! very nice
whatās the name of that song ?
saBGE - āStand Aloneā Blender Game Engine !!!
Just to recap on this Game Engine, so its standalone rightā¦
- Well have you ever considered the thought that BGE without blender is actually not BGE? @lopas
im not teasng or being mean or anything im just trying to make sense of this engine whatās the purpose of its existence why wouldnāt it be part of blender anymore?
(This Engine is supposed to be complete because of the Blender Package!)
BLENDER GAME ENGINE - Comes and contains all of Blenderās tools that can help in creating a game that functions with the internal Realtime Game Engine! (unless you are willing to recreate all the tools that blender offered in order to provide a perfect workflow just for the standalone BGE then itād make sense that this engine would come alone without cycles or blender render)
saBGE:
To me its just another game engine and has nothing to do with blender so it shouldnt be called standalone blender game engine, if it doesnāt use BGE Source code. (saBGE could might as well just be another version of GODOT or like an āOn the RISE Unity 3Dā, and one that has BGE Coating over its name or that shares the same interface that blender had)
This project might just amalgamate into something else and be renamed, its better than to avoid the confusion with newbies coming to blender and discovering UPBGE/ BGE.
Now in the case that the API is a remake or a correction of a sort to the BGE, itās fine; im not saying that shut down your project or rename the engine, its already too late; id suggest you stick to your plan but bare in mind if you are still designing the Interface or Building upon its API pls consider using the same architecture of the blender software, because its purpose is set around being a standalone version of BGE (or this is atleast what the name entails), which itās supposed to be; but otherwise the work is great and amazing and i feel many people will use this engine in the future and make great content.
donāt shy away from Blenderās interface lol (try your best to include all the tools that kept BGE users using BGE/ UPBGE tools that unified BGE and blender and i think thatās what made BGE unique from all other Engines)
Fred/K.S
When the project began, the idea was to create a stand alone game engine whose API replicated that of the bge in many respects. So simply by combining the words āstand aloneā and ābgeā I called it āsabgeā. Actually this is what it is, a stand alone engine, which connects to blender via plugins in order to get the needed data (meshes, collisionMeshes, armatures, animationsā¦) and which under many aspects resumes the bgeās API, so it doesnāt seem to be a so inappropriate name, however it is only a name if you want to call it ālopas engineā or something else for me is equal XD
But there are some differences and additional features, if the only difference was in being stand alone, this engine just wouldnāt have really made any sense! An engine that does the same things as the bge and that also needs export - import process ā¦who could ever take it into consideration??!
Are you saying that you are using absolutely 0% of BGEās code, not even copied, translated or inspired?
Inspired I would say yes, in the sense that I have tried to replicate many functions that I used to use in bge. My gameObject class has many functions called like those you find in the bgeās KX_GameObject class and that, in the end, do the same things. A specific example could be the āalignAxisToVectā function, from the user point of view it is the same, in substance it could be different in terms of code / implementation, (but the math should be the same). I chose to use the same names for a matter of habit, and simplify the games porting ā¦I donāt think Iām infringing some copyrights in this, I say right?
Thereās a precedent where copying an API turned out to be ok. But if implementation is copied, then copyrights would apply (GPL in this case). But like you said, in some cases there isnāt too many ways to implement some things, so code is ought to look alike in these situations. I think this is like walking on a thin line, but I just wanted to make sure that you were aware
The demos look pretty good! Whatās the end goal with this project?
Thank you, if you mean the goal of the super mario demo is simply to test the engine and possibly find inspirations to implement more specific features, I know I cannot distribute nor even sell such a thing. As for Sabge instead, I know that it could hardly be interesting for many game devs atm, as it is not equipped with visual development tools. I have no particular interest in developing them as I am fine using code only, and build visual tools costs me time, for this I have created a patreon page, in case I find some support I would devote more time in this direction and therefore also to the production of
documentation, tutorials etc ā¦ Otherwise continue to invest my time mainly on the development of demos and then games.
just implemented in sabge the per_object & per_pixel motionBlur
the problem here is that by increasing the size of the silhouette (needed), even the background, which in this case should not be considered by the fx, results blurred around mario ā¦ Iām thinking about some solution, perhaps using the depth buffer ā¦
Today Iām working on the component dedicated to particles managed by the GPU in order to make it more flexible and therefore suitable for representing different situations.
At the moment Iām ok on the management of particles as physical entities: how many particles must be born per frame, particle death, physical simulation (initial linear velocity, rebound elasticity, collision bound size, etc.)
The next step will be about graphics, i would like to have the possibility of replacing these simple round and bright particles with any mesh we can import in sabge.