This topic aims to share more progress from the ongoing GI developments.
Voxel Based Ambient Occlusion
On the hunt to achieve high-quality dynamic GI in Armory, voxelized scene comes super handy for calculating ambient occlusion.
Compared to good-old SSAO, this handles much higher scales and is no longer a screen-space effect. On the pictures below both techniques are combined - voxels for higher-scale detail, SSAO for small-scale detail.
The effect is pictured a bit strong here, toning it down is of course also doable.
Scene is The Grey & White Room by Wig42.
But the biggest gains of this technique - it is finally dark under the couch! SSAO is not able to handle this well, yet this was one of the biggest things turning down the whole render for me.
But realistically speaking, what frame rates did you get with this setup? I looked at the astronaut model and it’s super high poly, well, I didn’t try it in Armory, just opened it in Blender, but I’d be curious to see what FPS you got
@trsh:
WebGL is unable to access GPU features required for this, so web builds are not possible right now. Maybe with the WebGLNext / Obsidian things will look brighter.
Plan to make it more accessible:
Build a small archviz benchmark with binaries and sources
Enable it straight in Krom for Build 10
Record some vids
@razvanc-r:
I would not bother with this if there is no way to run it at real-time frame rates - I really want to build games with Armory!
GPUs are good at chewing through massive amounts of geometry, as long as they are not constantly interrupted or bogged down in other areas. That’s the reason I have been improving material compiler & batcher (also wonky render-paths in git - implementing new stuff there as well).
I re-downloaded Astronaut model again (it’s 1.9M tris) and quickly threw it there - my GTX 1060 gets it done at 60fps (16,7ms, capped, 1600x900). I do not want to make any claims - the scene will slow down as soon as it gets more complex. Just working on a tech that should be best suited for Armory goals right now and times to come (always hard to predict this). Scenes shown here so far are unrealistically simple, on the other hand there is tons and tons of stuff to optimize. Granted, this is not intended for integrated cards.
Armory is not the same thing for sure Although seems that Eevee will be able to show a similar output of Armory.
Regarding Eevee I’m just curious if armory will also have one of those output nodes with the name of the renderer https://code.blender.org/wp-content/uploads/2017/03/multi-engine-2.png
As for Armory I also clone Blender 2.8 every day.
I think right now Eevee is more a view-port, than game engine project. Armory is super-portable and far ahead it, so I think there is place for both. I just hate seeing multiple parties doing same thing, why then not put heads together
We have now Clay, Eevee, Cycles and Game Engine, so might as well add Armory to the list of renderers lol
Edit: Included in the Blender official release I meant
@trsh:
Looks like I am still doing terrible job at explaining what Armory is.
The main factor is different goals - Armory will not fill the purpose of Eevee, it is not a viewport project for Blender. Armory is mainly meant to build interactive content that runs anywhere. The editing happens in kind of a ugly way of current Blender viewport - that is where Eevee comes to the rescue, finally a great experience for the editing phase!
Same the other way around - I doubt you will see Eevee running in a browser or mobile device anytime soon. Why would it ‘waste’ time on that? The Blender guys I had pleasure to meet were in love with Unreal Engine - that is the pipeline they want to fill - offer UE users a great content creation tool (Armory can greatly benefit from this along the way). Both Eevee and Armory will likely pick up new skills as time goes, but so far they complement each other nicely.
If the projects would merge - do you think Eevee will ever run on a D3D or Metal backend? In the long run, Armory can not afford to miss D3D (or any graphics API for that matter) till it is unique to some platform (Xbox in this case). It aims to not take opinion and just get you to the platform you desire. Imagine I went ahead and started ‘bloating’ already huge Blender codebase with this. Similarly, Eevee is a forward renderer. Armory can not afford this - each platform has different constrains and different render technique may be optimal. Imagine that I would start making Eevee much more complicated with this stuff. Since Blender runs on set platforms (desktop), they do not need to bother with this as much.
Armory is designed as a ‘standalone’ project which anyone can take and throw into new tools. It bothers me there are not that many open source tools at the level of greatness that Blender achieves. If Armory eventually matures into a state where it is also usable for your own engine/tooling, it will reach another goal.
I am not sure if it all makes sense, but hopefully I was reasonable.
@Chris.k:
I tested the benchmark scene, there was no difference in performance between Krom and C++.
Generally speaking: using Krom is better for play-testing since build times are fast. Using C++ target is better when working on engine features, you easily recompile the whole engine there and can see the changes immediately.
I looked at the astronaut model and it’s super high poly, well, I didn’t try it in Armory, just opened it in Blender, but I’d be curious to see what FPS you got 
