New rig and introducing myself to Qt -

Created a new rig in Qt and Maya 2013. Let me know what you guys think. In the past my rigs were in dire need of help. Over the past 6 wks I took part in Rigging Dojo and I think I’ve definitely improved, and even added Qt to my tool set, but of course you only get better from constructive criticism. Since I’m looking for work and not in a studio, I don’t really have any way of seeing what’s helpful or not…soo…let me know!

Thanks in advance! - Trey

https://vimeo.com/49933379

Hey, so pretty good overall, and I like the rotation controls but just a few things to mention:

a)Probably good to boost the audio on your video capture.
b)Scale the UI waaaay down. If any UI took that much space on my screen, it wouldn’t be used.
c)Consolidate your controls. You really only need 1 tab to do all of those things.
d)Arguable point, but I believe bones should always be unselectable to the animator. Having controls on top that provide a level of abstraction is the best solution and would still work fine with your UI.
As an animator, I would never animate joints if I can help it. The non zero rotations, the weird undos and pivots etc make it hell.
Even if there is a UI, many animators still prefer the channel box or viewport manipulation

Number 1 rule of rigging is, imagine that animators are very fussy schoolchildren. Make your rigs accordingly

But I really like those rotation controls. Gave me an idea for an osipa style controller in PyQt

Great Feedback D! and Trey, glad to see you getting your work shown- it is the only way to improve is iteration.

The other thing I would say is to make sure you capture your screen in HD format, it looks like there are some size issues. 1280 X720 or 1920×1080 so that when it uploads it gets detected as HD and it will not have to scale during the encoding.

[QUOTE=bclark;18063]The other thing I would say is to make sure you capture your screen in HD format, it looks like there are some size issues. 1280 X720 or 1920×1080 so that when it uploads it gets detected as HD and it will not have to scale during the encoding.[/QUOTE]

Is this a tool for the animator to interface with the rig? If so I would address the overall design, having multiple tabs is highly inefficient and is a very slow when wanting to quickly just move something. And I would say from experience that making a tool to position and rotate controls is usually less desired. There is no real reason to redesign the way a user interacts with a rig, Maya already has great manip functions and nothing is as quick and precise then having clean controls. There is however huge gain in an animation picker ui which you have some indication of in the hand tab, I would focus on unifying that functionality.

the audio nobs are cool btw;)

Hey everyone! Thanks for the feedback! I’ve taken it in and today tried to make all the changes, let me know what you think of the revisions based on the feedback.

The tab section is now an admin section in another python module. That section is more for helping me with things, at least that was how I thought of it as I was rigging this.

Hey again, did another update and a new tool. Took a crack at building an autorigger. Let me know what you think of my approach so far. Thanks in advance!

Looking for work if anyone has any leads btw!

I’m just curious as to what purpose your autorigger would serve? From what I understood it’s linked to just the one mesh and proportion type?
It seems solid from what I saw, but could it support other rigs? What advantages does it offer over manual rigging? (often one offs are faster to build than to tool up for)

I’m sure it’s capable of scaling to other proportion types, but I read an excellent quote on Youtube about designing systems for use by other people:
>If you have one test case, your tool will probably fail very often
>If you have two test cases, it may work but you’ll run into hard to work with fringe cases
>If you have 3 test cases, your tool will work 95% of the time, and you’ll have built it the flexibility to work around fringe cases

Ideally to get it working for most things, you should take a step back and plan in a modular fashion. The best autorigs I’ve used are all modular because it allows one toolset to extend for the maximum number of rigs.
It’s actually easier to implement than to think about.

My colleague made this DVD. It’s sort of out of date (and by his admission perhaps too large a project to teach in this format), but if you read through the free overview pages, it will give you a really good idea of what goes into it.
http://www.3dbuzz.com/vbforum/content.php?154
http://www.3dbuzz.com/vbforum/content.php?154/view/2

Other autoriggers to perhaps study is The Setup Machine. It’s in dire need of an update, but it is by far the nicest public autorigger I’ve used. I’m not sure if there’s a demo, but there are videos and pdfs demonstrating how to use it (and you can extrapolate back from there)

Other than that,
>I would say decouple the animation UI (the rotary dials) from the build UI. As every rigger in the world lets me know, animators are mentally handicapped. You gotta sandbox them in their world and keep them away from your building tools.
>I went back to watch your AutoRig1 video, I notice you have a class ( start() ) with all these loose commands that run. I would definitely put them in an init() or something instead. It allows them to be properly inherited.

look forward to seeing what you end up with! It’s progressing at a pretty nice pace.

Hey thanks for the reply and the links. I’ll try to answer your questions:

  1. Purpose - To be able bring in various biped meshes with a typical skeletal type, and quickly link, position, and bind with already configured ik and controls. In the video yes, it is currently “scaled” to work. Once complete, prior to binding the mesh the user would be able to scale and position before tripping the IK Rig button which would then mesh bind. I probably should have indicated that, and also that this is a “work in progress”.
  2. The part of code I think you’re looking at is likely a limb. I place them in separate files. My driver file does use init(). I break things up by limb into different files. Easier to work on and troubleshoot, also likely a java coding habit to have one main driver class.

So indeed, it is still being built, this was just where I was at. That being said I’ll take your advice, take a step back, and a do some more research into what’s being typically built.

Thanks again for the input and links!:D: