Armory Engine Feedback: Armory at Blender Conference!


(Sirgeorge) #241

I checked your twitter recently and got some amazing apples to apples comparison in a link on your main site. Only one problem exists. You aren’t putting all of these items as links somewhere easily visible on the site. If there was a place where links to everything you did in regards to this project existed then people wouldn’t have to constantly look at all of the places they can find you or risk not catching something. At least, that is my two cents.


(SolarLune) #242

I don’t particularly see the need to improve on getting this engine or any pre-release engine out there until it’s actually available. No reason to worry about aggregating links and visuals in a single place until he’s gearing up for release.


(Sirgeorge) #243

I guess your right. Mostly I was bringing this up because I personally really want to get a location where all the resources are in to keep track of things very easily.


(rampa) #244

This is so cool!:slight_smile:
I’m hoping I can use it for a real-time renderer for imported Alembic files (using the Alembic Blender build). Seeing the architecture samples is quite encouraging.

Great Work! I hope it’s available soon.


(adriansnetlis) #245

lubos, do you need my help with some stuff? I can offer you:
-vehicle physics
-soft body physics
-game logic templates
-good shaders(can’t implement, but can point you to some)

If you need any of it, e-mail me([email protected]):wink:


(Ace Dragon) #246

It’s looking very nice so far, I think it’s getting to the point where people might not even miss the BGE if this became the drop in replacement for creating games directly in Blender.

The only thing I can see is that there seems to be a lot of feature creep and no defined targets for the first official release or even a beta (otherwise you eventually run the risk of people seeing this project as vaporware).

My suggestion, make a list of targets you want to meet, release the beta and focus on fixing bugs, crashes, and other issues, then release as stable when you think it’s ready.


(ohsnapitsjoel) #247

Agreed! I think a lot of us are itching to see it in action!


(SolarLune) #248

Yeah, I basically agree. Lubos might want to hit the major important points, like releasing the engine, improving usability across systems and fixing bugs, and working on distribution (assuming it hasn’t been done already). That’s kind of the point of the engine; nice lighting and great shaders don’t mean much if you can’t finish and distribute a game, or even use the engine (due to bugs and stuff).

Of course, you should also put it out there when it’s ready, and not before; don’t rush just because people are interested in it.


(Ace Dragon) #249

While I do agree that it should be released when ready, I do stress that the engine does not have to have everything (in terms of graphics) on an initial release.

For instance, Cycles didn’t even have things like SSS, anisotropy, and multiple importance sampling when it first became an official part of Blender (if Brecht and co. waited until it matched the likes of Vray or Arnold, we would still have a Cycles branch and nothing in master).


(SolarLune) #250

Oh yeah, of course, I just meant not to be pressured into release just because people seem to be clamoring for it a bit. The engine doesn’t have to have very much to be released for public usage.


(Sirgeorge) #251

My suggestion, make a list of targets you want to meet, release the beta and focus on fixing bugs, crashes, and other issues, then release as stable when you think it’s ready.

Yes, a very transparent and defined list would probably be a good idea. Releasing this as a minimum viable product would also be a good idea. Just getting something out there and saying, “hey, more is being worked on” will do well for this project.


(Sirgeorge) #252

It’s been a while. Anything new come up since the 11th?


(DoubleZ_) #253

A small video showing the game engine in action :
EDIT : Video deleted - just look to the next post to see it


(lubos) #254

Still going strong, just mostly focusing on under-the-hood stuff so it took a while to gather some new screens. :slight_smile:
Found a fun quote, “Give a man a game engine and he delivers a game. Teach a man to make a game engine and he never delivers anything.”, which is actually comforting and I am confident I can beat the odds sooner or later. :evilgrin:

I fully agree on all the criticism in regards to feature creep (and even not making the news easily visible), please continue bashing me for that. My trouble is that since I wish to turn this into long-term development and raise funds for the project, visuals are the easiest way of getting attention, at least in a scope of my skills. Plus since this is Blender (and even mimicking Cycles), I assume the general interest in visuals is very high. My favorite 3D games are now 15 years old so I woundn’t say graphics are that important to make a quality experience (for games), but you may have heard the non-sense going out there, “Why did you choose Unity? You should have used UE!”. This is a non-issue today as you can produce amazing graphics in both of them, but you get what I mean. And finally, most of the open/small-scale engines also seem not to place graphics as number one priority.

The good news is that I actually managed to get some initial funds, and I can continue a full time development for a few more months to come, hopefully enough to get things rolling in a good direction.

@adriansnetlis: Thanks for giving a hand, will get in touch!

Some of the mentioned under-the-hood progress:

  • Compositor pass compatible with forward renderer

  • Improved vehicle traits

  • Precompiled shader constants, making as much as possible of the shader work pre-calculated at compile time

  • Included helper python scripts for dropping objects down to ground and quickly cloning/distributing them

  • Proper asset tracking, only actually referenced assets get loaded (yes, this was not the case before as the scene is constantly changing and lots of files get generated and lots of them get removed)

  • Sorting draw calls per camera view, by default front to back to aid in early z-culling

  • More culling of invisible objects, also for lights, to keep draw calls count as low as possible

  • Support for de-interleaved vertex buffers, may perform a little better on newest cards

  • Support for exporting all assets to binary, speeding up load times and reduced the size further down approx 30%, more possible with compression

  • Font nodes, gets converted to mesh internally for now

  • X-Ray/Overlays support, also usable for attaching UI to camera

  • Basic built-in profiling with visual console with debug views, it is possible to deactivate each render stage at run-time, making it easy to compare performance cost and visual difference with shader enabled/disabled in an instant


  • For background, which is using world nodes, skydome is now rendered instead of full-screen quad. Basically most of the (deferred) rendering process is now very similar to the one described here:
    http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/

  • Basic volumetric clouds are in, based on:
    https://www.guerrilla-games.com/read/the-real-time-volumetric-cloudscapes-of-horizon-zero-dawn


  • Testing the new UI engine, while there is still no visual UI editing, it is using the css styling and xml lay-outing, making it super easy to use


  • Apart from skinning, timeline animation support is in:

Onwards:

  • Testing everything on Windows(almost done) and Linux, Mac is ready.
  • Putting docs together

Hope everything goes smooth!


(lubos) #255

@DoubleZ_ beat me to it. :slight_smile:

Got one more, a combination of Hosek-Wilkie sky, dynamic clouds, ocean and reflections.



(adriansnetlis) #256

You’re doing great job here, lubos.
I’ve got some questions:

  • What specular distribution are you using?
  • Do you have clear-coat support?
  • Have you implemented procedural textures?
  • Can you mix different shading models? For example, subsurface with clearcoat and with transluency or something like that?

Thanks!
Keep it up, I’m seeing something bright!:slight_smile:


(rampa) #257

I am so excited about trying this out as a realtime renderer! I use iClone for animation, and they have recently added Alembic export. The Alembic export can include baked physics cloth interaction (which iClone does pretty well).

The internal iClone renderer is realtime, but not as nice as this looks. So naturally, I want to use Armory with the Alembic importing fork of Blender to render my Alembic exports from iClone in a superior realtime engine.

Really looking forward to this! :slight_smile:


(Sirgeorge) #258

Hey hey, looks like the first release is coming along nicely. Getting something out there in an early form should go a long way to getting you more resources and starting the train for community support. As for the documentation, you really should get some community help. Getting people to organize things and keep things updated frees you up to do more critical work. I’d be willing but don’t have a lot of time to do much these days besides the minimum. Regardless, from your post it sounds close and I hope it really is that way. I really wanna see this sucker get released. Hoping for a release date soon (either soft or hard) and hope to see this project succeed.


(Jacob White) #259

Ui CSS editing?! You just made my day!!


(lubos) #260

@adriansnetlis
No clear-coat yet and only basic procedural textures, have to stop adding things now so hopefully getting back to that after early release. :slight_smile: Mixing translucency and other shading models should be doable. The system under the hood is quite flexible though, throwing custom shaders and creating custom render paths without touching engine code is possible.

@rampa
Now that sounds like an interesting use case! Have to keep this in mind and make it as easy as possible.

@Sirgeorge
Really appreciate that. Think I just sent you an email! :slight_smile:

I started working on a short release trailer, got the basic scene ready! All vegetation geometry is real but relies heavily on instancing which I have been improving and uses a very basic version of temporal anti-aliasing.