Bliss 3D Toolkit

This project has been postponed in favor of Beemo, a blend file version control system, which is a fortunate result of this endeavor ;).

Can’t wait to see the engine in action.

Side note - I probably can’t work with this as my machine is not Linux, and bullet has all the solvers I wanted to use, (The Wrectified/Jackii rig) is ran by physics, it’s a walking rigdoll.

People still use ODE (I ask because there’s been a number of applications and game engines over the last decade that have dropped ODE in favor of Bullet or PhysX, to the point where you almost never hear of it anymore)?

Also, the Linux only attribute for this engine is going to limit your audience here on BA by quite a bit. I do wonder though, why your own engine and not say, joining Agoose77 and Moguri in embedding Panda3D to the point where a person running his old project is not even aware that the BGE’s been replaced (along with his logic brick setups auto-converted to a HIVE setup)?

Yeah, I am targeting a niche crowd and I do doubt this engine will be widely adopted by mainstream for that reason and for the licensing. I actually do not see Extremis as the successor to the BGE.

That said, I have multiple reasons for this creation:

  • I needed an engine with certain specifications.

  • I want an engine that is intimate with Blender, i.e. uses its data structures.
    [LIST=1]

  • It is not practical for existing engines to adopt the blender file format so the only alternative is to write a new game engine.

  • I have bigger plans for it.

  • Ultimately, I simply have different goals.
    [/LIST]

If Moguri, Agoose77, et al. started a new engine, I don’t mind helping out. I see HIVE taking one direction and me going in another, but in the end IMHO they are both pursuits that would benefit the community. So I would not interpret this as hostile competition, but friendly competition.

Is your gameengine going to have marching cubes?It is the latest type of voxel.

Marching cubes is one algorithm for producing voxels from polygon based models. There are other techniques around, but what you’re asking for is more generally support for voxel rendering.

Planet explorer videogame uses the marching cubes algorithm.And it looks great.

Sounds like an interesting engine, just add support for Ouya. :slight_smile: Oh, yeah, only Linux and 64 bit (im still on 32bit win7). Im still curious about the license…

The licensing is (A)GPLv3. I use structs and code from Blender/BGE so it means any games that use Extremis have to be (A)GPLv3 also.

The way a user would use Extremis would be similar to Panda3D. Import the engine classes, create the engine, load blend files with it, etc. as both engines extend Python, i.e. provide a C/C++ library with Python bindings.

One of the differences with Panda3D is with Extremis all of the C code is exposed literally in Python (CFFI API-level), essentially everything except the shared libraries themselves. Panda3D uses an automatic wrapper generator. I find the CFFI method cleaner and more robust than C extensions/Ctypes/Cython/SWIG.

Voxels…that’s far away. I’ve read about them and my impression so far is that they’re overhyped. Anyhow, we don’t have the processing power to do it efficiently.

I thought the Ouya was a flop. Hey, there are the steam machines…

Progress so far:



I painted the vertices in Blender and then loaded the blend file in Extremis and used VBO+VAO+indices+shaders; really basic, but getting there.

Technical stuff:
I’m figuring out how to structure the Python classes to wrap around the Blender C structs like Scenes, Objects, Meshes, Materials etc. Once I have that in place, I can feed them into the Rasterizer.

Blend files are like portable databases so when you start the game engine you use an initial blend file as the starting database; this acts to setup the scene and world. Technically, you could also manually recreate all the C structs that make up the blend file if you wanted. Afterwards, you would load the game content like characters etc. and actually, when you load blend files (analagous to LibLoad in the BGE), it’s virtually the same as appending objects to the scene in Blender, because it is working directly on the structures.

Another area I haven’t fully explored yet is since I’m directly using the structs that also means you could modify things in the game engine and save them back to a blend file, so you could go back and forth; kind of blurs the line between the input and the output.

Note to self: VBO/VAO data could be stored in the blend file also to speed up the loading process or save it as an external file and pack it into the blend. For example, in Blender, there could be a function to generate the data beforehand and store it in the blend.

Do you have a launch title planned?

Thats all very interesting.

Panda 3D also supports Python 3 in the latest releases, IIRC, or at least will do soon :slight_smile:

Panda3D looks like a highly-capable engine with a lot of features; I’m surprised it’s not so popular. It looks like a good replacement for the BGE. Although, the API documentation is quite hideous. I get the impression they peaked around 2010 similar to the BGE (when mobile took off?). Their development appears to be similar to the BGE with a few devs (e.g. rdb) with the majority of commits. As for the foundational support, CMU appears to have moved to Unity and Disney no longer uses it. However, sometimes I think companies do this for abandoned proprietary programs - release it as open-source so it makes them look more community-oriented. Also, I think their equivalent of Dead Cyborg is Signal Ops.

The open-source gaming scene looks bleak, however I think one aspect is due to the fact that companies tend to not like contributing to permissive projects since a competitor can use their work and they have minimal incentive to, thus they never reach critical mass.

Personally, I don’t think it’s a good idea. It just seems like you’re making it for yourself and not others, because you’re restricting it to your needs, and not really others. Not alot of people have Linux, and if they do, more often than not, it’s 32 bit. That’s just my opinion though, and I would suggest attempting it and seeing how a game created with it turns out so people can see its potential.

You might say most of the users here are looking for support for older hardware, however there’s no shortage of appropriate generalized cross-platform game engines and the BGE is still around. Linux runs on a lot of different hardware but there also exists the more bleeding edge users like myself that want to push further. However, I do find it interesting how the idea of a Linux focused (game) engine contrasts with the fact that most popular game engines support Windows first and primarily, but Linux barely or poorly (until recent times).

Actually right now it is specific, since I’m using it as the foundation for a project I’m working on (for a competition). Again, the licensing is probably going to be the main issue since it directly integrates Blender source code (GPL), This saves a lot of work by not having to repeat code, but of course it’s not for everyone. However, I’ll demonstrate how much of a limitation this is later.

While I’m at it…

Latest Update:

  • Triangular meshes are preferred (also OpenGL core deprecates GL_QUADS). Since this is purely OpenGL core, every object requires a vertex and fragment shader (due to OpenGL core).

  • Still working out the renderer design. So far, shader code and programs are stored with the rasterizer rather than with each object since they can be reused.

  • Working on input module - users register callbacks

  • Implemented physics system.

  • Blender Integration
    [LIST]

  • Added the ability to create custom classes for any Blender object. Think subclassing KX_GameObject, but you can do this for World, Scene, Material, etc.

  • This and other game settings are done through custom properties (does not rely on “Blender Game” selected as the render engine).

  • Next up:

  • UVs/Textures

  • Lighting/Materials

  • Scene graph - culling

[/LIST]

My project is somewhat less demanding and doesn’t require sounds and animations just yet, so those are a lower priority right now. Also, I won’t release it until I’ve implemented a logging system and everything is fully and properly documented. The reason for this is one of the problems I encountered with the BGE was the lack of documentation, which makes software incredibly unfriendly. This idea goes hand in hand with focusing on productivity, readability, and maintainability.

Cool, make some video demo. :slight_smile:

Once I get physics fully implemented, I’ll do a video, but for now more screenshots :stuck_out_tongue:


Latest:

  • Rewrote math module based on linmath C header by datenwolf (may make this pure Python module).
  • Implemented world struct settings.
  • Created python bindings for ffmpeg library.
  • Implemented UVs/materials/textures.

Next:

  • Finish input module

  • Finish physics module

  • Refactor rasterizer module

  • Lighting!*
    [LIST=1]

  • Point lights

  • Spot light

  • Area light

  • Directional light (sun/hemi are such types)

  • Frustrum culling (this should be part of a scene graph module…)

  • More cleanup/refactor

  • Documentation/examples

  • Release!
    [/LIST]

* Lighting includes both per-vertex and per-fragment/pixel. Per-vertex is the traditional method and per-fragment the modern method, however per-vertex can be faster and per-fragment gives much better results. This seems to be less of an issue with newer graphics cards but still an issue with smartphones/tablets etc. Deferred shading is more efficient for per-fragment shading. Also, basically lighting is all done through shaders now with modern OpenGL 3.3+.

The basics are almost there. Frustrum culling is the last required functionality before release. I would like to get some debug functions in also.

What else? Technically, sound can be done in a low-level fashion through a python module right now. LOD, animations, text, transparency, shadows are in the next phase, and more advanced features like instancing, particle systems, navigation meshes, etc. afterwards. As I go along, I’ll figure out what else to port over.

I was also thinking about creating a BGE/KX compatibility layer (python level). For example, this would involve creating a KX_GameObject class that maps to functions in Extremis/Blender structs.

Something cool I saw: shape keys implemented through shaders (aka “morph targets”, “blend shapes”). :eyebrowlift:

I’d be interested to know what you needed from the engine that BGE is not providing, and why you think it is not a good idea to try to add those straight to BGE?

I fear fragmentation hurts the open source community a lot. People just go their own way. That is what freedom is all about, true, but it is not what gets things done, you know what I mean? As much as possible I’d like to see a broader group of people such as yourselves apply yourselves to one, stable, ongoing system and commit to improving it until it competes with and eventually exceeds the closed source model’s achievements.

I play this little game called “Minetest”, and it has issues that it would seem to me would have been instantly solved had they gone ahead and thought about using Blender from the get go. Obviously a Minecraft/Infiniminer etc. inspired work, the things they have done with voxels would be nice to have either in the BGE or available as a quickly applied add on rather than virtually a little game engine all to itself.

I don’t know. I just feel like I have seen this over and over since the days of all text internet games. No one seems to want to stick together and get one, excellent product going. When you get right down to it, that is what IP laws achieve. They allow investors to force people to cooperate. I do not like the aspect of investors forcing people to cooperate, but one wonders after a while if this is not why things have developed as they have. It seems you HAVE to force people to cooperate and stick to one project or else they just don’t.

Blender itself seems to be an exception to this rule, which is a big part of why I am trying to learn more about it

Anyhow, so my question was, why not just work on something that will make the default Blender Engine do what you want and perhaps offer it as part of that engine or else package it up in such a way that it easily “plugs in” so to speak?

(It might be obvious by this point that, while not entirely tech illiterate, my knowledge of coding, and especially large projects such as Blender and game engines, is quite limited.) =)

So please be gentle? HAHA!

Sounds like the dream engine. :slight_smile:

@ShaneRoach

I’m all for cooperation and collaboration, but why I don’t find the BGE viable:

  • The BGE’s future is in limbo. I interpret the BF’s actions in favor of deprecating the engine. Also, I highly doubt they would support a game engine since that lies outside its goals. IMHO, I believe the BGE is seen as that grown-up child that won’t move out of the house. As a result, the BGE essentially lies in maintenance mode:
    [LIST=1]
  • There is no doubt, the BGE needs a refactor, possibly rewrite, but this is not feasible given our resources and state of morale. The ongoing work right now is great, but it’s simply not enough.

  • The codebase is messy which makes it difficult to understand and write clean code, which is required to become a developer. Trying to build clean implementations on top of a messy codebase only adds to the problem, which IMHO is what will happen while the BGE is in maintenance mode.

  • However, turning the BGE into its own project would demonstrate its worth. I lean towards seeing this happen rather than replacing the BGE with an external engine, which would actually be parallel to that so Blender could support BGE, Panda3D, etc.

  • As a result of the above, becoming a developer is a difficult process which deters and discourages development -> catch-22 situtation.

  • AFAIK, currently only one or two people have commit rights which makes code review a slow process and I doubt that’s so fun for the developers.

  • The BGE is tied to Blender’s development process which does not allow BGE development to happen independently and at its own pace and direction.
    [/LIST]

I also have technical reasons. Originally, I created a special module for the BGE in C++, which for all intensive purposes, would never be included in trunk. At the same time, this allows me to try a different model than your generic C++/LUA engine - if I did that then it’d be really redundant.

Trust me, I didn’t want to write my own engine because I hate repetition and reinventing the wheel, but based on my requirements, in the end it made sense.

This is a secret preview of my “game”; not sure if the world is ready for this: :RocknRoll:

I’m working on interfacing this with gesture cameras, myo, augmented reality, etc. I’ll get a better video up later. Blender/BGE works also…