January 12, 2019 at 1:44 pm #6224
- We’re thinking about switching to github as they have a free option now. Thoughts?
- Currently our second state is called template. Is that confusing with the idea of a rig template? Wondering if ‘shaping’ would make more sense?
Feel free to add other MRS related discussions.
January 14, 2019 at 1:51 am #6239
instead of template you could also call it blueprint. as it refers to something that is already defined and can be shared and adjusted by others
January 14, 2019 at 3:05 am #6240
cant find an edit function to add extra comments to my first reply,
but while shaping the template using the curves i find myself selecting curves over and over, some of which are hard to select,
so maybe adding a tag setup to these controls with the new controller node for pickwalking might speed this process up a bit
it will lock maya users prior to 2016.5 out so maybe this is not a wanted feature
January 14, 2019 at 5:32 am #6241
That’s a good idea. I’ve not delved too much into those nodes yet. The version thing may or may not be an issue. We should probably set a floor at some point.
A version floor is a good idea for another topic 🙂
January 14, 2019 at 11:44 am #6242
Is there also a way to turn off the prints in the build process? or a way to log only warnings/errors? That could speed up parts of the building already.
Also are the build processes wrapped into an undo chunk? I pressed pre-rig by accident before and it generated a lot of empty groups, I could undo, but the undo also took quite some time.
And seeing as arms and legs are supposed to be on a plane, is there a way (or maybe this can be added as an option to be forced later) to lock the elbow/knee onto the set rotateplane. for me personnaly its easier to define begin and endpoint of the limbs, then the rotate plane and constraint all the intermediate joints to the plane itself.
All in all I really like the setup, most of it is intuitive enough and the videos explain clearly what is needed to build the first rig with the template, there are still some things unclear to me here and there but I am sure i can find that out as well.
January 14, 2019 at 2:43 pm #6248
@Prints – yep, I’m starting to turn off those debugs in the main branch. It’s definitely a speed hit.
@Undo chunks – yes though I find them finicky so if you have thoughts on how to make that better I’m all ears.
@Following plane – they pretty much do now. The mid handles follow the start/end regardless of limb handles and zeroing those should put them back on the ‘line’. Is there a case you’re not seeing this happen?
January 14, 2019 at 11:14 pm #6261
@prints – a simple util function in the menubar to switch to different states would be perfect, so people can build with prints of, and if they find errors, switch to full print and check where the error occurs.
@undo chunks – you can add a decorator:
as long as the functions you use are undo friendly it should be fine, up till now i only found that the wiredeformer command is a bit finicky, just replace the ‘cmds.warning’ with the logging function, the only problem with this code is that the stacktrace doesnt work well with the try except, so maybe a traceback function is necessary
@following plane – will take another look, maybe i just didnt do it properly 🙂
January 19, 2019 at 3:45 am #6370
I’ve tried the decorator route on undo but not had huge luck there. Happy to have a hand if if you wanna help implement. It looks like I might could try it in my Callback class. I’ll try to remember to give it a look next week. Most of my ui calls harken back to cgm_General.Callback but some have their own custom ones. There’s some exception experimentation in there as well if you’re interested as well as a failed overall function class idea I ran with a couple of years before abandoning.
I took a stab at better error reporting this week so hopefully breaks will be more helpful as to what’s happening.
@switching modules between log/debug/ etc. I’ve thought something very similar. Just haven’t had time.
January 14, 2019 at 12:41 pm #6244
something that might already be in there, but a possibility of adding a roll-joint on the wrist would be very helpful for deformation:
as it is now the only roll joint i can find is a single one in the elbow, to have a roll-joint in the wrist position would result in this behavior with minimal skinning:
I am digging through the code as to how it’s all setup but that’s going to take quite some time
January 14, 2019 at 2:38 pm #6247
Regarding the roll wrist. That is definitely something I’ve been thinking about. It’s not as much an issue when you have more roll joints on the lower arm section (you’ll learn how to do that in the next module) but it’s still worth exploring.
If it’s something you’re interested in, it would be a relatively small add on to walk you through figuring out how to add to the setup and push back to the main branch. Lemme know.
The section you’re looking for to dig is cgm.core.mrs.blocks.organic.limb. 🙂
January 14, 2019 at 11:19 pm #6264
ok, will take a look tonight if i can find it 🙂 otherwise i will contact you about it.
did look into the code here and there, it seems like all different types of rig are setup in the same file (template, skeleton, rig) maybe a video explaining the thought behind the code would be very cool
January 19, 2019 at 3:43 am #6369
You may have found it but yeah. Each rigBlocks module houses all the main calls for that module. The reason I did it this way rather than subclassing the main cgmRigBlock was from frustration with that setup in the past from that workflow.
With the subclass stuff and red9 setup which I sublass our nodes to require specific reloads to not break things.
So when you’re making lots of changes you have to reload everything a lot. Having each rigBlock instead find it’s builder module from it’s blockType let me easily amend block setups and even add new ones without having to register each block to the registry and all that.
cgmRigBlock of blockType limb grabs the LIMB module whenever it is going for blockModule call.
Years of iteration is what got it here. Don’t know if its the best result but it’s where we are. Hope that helps. 🙂
January 14, 2019 at 6:46 pm #6252
A note on roll joints that sit on top of other joints.. Make sure they have a label for good mirroring on skin weights 🙂 Second, don’t have them sit right ontop of other joints if skeleton needs to work with the HIK roll system:)
January 14, 2019 at 9:19 pm #6260
That’s a good thought. I had that issue back on Morpheus 2 at times when I had extra scale joints under the reg ones and that main hinges. For the most part the better tools (ngSkin ) were fine as long as the naming was proper. Standard maya tools balked a good bit though.
I actually wanted to test how it would look if you just had an option to ignore the extra channels on the wrist and see if the finger joint weighting would hold up the same effect.
January 14, 2019 at 11:23 pm #6265
labeling joints is always a good practice, it makes it so much easier for skinning.
as for the metacarpals taking over most of the weigth in the wrist should be fine as long as they are setup to be close enough to the wrist as the motion of these bones should not have a big reach.
You must be logged in to reply to this topic.