Armory Engine Feedback: Armory at Blender Conference!

(SolarLune) #161

I understand it not using Python.

As far as I understand it, Python is difficult to embed on mobile devices, it doesn’t run as quickly as a statically typed language, and other languages like Haxe (which this uses) can compile down to native C++ code, which means the maximum speed possible (which is pretty great when you’re dealing with games with a lot of elements processing at the same time). Haxe isn’t too difficult to use; it’s something like Java, actually.

I wouldn’t really worry about what people associate Blender with; whatever gets the job done for the engine is what should be pursued.

(BluePrintRandom) #162

Haxe is like writting C though isn’t it?

Seems a bit low level to be coding in…

(SolarLune) #163

Wha? Nah, it’s a pretty advanced language, like C++ or Python or whatever. There’s the usual modern programming conventions like classes, objects, references, lambda functions, etc. Weirdly, I’m looking at a recent Haxe example, and it’s not nearly as verbose as I remember; guess it’s simpler than I thought.

(quickmind) #164

So is there a way to create a conversion of python coding to haxe? its just a thought and i know it wouldn’t be perfect but it would be easier for some of the beginners so that they dont get squashed from the difference of the BGE to this… and im just lazy… just a thought.

ok so i looked at the very very basics of Haxe… And it isn’t too scary… it looks very much like JS… i have worked a little with Js so Haxe doesnt look sooo scary now… its just a little scary :wink:

(Lsscpp) #165

it’s easy to get informations nowadays :wink:

If I understood it right, there will be also visual programming via nodes, right?

(youle) #166

Wow, this looks amazing! Congrats! And the development is so quick :slight_smile:

(CG Sky) #167

Very amazing what you have done so far! Awesome that the development is so quick! I´d also be looking forward to test it out, and create a cool test scene with it. I will follow the development!

(Mistran) #168

Armory engine logo designs for Lubos:)


(BluePrintRandom) #169

I like the anarchy looking one :slight_smile:


(quickmind) #170

I agree on #4… i just looks nice and like it has power but control… idk i just really really like it…

Man i can’t wait to see this come to life… though the coding is going to get me for a while… ill just have to get use to it…

(bullx) #171

Please can we keep this post for the project updates and not for logo/name proposal?

(Formless) #172

I really like #5. It holds together in every variation, and looks the most like a logo you’d use for a game engine.

(TwisterGE) #173

I was trying to say that, but…

(adriansnetlis) #174

We must make a new forum section for discussing this project soon. Or maybe for all the external(but releated) projects and forks.

(KiiNGz) #175

I like number one if you remove the box!

(ohsnapitsjoel) #176

GUYS. Cut it out with the name and logo suggestion clutter, please.

(Frederick D) #177


When Kha supports VR, will it be possible to deploy to the announced Google Daydream platform on Android N?

(lubos) #178

Just wow looking at all the messages:)

For the images posted deferred rendering is used, but the system is not tied to any render technique. There is forward path too(aimed for low end, missing the fancy stuff of deferred one), and proof-of-concept path tracing.

I agree the UI is a concern, but building a separate one would take months if not years, plus lose the appeal of all in one content creation tool - killing the main point of doing something novel. I already got used to Blender way too much so I am unable to think clear here, but why not try bringing the suggestions to Blender itself? Note that this thing could be hopefully used not only for games, but for all kinds of other stuff thanks to Blender capabilities. If you check out the recent MacLaren demo created in UE4(interactive car visualization), creating that thing in Blender with realtime renderer would be way more effective.


@Frederick D:
There is some basic VR support in Kha so should be doable - will keep that under radar and check it out:)

Big thanks for the logo designs, checking them out!

Started the rename to Armory to solve the name trouble, will also try to make it easier to follow the news. There have been loads of new stuff, a proper post will come but in the meantime I tried to at least record the videos.

A new one!

  • Material node parsing has been improved. Slowly adding more nodes - color ramp now works too.

  • Pipeline nodes can call functions now, making it possible to adjust frame composition with logic. For example processing some shader data, or making the screen flash red when player health is low, or lowering the render target resolutions when FPS is low.

  • UV project modifier now works, used for decals!

There is some big Kha news coming during the weekend, waiting for that to see how fast the engine could leverage that and then start wrapping up. :slight_smile:


(Mumrik) #179

Hey Lubos it looks amazing, have you got any plans to implement a “pre rendered” feature in your game engine. There are many people who are fans of old pre rendered games, resident evil, monkey island, final fantasy etc. Where a rendered image is cut into parts in photoshop and then layered onto each other in a game engine to achieve the illusion of depth. Then a character is placed into the scene and runs around inside the painting on top of an invisible collision mesh.

As far as I’m aware this is sort of a lost art, I don’t think there are any game engines that has this feature. The problem is that when the camera pans through the scene tracking the location of the player the perspective is distorted. What you need is an ortographic camera for the background and a perspective camera for the 3d character. There is one guy who made this work in the unity engine by using some fancy codes but if possible this would be a very neat feature in the blender game engine, or the lubos engine.

Here is some guy describing the issue:

The idea is to use a RenderTexture that you display on a GUITexture. That GUITexture having a resolution higher that the screen resolution, it becomes possible to move it around by changing its pixelInset values.This technique prevents any camera movements, and so keeping the same camera angle between the prerendered background and the 3D camera view.
The only issue remaining with this technique is that the GUITexture might need to be of a high resolution in order to fill the whole screen without any quality loss. Also, there’s at the moment no anti-aliasing available for RenderTexture, but it looks like they started working on it.
And here is some more technical stuff on the topic:
Here are some example of the kind of graphics the 412x412 something resolution games were able to achieve back in the day. Today backgrounds could have much higher resolution and it sure would be neat if the programming aspect of all this could be done easier.

Final Fantasy

Resident Evil

Alone in the dark

Monkey Island

Icewind Dale

If it wouldn’t be too difficult to implement as a node or a series of nodes it might be a good feature to have since there really is no game engine that has this as an inbuilt feature. Since these type of games dissappeared when engines become more powerful, but still today there is no game engine than can beat a render engine and photoshop, beautiful games could be made.

But keep up the good work, it’s looking great!

(adriansnetlis) #180

Actually you must be able to fit it in perfectly in perspective camera.