mgear-dev/mgear_dist

mGear v.3.x.x distribution repository

mgear_dist's Issues

mgear_dist: update release log

the release log need to be updated

Shifter: Games: Tools for decouple deform and control rig

From @miquelcampos on October 13, 2017 5:25

-export import jnt connections
-Decouple for easy FBX export of deformation joints and geometry

Copied from original issue: mgear-dev/mgear_legacy#64

Setting connector drop-down menu to "orientation" results in an averaged rotation of all IK Ref objects

Describe the bug
If a component's IK Reference Array has multiple objects, and its connector is set to orientation (instead of standard), an orientConstraint is made with an "averaged" offset. This differs from the standard connector setting, where a parentConstraint is made (but offset is maintained).

To Reproduce
Steps to reproduce the behavior:

1. Create multiple control_01 objects (e.g. create 4 of them)
2. Name one control: "hand" (this is optional, but I'll refer to this later as "hand")
3. Adjust orientation on all control_01 objects -- by large amounts
4. In "Component Setting" for each control_01, uncheck "World Space Orientation Align"
5. Add all control_01 objects to hand control's IK Reference Array
6. In "Main Settings" for hand control, change connector to "orientation"
7. Build rig from guides
8. Observe "averaged" orientation on the hand control

Screenshots

Additional information
NOTE: In screenshots, "EPIC_control_01" was used -- however this behavior is identical to the "control_01" component
Maya version: 2019.3.1
mGear version: 3.7.11

Submodule update --init failure on excons

I cannot get a clean git repo setup because of an issue with the excons submodule.

git submodule update --init
error: Server does not allow request for unadvertised object 61f5e5ce4f55ee8f148a92c9b75094dbe62a4047
Fetched in submodule path 'excons', but it did not contain 61f5e5ce4f55ee8f148a92c9b75094dbe62a4047. Direct fetching of that commit failed.

To Reproduce
Start fresh terminal:

git clone https://github.com/mgear-dev/mgear_dist.git
cd mgear_dist/
git submodule update --init

Vendor scripts not getting released correctly with sconstruc

If you define the same exact path twice in the sconstruct only the last one declared is the one been taken into account so if you need copying on the same release folder from different sources you need to place them under the same line as a list.

Synoptic: Replace script jobs by callbacks

From @miquelcampos on August 28, 2017 10:34

EDIT: implement after: mGear: Callback Manager #165
Replace the scriptjobs for visual feedback with callbacks, for a more robust management with several synoptic window open.
Right now only the latest synoptic view has visual feedback for selected controls.

The call back manager should be independent from synoptic

Copied from original issue: mgear-dev/mgear_legacy#52

mGear dist: add QJsonModel submodule and configure scons

Shifter: New components window:

From @miquelcampos on August 21, 2017 2:57

• Folder organization and project component repository
• drag and drop
• duplicate component + edit in external editor
• Guides templates tab
• quick search
  • tags ?

Copied from original issue: mgear-dev/mgear_legacy#45

update menus to str command

setting all submodule menus to match mgear-dev/shifter#86

Allow Dup Sym to mirror extracted control curves

It would be great if I could modify my control curves on the built rig, just for the left/center side, extract control curves to the left/center guides, then dup sym on the left guides and get the control curves mirrored automatically to the right side after build. Would save time modifying guide curves that could be mirrored.

Exporting skinweights on lattice does not save the file

Describe the bug
It seems like there is no filed saved when exporting skinned lattices.

To Reproduce
Steps to reproduce the behavior:
Skin a lattice. Export the skinned object weights. There is no file saved.

Additional information
I haven't had the time to debug it, maybe it's just looking for polygon or curves as an objects to export, but there is usually fair amount of non-linear deformers used in rigging so maybe it's useful to have that exported as well.

mgear_dist: Add namespace into mgear script

When I integrated the namespace system I forgot to add it ass well on the main one

matrixConstrain not loading on windows

Describe the bug
when loading the plugins the matrixConstrain is missing

To Reproduce
Not sure if this is the latest mgear version. It's on the computer of the client

Screenshots

Additional information
Add any other information about the problem here.

Easy installer

create a drag and drop script to install mGear in the user folder

Shifter: Build log control list print

From @miquelcampos on November 3, 2017 21:14

improve the controls printed list by creating a table with the following headers:

• component
• name
• controls list for the component

Copied from original issue: mgear-dev/mgear_legacy#81

Shifter: Guide multi renamer tool

From @miquelcampos on October 19, 2017 4:51

Tool to rename multiple guides at the same time

Copied from original issue: mgear-dev/mgear_legacy#69

rigbits.lips_rigger.lipsFromfile / eye_rigger.eyesFromfile don't seem to work with new json config files

rigbits.lips_rigger.lipsFromfile / eye_rigger.eyesFromfile don't seem to work with new json config files from 3.6.0.
They still work with old config files generated with mGear 3.0.3, though.

To Reproduce
Export json config files for the lips and eyes using the new Facial Rigger on mGear 3.6.0
Try to build using mgear.rigbits.lips_rigger.lipsFromfile(path)

Screenshots

Shifter: Prevent guide component creation on sizeRef Nodel

From @miquelcampos on October 20, 2017 9:43

Add a checker to avoid guide creation on to of the sizeRef node from the Control_01. This will break the build

Copied from original issue: mgear-dev/mgear_legacy#70

Create new sphinx project

The previews Sphinx project is okay but in order to structure it all in a nicer / more understandable way we need to generate a full project from scratch for mGear 3.0.0.

Moving all hard coded rst content/images to the new project is going to be done and then the API documentation generation will be fully automated.

mgear_dist: update __init__ scons template with new module reload

update to match @tokejepsen's new reload function

import skd fails with sdk with more than two keys

while the sdk_io.exportSDKs seems to correctly write SDK with more than two keys, the import with sdk_io.importSDKs is not correct.

Synoptic: filter listed tabs folder

From @miquelcampos on October 5, 2017 8:56

Avoid listing .svn folder or other folders starting with "." on the available synoptic tabs list

Copied from original issue: mgear-dev/mgear_legacy#60

2019 OSX builds - crash during build from selection

Hello! - hope this is the correct place for this :)
I just finished building the plug-ins for Maya 2019 on OSX.

Description
When I import the template biped guide, and 'build from selection' - Maya crashes mid-way into the build.

What is working:

• The plugins load fine.
• I am able to build random modules just fine.
• A template biped rig that was generated on mgear 3.1.1 on windows/OSX Maya 2018 is working fine.

p.s
Build of the plug-ins seem to work perfect on 2018 OSX

To Reproduce

• On Maya 2019 (OSX), use the plug-ins from below, import biped guide and build rig.

The error does not say much, not the standard Maya fatal error:

Additional information
built plugins: https://www.dropbox.com/s/imdxbs1s22u1ior/2019-osx-plug-ins.zip?dl=0
scons build log: https://www.dropbox.com/s/glonggxthhfuw3y/scons-build-log.txt?dl=0

Osx 10.14
Maya 2019
SCons 3.0.1 installed with brew

EDIT:

Further testing shows that the crash is related to the arm_2_jnt01 and leg_2_jnt01.
When these modules are deleted from the template, the build completes successfully.

• parenting them under the root control - still crashing
• unlinking them from the host and references IK etc - still crashing
• update guides - still crashing
• replacing them with any arm/leg module that i am creating - still crashing
• replacing them with other module, like a chain that i am creating - all good.

Investigation continues...

EDIT 2:

Building with 'objects' mode works, any mode above will crash.

So far this actually looks like a 2019 OSX issue, and not related to the plug-ins themselves, but this is just a gut feeling.

dropping support for Maya 2017 and older

stop supporting Maya 2017 and older versions

submodules naming convention

Feature description
Naming convention of submodules

Extra information
Currently the repository consists of different style naming conventions:

simpleRig (camelcase)
maya-math-nodes (dashes)
mgear_core (underscores)

Would you like to standardize it? I personally prefer dashes or underscores, because everything becomes lowercase and easier to guess.

Allow video embeding on the sphinx documentation

Rst and MD files do not allow video embedding... or at least not with sphinx by default.
Need to write an extension for sphinx that allows this.

New drag and drop installer

more info #61

Add BraveRabbit weightDriver to mGear dist

https://github.com/mgear-dev/weightDriver

Release log needs to be mapped correctly to older and newer issues

mGear's uses a custom sphinx extension called changelog_links that reads the releaseLog.rst file and generates the correct links to the issues on gitHub.

Rigbits: Add spring bake function into menu

It would be better if people can access the srping bake function from the menu as well.

Make guide / rig nodes unique

Feature description
Currently, when building a rig from a guide, there are duplicate names in both the guide and rig hierarchies. Would it be possible for the built rig to have unique node names not clashing with the already existing guide?

Extra information
Currently, we are working around this by using long names in our scripting, but we are wondering if that's at all possible without causing any other problems in the framework?

mGear: icons for menus

From @miquelcampos on January 31, 2018 9:3

This is not super priority, but will be nice to have icons for the menus.

Any designer reading this? :)

Copied from original issue: mgear-dev/mgear_legacy#150

Modularisation of mgear

From @mottosso on November 14, 2017 8:31

Hi Miquel,

We talked briefly about splitting mgear up into modules, such that a user could install only the parts of interest and to improve maintainability of smaller parts, as opposed to one large library.

Here's how I see that working.

• Core
• Data
• Extensions

             _______ 
            |       |
     .------| mgear |-------.         core
     |      |_______|       |
 ____|____  ____|____  _____|_____
|         ||         ||           |
| shifter || rigbits || simpleRig |   extensions
|_________||_________||___________|
 ____|___
|        |
|  data  |                            data
|________|

Data

I'll start with this, as it's best suited for splitting apart. The Components, these are the data to an otherwise data-driven core framework. The data determines what can be built and details of how to build it.

Different data in, different rigs out. Simple.

    data
 ____ | ____
\     |     /
 \    v    /
  \       /
   \     /
    |   |
    |_|_|
      |
      v
     rigs

If data were to be separate from the core, then there could be many different sets of data, by many different authors. This enables others to build their own library of rig components and facilitates discussion about the data itself, without getting distracted by the underlying core library.

For example, there could be a discussion about the various ways there are to build a component for IK/FK switching, and compare and contrast their differences. There could be many components out there, each with their own documentation and usage scenarios. A collection of components could have its own website, like how Material Design and Bootstrap is data to CSS, documenting each individual component and thinking about the design of data, separate from the underlying framework.

Core

The core library is what glues the data together. It's contains the mechanism for exposing the mechanisms to the user and how to actually read and make use of them.

In here I see every module under the mgear/ package. The packages in there are what I'd call "extensions".

Extensions

An extension builds upon the core library to form something more specific than mgear itself. Shifter is a good example of this. Shifter implements a data-driven approach to a rig framework and is, I think, the most flexible and powerful of the existing extensions.

The key point here is that mgear is fully capable of existing without these, but these are not able to exist without mgear. The extensions can be developed and maintained separately from mgear, and vice versa. Their own issue tracker, their own release cycles etc. Meaning the cognitive load when trying to understand either mgear or any of the extensions goes down by the amount of code each contain.

Say for example that, as a user, I was only interested in Shifter. At the moment, because it is bundled alongside mgear and the other frameworks, I can't tell whether I also need to learn and understand these other extensions. I can't tell whether making a change to Shifter would break simpleRig and I also can't tell which parts of mgear is actually used in Shifter, or if Shifter is used in mgear (i.e. a cyclic dependency).

Notes

Finally, these are just thoughts. I don't feel I know mgear well enough to say exactly this is the ideal approach. But I do think it lends itself well to being split up as there currently exists a few different frameworks embedded into one repository.

Something I'd like to see which I think would help adoption and maintainability is separating anything compiled from things that need no compilation. I found it really difficult at first to make a contribution to this project because I (1) didn't understand that I needed to build (instructions could help here) and (2) didn't have a suitable compiler installed to actually perform the build. Because of this I wasn't able to actually test what I contributed, and without automated tests we ended up with a contribution that broke mgear!

Here's what I'd like to see..

$ pip install mgear

This would grant a user with the basic framework for building tools with mgear.

$ pip install shifter

Now they'd be able to leverage a data-driven approach to building rigs.

$ pip install shifter-basics shifter-mocap

And now they'd have some data to get started with.

Copied from original issue: mgear-dev/mgear_legacy#94

Lip Joints naming issue with facial rigger

Describe the bug
The lip joints are not named with left and right naming convention. So when working with weights it's not easy to mirror. NGSkintools

To Reproduce
Just setup the face and do some manual tweaks and weight map gets damaged when you do a mirror

Screenshots
If applicable, add screenshots to help explain your problem.

Additional information

Anim Picker issues and Viewport Freeze

Thank you for your continued support on this tool!

Describe the bug
Trying to resize the Anim Picker view will eventually cause the Maya Viewport to stop updating. Maya restart is required after the issue.

To Reproduce
Environment:
macOS Catalina 10.15.4
Maya 2018.5
mGear 3.5.0

• Launch Maya with a new scene.
• From the mGear menu: mGear -> Shifter -> Guide Template Samples -> Biped Template.
• Select the 'rig' object, then build the rig (mGear -> Shifter -> Build from Selection)
• Load the Anim Picker via the mGear menu
• Load the biped.pkr file (Load -> Select File -> biped.pkr -> Load Picker -> OK)

Few issues appear at this point:

• Actually clicking the 'Load Picker' button is hard to do (some misalignment between the button and the highlight area, see the video)
• The view for the picker initially shows only the bottom left portion of the buttons, must be resized with the mouse wheel
• Where the mouse cursor is doesn't correlate with what is highlighted in the picker. The mouse is offset by an arbitrary amount from what it is highlighting in the picker (this is not representative in the video, but if you try to mouse over elements you will see the issue).

Try to resize the Anim Picker a few times, and then try to manipulate the view port. The viewport will become unresponsive and require a Maya restart.

Screenshots
mGear3-5viewportfreeze.mp4.zip

Additional information
I have some other 3rd party plugins installed, so it would be worth seeing if this is an issue for everyone with Maya 2018 on macOS Catalina.

Incorrect grammar in UI

Describe the bug
Proper grammar for UI is Blink Height.

Screenshots

submodule Serguei Maya math nodes

https://github.com/serguei-k/maya-math-nodes

mgear_dist: math nodes for Maya 2017 win64 are no loading

provably are not correctly compiled

mgear_dist: Add cvwrap menu item

Add CVwarp menu item when Maya starts

Shifter: Custom Steps: Version control

From @miquelcampos on September 4, 2017 6:13

Option/Tool to control versioning on custom steps

Copied from original issue: mgear-dev/mgear_legacy#55

`git clone https://github.com/mgear-dev/mgear_dist.git --recursive` does not work (Permission denied)

Describe the bug
Executing the command git clone https://github.com/mgear-dev/mgear_dist.git --recursive does not work as expected. Some submodules do not materialize correctly.

To Reproduce
Execute the command WITHOUT any credentials in a terminal.

Additional information
See attachment for a complete log.

clone_log.txt

Synoptic IK/FK match ikRot check.

Feature description
The mgear biped guide template's arm comes in with default settings that has separate IK arm translate and rotate controls. The synoptic looks for the ikRot nodes. So if you choose to disable the separate rotate translate settings the IK/FK match stops working. FEATURE REQUEST: a simple check if the ikRot exists, if not don't look for it and match the arm FK or IK.

DOCUMENTATION: Improve documentation and tutorials for final users

• Document for Shifter rig features
• Video tutorial for character rigging under 15 min with voice over
• Document for all menu tools

mgear_dist: add default vendor modules in vendor folder

reference conversation: #32

Shifter: Spring chain bake not working as expected

From @miquelcampos on June 5, 2018 23:49

when animating the “spring chain intensity” and doing a bake with the “synoptic baker”, the result is broken…only when doing a “bake simulation” on the plot-group, the result is as expected, but then no unbake is possible…

Copied from original issue: mgear-dev/mgear_legacy#222

animbits cache manager

When having isRig attribute on a non mgear rig present it still can't find the rig.
It is only looking for this attribute right?

error in scripteditor:

mgear_dist: Create new distribution structure

Due to how mgear_dist is growing it would be good to have the structure inside mgear_dist to be a little bit clearer and simpler.

@mgear-dev/developers I will create a test for this and will let you know when you can check it out. If you already have some comments please shoot

mgear_dist: Add version number to all sub-modules

We will adopt a system like Pyblish using version.py to track each submodule version.
We will start with 3.2.0 version for each module. From this point each version number will evolve separately

exporting of sdk doesnt work on blendshapes

blendshape need to be added in connection types.

Shifter: IO guides templates

From @miquelcampos on August 21, 2017 3:9

-IO to json files .shifter Template (.st)
-import partial guides
-json file guide explorer
-build from file

Copied from original issue: mgear-dev/mgear_legacy#46