Better UI elements, guides, hierarchical options, rules, etc

[Anyeos]

An enhancement to UI First of all, I will try to work on this by myself. I only want to put it here to discuss and improve the ideas what I will write next.

The proposal

1. Better actual UI organization. There are a lot of things to touch on parameters and touching a lot of numbers is some slow for me. Worst if it is organizated by only a Select Box. A better aproach can be put all on a hierarchical manner. I still don't know how on Blender that can be done, but maybe something like the outliner. I am thinking if is possible to replace the numbers by a slider. Here are a guy that made a widgetset for Blender: https://github.com/jayanam/bl_ui_widgets

2. Guides and rules We can have visual guides and rules around the character. So we can choose that particular parameter (ie: right eye) by clicking over the guide. And when it is selected it can be higlighted too so we can see what we are modifying.

For clarify I will try to implement all above for myself as I said before, but I publish this "issue" so we can discuss this. I am open to any idea or technical details and so.

[Anyeos]

Proposal for some modifications to the actual UI The elements from (top to bottom) "CREATION TOOLS" to "Random Generator" can be leave as is actually. The other elements can be converted to tabs that will change completely the content of the middle group. An example is the MakeHuman addon that uses buttons as tabs. I suggest using tabs for: Body Measures, Automodelling Tools, Rest Pose, Skin Editor, Finalize Tools and File Tools. The "Display Options" can be as is actually too.

Basically the tab approach is for things that you need to concentrate one by one and too it group things that are non destructive.

The elements from top are destructive or you are on risk of mess all your parameters (ie: Ramdom Generator).

So we will have three groups:

1. Top. Group of destructive or risky things that we must use at first.
2. Middle. Group with tabs for non destructive things that we need to pay attention one by one (so for that the tabs).
3. Bottom. The visual thing that we can always touch just to speed render time or to look an hq version.

That are my suggestions for now. When I have the time I will try to implement it.

[Anyeos]

Suggestion about "Body Measures"

1. Each category can be a toggle button. So you can just toggle it to have the parameters visible on the panel or not.
2. All the input box can be converted to sliders like. As the documentation of Blender API say it can be achieved just putting the value of "subtype" to 'FACTOR'. So we will get a more visually aproach instead of only a number.
3. The parameters name can be more user friendly too (anyway the real name can be get overing the mouse on the slider). We can use a main label for the group.

[Anyeos]

I have implemented some of the above things:

init.py.patch.txt

[animate1978]

Hello :)

I am not really familiar with patching, I did look through the code though and manually copied some of the changes. Feel free to fork the repository, if you wish.

I like the suggestions and some of the code I copied will be used, that subtype='FACTOR' really makes a huge difference in the UI alone.

[Anyeos]

The patching command is something like this: patch -p0 < file.patch But I did a mistake on the file directory so it will not work correctly. Instead you will need a -p of a higher number: patch -p5 < __init__.py.patch.txt

Anyway you already manually applied the code so there are no need for patching right now :-P

[Anyeos]

The actual code not did a lot of modifications. The screenshot shows it. What I modified:

1. the subtype='FACTOR' thing.
2. Grouping the main elements on 3 big groups.
3. Userfriendly names for the Body Measures parameters.

I am satisfied with the result. I don't think the tabs will be much better, or the toggle button for each category. What I did was enough for me.

I don't want to make a fork because what I need is already covered. But if you think it can be more practical I will do a fork later with all the changes what I want to include and you later can choose what changes apply to your original MB-Lab. If you prefer that approach I will do it.

[ldo]

Re patching: “patch --dry-run” is useful for testing out whether a patch will apply cleanly, without actually modifying any files.

patch is basically a tool that reads diffs in the format produced by “diff -u” or “git diff” and applies them to change the first version of the files into the second version.

[TetoTheSquirrelFox]

@Anyeos, @animate1978 is pretty busy on another subject for the moment, and has a hard time to integrate your propositions. Some of them were successfully integrated like cursors look.

As I don't know how to work with Github, I did my thing on my side, but I tried to keep what you wanted : 3 sub-panel for topics that can destruct character shape by a new one, the non destructive tools, and other things for the display and save/finalize the character.

So at the end I have this :

And I can show in the same time one tool of each sub-panel, like this : Does this fit what you want ? (I propose it to @animate1978 anyway, because that looks cool, but you are the original author of course)

[animate1978]

Oh that does look good, it is a nice separation of the different tools.

I have been busy with Toon Girl JSON export process that I haven't gotten to the UI yet so thank you @TetoTheSquirrelFox for taking the reins on this.

[Anyeos]

@Anyeos, @animate1978 is pretty busy on another subject for the moment, and has a hard time to integrate your propositions. Some of them were successfully integrated like cursors look.

As I don't know how to work with Github, I did my thing on my side, but I tried to keep what you wanted : 3 sub-panel for topics that can destruct character shape by a new one, the non destructive tools, and other things for the display and save/finalize the character.

So at the end I have this :

And I can show in the same time one tool of each sub-panel, like this : Does this fit what you want ? (I propose it to @animate1978 anyway, because that looks cool, but you are the original author of course)

That is something that I already did. Just check my patch, it is easy to understand, the new code is prefixed with a + (plus) sign. And if you use friendly names for things like mass, age, and so, it is more easily understandable. But you will not notice that until dont see it. And for that I created a function that just deletes the prefix if there are one. If the input string is "character_mass" the resulting string will be "mass". And that does not affect the behaviour of the code because I use only the parameter that is declared as "human readable name", so it is safe to put any string there. It only will affect the display but not the function.

[animate1978]

@TetoTheSquirrelFox - the GUI has some bugs in it, I will take a look at it, but so far the Auto modelling tab produces an error

[TetoTheSquirrelFox]

@TetoTheSquirrelFox - the GUI has some bugs in it, I will take a look at it, but so far the Auto modelling tab produces an error

Bug fixed, sorry about that. Bad variable name. Double checked other tabs THIS TIME and all seems good. Pushed the fix on Github.

[animate1978]

Since we are on a GUI topic there is something I have been wanting to add to MB_lab I just haven't figured out how to just yet, which is to allow users to change shader colors in the MB_Lab UI.

There is a lighting addon called Gaffer which can be found here - https://github.com/gregzaal/Gaffer

I am going to look over the MB-Lab code and see what I can do

[TetoTheSquirrelFox]

Careful, the author asks for money if user likes it, so don't copy it too much ! ^^

[animate1978]

Oh no I won't be copying much, if anything, just the idea.

I remember one of our guys had mentioned somewhere this was possible I just need to find out how lol

[TetoTheSquirrelFox]

So, since @Anyeos suggestion, I started something, that is transparent for the user for now. When the user starts a session, all data to handle a model is stored under /data/ I think, as @Anyeos, that the mods from other creators that are new model, or the new model that is being made, should be in their own /data/ directory. The sub directories don't change of course.

So a very simple way is to change one method, get_data_path in file_ops, as it's the method always called when we want to have the path easily. What I changed :

• If we call the method with a name, or an humanoid instance, the /data/ directory is stored as a static variable and used each time we call the method.
• When a humanoid instance is created (in the beginning of a new session for example), the /data/ directory is saved, if "data_directory" is in the config file.

@animate1978 , if you agree with this, it could be used for later, when multiple models will become a reality. (but for that, all code must be checked to be sure that /data/ directory is always good, I think it's not hard to do).

(I tried to create a session and play with it : no suspicious things occurred)

[TetoTheSquirrelFox]

From a tutorial I discovered something very interesting for UI style I think.

What do think that instead of this :

We have this :

The look is way more interesting and Blender-like, isn't it ?

And thing takes seconds to change in the file. For example this : becomes this : Way more fashion, no ?

Edit : So cute and sooo compact :

[animate1978]

I do like this GUI change. I will be doing merges soon so I can play around with the changes that have been done.

[Anyeos]

Nice work guys! I didnt suggested something like the UI revamp because I respected the original design but I prefer a more compact one if you ask me.

[animate1978]

Did some editing to the Pose and Animation box, this was unchanged from Teto's GUI work. Now it conforms to the rest of the look.