I agree that the current priority should be to polish up the existing feature set, but I have one suggestion for beyond the initial release which I think would be useful for low performance targets. That is temporal reprojection (a la Killzone: Shadowfall), a method which provides better image quality than traditional upscaling, and looks nearly identical to a full resolution image under certain conditions. This involves rendering every other vertical line of pixels and switching to the next line every other frame, filling in the empty spaces by predicting movement from motion data on the previous two framesā pixels. This allows you to focus on rendering only half of the pixels with less expensive image processing on top, possibly offloading it onto whichever processor is less occupied.
I canāt find a paper specifically detailing the method further than the descriptions given by Guerillaās devs, but I imagine thereās documentation for something similar. This could be a boon for weaker devices, testing in the WebGL viewport, and for gamers in general as such techniques are uncommon on PC platforms, although they offer a decent image for a reasonable compromise.
On a different note, I imagine a short-term solution for LoD would be to manually probe for distance from the camera and destroy/load objects ourselves. I already have a chunked tile-like solution made up so I donāt imagine it would be too difficult to recreate within Armory.
Iām quite suprprised too, I didnāt thought Lubos would take the effort to add Python support. Good work lubos. That said, would you care to explan in wich way you implemented it? CTypes? Compiling for Python? As a separate program? Using some port of the python library for Haxe?
I mentioned this on the video and on Twitter, but this looks phenomenal.
I know everyoneās excited for a new feature to be added here or there, but I think the prime thing is for it to be released for testing, and feedback to be collected. Thereās not a huge point to adding more and more new features before itās released - thatās just more things that have to be fixed, and more things that wonāt be working correctly.
I think that, as time grows closer to release, lubos should work on the usability aspects of the engine. For example, I personally hope for solid documentation on the API and on exporting to standalone executables. If these are done, Iād love to look them over, even now.
@lubos - Are you really doing all of this by yourself? Or are you, maybe, part of a team thatās developing this engine for a game project?
Please consider an early release,lubos, cause I could use it just like it is in your last video.
But maybe we all have to wait until your meeting with Ton in September ?
Incredibly cool. Iām quite excited thinking at what this + new blender 2.8 realtime engine can become.
Now Iām waiting for 5 minutes of (nodes) visual programming in Armoryā¦
Itās both an addon and an engine. Or rather it is an engine that includes a Blender Addon in order to use Blender as itās interface (Similar thing did GameKit in the past). But technically it is a game engine, not an addon, since you can make games with it without Blender, but you canāt do anything with only Blender+Armoryās Addon.
Now since lubos seems very productive, I wouldnāt be suprissed if the engine where to be automatically downloaded when installing the addon or something like that.
Scroll up a bit and you will see what his projected price is, but he will give all early supporters early access regardless of how much you can donate.
A release starts laying the ground for a lot of things. All of a sudden you have testers for the engine leaving feedback. You can start opening up things so people can hopefully tweak and improve the engine on their own. The forums and wikis will also get a boost and that will help with getting more members in and getting old ones updated on the latest changes. Iām still working on my own coding skills but Iāve heard from others that may want to help contribute code and thus speed things up. I suggest another release date update and as for what I think engine updates should focus on, I canāt say without first seeing the first release of the engine.
I canāt seem to find it, but I do recall Lubos mentioning somewhere that the foundation for level streaming is a high priority and he has already completed the ground work to make it a fully developed feature.
I also want to know what the minimum file size is. Also, when is the manual going to get updated to the finished version for the first version of the engine? I want to see an update on the release date of some of this stuff. Hopefully Iāll get that.
