Armory Engine Feedback: Armory at Blender Conference!

Hello!

I started toying with an idea to build an alternative game engine based on Cycles nodes, in a form of add-on. I have been slowly getting further, and implemented physically based rendering now.

I am looking for some feedback from Blender users, to find out if this would interest you. If you are an unreal/unity/etc user, what would make you consider trying out different engine? What is the killer feature that you would need?

This may not be an ideal place to gather feedback for this project but I suspect there is a higher interest for game development around here:)

Including some screenshots below!

Physically based material test, showing spheres with varied roughness and metalness.

Realtime render of the Cerberus gun.

Rendering of PBR materials exported from Substance, I would love to move the material painting/design phase to Blender itself too - can anyone provide info on current state of PBR in viewport? That would be a key to loads of new cool possibilities with Blender.

Attachments




2 Likes

Is this BGE or…?

will it use the same logic? only diff is cycles node materials?

I would definitely at least give it a whirl :smiley:

It is not built on top of BGE, here are some reasons for this:

  1. It can run using standard Blender as add-on, no need to provide a separate build - faster development iteration.
  2. The obvious one, portability. The core used here can run on desktop, mobile, web and even consoles. It is possible to add new targets without rewriting existing codebase.
  3. This project is not tied to OpenGL. There are lots of different graphics APIs now, in order to maximize portability and performance on each platform the engine needs to take advantage of this. There is support for OpenGL/ES/WebGL, D3D9/11/12, Metal for iOS and the recently released Vulkan is already in progress(will likely become well represented on Android).
  4. Shared content pipeline with other well known engines. The engine is using metalness PBR workflow, which makes it possible to exchange content with Unreal/Unity.
  5. Programmable render pipeline, meaning a render technique can be easily exchanged. The engine is not tied to classic forward renderering - you can switch to deferred or build your own. You can choose one based on your game needs, or switch it based on platform.

This is all mostly catch up to modern engine standards, but I believe the shared content creation/game building workflow the Blender integration offers is well worth the try. If you are as excited as me for game tech I would love any kind of help on this project. :slight_smile:

Could only embed 3 screenshots in the first pots, some more here:

A look at the material system: albedo, metalness, roughness, normal and occlusion maps can be included or a value can be set instead. This is known as metalness pbr workflow. It’s a regular Cycles material, meaning that what you see in the game and what you render using cycles looks (mostly) the same. Once the pbr viewport is out, this should be even simpler.

[ATTACH=CONFIG]424843[/ATTACH]

The second system is for composing render pipeline. Below is pictured a deferred renderer - create a gbuffer, draw everything into it and process lighting in the final pass. This makes it easy to switch between forward/deferred or other render techniques. It is possible to also reference world nodes from here, which is useful to draw an environment map. I am thinking of a support to reference simple compositor nodes for post-processing rendered scene. There is no need to alter this, standard renderers come as default.
[ATTACH=CONFIG]424844[/ATTACH]

Small example of game logic nodes. In this case the nodes move target object on the X axis using sine value, and rotate it around Z axis. This is the visual way of composing logic, the other way is usual code programming.
[ATTACH=CONFIG]424845[/ATTACH]

Feel free to discuss anything that comes to mind!

It is not built on top of BGE, here are some reasons for this:

  1. It can run using standard Blender as add-on, no need to provide a separate build - faster development iteration.
  2. The obvious one, portability. The core used here can run on desktop, mobile, web and even consoles. It is possible to add new targets without rewriting existing codebase.
  3. This project is not tied to OpenGL. There are lots of different graphics APIs now, in order to maximize portability and performance on each platform the engine needs to take advantage of this. There is support for OpenGL/ES/WebGL, D3D9/11/12, Metal for iOS and the recently released Vulkan is already in progress(will likely become well represented on Android).
  4. Shared content pipeline with other well known engines. The engine is using metalness PBR workflow, which makes it possible to exchange content with Unreal/Unity.
  5. Programmable render pipeline, meaning a render technique can be easily exchanged. The engine is not tied to classic forward rendering - you can switch to deferred or build your own. You can choose one based on your game needs, or switch it based on platform.

This is all mostly catch up to modern engine standards, but I believe the shared content creation/game building workflow the Blender integration offers is well worth the try. If you are as excited as me for game tech I would love any kind of help on this project. :slight_smile:

Could only embed 3 screenshots in the first pots, some more here:

A look at the material system: albedo, metalness, roughness, normal and occlusion maps can be included or a value can be set instead. This is known as metalness pbr workflow. It’s a regular Cycles material, meaning that what you see in the game and what you render using cycles looks (mostly) the same. Once the pbr viewport is out, this should be even simpler.


The second system is for composing render pipeline. Below is pictured a deferred renderer - create a gbuffer, draw everything into it and process lighting in the final pass. This makes it easy to switch between forward/deferred or other render techniques. It is possible to also reference world nodes from here, which is useful to draw an environment map. I am thinking of a support to reference simple compositor nodes for post-processing rendered scene. There is no need to alter this, standard renderers come as default.


Small example of game logic nodes. In this case the nodes move target object on the X axis using sine value, and rotate it around Z axis. This is the visual way of composing logic, the other way is usual code programming.


Feel free to discuss anything that comes to mind!

PS.: Yes, I think the term pbr is vastly overused too!

1.what is the licence?

  1. is it fast enough on the render for game development with a complex environment?

  2. will it use python as a scripting language?

Will this game engine have good support for destructable environments and openworlds?

So…:eek: this is absolutely amazing, Blender Cycles game engine- with the quality and speed as the Unreal engine that would be wonderful.
Thanks to lubos for such a great job!!!

First of all, thanks for your work.

Some thoughts:

  1. The ‘Cycles Game Engine’ is a misleading name as I would expect something like Brigade with real-time pathtracing.
  2. Developing a game engine alone in most of the time is a dead project without writing a single row of code, especially when there are industry-leading solutions for ‘free’.
  3. Check the feature-list of UE, Unity. Make calculations how much time needed to implement what they have today.
  4. Building anything ‘on the top’ of Blender means that you are tied to OpenGL, at least in the development process.
    It means that you could only have a ‘slow’ editor at the current state for huge projects.

Here is what I suggest: work together with others on the PBR viewport implementation. That is useful and necessary for Blender and gives success at the end.

Are you using a premade render lib with support for OGL/DX or you code one? Is there a git to look at the code?

Many people want other things, besides what you want,

go ahead and code the viewport branch yourself bub.

Well I am keen to see this. Let me know when I can try it.

@BluePrintRandom

'Many people want other things, besides what you want,

go ahead and code the viewport branch yourself bub.’

Wonderful comment you had, but I don’t think you should be the ‘voice’ of the author.
As he was interested in opinions, I tried to help him with pointing on some problems, but thanks again, your comment was very helpful and productive;)

I’m glad I could be of assistance, now scurry off and code what you want :smiley:

‘This is exactly the kind of response I get when asking if a blender/BPY feature could be ported to bge.’

so I guess I should be nicer.

@BPR

‘I’m glad I could be of assistance, now scurry off and code what you want’

The problem is that you gave an emotion-driven answer what was simple not useful at all.
The poster asked for feedback, I gave him feedback based on facts.

See the difference.

If this is going to be built into Blender the same way the BGE is (only with everything being node-based), I don’t see why there has to be a duplicated effort in terms of graphics code when there’s a chance that the engine can simply tap into the code being written in Hypersomniac’s branch (which is based on the exact same concept).

Case in point, the BGE already does something like this (in that it simply uses the same GLSL code as the viewport when the render engine is set to Blender Internal). However, you can disregard the above if the Blender part simply manifests as an interface to a standalone application since it would need its own code for everything anyway.

Now for the thread in general, it will be interesting to see if he can manage to make this into a full replacement of the BGE complete with a more permissive license (to the point where the existing BGE can simply be jettisoned, but that depends on whether or not it’s an open source solution as opposed to a commercial one with a pricetag and maybe a ‘free’ version).

  1. The Blender integration is licensed as GPL(obvious), the engine core is LGPL right now. The intention is that if you fork it you have to make it public so others can benefit from it, but you can do whatever you want with the created game. I am not a licensing expert but the goal is to base it on these two points.

  2. Would love that! A solid base is done but still lots of work ahead. The system is inspired by Horde3D engine which is no longer maintained but was generally well designed. (Urho is another one inspired by Horde)

  3. I was thinking about this for a long time. There is no Python support right now and I am leaning towards not putting it in. Most Blender people are familiar with Python, and I actually love it too, but don’t feel it is the best choice here, as it could lead to performance and portability(critical parts) issues down the road. There is BGE with Python, so it is good to offer a different approach here. For high level there are logic nodes, for ‘lower’ level there is Haxe(at C#/Java/etc level) - people can be sceptic of languages but it is a key to superior portability which I want to maintain. Both of these can be combined. C++ can be used for native targets if desired.

PS: We chatted at mailing list about texture painting, thanks for helping out there!:slight_smile:

Destructible environment - would welcome help on this one, open worlds - one of the priorities, I love those too!

These are great points actually which should be mentioned too!

  1. The intention was to express it is node based and offer a familiar name, but I see this can be confusing. If confusion will continue the name can be changed, also if Blender Foundation would rather reserve the name then I will rename it too.

  2. I agree. On the other hand I don’t want this to be solo project. The core tech which engine builds upon is not developed by me - this handless all the low-level stuff, shader compilation and more. The Blender already offers a stunning editor with loads of features that can be leveraged, like nodes, managing content etc. And last but not least, I started this topic to see what do people think, and get more people on board if they are interested. :slight_smile:

  3. Yes, chasing a feature list of those giants is a dead end. But offering different workflow could be worth a try. What I liked about this idea is the common ground for complete game creation. The ability to run a standard Blender add-on and generate content directly into the game, adjust rigged models on the fly,… The Blender ecosystem is huge, and the idea is to live in harmony with it and contribute to it. Bear in mind that the giants have problems on their own(still not ideal HTML5 support, Blender feels way more smooth than UE editor, simple projects have big sizes), lots of things are constantly evolving in 3D rendering and they are just ‘free’ as you mention.

  4. The editor is built on top of Blender, but the core renderer is separate from it. That is intentional so the game renderer is not tied to Blender development, as Blender has different priorities. Im fine with Blender providing editing capabilities using OpenGL, but the game itself needs to be as portable as it gets and utilize the fastest technology available on the target it runs. In other words, PBR viewport implementation is the thing that this project desperately needs too. It needs it to improve editing experience. The game renderer is not tied to this.

The low-level lib is pre-made (although I like to contribute to it too). The higher level rendering is then handled by engine. I am still wrapping up the sources but if you are a developer and want to have a look just PM me.:slight_smile:

The case is this one. Hope the explanation in previous answers serves well:) In short, I wanted to keep engine development flexible and independent, as Blender has own set of priorities and its goal is not to chase Vulkan/D3D12/Metal implementation and latest realtime rendering techniques.

Now for the thread in general, it will be interesting to see if he can manage to make this into a full replacement of the BGE complete with a more permissive license (to the point where the existing BGE can simply be jettisoned, but that depends on whether or not it’s an open source solution as opposed to a commercial one with a pricetag and maybe a ‘free’ version).

Hehe you can just mention me directly, also if anyone has any questions don’t hesitate to reach me out anywhere:) I would rather not try to replace anything, just offer a different approach. The licensing is explained in the first reply, want to stay open-source! I am looking for ways to fund development to keep moving fast and hopefully engage more people. If anyone has ideas on this front let me know. Obviously a solid set of demos will be needed first, which I am working on:)

Including some more stuff!

A small demonstration of 3D physics, recorded a video here.


Basic particle system just emitting balls, rendered using instancing.


Preparing a vehicle physics demo, it is already working quite well but work on the environment is needed to make it more interesting. Not my strong side - if anyone is able to spare some time to design a race track reach me out! :evilgrin:


You should to try to understand and impliment BGFX rendering library.

As mentioned, the engine is already built on a library which does exactly what BGFX does. :slight_smile:

Edit: To expand it a little more, the libraries this project is based on(Kore and Kha) offer the native capabilities that BGFX does, but also have first class HTML5 support(no emscripten) - the web/javascript world is too big to not take it seriously now. Another plus is that it aims to provide generational graphics apis design - that means we can write rendering pipeline that is suited perfectly for OGL/D3D9, and the other one for Vulkan/D3D12/Metal.

The name is indeed confusing. Since Cycles is a ray tracing renderer, I was first confused, because I expected some kind of a ray tracing solution.

However, what I have seen so far looks pretty good. Well done!