Hi Ingo thats funny to read your update, that’s pretty much what we discuss in the private email you requested on Vimeo last week.
To complete this thread I will add my point of view here as well.
@Not everyone is API savvy or good at scripting to begin with.
Im dont really agree on this one:
What we expect for most people is to learn their craft and get comfortable with their tool. At some point one element that get
important as well is start to have basic experience with scripting capacities of your software:
Here you dont need to concern yourself with python pymel nor dotnet if you have 3dsmax background.
Dont be shy and be concerned with style, naming convention and other programming issue.
Just take babies step and look at your script editor when you do an action: its fun interactive and easiy to do.
From there you can just patch some automation procedure by moving things around
and it might be enough for you most of the time.
@Those who are diving into the API often work for a studio … their work will never be published,and thus not helpful for the general community.
Depends of place, and experience you have with contract. when you learn the api at the studio,
you build element specific to the studio so sure these are elements that give competive edege between place
One thing people have to be aware of is that a studio own only what it paid for:
what you do before enrolling and after you quit a company is yours.
What you do on your free time or at home have nothing to do as well from them:
Only what you do at their facility, using their ressource are covered by fair ip contracts.
In my case it quite clear in most of the studio i work at ( mid to small place ) i wrote more plugins for maya
than their entire pipeline tool department… and i have demoreels showing work anteriority).
So im free to share my toys as what i did in those place was trying to integrate my works following their
pipeline constraint, time/budget
My most original/ solid work where done at home because of that .
I really enjoyed working alongside different department like look dev / characteFX or animation) though.
@Open source often means - no support, do it yourself:
When you look at rigging 95 percent of things can broken ,recombined, split shared as simple scripted plugins:
Focus first on stability and reliability, speed will come later. ( and you can get some help form your
programmers or TD ).
On such a nodes having template file or short script to connect element are more than enough.
@good API exercise (ibid: that was the very own formula i used)
I was saying that writing a twist reader is an excellent beginner exercise:
It cover fundamental concept like vector math, ( projection, angle between )
[one assignment could be to rewrite from scratch maya angle between node.]
matrix space conversion:
[writing max expose transform so you can from two matrix attribute let say extract the angle
between both up vector]
aim constraint, and quaternion.
[( cross product, pole vector). and the use of quaternion to have a reliable reference space ].
Its kind of hands on eaxmple which can help you improve,spread your coverage of the API and gain confidence.
If i look at your product:
i can see you use an aim quaternion as reference space.
the difference between this space and your driver helps compture an angle between a common axis : a first twist estimate
lastly you have a batch mutliply divide node which spread twist value along a limb segment( mine support
angle / scale and was trivial and fun to build: ( just be careful as sampling a ramp attribute
is a bit slow with a lot of element ( > 150 ) .
@Personally, I rather use a plug-in which has a good support, someone who cares about his tools,
We can see from your website some really good Tool and UI design. your learning material are also excellent:
Nonetheless, i cant see what you show targeting other people than some animator or beginner rigger?
What make you cone reader better than Michael comet pose reader? Any reason you don’t talk about it
and have written a strip down version?
On your weightDriver you have translation part which combine a joystick element with a ramp:
this part is more interesting but driving a mouth blendshape and using a ramp is quite concerning:
usually for this kind of component ( on face tweaker, UI slider or joystick ),you have to guaranty the straight
correspondence between what you animate and the actual moving of points . hence why for facial animation
those offset are a big no: if your animator need ease in and out he will usually tweak his curve tangent…
Your extract delta file seem to be as well a clone of Chad Vernon cvShapeInverter ( with the same random matrix hack ).
Personally i used real matrix math for that, thats why now im able to invert dual quaternion skin , lattice
deformer ( interesting subject which can help people improves their math skills) and have a look at
skin decomposition. One study can lead to antoehr an will become the foundation to acquire new skills
Texture deformer : something covered extensively by david gould in is complete maya programming book.
displaceD from Hajime Nakamura https://github.com/redpawfx/DisplaceD.
Had a shot at it, quite fun to deal with animatable weights.
your iCollide and sceneAssemblyManager are more informative ( you at least give credit to stretchMesh which help you build your plugin reference)
Any reason again we dont see information on equivalent component?
https://www.youtube.com/watch?v=SEU2nMF6ARs
L3Deformer - Collision Deformer
Jan Lachauer
https://vimeo.com/13150202
https://github.com/Bumpybox/Tapp/blob/master/Maya/plugins/jlCollisionDeformer.py
Maya muscle have still to date unparalleled and unmatched deformer feature ( a pity they are blended
together into one uber node: people have request for years autodesk to split them to no avail
: so guys if you want to access really goo node and deformer just go to maya feedback and vote for this.)
So i guess your opinion reflect your circumstance are coherent as a whole:
your will to help the community is commendable but you seem to operate more as a tool vendor and 3rd party service provider.
Im character TD and i always tried to share my old toys at some point,as open source elements.
but in my eyes having an article explaining a technique is more useful .
I always made my point to give people enough reference link to show people what I study, what was my struggle,
how i overcame a problem or what was my failures.
However after work and my own research i don’t always have time nor energy to provide support to random peoples.
I have nothing to sell and I don’t need to raise my audience nor customer base.
What i do is mostly for my personal enjoyment and tools, custom nodes deformers are a mean to an end not my goal
Releasing a free product is a common business practice (http://creaturerigs.com/stretch-ik-maya-plugin/
https://www.toolchefs.com/?page_id=225 ) it can help you reach new people and companies( nothing wrong with this).
For my part what i want for my peers and my communities is to be self sufficient: make your own experiment,
try commercial product, whatever helps you achieve your goal ( a good animation rig, with good deformations)
but dont lock your self on a 3rd party solution, especially on basic level things.
i think i had something publish since 2014 on github:
quaternion aim constraint[I]
https://github.com/cedricB/circeCharacterWorksTools/blob/master/maya/plug-ins/heimer.py
twist segment node[/I] for angle / scale: support start twist - endTwist and midTweak ( same with scale )
https://github.com/cedricB/circeCharacterWorksTools/blob/master/maya/plug-ins/tortilla.py
twistReader[I] this one one hacking maya orientConstraint node
https://github.com/cedricB/circeCharacterWorksTools/blob/master/maya/plug-ins/twistKnot.py
( have something more self contained never have time to upload)
@agreed that there cannot be a perfect solution:
I as said quite some time ago writing history node which track twist is more tricky to handle
but sampling twist as animator work on the rig can introduce erratic result and be unreliable.
the only time we can guaranty a stable behaviour is when bake the twist ourself and flush anything here before playblast
or point caching.
when you write a divide node you take care of division by zero? So yeah a node operate within a range, and must fail in
predictable manner ( not crashing maya of course ):
Here asking animator to track a twist attribute on a character is to ask to manage 2 shoulders, 2wrists,
2 elbows, 2ankles, 2knees, 2upper legs, 2upper arms and so on: will tire them really quickly and they will
quickly rebell at you.
You are not the first developer to explore this workaround ,a lot of other guys im sure did it long before us.
Had study this some years ago but after some time made my conclusion:
it can work in a lot of simple case but in medium ones the cure will be worse than the disease.
The latest version of maya has a pose and shape editor tool similar to your main product Shape ,did it start to have an impact on your side?
( autodesk have this kind a dirty habbit to integrate their own flavorof poluatr tool: grease pencil/(mark zubrick), steroscopic camera rig, texture hyperveil/asset
container and so on, buying separate product like maya muscle ,nex or mash)
