With Blender development faster than ever before, the Armory addon is a bit lagging behind. I open this thread to discuss how we could adapt new changes from Blender into Armory3D.
Here the discussing should be mainly focused on adapting to the new upcoming 2.93 LTS version of Blender. Moreover, Armory specific issues do not belong here.
I propose that we separate the Blender-Armory issues into 4 broad categories;
Exporter changes: Here, changes in the new Blender with respect to the current exporter script will be dealt with. For example, name changes of certain settings/parameters.
New features: Here, Any new feature such as a new material node, new parameters. For example in the newer versions of Blender, a new RigidBody feature has been introduced.
UI changes: Here UI specific changes can be adapted. Such as more control over logic node designs, possibility of improved callbacks for live updates and so on.
Deprecated features: Any features/Material Nodes/Data Types removed should be dealt with in here.
That said, arguably, the new 2.93 LTS version is about 3 months from now. But, we do have some ideas about the features and changes from current 2.9.X, which should help us foresee the development needed.
These are my thoughts for further development of Armory3D. Please feel free to discuss any new ideas or changes.
Sounds good to me, we should also discuss how to manage the transition on Github. My proposal would be the following:
We should ask lubos to add a branch (and maybe also a label) for 2.9 for which we create pull requests (you can choose the target branch when opening PRs). Maybe we should open issues for some of the bigger tasks as well, I don’t know. Then, somebody of us can create a “main PR” in draft mode which merges the new branch into master when ready.
I made a small (likely incomplete) to-do list for 2.9 a while ago for the above points:
1. Exporter changes:
Rigid bodies: steps_per_second was renamed, leading to an error on export
The principled BSDF node has a new emission strength input, node indices might be wrong now
The attribute node got an alpha output socket in 2.92, also it can now access custom properties of the material’s user
2. New features
Support for Nishita Sky model: there is a very nice implementation here that is licensed with the Unlicense (so we could just port it over): https://github.com/wwwtyro/glsl-atmosphere. However there is still the open issue of (ir)radiance discussed here. Maybe there even is a preetham implementation somewhere around to have support for all Blender sky models?
Check if the new asset browser can be utilized for better multi-file projects (proxies, maybe even node setup/traits). Also, is there anything we can do with library overrides?
Outliner items now have color tags, we could utilize this to better mark the trait collections in the outliner
Colums can have headings now
Check if some icons changed
I’m not aware of any deprecations so far. Also we should go through a few of the forum posts/issues in the last month to see which are related to 2.9 to identify more issues.
Should we add some checklist somewhere to keep progress of everything? Opening issues for each item would probably be a bit of an overkill. On the other hand, that’s what issues are for. I don’t know, if we do it we should of course combine many small changes into bigger issues (like UI changes, general API changes).
Yes, I also agree with this. It is better to have a separate branch for 2.9 development.
Thanks, that’s a great starting point! We can definitely use this.
Yes, I totally agree. Having a checklist for all changes gives a much better overview. We can of course use GitHub issues for bigger issues that need some discussions. With lists, we could also better categorize the type of issue.
If @timodriaan or anyone has a good idea for a place to host this checklist, please do suggest.
I have no idea, maybe we should create a google docs or office 365 document, or just use a checklist in the main PR with the disadvantage that only one is able to edit it. Anyways we should mirror the checklist to the PR so that the progress will be visible in the PR overview page.
Because nobody answered so far: here is a small poll about where we should have the checklist
Google Docs
Office 365
PR checklist is sufficient/ok
Other (see answer)
0voters
Google docs and office 365 do not require you to have an account if I’m correct, I could share a link via PN (everyone wanting to contribute should then tell me so I can send the link). Having a checklist that everyone involved can edit has the advantage of being able to claim a task if there doesn’t exist an issue for it.
Now, if you want to contribute, please send me a PM and I will send you the link. If you have a google account it’s even better because if every contributor has one we can make the document publicly available and only invited people can edit it (I would need your email address for that I think?). Otherwise we would not publish the link, that’s ok too.
Oh, and if you’re undecided if you want to contribute, that’s ok too, you can still get access to the document.
If you want I can create an issue to ask lubos for a 2.9 branch?
I’m currently updating the Blender UI a little bit because there were some changes in 2.9: margins and alignment have changed and columns can have headings now (some example screenshots). Because designing a UI depends a lot on personal taste, I want to present my prototypes and ask for your opinion before opening a pull request:
Armory Project panel
Some options are now grouped together to have a clearer layout, what do you think of the column headings on the left? They’re very vague. Also, what about the order of properties?
Postprocessing panel (part)
Some options are now grouped together and there are column headings (the checkboxes instead just say Enabled). What do you think of that? It still looks unclear and ugly in my opinion. Especially when a postprocessing effect is active (not grayed-out), the heading is not really different from the property names.
Also, does anyone know if the Micro Shadowing option is in any way related to SSRS?
[left: before, right: after]
Some options like letterbox now fit in one line to make the UI more compact. It’s still a bit cluttered but there is a lot less scrolling now.
Material blending panel
Now the options are grouped together and the alpha group is now marked as such. If the layout is wide enough, the groups are ordered next to each other (flow layout).
I would really appreciate some feedback, thank you
@E1e5en There were quite some changes in the layouts, maybe the bug from here is fixed now?
@Naxela whats the current state of the lightmapper and Blender 2.9? Is there a lot of work that needs to be done? There is at least one small issue that I know of which is described in the todo list in the post above, maybe you can look into that if you get some time?
I understand that the Armory Project panel is still a bit vague, but I think there must also be an “Export” Flag. As for my understanding, Minimize Data and Export Tangents are more of exporter options, not sure though.
Post-Procesing feels much nicer and ordered now!
The Compositor panel also looks good. However, could the different settings such as “Volumetric Fog” and “Auto Exposure” be spaced apart a bit? Like in the Post Processing panel, This way they are more distinguished.
These are just my opinions. Feel free to correct me if I am wrong somewhere.
I agree, the UI setup is quite good and I like how it is ordered much better with coherent grouping. Especially the compositor panel fits nicely!
As for micro shadowing and SSRS, it’s not directly related, as micro shadowing is a simple shadowing effect that works on the occlusion fresnel, whilst the SSRS is traced, although I’m not sure how it works exactly other that it deals with projection and does something with the view and depth buffer, but effect wise I guess they can be grouped as it’s often (imo) visually similar.
I was wondering, does material blending work for others? Or does the error described here still persist?: https://github.com/armory3d/armory/issues/1615 - I was thinking of looking into it with a fix if it’s not just me.
As for lightmapping, there’s a few fixes that needs to be done due to 2.91 API changes impacting the following areas:
Scenes/Collections
UV projection algorithms (Smart Project has been ported from Python to C)
Python binary paths are changed, I think multiprocessing options was the reason behind this
Due to changed nodes, integrated denoising needs to be fixed too
Shifting the same file between 2.83 LTS and 2.91 makes the lightmapper throw errors due to nodes.
Key bindings are changed; The one listed in the to do list you mentioned
I’ve been getting a lot of enquiries of whether I could make The Lightmapper work for 2.91 too, so once it’s done for the the standalone addon, the fixes should come automaticlly to the Armory lightmapper. Hopefully it won’t be too much work.
Yes that’s true (although Export Tangents probably fits in both categories) . What about renaming Build to Export or Exporter and maybe move Loading Screen into Runtime?
They really should, it makes everything much more clear. I was a bit afraid of it because it kind of suggests that fog and auto exposure settings belong to different “categories” (all the settings above are much denser), but I think having a bit more space really helps to better understand the interface. New layout (I also moved the lens flare and fish eye setting further to the bottom which is also cleaner):
Actually, there should probably also be a separator (blank space) after the tonemap setting at the top.
Then I guess it could be moved a bit up or down, right? It now looks a bit misplaced in between all the other option “blocks”. New layout (still needs some work):
Maybe it’s a bit off-topic, but since it’s in the means of updating/redesigning UI anyway, one thing that always bugged me is that it may be a bit confusing to distinguish the settings for Armory’s renderer and the ones for eevee. I think just the “Armory” in front of the panel is not enough, which would probably lead to confusion for new users. Is there a way to group armory or eeve settings as a whole like in another panel, or is it not possible to do something like that in blender (grouping panels that are “owned” by blender)?
Probably this may conflict with the idea of straight blender-to-armory, but for the time being I think it’s better to keep them distinctly separated until there is a plan to emulate eevee in armory
I totally agree with you, I also find it a bit confusing and annoying sometimes. I did some research about that yesterday and unfortunately Blender is quite limited in that regard, it is not possible to add a new tab to the properties editor for example even if the Python API for such a functionality would probably look almost the same as the panel API. There are a few alternatives but all of them are not that great in my opinion:
It is possible to give panel headers an icon (but that’s not “Blenderish” and attracts too much attention IMO)
Some panels could be moved into side bars of editors, but that would decentralize Armory a bit and makes stuff harder to find… Maybe some trait property things can be duplicated to the sidebar however.
It is not possible to create custom editors (there were plans for it, I couldn’t find out why they got cancelled). However it is possible to somehow use existing editor types as the base for other editors, like the Scatter addon does it (source) with the preference editor. I have no clue however how it’s done, it’s a paid addon. Also, I don’t know if that is only possible with the preferences editor. In general, the scatter addon UI is quite impressive.
It is possible to embed imgui in Blender which can be overlayed either in an empty node editor for example or over the 3d view, but it’s ugly and just too much work.
Also adding Armory as a render engine could work (probably less panels would show up), but if I remember correctly Lubos decided against that while he was still working on Armory. I think it has a lot of disadvantages (loosing Eevee preview and many other settings)
Ok, so I found a hack with which a “cheated” custom Armory properties panel is possible, but it has some flaws:
It’s currently using a Python icon for the Armory tab, but it can be replaced later
This works because there are a bunch of happy coincidences in the API:
You can append/prepend to the tab bar drawing function
You can create another EnumProperty that holds all custom tabs, unfortunately you can’t update the internally used property that holds all default tabs (=> no real custom properties panel)
Set the options of the new EnumProperty to ENUM_FLAG so that its only value (the Armory tab) can be deselected (this enables multiple selections but we only have one item in it)
If the new tab is selected, set the properties panel “context” (active tab) to render.
Now, override/wrap the poll() function of all panels in the render context to additionally check if the Armory tab is active
So the Armory tab is actually the render tab, but when drawing the UI there is a selection based on whether that tab is active or not.
As you can see in the render properties, you can even draw on top of the properties panel without having a sub-panel (see the Render Engine dropdown for example), which has also a poll() method and to which you can also prepend/append drawing functions. This makes it possible to have even more freedom with the UI, you are not bound to panels. For example we could permanently stick the Play/Clean buttons to the top with that.
Flaws:
You can check for property updates on the new tab(s), but not on the existing ones as far as I know. This means that you have to deselect the Armory tab with Shift + Click which is bad (otherwise you could deselect it when another tab is activated). There might be ways around that with the msgbus module but that will not work if you switch back to the render panel as it is already active (-> no update triggered).
The new search menu doesn’t work yet with the Armory tab, but I think it can be made possible
When – for example – pinning the current material in the top left corner of the material properties area, the Armory tab doesn’t hide. I don’t know yet if this is possible to implement.
Two workarounds
Replace the new Armory tab with a toggle button (BoolProperty under the hood) that just decides for ALL tabs whether only the Armory panels should be visible. Actually, I kind of like this solution even if it doesn’t give us as much freedom with the UI if we decide to keep the Armory UI visible even when this button is not activated (that’s something to discuss then). Problem: the toggle button would be a few pixels too far to the left compared to the tabs, I’ve spent half an hour searching for a way around that but I didn’t succeed. You could replace this with an icon and a checkbox below that, but it would probably look ugly.
Introduce a 2-layered tab bar. There would be a Armory button at the bottom and if you click on it, the default tabs collapse into a Blender button and the Armory tab opens. To open a default tab, you’d first have to click on the Blender button to close the Armory tab and to go back to the default tab view. This allows us to even add more Armory tabs without having a too big tab bar and it solves the clicking problems mentioned above (like node categories but for tabs). This can confuse users but it’s actually not that counter intuitive. However, the disadvantage is that we need to fully override and copy the tab drawing function, which makes it more dependent of Blender updates. But it would work.
Obviously there is still the option to keep it as it is, I have to do more tests first.
I hope this was understandable to some extent, I’m pretty tired and I want to go to bed but I am too exited to not let you know about my findings today
If we only use appended/prepended drawing then no, otherwise it depends. We can wrap the draw and poll functions so that we call the original functions in the overridden ones. If someone changes them, we still use the changed functions if the other addon is registered first, so Armory doesn’t break other addons. If it’s the other way around, it’s for the other addon to ensure that nothing is broken (also via wrapping so that there is a call stack of draw or poll functions). But I don’t know of any other addon that does this, I think its a solution that nobody used before, so we should be pretty safe anyways.
Thanks for the links, I didn’t know those channels. The pixel offset mentioned above is probably something that needs to be fixed in the Blender layout code, I tried about every combination of rows/cols/splits/boxes you can imagine^^ The tab bar is just not made for any other layouts/widgets. I wish there would be a variable that lets you offset an element by a few pixels, like Zui can do it.
If you (@ everyone) understood the workarounds I paraphrased above, which one do you prefer? New prototype for the second idea (in theory we can now add multiple Armory tabs without having a crammed interface):
Btw, the search menu is fully functional with this, I have no clue why but it’s great
We need some proper Armory icon, I took one from an Armorpaint commit but it doesn’t look that good in the UI (maybe it’s just slightly too large compared to the other icons?):
Found another flaw: it’s not possible to add custom properties to panels, only to screens (layouts) or the entire window manager. So when you switch to the Armory tab, every opened properties editor will switch to it.
I could be wrong, but I think this way will give some work to update for future Blender versions (we can’t expect Blender Foundation to leave this “support”. As you said, even you don’t know why this is working). I don’t know about what is better as i never touched Blender API, but my idea would be to create a second Editor type (or even just copy/paste the properties editor type and remove the Blender stuff from it). This way even the objects tab will be more clean (it have lot of settings and the word “Armory” before each title bar looks like a workaround for me). For tabs that intersects between the Blender properties and Armory properties, maybe is possible to create some kind of “link”? Like for the physics tab. This is just what i think, maybe this thing is a pain to do and i personally don’t care about the UI organization and i will be happy with any layout, but the truth is without an intuitive Ui, newer users may be scared and this is not good for all of us. And thanks for your initiative guys, is really inspiring to see your commitment as always
The “I don’t know why it’s working” was about the new panel search, and I falsely thought that it somehow overrides the poll() method but it doesn’t. So, everything is clear now for me
Regarding the “Blender-dependency”: In my opinion it’s not a big problem in this case as the tab bar layout is probably changed once every 10 years or so, even then it will probably continue to work as we would wrap the original drawing function in our drawing function (Python makes this pretty easy). Basically we just append something in front of the original code. There are a lot of other things that break more often.
But the flaw that I found yesterday is a huge problem unless we decide that it doesn’t matter if the Blender/Armory switch has the same value in all windows (so you see the same panel)… In theory you could dynamically create a tab bar for every properties editor with it’s own enum property but that would be the ugliest workaround the world has ever seen^^ So unless we find a better solution I guess we need to keep the current way. Does anybody have an idea maybe?
Speaking of a better solution:
That would certainly be the cleanest and best way, but unfortunately it is not possible with the Python API (you would have to change the Blender source code and provide custom builds), that’s why I was looking for a way to create a new properties tab. Blender’s Python API is very restricted unfortunately even if it’s huge. On the other hand, that is what makes you creative because you always need to find workarounds. The reason why Armory has a custom node editor is just because of the fortunate circumstance that Blender creates an editor for every node tree type.
Slightly redesigned trait panel, what do you think?
I will remove the task from our 2.9 checklist then.
