Armory 2020 #1545
Comments
|
... if you're moving things to C, would Rust be considered? |
|
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. 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. |
|
@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). 🤔 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 |
|
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:
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 |
|
Cool Spot, looking forward to Kinc-Armory! |
|
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? |
|
@BlackGoku36 - Yes, calling directly into it would require |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 |
|
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. |
|
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. |
|
If I put all opinions together, I recommend the fallowing:
Depends on what games. Remember our drone demo hanging for a Year. Go and finish it! :P
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 |
|
@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. 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 |
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 |
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. |
|
@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 |
|
@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 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. |
Do tell me how? |
|
@BlackGoku36 look at retrospect of releases first |
|
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 |
|
I wonder how we could speed up the development. Can't wait to get my hands on the next version :P |
|
@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. |
Blazor? |
|
Love your work Lubos. |
|
Hello everybody!
Judging by the following: |
I understand it's not cheap for everyone, different standard of living. It's cheap for me only because I'm a freelance artist, so I make money from my 2 RTX 2080 Ti. I use it for rendering in Blender. the RT core definitely speed up rendering. Buying the RTX 2080 Ti for gaming is is bad idea I agree. Like i said game engine aren't for just games nowadays, its becoming increasingly popular for artist to create beautiful pixels. Even Unity added support for ray tracing via DXR, so I would to see ray tracing support with Armory this year or next. Armory is kind of special in that its integrated into Blender so people who want to render animation/still can do it all in Blender once real-time ray tracing is implemented, no need to export out to Unity/UE4/Godot. Armory won't replace UE4/Unity but it has it place in this crazy dynamic ever changing world of intense competition. |
|
Guys take this to the discord or forums pls :( |
|
With Kha, there was the ability to "cross-compile your code and optimize your assets for even the most obscure systems. ..." Does this change that? |
|
Armory was always a little restrictive in regards to the targets supported by Kha because the physics engine was only ever supported in C/C++ and JavaScript, therefore switching from Kha to Kinc does not in itself change anything in regards to the supported targets. |
|
@RobDangerous moving forward with g5 however i guess gles2/webgl will be cut? |
|
Not because of G5, that also works on gles2/webgl and will continue to do so. G5 is not about new GPU features - I repeat that quite often but nobody ever listens. |
|
I expect this could be used with current Armory it is not tied to c++ or js or even Kha, I have not tried it yet. https://github.com/saharan/OimoPhysics |
|
Hi，I can see Armory3d will become the engine in other fields. I can use it to make the visualization project like more complex Verge3d(webgl). Maybe I can use it with MAX/MSP to create media interaction system. In addition, it is easy to write UI interface. |
|
@luboslenco Can we please have an update on the progress? Will Armory take advantage of armorcore? |
|
The original plan stands intact, I have been working on the D3D12, Vulkan and Metal backends, next up is
|
|
That's good news! Btw, the current Kromx(armorcore) binaries for Armory are a bit out of date (VR is broken for example due to the latest changes in Iron and Kromx), what do you think of implementing automatic builds via Github actions so that the binaries are up to date for each monthly release at least? |
|
It should be done asap once things settle down but right now it would be too much for me to keep up. I believe VR was already busted, but it will work better via armorcore/Kinc once finished. |
|
Are there any plans on still supporting hxcpp as a target with iron in c ? The focus of armory/armorpaint seems mostly focused on Krom/armorcore and before that on HL/C. Since hxcpp's GC is better then HL/C's GC and the target that is used on consoles right now with Kha/Kinc is hxcpp maybe more emphasis should be put on that target. Also, Armorcore couldn't be utilised on consoles since the only option would be to use jitless but that would have huge performance costs. I say the focus seems geared towards those other targets mostly because libs that used to use hxcpp as a target, like haxebullet, have been changed to support the other ones more with js and webIDL as defaults. These assumptions might be wrong. |
|
Armory will not be dependent on Kha (Haxe) once ArmorCore is finished, hence no hxcpp / hlc (Kinc has no ties to these). It will be hooked directly to Kinc, all of the engine heavy lifting will be done in C. The option to write traits in Haxe/logic-nodes will stay, but it will also be possible to write traits in C.
|
|
I will word the question differently: If I write haxe traits now, could I be able to use that code on pure native targets. My understanding from what you said is no because haxe will only be supported on Krom/Armorcore. The other question that arises is, how will zui fit into this ? If zui can only be used on the Krom/Armorcore target it wont be functional for native targets for game UI's. Defeating the purpose of armory2d. Maybe we could use the json exported with armory2d with IMGUI though. That may be the reasoning you have. |
|
Can you elaborate on what do you mean by pure native targets? There will be only one 'target', hence the move to C - only the game logic will be (if you choose so) in Haxe. Just to clarify - Krom and ArmorCore will not be the same thing (that's why I renamed it from Kromx to make it clearer). ArmorCore will expose interface specifically for Armory. |
|
A pure native target would be a target that doesn't use V8 and is compiled to c/cpp(HL or hxcpp). Ideally, and from what I gather from what you say, the flow would be the gamelogic will need a GC but not Armory, and Armory c will be useable in haxe and will be able to compile to native targets( like hl or hxcpp)? |
|
No hxcpp / hlc like mentioned - if one wants the GC then the game logic goes through the V8. But if you want to sidestep V8 & GC, you can - via C, Rust, or whatever compiles to WebAssembly (which can be converted to C). It's designed with the C/Kinc in mind first + the ability to sidestep GC. |
|
Ok when you say we can use anything that compiles to WebAssembly so it can then be converted to C you mean by using this wasm2c ? On another subject, if it's the case to prioritize native is their any plans to have access to armorcore/armory with library compilation(by using KINC_FUNC before native functions) so we can use armory from native directly ? Like what ustance and me are doing with our wrapping of kinc to other native langs. Will the webassembly 2 c be preferred as opposed to giving access from a lib to native langs ? FYI I support the change to full or partial native. It just seems unclear what the road to this is considering armory is right now pretty much Haxe bound. If we want to work on this imminent port should we be more in the armory repo or armorcore to create C representations of what we have in the Haxe world say I want to create Trait.c ? |
|
What it's the plan for console support? @luboslenco |
A tool like that or similar, might be also possible to "exploit" the v8 turbofan for AOT compilation, maybe wasm-to-llvm option eventually pops up.
Right now there is plenty on the plate but yes would be nice to do that eventually.
The armory repository should stay intact for the most part, I will take care of the transition where necessary (ie. rewire calls directly to armorcore once ready).
The plan is to use Kinc as usual for that. As for writing logic - it will be ok to use logic nodes, but if the game needs complex logic it will be recommended to use non-jit / non-gc language for heavy stuff. |
|
@luboslenco Thanks for the clarification, but I still don't know how traits can be written in C/C++. The C trait API is very basic https://github.com/armory3d/armory/blob/master/Sources/armory/trait/internal/wasm_api.h ? Am I missing something? or the API still needs to be added here? Thanks |
|
Sorry the API is not yet available. First the iron library has to be ported, working on it. |
|
Thank you very much for your reply. I was just asking if I am missing something. Thank you for all of this great and huge undertaking. |
|
I created an issue #2016 (comment) where I believe the Rust code for web assembly should be more simplified. There is just so much text going on. |
|
@Joe23232 the WASM code looks already pretty neat compare to pure rust and is working. |
|
@onelsonic Is this your code? |
|
@luboslenco 2020 is almost over. Can you inform the community of what has been done and what needs to be done in terms of these plans? I think we deserve some honesty. |
|
nevermind... |
@luboslenco If ever you already have something I would just add to it. |
and others
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!
The text was updated successfully, but these errors were encountered: