Armory Engine Feedback: Armory at Blender Conference!

Is there a git?

Win 64 build?

This is amazing thing. Well, it seems that 2 people have gotten to this advanced shading stuff at once, but I will not discuss this sentence any more:D

are you using bullet?

do you plan to make the swap to openCL physics?

I would love to see cycles nodes in BGE, and possibly procedural texture support as it is useful for dirt maps etc. However, how does it render the materials, CPU/GPU? The reason I’m asking is that lower end machines struggle with loading materials, resulting in texture pop-ins/slow updates which can be seen on some games made with UDK/UE4.

As an example in UE4, when creating materials, the materials could take a long time to update/render on lower end cards, it even happens when playing some UDK/UE4 based games. I’ve also noticed the same pop-in effect on IdSoftwares Rage title, which needed hacks to fix the problem.

Multiple layered materials seems be quite a hog on UE4, I’m not sure if CUDA is to process it, but it slows down the overall development. I’ve been able to get similar looking materials in BGE as it is now using some clever tricks and it perform way better than what I’ve experience in UE4, Unity however does not have this problem with it’s standard shader.

Well, this certainly looks rather good. Really nice work on the graphics side of things, and I agree with your choice of dropping Python in favor of Haxe.

How does the Haxe logic integration work?

Having issues with forums, mostly unable to post… Hope that gets resolved soon.

@SolarLune:

Thanks for tuning in, I actually recognize you from around the internets. :slight_smile: Happy to see that people are willing to use something non-python, thought that would be the biggest issue. There are still logic nodes for high-level stuff, so that may make it easier.

For each Blender object you can specify a set of traits(ie components), which can be used to instantiate Haxe classes. Using that you can reach the usual coding-level stuff. Logic nodes are also added as traits, and behind the scenes they are translated into Haxe. This also makes it easy to share traits among multiple objects easily.

I recorded a short trailer of ‘racing track’ demo, linked below. The assets are mostly hand-made, could be much improved on that front. Currently working on a video which shows complete development of that demo from empty scene, which should demonstrate the basic workflow of this engine. :slight_smile:

In game:


Cycles render:


Side note, Kha/Kore which this engine builds upon started with support for another target, Raspberry Pi. The engine can leverage that. :eyebrowlift2:

Looks really nice!

Yeah, the physics looks simple now, but already kind of good.

You should add in SSDO to realy call it Cycles Engine.

Looks awesome!
Can’t wait to try out fancy ray marching GLSL stuff there. Is there support for efficient scene FBO construction and passing?

@adriansnetlis:

It’s still Bullet under the hood, which should be hopefully sufficient to progress for now(no OpenCL yet).

I have a SSAO pass ready for deferred renderer, might try to bump that to SSDO as they are not that different. Will post some SSAO/SSDO stuff if everything goes well. SVOTI implementation in CryEngine seems to be praised these days, but that will not be that easy to pull off. :slight_smile:

@Jackii:

Thanks! You should be able to assembly any rendering pipeline using nodes, attach custom glsl shaders(which are automatically compiled based on target using a tool called krafix, to keep everything portable), render to textures(with mrt support). :slight_smile:

Using this approach I created a proof of concept path-tracing renderer. Every other part of the engine is the still same - physics, logic, portabilty etc. are in place. It’s important to note that this is only concept, no arbitrary geometry is supported, it only does spheres, cubes and planes for now. And its still noisy of course. Happy with the flexibility though. The renderer can be improved in the future independetly, but I would also like to explore mixing usual rasterized rendering with path tracing for some effects.




Any graphical effects that you find important to have which are still reasonable to implement? Maybe something along the lines of depth of field, bloom, motion blur?

Nice, nice! I wanna try this engine. What about performance? How much FPS do you get and what’s your GPU and CPU?

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

@adriansnetlis:

Thanks! Did not yet do proper performance test of path tracing, but to get a feeling you can check out this version, which I used as a reference. I am mostly developing on Intel Iris gpu, which kind of forces me to ensure engine will run on lower end machines too. You can squeeze some decent output even from integrated cards these days. :slight_smile:
http://madebyevan.com/webgl-path-tracing/

Started work on the next sample, an FPS template. Using physics, deferred renderer, SSAO, FXAA, depth of field, motion blur. Still have to do some tweaking, will prep a video once it is finished. :slight_smile: After that I will do one more, third person template and wrap it up!

Attachments


Little update, finally preparing to record a short video. Been working on the shaders, here is some new stuff.

Starting with overused bloom, vignette, subtle lens flare with occlusion and lens distortion at screen borders:

Testing volumetric fog:

Multi-material animated model, skinned on the GPU:

If anyone is into realtime rendering stuff, the process is now close to this, although obviously at much simpler scale:evilgrin:

Plan to finally set a release date in stone. Be back soon!

Attachments




Damn I am really impressed.

That looks really good! Will it become integrated with blender core when it is finished? (I.e. Put in the release download without installing any add-ons/plugins, like the current BGE is?)

Thanks guys for replies.

@Genzer:

I would be all for integrating into Blender core but it is obviously something I can not demand. Also while I am around at blendercoders IRC channel talking about small bugs, I am too ‘shy’ to even bring the topic of a game engine. Even BGE development is mostly not a priority there as there is loads of work to be done on ‘serious - non game’ stuff (I am only talking from my experience, the reality may be different). Also, this engine is not using Python for scripting.

As discussed, the name ‘Cycles Game’ will need to change at release too if it won’t get ‘blessed’ by Blender. I originally wanted to relate to Blender and nodes by using it, but do not want to make any confusion.

Still, I think game engines (ie realtime, interactive renderers) are for ‘serious’ stuff too. UE4 is now used by Nasa, McLaren, Ikea to build cool things. I believe this is the space Blender could be excelling at too. Hopefully this thing will evolve to help it. :slight_smile:

Realistically though for it to be possible to create a complete high quality game in the blender game engine or in this cycles engine, there has to be better management of scenes and assets, a lot of features have to be built into the game engine. What must be prioritized is improving upon the logic bricks or replacing them by something that’s more efficient. The blender game engine is already quite powerful graphically, diffuse, normal and spec maps goes a long way. Physically based rendering is nice but it won’t make people want to make games in the blender game engine. Because the logic bricks are clunky, the management of scenes and assets is clunky and unreal engine and unity engine are free alternatives that are much better in every single possible way.

The reason we’re not seeing any games in the blender game engine of high quality isn’t because blender can’t render nice graphics, it’s because of how badly the programming side of things are. It would be much easier for a team of people to create a pipeline around unreal engine than it would be to mess around with blend files. I have done it once myself, blend files are a mess to work with and there are a lot of features that you have to try to squeeze out of the engine that should be built into it by default. Camera collision detection, creating huds quickly, letter by letter text that’s not pixelated depending on how far or close away it’s form the camera. Reading text from text files outside of the engine. A game asset library with organized textures and models all that are possible to access from outside of blender.

Blender is a very confusing program, messy layout. I have used it for some time and I still today get confused when I try to enable transparency on a texture. It’s not in one place you have to move in between tabs and these tiny things and the logic bricks is the biggest reason in my opinion it would be better to cut out the blender game engine entirely from blender. You’ll never catch up to unreal engine and unity engine, if you can’t improve upon the logic bricks and the management of assets and scenes. Loading screens is another thing missing, when you switch scenes the game freezes, this kind of stuff is more important. PBR is nice but a dead end I’m afraid.

This is perfectly true and I agree completely. I believe things are getting better though. Blender is open, we have the power to improve it.

Why is PBR dead end though? It’s just one small ‘buzzword’ among many, many other things. I have been developing games too and if your game does not have appealing visuals, you don’t stand a chance, there is loads of competition now. It is sad but for general cases, visuals go a long way in gaining attraction of players. The engine needs to aid you here as much as possible. Also since this is now becoming a standard, you can easily utilize the same content from other engines.

For coding it’s basically the same setup as UE, logic nodes and regular programming. I will not argue that it is way behind UE, but the ground is there.

I have been talking about other things like portability, which is also critical, but it is not something that gains attention at first sight. It is ‘just’ something that you need later, when you are about to deploy your game. When I mention that the shader compiler can cross-compile modern glsl to essl with automatic including of extensions for WebGL deployment, no one will find it interesting. That is why there are mostly renderer shots. :slight_smile:

Putting improved asset/scene management as a priority. :slight_smile:

Side note, if anyone saw the news of being able to turn xbox one into dev-kit:

Sadly I do not own xbox one, but the tech that is used(Kha/Kore) for engine is already showcased running on it. That is the direction I would like to keep going, targeting new platforms which developers can seize as opportunities.

In conclusion, all this project is attempting to do is making the game development in Blender exciting. Not UE killer, but something with different workflow. Not perfect, but something that can be built upon and shared.