search

armory3d / armory

3D Engine with Blender Integration
https://armory3d.org
zlib License
3.06k stars 315 forks source link

Armory 2020 #1545

Open luboslenco opened 4 years ago

luboslenco commented 4 years ago

Welcome! With 2020 already in full swing, I would like to outline some plans for Armory architecture in the upcoming year. 🔨

Feel welcome to bring up any of these points for a discussion. If you have additional ideas which may improve the project further, please bring those up as well. The goal is to keep Armory viable long-term with a modern base ready for upcoming years.

My biggest thanks to everyone who already contributed to the project in any form over the years!

Clockwork-Muse commented 4 years ago

... if you're moving things to C, would Rust be considered?

nanjizal commented 4 years ago

I can't seem to get any online samples of WebGPU working on my mac :(

NME uses Webassembly http://hughsando.com/category/nme/ it does not load or run as fast as WebGL ( see my PolyominoTriangles tetris tests from 2017, in Kha WebGL, WebGL haxe, WebGL Heaps, WebGL OpenFL - NME JSprime equivalent ).

WebGL is definitely the ideal output for showing potential clients work as it runs on mobile from a github repo, and I am yet to believe the Webassembly / c in browser offers enough advantages.

I am sad that Armory is moving away from Haxe. If Iron moves to C, it will definitely be beyond many of us experimenting with, for instance projects like Rice2D use your components and could use Iron.

I looked at Rust briefly once meh, Nim seems more interesting and looks like there may already be start of a Nim target for Haxe, certainly I would suggest using Nim over c if you want more reliable code base, it has good parallel support and speed. https://github.com/RapidFingers/Craxe

Haxe has many other evolving target solutions cppia, Hashlink, LLVM target etc...and they involve many talented devs, I think it's nice that Armory currently has potential Haxe choices but in future you will be more tied to c tech. For instance I presume if Robert stopped working on Krom/Kinc/Kinx then Kha could be maintained and run on another target - same type of argument that users had against Haxe till other devs got involved.

The other consideration you need more stability, porting Iron to c is only going to divert you from improving current reliability and stability, also it may absorb a lot of your time on complex stuff and not give you as much time for the visual graphics stuff you also love?

But these are just my ideas and fully aware that I am very biased being a haxe user, and I don't get much time for code let alone learning blender so my opinion is not that relevant, but always amazed by what you create.

BlackGoku36 commented 4 years ago

@Clockwork-Muse Kha is to Haxe, Kinc is to C but there is nothing to Rust, If kinc wrapper was made for rust, than you would have to write entire thing in unsafe blocks, which defeats purpose of rust(AFAIK).

I am sad that Armory is moving away from Haxe. If Iron moves to C, it will definitely be beyond many of us experimenting with, for instance projects like Rice2D use your components and could use Iron.

🤔

What about projects like zui, It will still stay in Haxe, right?

With iron and armory written in C, it would open up lot of possibility, like use C's projects like Imgui, etc.

p.s. It would be easier to discuss in Discord server in channel like armory_dev with mods making it private

trsh commented 4 years ago

Can't hide that I am excited. I do support all the directions you are aiming, but have some suggestions:

a) I don't think all of the bugs registered are because of the current low-level parts tech stack and will magically solve as you move to Kinc. Probably lot's are logic bugs and things that just need rework. So would be great if along the rewriting you pick the most urgent ones (like lightning) and solve them, so we don't get the new version with same problems. Maybe some of them can be solved even before the big migration, so we can finish our games and demos?

b) To attract more contributors please implement some "best practices" for coding. Managing the code in a manner as efficient as possible, to make it easily understandable, by the person that writes the code, and by the people that will read the code in the future. There are many books and online material on the topic, but what can I say from my exp:

1) Always go for hard OOP approach and split the logic as needed in sub sections, so there are less huge code chunks, that are hard to extend. 2) Always comment the code appropriate 3) Check some best practices for namings. Like use camelCase for this, pascalCase for that, always start a boolean variable name with is, always write understandable function/variable names, etc etc. Maybe there is even some automated linting for C, like for JavaScript. I don't know. 4) Don't ignore warnings

Reading clean code, is like reading a good book and I think is very important for open source projects.

c) Update your blog or twitter even with small accomplishments , so we can fallow the development and maybe help.

d) Please, don't aim to much for high end gear and tech, like RTX graphic cards for ray-tracing (ctytek and Godot for example implemented ray-tracing on Vulkan, with no need of DXR - RTX), VR's, etc. But focus more on stabilizing the engine basics. Most devs here are not Big companies that want to make the next FPS AAA title (what is also impossible without the basics working), but rather small Indy developers why are aiming for simple Mobile/web game. Everybody tells me that Armory already has fantastic looks. What people are mostly missing is like Network stuff, online streaming for large worlds, adding post processing or custom shaders with ease, ik resolving for procedural animations, more of the blender shader nodes support (like refraction), etc., But MOSTLY the engine overall stability. If you don't believe me, create a survey or just check the feature requests and bug/feature request ratio in git :). And we still want graphics scalability so we can aim games also for older devices.

I hope this helps, good luck!

Edit:

Please remove my ban in Forums. I think the haste is over and my attitude has also changed! :D

RobDangerous commented 4 years ago

Cool Spot, looking forward to Kinc-Armory!

Sandy10000 commented 4 years ago

I am very relieved to hear the future of Armory.

Will bugs related to kha and iron be fixed in the future? Or are you dedicated to building a new environment?

Clockwork-Muse commented 4 years ago

@BlackGoku36 - Yes, calling directly into it would require unsafe blocks. However, dependent code would not - depending on the exact structure this could be a significant portion.

Didiercode commented 4 years ago

It’s normal that the goal is to keep Armory viable long-term with a modern base ready for upcoming years… but as Armory is here since several years without switching to version 1, I can only ask you the question if, quite frankly, isn't this actually the classic target drift that will again unnecessarily delays first reliable version of Armory, drives up costs/time which you may not have enough to do and can even destroy your project. As you are the only developer/designer, it’s essential to avoid this risk.

Otherwise from my personal point of view, I would be very happy to use D3D12/DirectML in Armory.

RobDangerous commented 4 years ago

Don't spoil the fun... because for a one person project fun is the key to getting work done efficiently. Being on top of the game in terms of graphical finesse seems to be what Lubos enjoys most about this project from what I can tell - please let him just do that and I'm condident that'll actually minimize the risks.

Didiercode commented 4 years ago

the fun of a project is the key to effective work ... up to a certain point; it's called the age of heroes and effectively it's more fun ... but it works for a while. The investors/supporters/ecosystems... find the fun too in software finishers who don't have as much fun.

RobDangerous commented 4 years ago

Urks. Anyways, Lubos, I have more advice for you: Get away from that traditional versioning scheme. Nobody ever asks me for version 1.0 because I'm already at version 2020.1. It makes my life better.

trsh commented 4 years ago

I must agree with @Didiercode . Every project is fun to certain point. After that is hard work and dedication to bring something to the finish line. New ideas, tech, etc. often kill projects or keep them in never satisfying loop. If you are building a engine for your self, its fine, but there we have supporters and donators and whole community behind. We want to make actual games with Armory, not just experiment with new shiny features.. and there will be always something new on the horizon, like http://www.lightmass-dynamics.com/ . Currently Armory is like a Ferrari, with broken tires, gear box and lights, so you can't really drive it :D

VicentGJ commented 4 years ago

I agrede with @RobDangerous in this. When it comes to this kind of projects the important is that the maintainer found it fun to work on it, or they are driven by a very particular necessity. If the project proof to be useful to other people, and start growing, then the motivation will switch from fun to the happiness that comes from knowing that your work is beneficial to a lot of people. That is the way this usually works and because of that we have to support @luboslenco in any technological decision he made.

BlackGoku36 commented 4 years ago

Writing a game engine isn't small thing, neither is implementing stuffs like RTX, they take time, sweat, tears(bugs lol), blood(ofc not), and headaches to be implemented. The ability to achieve this is largely governed by how much fun you get working on this, believe me you can't work on stuffs you don't find fun. In our case, we know that @luboslenco find stuffs such as fancy looking shaders, modern technologies, etc. fun. So, I agree with @RobDangerous and @VicentGJ .

To be honest, armory already looks like "1.0 stable" game engine, with which you can make complete game in. The only thing right now, is that it is full of bugs, and it feel like whole engine is holding up with duct tape. So, addressing bugs should be top-priority right now, ofc i know that bugs are really headache to solve, so since we are are porting Armory from Haxe to C (Kinc), I suggest we........re-write the whole engine from ground up? This will solve many bugs such as lightings, animations, and also introduce better code base architecture, and the main goal should be to restore all the promised stuffs that were removed because of reasons, like blender viewport rendering, Sub-surface scattering, Node based render-path, grease-pencil(we already got @N8n5h taking care of this), etc. With C, we will able to use many C libraries and remove codes that are re-write in Haxe, this will help a lot with fixing bugs and adding of new features.

trsh commented 4 years ago

If I put all opinions together, I recommend the fallowing:

1) Move to Kinc (C) - rewrite clean robust code with "best practices", but don't reinvent the wheel where it's not needed, so it's not like 4 years orsmth.

2) Address prioritized bugs and community feature requests/promises over fancy RTX, VR, etc stuff in respect to all donations and support. I even suggest to open a Pool of the most anticipated bug fixes and features for the upcoming release. I bet RTX will be not on the Top :P

@BlackGoku36

To be honest, armory already looks like "1.0 stable" game engine, with which you can make complete game in.

Depends on what games. Remember our drone demo hanging for a Year. Go and finish it! :P

...I suggest we........re-write the whole engine from ground up? This will solve many bugs such as lightings, animations, and also introduce better code base architecture...

I don't think every piece will be reinvented from ground up (to consuming), I think most of logic will be Ported/Moved. That, if it isn't Kha issue, will leave the same problems pending.

Anyway, time to learn C

Didiercode commented 4 years ago

@trsh sure that a real disruptive approach sould be by redisigning Armory completely around AI and path tracing and seems to me too the best way for getting more fun !

Comparatively with the approach proposed by @lubos with Kinc / C, it seems that we are stuck to ideas and concept based on evolutions of existing data representations, coming from an outdated trick based on 80's approaches/ technological foundation from work on CAD software which were never meant nor designed to be used at using today IA/ML technics. Thus this needs building a new type of data representation that Kinc and C are not prepared/made for that I suppose too. Compared to a boring rewriting Armory code, that's really what could be fun to do. @trsh your link to the http://www.lightmass-dynamics.com/ is a perfect illustration of what could be a real fun way to get Armory viable long-term with a modern base ready for upcoming years, with a new efficient way "to store & execute geometry and its properties inspired by quantum mechanics and implemented with neural networks" https://www.youtube.com/watch?time_continue=137&v=vWH-clyV5XM&feature=emb_logo

This was already evoked in the Armory forum in March 2018 ... https://forums.armory3d.org/t/is-a-new-armory-ai-technology-the-creator-of-demand-or-a-response-to-it/2087/4?u=didier

BlackGoku36 commented 4 years ago

Depends on what games. Remember our drone demo hanging for a Year. Go and finish it! :P

Care to point out what was wrong? Well, I can. The bug we faced were:

Careful people, we got some 10x programmer who have coded game engine and have made really good contribution to Armory itself above /s

trsh commented 4 years ago

Tell me thing that made it look like it was not "1.0"

Yeah, not working lights doesn't sound like 1.0 version :P to me (but that's opinions). Try to play with Omni, add multiple, also doesn't work :P. And you didn't mention all issues. Anyways, because of those NOT fancy things, but basics we could not finish the demo, so that's not 1.0 to me, and I stick to it.

trsh commented 4 years ago

@Didiercode there is no more info of the tech as that site and videos. And it's very experimental. Way to far to aim for :P

Didiercode commented 4 years ago

@trsh If Armory was managed like a startup and taking the way to become disruptive with IA inside, it could be supported like Lightmass Dynamics with the Techstars in Canada or France ... look info here https://www.techstars.com/content/accelerators/dix-nouvelles-startups-accelerent-leur-developpement-avec-techstars-montreal-ai-2019/ ... Lightmass Dynamics is considered as one of "the world’s most promising startups to future-proof your business."

Thus Armory could get more fun and with ressources with Techstars as it is an acceleration program based on mentoring. Many of these mentors are entrepreneurs themselves, but a large number of AI technical experts and business people from a variety of industries.

Lightmass Dynamics approach could be inspiring. look here https://developer.download.nvidia.com/video/gputechconf/gtc/2019/presentation/s9367-beyond-polygons-voxels-and-rasterization.pdf has how to make animations guided with NN inputs.

But open-source is also fun ! :) ... and an real "Open Organization of Armory is needed ... this is how to build an avidly engaged community that can ignite this kind of passion, fun, innovation, ... that drive outsized results ... and we need some key practices and meet our expectations like transparency, authenticity, openness, responsiveness ... you can have a look at the forum remarks in link with thoses key practices to measure at what level it is today.

I think that Armory could become one of the most powerful game engine if not only Lubos but also a community pushes it forward, fixes bugs, produces tools, complements,... and still gives you the opportunity to be a kind of Armory engine CTO of your branch as you can do it today with access to the source code. I hope I am not the only one to think that it makes all the difference as some of us need to differentiate our work and to have the total control over final product.

I think that @luboslenco can realize now in retrospect that wanting to rewrite alone the whole Armory game engine as he proposes today, he would end up with decades old technology.

Thus I think he has to take the risk, for fun too, to adopt a frankly disruptive and risky way today to be in the course tomorrow.

BlackGoku36 commented 4 years ago

I think that @luboslenco can realize now in retrospect that wanting to rewrite alone the whole Armory game engine as he proposes today, he would end up with decades old technology.

Do tell me how?

Didiercode commented 4 years ago

@BlackGoku36 look at retrospect of releases first image and tell me how could be the future planning ... everymonth delivery at start then every year ... first version in 2030 with KinC ?

BlackGoku36 commented 4 years ago

I don't get what you are trying to say. You are talking about lubos using decades old technology and now you are talking about Armory with kinc releasing in 2030.

If you are talking about that Armory with kinc releasing in 2030 and technology would be really different by than and lubos would end up using old technology, than that doesn't make sense at all. UE4 is almost 5-6 years old and it is using up-to-date technologies

trsh commented 4 years ago

I wonder how we could speed up the development. Can't wait to get my hands on the next version :P

Didiercode commented 4 years ago

@BlackGoku36 what we can predict without necesserely being a guru in the domain, is that as game industry is providing VA in industries like training, data sciences, communication, defense, education, medecine, ... this disruptive potential of game engines techs will boost the growth of new types of companies and threaten well established positions in next years like this UE4 one.

It's up to Lubos to offer a real value proposition that cannot be dismissed in the next decade... but I don't see it today and I hope to be wrong as he's already achieved something surprising with Armory 3D and ArmorPaint for someone on his own.

One way to consider to get something modern for next decades is for example to consider neural networks, with a generative models approach (see discuss in Armory forum about that) that demonstrates to have the potential to change how graphics are created.... for example this has already demonstrated to bring us the potential to to create new scenes at a fraction of the traditional time we need today ...

Imagine for example a new appraoch to develop your game with a next generation of Armory Logic Nodes, available to use an image-to-image approach ... the game engine use edges of your objects to produce new 3D objects inside your game ... new design with no 3D efforts in Blender, as you have a connection to different Neural Netrworks available inside or outside Armory and trained on real objects, look demo here https://affinelayer.com/pixsrv/ or videos here https://vimeo.com/user59566598 like the one with bird-eye of a city ... a kind of automatic ArmoPaint with IA and automatic creations of your 3D scene in real time during play of your game. You stay focus on creating innovative and fun games ... not on graphics and 3D animations.

arigbs commented 4 years ago

Armory traits will be written in Haxe/JS like usual, or anything which compiles into WebAssembly.

Blazor?

smxhams commented 4 years ago

Love your work Lubos.

Dimous commented 4 years ago

Hello everybody!

@Clockwork-Muse Kha is to Haxe, Kinc is to C but there is nothing to Rust, If kinc wrapper was made for rust, than you would have to write entire thing in unsafe blocks, which defeats purpose of rust(AFAIK).

Judging by the following: https://github.com/Kode/Kinc/issues/389 (https://forums.armory3d.org/t/rust-and-the-vision-of-armory/3146/22) rust backend is planned/worked on.

onelsonic commented 4 years ago

New Year, New stuff, Always great news to hear new stuff! @luboslenco if you need any help, shout-out! Not sure if there are a lot of coders amount us? C language equal SPEED SPEED and SPEED, and... access to all the major libs both free and commercial. So we will get up to date physic engines to plug-in and much more. Not sure about the multi-threading as that will be dependant upon the target?

I'm more interested in knowing the next planned workflow. Will it be similar to current: Coding in Haxe/C > that is then transcoded into the target ie WebGPU, Metal ?

Then speaking of Armory, correct me if I am wrong as I started to asses the tech 6 months ago, since August so don't know the full history. The current and planned workflow are both heavily depending on Kha/Kinc. Which is currently targeting a lot of systems but have some core critical issues remaining. It feel like trying to target too many systems none are fully polished and finished. Node JS/Krom are probably at a better state than other targets but still incomplete.

It seems like Kha/Kinc is the bottleneck here, the problem is that both projects Armory vs Kha/Kinc have different use and one need the other to function, as Armory is based on Kha/Kinc.

Another example, when reviewing the targets, now with vulkan why still bother targeting Direct3D12 in the future? When vulkan is achieving higher FPS vs DX12 on AAA games.

The strengths of Armory were: BLENDER LIGHTWEIGHT SPEED MOBILE/PC CODE READABILITY (HAXE) which makes it a pretty good tool if a real tech game demo could be made. (Thinking there of a Godot robot Shooter Demo like)

Then you have the PC vs Mobile paradigm that can define your targeted systems.

As of today Ray Tracing, RTX in games is more of a marketing gimmick used by one brand to sell more hardware, like Cuda was. Still far to be mainstream. Then the best renderers in this area are PIXAR and OTOY (OctaneRender) but can't be use for a realtime AAA game yet with our current gaming hardware, except if your are willing to spend +50,000$ for your graphic cards. So one can question how some reverse path tracing technique with a MonteCarlo estimation will perform on mobile?

Seems like this can hurt the strength of Armory capable of targeting Mobiles.

Then moving to C and knowing its complexity you will also hurt the code readability, where HAXE is pretty good at this (HAXE has been used in the last Pokemon "sword and shield".) OCaml is even better, probably the language requiring the less number of lines for a same program compare to the others (this last one is heavily used in realtime finance and can be applied to gaming)

Being in the tech/gaming industry for +20 years my advise will be to try emancipate from any bottleneck (Forking your own Kha/Kinc) and focus on your current product strength which brought you some visibility and a small community and improve these strength continually while launching a fully finish tech demo and then game. Otherwise you can end up with a never-ending research trying to achieve something but never completing it.

If your goal is not a finish product but more the research aspect, then these guys pointing some exotic deep learning renderers is an area with good potential future. New data representation, GAN networks or even Voxels are also an area of research for realtime 3D, which start to have good commercial products. https://www.atomontage.com/ (Start-up venture series A. Secured 2M$ 3 months ago) https://www.euclideon.com/ (leader of GeoScan 3D representation since 2014, similar tech can be applied to gaming)

If the focus is gaming you still have the limitations of the current hardware still currently optimised toward rasters. John Carmack has made a lot of talks about this.

The essential is knowing what motivates you and keep going at it full speed, with a smile.

Happy New year to you all. (From the Green Hill Zone)

trsh commented 4 years ago

https://www.euclideon.com/ is rather a bad example for gaming industry (they backed of long time ago). https://www.voxelfarm.com/index.html is a good one, and it can be integrated into Armory and its already used in games. https://www.atomontage.com/ has been into development for eternity, so Im suspicious about they end product for gaming - could end up like euclideon. This is another voxel project to fallow https://twitter.com/ProgrammerLin . But yeah, voxels are like different genre with different qualities.

RobDangerous commented 4 years ago

Because D3D12 is required for Xbox and consoles are currently my main focus. How would forking Kinc aka effectively halfing the man power working on the backends improve things?

RobDangerous commented 4 years ago

Armory does not have its own system targets. When you talk about D3D12 and Vulkan, you talk about Kinc. When Armory manages its own fork of Kinc and deletes the D3D12 code that doesn't save the Armory team any work at all.

RobDangerous commented 4 years ago

But how would forking Kinc help with that?

N8n5h commented 4 years ago

I think the fork is for Krom a.k.a. Kromx and not Kinc exactly, @onelsonic.

RobDangerous commented 4 years ago

Why would you need to fork it to focus on the targets you want to focus on?

onelsonic commented 4 years ago

Well, removing the extra steps to validate the compatibility with other unnecessary targets?

RobDangerous commented 4 years ago

There are no extra steps.

BlackGoku36 commented 4 years ago

Oh boy, here we go again. Time to grab some popcorns 🍿 A request to @luboslenco , limit this issue to only contributors, other can kindly go to forum post: https://forums.armory3d.org/t/armorys-future-is-announced-on-github/3856

luboslenco commented 4 years ago

(@trsh please keep these masquerades away, it's been going on for years now. Basically unable to have a discussion without those popcorn sessions.)

luboslenco commented 4 years ago

Thanks to all for posting the feedback, it helps a lot with planning things around.

Will post another update detailing the progress along the way!

RobDangerous commented 4 years ago

(you're all free to read the whole IRC chatlog starting with last month to look behind the masquerade)

QuantumCoderQC commented 4 years ago

What would be the state of Physics Engine? Will it still continue to be applied as a Haxe Trait?

Disar commented 4 years ago

@luboslenco So to be clear only mobile devices with vulkan support are going to work?

ghost commented 4 years ago

d) Please, don't aim to much for high end gear and tech, like RTX graphic cards for ray-tracing (ctytek and Godot for example implemented ray-tracing on Vulkan, with no need of DXR - RTX),

Crytek and Godot ray tracing implement that don't support hardware RT are slow, supporting hardware RT feature make sense since nVidia has hardware RT, and soon AMD will have card with hardware RT support , same with Intel Discrete GPU. I've tried other engines with ray tracing support via software(read not using RT hardware) and they are extremely slow, like 4 frames per second compare to 20 fps on Unreal Engine 4 with DXR on a RTX 2080Ti. I don't mind if Armory engine becomes the "Crysis" of the game engine world, catering to only high end graphics. So many engines already support mobile game development.

Another question is should Voxel Cone Tracing be dropped also? It's got too many problems and ray tracing hardware will become common place in this year.

trsh commented 4 years ago

Another question is should Voxel Cone Tracing be dropped also? It's got too many problems and ray tracing hardware will become common place in this year.

Only for real game Geeks. What is like 20%? Most casual gamers (like me) will wait for years until the RTX card price drops to something reasonable. I don't suggest to make Raytracing via Vulkan orsmth, I just said it's possible. I suggest to postpone it until it's more mainstream. And it would be a bit stupid to drop low-end lighting, as we still want to develop for mobiles and consoles like Switch :P (and WEB).. , not that armory becomes some monster only for 3000$ pc's and next gen consoles. Graphics scalebility is every engine strength. Look at UE - one can develop games almost for all platforms with beautiful (appropriate for hardware) graphics.

ghost commented 4 years ago

Another question is should Voxel Cone Tracing be dropped also? It's got too many problems and ray tracing hardware will become common place in this year.

Only for real game Geeks. What is like 20%? Most casual gamers (like me) will wait for years until the RTX card price drops to something reasonable. I don't suggest to make Raytracing via Vulkan orsmth, I just said it's possible. I suggest to postpone it until it's more mainstream. And it would be a bit stupid to drop low-end lighting, as we still want to develop for mobiles and consoles like Switch :P (and WEB).. , not that armory becomes some monster only for 3000$ pc's and next gen consoles. Graphics scalebility is every engine strength. Look at UE - one can develop games almost for all platforms with beautiful (appropriate for hardware) graphics.

You have to understand modern game engines are used for many fields nowdays, look at UE4. Alot of people are using it outside the game space, like interactive real-time walk through of homes, product shots,automotive configuration,even still frame rendering,etc. There are even studios using for animated cartoons(I think Barbie uses UE4). That is why Epics Game isn't waiting for ray tracing to become cheap or mainstream they are actively working on improving ray tracing now because their customers want it and demand it. I can see Armory being used outside the gaming space just like UE4.

https://www.youtube.com/watch?v=H2-9vEuRYVY

trsh commented 4 years ago

So bottom line, work on tracers but don't drop low-end lighting. Not up here for long discussions. I think @luboslenco already has a plan and will stick to it.

ghost commented 4 years ago

So bottom line, work on tracers but don't drop low-end lighting. Not up here for long discussions. I think @luboslenco already has a plan and will stick to it.

I could care less if low-end lighting is drop, it's not that important to me. I can definitely see its usefulness for creating games for devices like IPad's. The wording about dropping older API made it sound like lubos was dropping support for low end platforms, that's the only reason I brought it up.

Nodragem commented 4 years ago

I think you need to communicate more with your community, because many people do not know about your monthly releases ^^ See this recent video on Armory: https://youtu.be/lwdVwMTnCm4

trsh commented 4 years ago

Video on point!