A new tab for tools about edit / creation of a model [Face expressions done]

[TetoTheSquirrelFox]

What's this ? As I developed a morph editor, and Animate1978 develops his own tool for creating a new model, it's pretty obvious that sooner or later that MB-Lab will be a complete tool for creating characters from model to the shader. The list is pretty big.

But the size taken by the tools could be huge very fast and could bother the readibility of the addon, in an user point of view

Proposal : a new tab Like this.

But I'm not happy with that : I don't think that those 4 main categories are good. I'm thinking more about this :

1. Model
2. Weight painting
3. Muscles
4. Phenotype
5. ...
6. Morphs
7. Shaders
8. Config files <- character_config.json for example, I think that it's possible to edit it directly in Blender.
9. files management.

What I propose anyway is a framework for the next level of the addon. Separate the tools for a simple user that just want to create characters developed by others, and the creator himself. The more everyone here go deep inside the addon, the more that all can be customized and done by anyone who has skill in sculpting, because everything can be done in Blender, so can be saved in files because Blender is an opened soft.

Additional context I first tried to do this in another add-on, to avoid polluting the actual. But it doesn't work. At all.

So what do you think about this ? Animate1978 / team, do you like the idea or not ? (I won't be mad if you don't like, it's just a suggestion). I could also do a fork, do my stuff and integrate it after it's done ? (I mean, the framework, not all the tools inside)

[animate1978]

I think it's a great idea actually. I believe it would need to be it's own repository... which is totally fine really. This can be discussed. This way people can activate either option, one for creation, one for development. Or both if they so choose. We can work on the name at a later time, MB-Crea is a bit odd.

[animate1978]

As a note Rigify for MB-Lab works hand in hand with MB-Lab if we can approach it the same?

https://github.com/danielenger/Rigify-for-MB-Lab

[TetoTheSquirrelFox]

No problem for the name. Crea means creation, of course, to be different of Dev, but whatever name will be good. Yes, I was thinking of rigify (not the addon itself, that looks very good and useful), as a way to regroup other stuff in one place.

I was thinking a lot about this, and here are my conclusions :

1. there are 2 types of creations. The user who want to create a compatible model from scratch, and want to create anything, even the muscle system, and the guy who wants just create stuff like morphs, or just wants to adapt things (like rigify) to existing models.
2. So 2 big categories : adapting tools and compatibility tools. The first regroups all tools like rigify, that uses a finalized model made by MB-Lab, and adapt it for something. And the second is for creating a compatible model from scratch.

For this last point I think that the best is (don't hesitate to tell me if I'm wrong), the creator should be able to start from a model made with Blender, and save any part needed in order to be fully compatible with the engine. It's a difficult task, because making a compatible model by pressing a single button won't be possible. And trying to do something by taking the model somewhere, the muscle system elsewhere, and so on, is note possible to manage. So, I think that the best way to do such thing is to have a kind of check list, in a special directory, where the creator write all files needed. And I think that the most efficient way to avoid any problem is to say : create you model with Blender, model, muscles, morphs (optional), rigging system, and so on, and when it's done, create a compatible model by using dedicated tools. This way, we can imagine a tool that can say, your model is fully compatible, or it lacks this and that. (So I think that my morph creator will be better in the first category)

Huge work, no doubt. But if my proposal is accepted (or another one of the same kind), it would be just a matter of time to finish the tool. And something needed at first, imho.

I'm starting something, in my own fork, and I'll post news here.

[TetoTheSquirrelFox]

How it goes so far : 2 big categories

1. Adaptation tools (for rigify, morphs...). Basically tools for change something, not start from scratch
2. Here we go, if we have a new model and want to transform it to be a compatible model for the engine.

Just an example when choosing adaptation tools: I put my morphing module here. You can see there's a problem : No compatible model is selected, so a warning message is shown and you can't choose anything. Of course if you choose a model, everything comes back to normal.

In my fork the morph creator is already modified. And I found few little bugs. Not big ones, but I don't know if they could become big with other systems like Apple. Animate1978, tell me if you want the corrections.

Tomorrow I start to populate the rest, I hope to have a fully finished framework before the next week-end. So we could discuss on it and decide if it can be in the addon or not.

[TetoTheSquirrelFox]

Here my temporary framework about what I think that creator do to have a fully compatible model. Tools under "Adaptation tools"

1. Rigify : Integrate the addon made by Daniel Enger to put Rigify in a model (if he agrees)
2. Blenrig : Same task but with Blenrig. This one is complicated, just to use it, but is very advanced (more than Rigify I think) and I started to learn it and I like it (for now).
3. Morphs Creation
4. Base expression : Basically morphs for expressions. Base, because after that we combine them to make final expressions.
5. Final expressions : The tools are separated because they don't work the same way.

I personally think that it's important to have different rigging systems. imho, the one made by Manuel is kind of outdated. Good for games, not for animation. But I can be wrong, please tell me if I am.

Compatibility tools (maybe the name is bad). Tools to create a fully compatible model for MB-Lab, with tools to create and manage config files. Titles are self explanatory.

Is there any lack of something ? What do you think ? Shall I continue, or not ?

Also, I've seen that there's a new file, numpy_ops (what does mean npz ?), where many methods could replace the ones I did for my morph creator. The code is very compact (very skilled, mine looks like if...then...goto in comparison) so little explanations would be appreciated (not about numpy itself, I have the documentation).

Edit: Behavior for morph creator is better now, when no compatible model exists.

[Noizirom]

I use the numpy .npz files to save presets for the hair shaders. It's not really complicated once you get the hang of it. It's similar to saving and loading .json or any text file. The .npz are binary files. I like them for this task over .json files because once a file gets larger it takes longer to load, but .npz I can load only the info I need without having to load the whole file to memory. I've updated the numpy_ops file with the Hair engine. I re wrote some functions. The functions at the bottom are the latest. It can be found @ https://github.com/Noizirom/MB-Lab/tree/dev

Make sure it's the Dev branch and not the master branch.

On Mon, Feb 10, 2020, 4:48 PM TetoTheSquirrelFox [email protected] wrote:

Here my temporary framework about what I think that creator do to have a fully compatible model. [image: image] https://user-images.githubusercontent.com/59537161/74192120-2c74ba80-4c55-11ea-89c6-350823d2caee.png Tools under "Adaptation tools"

1. Rigify : Integrate the addon made by Daniel Enger to put Rigify in a model.
2. Blenrig : Same task but with Blenrig. This one is complicated, just to use it, but is very advanced (more than Rigify I think) and I started to learn it and I like it (for now).
3. Morphs Creation
4. Base expression : Basically morphs for expressions. Base, because after that we combine them to make final expressions.
5. Final expressions : The tools are separated because they don't work the same way.

I personally think that it's important to have different rigging systems. imho, the one made by Manuel is kind of outdated. Good for games, not for animation. But I can be wrong, please tell me if I am.

[image: image] https://user-images.githubusercontent.com/59537161/74192692-49f65400-4c56-11ea-8e75-d727816cc154.png Compatibility tools (maybe the name is bad). Tools to create a fully compatible model for MB-Lab, with tools to create and manage config files. Titles are self explanatory.

Is there any lack of something ? What do you think ? Shall I continue, or not ?

Also, I've seen that there's a new file, numpy_ops (what does mean npz ?), where many methods could replace the ones I did for my morph creator. The code is very compact (very skilled, mine looks like if...then...goto in comparison) so little explanations would be appreciated (not about numpy itself, I have the documentation).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/animate1978/MB-Lab/issues/234?email_source=notifications&email_token=AKYHC3WUHLL3AQHWZDCRERLRCHDUVA5CNFSM4KSAIF52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELKNPAY#issuecomment-584374147, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYHC3TCSJMHNWK24HVZACDRCHDUVANCNFSM4KSAIF5Q .

[Noizirom]

Btw if we just want a character creator that just recreates characters, that would be easy. But what we want is a character that can be morphed from a base model. The biggest issue with that is remapping the verts, faces, etc. For repeatability. I kinda think if we used empties for morph targets like the old makehuman used to have. Just a thought, because it would be easier to repeat morphs on a random character by controlling the empties versus mapping all the verts for each character. I hope that makes sense.

On Tue, Feb 11, 2020, 5:02 AM Zion Hill Hill [email protected] wrote:

I use the numpy .npz files to save presets for the hair shaders. It's not really complicated once you get the hang of it. It's similar to saving and loading .json or any text file. The .npz are binary files. I like them for this task over .json files because once a file gets larger it takes longer to load, but .npz I can load only the info I need without having to load the whole file to memory. I've updated the numpy_ops file with the Hair engine. I re wrote some functions. The functions at the bottom are the latest. It can be found @ https://github.com/Noizirom/MB-Lab/tree/dev

Make sure it's the Dev branch and not the master branch.

On Mon, Feb 10, 2020, 4:48 PM TetoTheSquirrelFox [email protected] wrote:

Here my temporary framework about what I think that creator do to have a fully compatible model. [image: image] https://user-images.githubusercontent.com/59537161/74192120-2c74ba80-4c55-11ea-89c6-350823d2caee.png Tools under "Adaptation tools"

1. Rigify : Integrate the addon made by Daniel Enger to put Rigify in a model.
2. Blenrig : Same task but with Blenrig. This one is complicated, just to use it, but is very advanced (more than Rigify I think) and I started to learn it and I like it (for now).
3. Morphs Creation
4. Base expression : Basically morphs for expressions. Base, because after that we combine them to make final expressions.
5. Final expressions : The tools are separated because they don't work the same way.

I personally think that it's important to have different rigging systems. imho, the one made by Manuel is kind of outdated. Good for games, not for animation. But I can be wrong, please tell me if I am.

[image: image] https://user-images.githubusercontent.com/59537161/74192692-49f65400-4c56-11ea-8e75-d727816cc154.png Compatibility tools (maybe the name is bad). Tools to create a fully compatible model for MB-Lab, with tools to create and manage config files. Titles are self explanatory.

Is there any lack of something ? What do you think ? Shall I continue, or not ?

Also, I've seen that there's a new file, numpy_ops (what does mean npz ?), where many methods could replace the ones I did for my morph creator. The code is very compact (very skilled, mine looks like if...then...goto in comparison) so little explanations would be appreciated (not about numpy itself, I have the documentation).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/animate1978/MB-Lab/issues/234?email_source=notifications&email_token=AKYHC3WUHLL3AQHWZDCRERLRCHDUVA5CNFSM4KSAIF52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELKNPAY#issuecomment-584374147, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYHC3TCSJMHNWK24HVZACDRCHDUVANCNFSM4KSAIF5Q .

[animate1978]

I have been keeping up on this, as well as checking out the code, I am excited for this.

This will push the development cycle back but it is totally worth it I think. This is a huge change and very worthy of being worked on right now, I would much rather release something that I think is a massive development milestone, than to keep making these small incremental releases, at least for something like this.

I will pull your code to a local copy of this dev branch, I have been messing around with the Toon Girl mesh on my Blender 2.83 build so I will be putting your new code into that copy (it is not connected to Git, just a copy of the current dev branch).

I have also paused working on the docs for this release until more has been developed and I can work with it more (so I know what I am writing about).

[TetoTheSquirrelFox]

@Noizirom : Your both messages make sense.

1. The first one : Thanks for the explanation, and I agree it's useful. It's just that for morphs I have to work directly in .json because the engine works with .json. I mean, we could change the type of files used by MB-Lad, and why not, especially if dozens of contributors make new models, morphs and so on. But I just suggest to do that only in the end when all is fine. Because .json is human readable. ^^
2. Yeah I was thinking about it too. For af01 for example, there are more than 330 morphs ! Huge. The best to do would be to superimpose the 2 models (the one with all morphs, the new one) and link the surface of the 2nd with the 1st. After that (...) it would be a piece of cake (we do the morph with the 1st, and save the changes as a morph in the 2nd). And we could correct the result directly with the tool. Tedious and long, but not very difficult. But for the moment it's waaaay beyond my skill. ^^

@animate1978 : if this goes to its term, it will be simply an addon that could create humans, but also cats, horses, ... About the releases, you do what you want, you are the boss. I just think that doing a release with morph tool would bring you many new users and potentially new collaborators for other tools we have to write, and I won't be able to write all of them, unfortunately. ^^ But you do what you want, again you are the boss, and it's not because of my ego I suggest you a new release. I'm perfectly OK to wait.

[Noizirom]

Another option that I thought of, could be we use a base mesh for morphs and transfer the shape keys, then bake those changes to the finalized mesh. Then we could avoid having to map meshes but still be able to use MB lab morphs. We might not need to create new morphs, just transfer the old ones to the new mesh. I'm not sure if anybody mentioned this before, I apologize if they have.

On Tue, Feb 11, 2020, 11:55 AM TetoTheSquirrelFox [email protected] wrote:

@Noizirom https://github.com/Noizirom : You both messages make sense.

1. The first one : Thanks for the explanation, and I agree it's useful. It's just that for morphs I have to work directly in .json because the engine works with .json. I mean, we could change the type of files used by MB-Lad, and why not, especially if dozens of contributors make new models, morphs and so on. But I just suggest to do that only in the end when all is fine. Because .json is human readable. ^^
2. Yeah I was thinking about it too. For af01 for example, there are more than 330 morphs ! Huge. The best to do would be to superimpose the 2 models (the one with all morphs, the new one) and link the surface of the 2nd with the 1st. After that (...) it would be a piece of cake (we do the morph with the 1st, and save the changes as a morph in the 2nd). And we could correct the result directly with the tool. Tedious and long, but not very difficult. But for the moment it's waaaay beyond my skill. ^^

@animate1978 https://github.com/animate1978 : if this goes to its term, it will be simply an addon that could create humans, but also cats, horses, ... About the releases, you do what you want, you are the boss. I just think that doing a release with morph tool would bring you many new users and potentially new collaborators for other tools we have to write, and I won't be able to write all of them, unfortunately. ^^ But you do what you want, again you are the boss, and it's not because of my ego I suggest you a new release. I'm perfectly OK to wait.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/animate1978/MB-Lab/issues/234?email_source=notifications&email_token=AKYHC3TVTMQFL5DB3PS76TLRCLKADA5CNFSM4KSAIF52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELNFXXI#issuecomment-584735709, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYHC3W5WMLV4CZ4CCQMJHLRCLKADANCNFSM4KSAIF5Q .

[TetoTheSquirrelFox]

Nope, you're correct that could be good too. The only problem for the moment is that Blender can't save shapekeys (separated to the model I mean), and you can't transfer (except one by one) from one model to another. It seems that it's on the works, though. Maybe I'm wrong. But yeah, we definitively need this tool, especially if models available explode.

[ldo]

Let me suggest avoiding putting binary files into a source repo. Text files are not just human-readable, they can also be managed with tools like diff and patch. This is good for seeing what has changed from one version to another. It also makes it more feasible to do merges from different branches.

[Noizirom]

Fblah has a shapekey transfer addon that we tried to adapt to MB lab. At the moment I can copy and transfer shapekeys but I had a problem where it copied the shapekeys set to 1. I'm going to work on it some more.

On Tue, Feb 11, 2020, 3:07 PM ldo [email protected] wrote:

Let me suggest avoiding putting binary files into a source repo. Text files are not just human-readable, they can also be managed with tools like diff and patch. This is good for seeing what has changed from one version to another. It also makes it more feasible to do merges from different branches.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/animate1978/MB-Lab/issues/234?email_source=notifications&email_token=AKYHC3ULZSQDOYMVDZCZNKTRCMAPBA5CNFSM4KSAIF52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELN35EY#issuecomment-584826515, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYHC3QSD534U4THI6QNRLLRCMAPBANCNFSM4KSAIF5Q .

[Noizirom]

@Ido the binaries are easy to access and would only contain preset information. Changes will be made by the user meaning the information held will be different among users. This information saved will be something the user would change in the program. It's not like the .json files where the information is used to build the character. I like them because of the memory management and speed.

On Tue, Feb 11, 2020, 6:18 PM Zion Hill Hill [email protected] wrote:

Fblah has a shapekey transfer addon that we tried to adapt to MB lab. At the moment I can copy and transfer shapekeys but I had a problem where it copied the shapekeys set to 1. I'm going to work on it some more.

On Tue, Feb 11, 2020, 3:07 PM ldo [email protected] wrote:

Let me suggest avoiding putting binary files into a source repo. Text files are not just human-readable, they can also be managed with tools like diff and patch. This is good for seeing what has changed from one version to another. It also makes it more feasible to do merges from different branches.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/animate1978/MB-Lab/issues/234?email_source=notifications&email_token=AKYHC3ULZSQDOYMVDZCZNKTRCMAPBA5CNFSM4KSAIF52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELN35EY#issuecomment-584826515, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYHC3QSD534U4THI6QNRLLRCMAPBANCNFSM4KSAIF5Q .

[TetoTheSquirrelFox]

Fblah has a shapekey transfer addon that we tried to adapt to MB lab. At the moment I can copy and transfer shapekeys but I had a problem where it copied the shapekeys set to 1. I'm going to work on it some more. …

Yes please. ^^ And since it's done it will be another useful tool.

[TetoTheSquirrelFox]

Short story, I'm tired. ^^ So that I've done tonight, and I won't explain much :

Basically it's a mechanism to create a "project" where all files created later to have a compatible model for the engine will be saved. Dedicated directories and so on. And a file for all information about this project can be saved / loaded. It's not perfect, but is already fully functional. It's just that when loading a project, I can't update the StringProperty or EnumProperty shown on the picture (I don't know how). I used a workaround that is good but not perfect.

The point is, as the morphcreator, this is for ensure that names are correct, so after that save/load operations will be automatic. No possibility for the user to choose the file names, there are strict rules to ensure the complete compatibility with the engine.

By the way, as usual, I use snowflake when save/load operation is automatic, no file to choose. Also, the files are in my fork, dev branch (I think).

[animate1978]

I grabbed your branch last night to just test it out a little and I know it is early in development but is there a reason for the created directories to be so restrictive on permissions, can't even view inside folders? Again not a big deal at the moment since it is so early just might want to change that in the future.

Other than that I am impressed very much with this.

[TetoTheSquirrelFox]

Nope, it's not normal AT ALL that you don't even have permission to view what's going on inside directories. Are you on windows ? I know that makedir can make directories with restricted rights, I figured that by default the user can do everything, it's clearly not the case. Please give me your os, I'll checked it out.

[animate1978]

I am using Ubuntu 16.04 actually at this time, I accidentally deleted my Windows 7 drive like a boss a while ago and have yet to re-install so this is what I am using/

[TetoTheSquirrelFox]

OK, I understand better what's going, on, as there are parameters dedicated to systems like Unix. I'll check that, I just hope that there won't be need to check the system before creating directories...

Anyway, You're the boss ! ^^

[TetoTheSquirrelFox]

So the base expressions tools are done. It took me forever but it's done. How does it work ?

1. It allows you, like morph creator, to make your own base expressions (like ears down, brow up, and so on) or change the existing ones.
2. The files are under \data\expressions_morphs and the files work exactly like other morphs : each expression is a list of vectors that modify the location of vertices.
3. The way the files are handled are equal, except that there are mechanisms to separate in the engine the vectors for morphs and for expressions.
4. what are the differences ? Each expression has the same kind of name, starts with "Expressions_" then the body part, then the movement itself, and if it is for max movement or for min.
5. Base expressions can have _max values, or min/max, but not only _min.
6. Important : each file has an special expression, named (for example) "Expressions_IDHumans_max" with no value. It's a special name used as an identity, and used by the engine to know what the file is for.

The UI looks like this: We can choose to use standard expressions : or to change everything: As the work is reeeaaaally tedious, I tried to allow the user to name its expression as fast as possible. The way the file is saved and related tools work the same way as the morph creator.

I'll try to make the combined expression this week, but I think that I'll face more problems, as there's no existing tool to create combining base expressions, and I think that it won't be simple.

I didn't test this part much. Thanks to tell me if there are bugs. ^^

[TetoTheSquirrelFox]

Small update tonight : Names and ID basically. For ID, I can create one, but for the moment the engine doesn't recognize it. When tools for creating a new model, the expressionengine will have to be changed to accept more than 2 ID (Human and Anime). More than this, the engine loads every expression data bases, so this will have to be changed too. (by the way, why ? I don't know).

[TetoTheSquirrelFox]

I didn't waste my time this evening. As I said in the previous post, expressionengine was made to accept only 2 types of models (humans and anime), for a reason I don't know (maybe Manuel coded quickly to have the things done, and would come back later to improve the code?) And that would be a problem for future models that would not have the same expressions.

So I change things in expressionengine.py in order to allow that.

Surprisingly, it simplified the code (and I think that I can do better, but it's for another time) (changed other few things not shown here)

and I added few methods for later :

@animate1978 : If you agree, you can commit the new file in the main repository (tried expressions with a human and a anime, everything looks good), because it may help you or everyone who develops a new model (and does things manually for the moment ^^ )

Anyway, I continue to work on expression editi/creator, and I think that I'll propose a new UI for the actual expression tool, because... Imagine that we have 80 expressions to display ? Ugly and tedious to use. Needs some improvements here.

[animate1978]

I did some edits, there were a few bugs in the code, my recent commits should fix these. https://github.com/animate1978/MB-Lab/commit/7734dd733c386f3407be730f03218eb42136d751

[TetoTheSquirrelFox]

@animate1978 Thanks, I corrected on my side.

Good news guys, I finally learned how to code EnumProperty that can update their content on fly. It took me 2 days to figure that "items" on entry can be list of tuples, but also methods, but this method must be defined before the enumProperty.... The most difficult was to find an example where the code looks like a lot how Manuel handled Python for the addon.

So I wanted an updated ('ANIMATABLE') enumProperty to simplify the Face Expression editor (the one already available) that user can use when his character is finalized. But the goal is also to use it extensively for the model creator, especially for the characters_config.json, that I want to handle entirely in Blender.

So, about Face Expression editor. For the moment it's very tedious when you don't use the filter, because you have all expressions shown, and you have to scroll up and down to find the one you want. Very, very boring. And pretty useless if the list grows.

So, I propose this : And that's all. If you know the name, you use the filter : (I didn't touch the key frame, and where it is) If you don't know, empty the filter and an enumThing shows up, and you can choose whatever you want, all choices are visible (and in a convenient way, for me) : then you can play with the expression :

I didn't do extensive tests, but it seems to work.

@animate1978 : if you are interested, I changed few files, like Algorithms, where I added a method to get a value from an enumProperty easily.

[Noizirom]

Bravo Teto! Bravo!

On Sun, Feb 16, 2020, 12:40 PM TetoTheSquirrelFox [email protected] wrote:

So the base expressions tools are done. It took me forever but it's done. How does it work ?

1. It allows you, like morph creator, to make your own base expressions (like ears down, brow up, and so on) or change the existing ones.
2. The files are under \data\expressions_morphs and the files work exactly like other morphs : each expression is a list of vectors that modify the location of vertices.
3. The way the files are handled are equal, except that there are mechanisms to separate in the engine the vectors for morphs and for expressions.
4. what are the differences ? Each expression has the same kind of name, starts with "Expressions_" then the body part, then the movement itself, and if it is for max movement or for min.
5. Base expressions can have _max values, or min/max, but not only _min.
6. Important : each file has an special expression, named (for example) "Expressions_IDHumans_max" with no value. It's a special name used as an identity, and used by the engine to know what the file is for.

The UI looks like this: [image: image] https://user-images.githubusercontent.com/59537161/74609507-e606dc00-50ea-11ea-91af-cc51597d331b.png We can choose to use standard expressions : [image: image] https://user-images.githubusercontent.com/59537161/74609527-16e71100-50eb-11ea-8946-1f30d9da1f60.png or to change everything: [image: image] https://user-images.githubusercontent.com/59537161/74609310-45fc8300-50e9-11ea-97e6-697ad2ead250.png As the work is reeeaaaally tedious, I tried to allow the user to name its expression as fast as possible. The way the file is saved and related tools work the same way as the morph creator.

I'll try to make the combined expression this week, but I think that I'll face more problems, as there's no existing tool to create combining base expressions, and I think that it won't be simple.

I didn't test this part much. Thanks to tell me if there are bugs. ^^

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/animate1978/MB-Lab/issues/234?email_source=notifications&email_token=AKYHC3R3X2PGYLNCQ7Z47QTRDF27RA5CNFSM4KSAIF52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4NHZA#issuecomment-586732516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYHC3VMMQSY65RJAID2UHLRDF27RANCNFSM4KSAIF5Q .

[TetoTheSquirrelFox]

Just a few update about my reverse-engineering on base expressions morphs. There aren't used before user finalizes the model, but there loaded since the beginning, in the same time that the regular morphs. So we can use them directly, but I don't know how. So I did a little reverse-engineering; @animate1978 , if it's useful for you (documentation maybe)... Tomorrow, I'll try to show and use them like any regular morph. The big problem I think is that there are morphs with just a _max value. Will it be a problem when creating a prop ?

Anyway (I may update the post) :

Example of read file : \data\expressions_morphs\f_af01_exprs.json

The steps before the file is read :

1. The morphengine is initiated somehow.
2. The expressions files are loaded like other morphs (for morphing body) while --init--
3. The files are loaded with the method « load_morphs_database » → The same method for regular morphs. That means that le data are stored in the same place.
4. Each morph become a dict where the name is the key, and values are a list with bunch of [vertex name, displacement by Vector]
5. Plus, there’s a « self.morph_modified_verts », a {} where each morph name (the key) has a value that is a set with all vertices involved in the morph. 6 And also « self.morph_values », a {} with the morph name as a key, and 0 as value, useful to store the change value.

When are these 3 variables are used ?

1. self.morph_values : in morphengine → correct_morphs(self, names) in morphengine → calculate_morph(self, morph_name, val, add_vertices_to_update=True) in humanoid → combine_morphings(self, modifier, refresh_only=False, add_vertices_to_update=True) ⇒ It’s this method that updates the attached morph.
2. self.morph_modified_verts (only in morphengine) : load_morphs_database(self, morph_data_path) calculate_morph(self, morph_name, val, add_vertices_to_update=True)
3. self.morph_data : in humanoid → init_database(self, obj, character_identifier, rigging_type) in morphengine → --init-- in morphengine → --repr-- in morphengine → load_morphs_database(self, morph_data_path) in morphengine → correct_morphs(self, names) in morphengine → convert_all_to_blshapekeys(self) in morphengine → calculate_morph(self, morph_name, val, add_vertices_to_update=True)

Then, what methods are used by main class, or other classes, that can be used if I want to use the base expressions morphs, and control them, and update model accordingly ?

1. in morphengine → correct_morphs : in humanoid → correct_expressions(self, correct_all=False)
2. in morphengine → calculate_morph : in morphengine → correct_morphs(self, names) in morphengine → convert_all_to_blshapekeys(self) in humanoid → combine_morphings(self, modifier, refresh_only=False, add_vertices_to_update=True)
3. in humanoid → combine_morphings (humanoid only) : update_character(self, category_name=None, mode="update_all") init_delta_measures(self) search_best_value(self, m_name, wished_measure, human_modifier, prop) measure_fitting(self, wished_measures, mix=False)
4. in morphengine → load_morphs_database (morphengine only) : --init--
5. in morphengine → calculate_morph : in humanoid → combine_morphings(self, modifier, refresh_only=False, add_vertices_to_update=True) in morphengine → correct_morphs(self, names) in morphengine → convert_all_to_blshapekeys(self)
6. in humanoid → init_database : --init-- → start_lab_session()
7. in morphengine → load_morphs_database (morphengine only) : --init--
8. in morphengine → correct_morphs : in humanoid → correct_expressions(self, correct_all=False)
9. in morphengine → convert_all_to_blshapekeys : --init-- → class FinalizeCharacterAndImages → execute(self, context) --init-- → class FinalizeCharacter → execute(self, context)
10. in morphengine → calculate_morph : in humanoid → combine_morphings(self, modifier, refresh_only=False, add_vertices_to_update=True) in morphengine → correct_morphs(self, names) in morphengine → convert_all_to_blshapekeys(self)

[Noizirom]

@Teto to be honest, you've probably gotten further than any of us on the morph engine. It's pretty much the "bread and butter" of mb lab. It's the most complex of the engines. The next would be the skeleton. I had originally done some of the deciphering, but I hit a block and started working on tools to make what we're trying to do easier.

On Tue, Feb 25, 2020, 4:35 PM TetoTheSquirrelFox [email protected] wrote:

Just a few update about my reverse-engineering on base expressions morphs. There aren't used before user finalizes the model, but there loaded since the beginning, in the same time that the regular morphs. So we can use them directly, but I don't know how. So I did a little reverse-engineering; @animate1978 https://github.com/animate1978 , if it's useful for you (documentation maybe)... Tomorrow, I'll try to show and use them like any regular morph. The big problem I think is that there are morphs with just a _max value. Will it be a problem when creating a prop ?

Anyway (I may update the post) :

Example of read file : \data\expressions_morphs\f_af01_exprs.json

The steps before the file is read :

1. The morphengine is initiated somehow.
2. The expressions files are loaded like other morphs (for morphing body) while init
3. The files are loaded with the method « load_morphs_database » → The same method for regular morphs. That means that le data are stored in the same place.
4. Each morph become a dict where the name is the key, and values are a list with bunch of [vertex name, displacement by Vector]
5. Plus, there’s a « self.morph_modified_verts », a {} where each morph name (the key) has a value that is a set with all vertices involved in the morph. 6 And also « self.morph_values », a {} with the morph name as a key, and 0 as value, useful to store the change value.

When are these 3 variables are used ?

1. self.morph_values : in morphengine → correct_morphs(self, names) in morphengine → calculate_morph(self, morph_name, val, add_vertices_to_update=True) in humanoid → combine_morphings(self, modifier, refresh_only=False, add_vertices_to_update=True) ⇒ It’s this method that updates the attached morph.
2. self.morph_modified_verts (only in morphengine) : load_morphs_database(self, morph_data_path) calculate_morph(self, morph_name, val, add_vertices_to_update=True)
3. self.morph_data : in humanoid → init_database(self, obj, character_identifier, rigging_type) in morphengine → init in morphengine → repr in morphengine → load_morphs_database(self, morph_data_path) in morphengine → correct_morphs(self, names) in morphengine → convert_all_to_blshapekeys(self) in morphengine → calculate_morph(self, morph_name, val, add_vertices_to_update=True)

Then, what methods are used by main class, or other classes, that can be used if I want to use the base expressions morphs, and control them, and update model accordingly ?

1. in morphengine → correct_morphs : in humanoid → correct_expressions(self, correct_all=False)
2. in morphengine → calculate_morph : in morphengine → correct_morphs(self, names) in morphengine → convert_all_to_blshapekeys(self) in humanoid → combine_morphings(self, modifier, refresh_only=False, add_vertices_to_update=True)
3. in humanoid → combine_morphings (humanoid only) : update_character(self, category_name=None, mode="update_all") init_delta_measures(self) search_best_value(self, m_name, wished_measure, human_modifier, prop) measure_fitting(self, wished_measures, mix=False)
4. in morphengine → load_morphs_database (morphengine only) : init
5. in morphengine → calculate_morph : in humanoid → combine_morphings(self, modifier, refresh_only=False, add_vertices_to_update=True) in morphengine → correct_morphs(self, names) in morphengine → convert_all_to_blshapekeys(self)
6. in humanoid → init_database : init → start_lab_session()
7. in morphengine → load_morphs_database (morphengine only) : _init
8. in morphengine → correct_morphs : in humanoid → correct_expressions(self, correct_all=False)
9. in morphengine → convert_all_to_blshapekeys : init → class FinalizeCharacterAndImages → execute(self, context) init → class FinalizeCharacter → execute(self, context)
10. in morphengine → calculate_morph : in humanoid → combine_morphings(self, modifier, refresh_only=False, add_vertices_to_update=True) in morphengine → correct_morphs(self, names) in morphengine → convert_all_to_blshapekeys(self)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/animate1978/MB-Lab/issues/234?email_source=notifications&email_token=AKYHC3VLFZOOWGV4D7ML5GTREWFJRA5CNFSM4KSAIF52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM5S65Q#issuecomment-591081334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYHC3X5DT2FKOW7MKACWLLREWFJRANCNFSM4KSAIF5Q .

[teto]

wrong github handle; I think you wanted to ping @TetoTheSquirrelFox

[TetoTheSquirrelFox]

Today's fun fact : While dealing with how the morphs are handled, and why morphs for expressions are not in morphs for, well, regular morphing body parts, I discovered that the morphs are stored in categories (that are special objects "HumanCategory" in humanoid.py). BUT, there's a category that is out any category, a special category that Manuel was working on I guess, because I've found no data about it in a .json file or elsewhere in the code : "BasicAsymTest". The name is self explanatory (it is inhumanoid.init_database(...) ).

And I think that for this particular purpose, he decided to create special morphs to put asymmetry in a model. That makes sense. You create a symmetric model because it's way more easier and faster, and you add the asymmetry at the end. Maybe an idea for the future.