Scripting For Rig Portability
46 views
Skip to first unread message
notanymike
Oct 8, 2014, 3:05:28 PM10/8/14
to python_in...@googlegroups.com
http://forums.cgsociety.org/showthread.php?p=7909562#post7909562
I'm not sure why I didn't get any replies on CGSociety about this. Hopefully it'll get some thoughts & discussion over here...
Justin Israel
Oct 8, 2014, 4:53:38 PM10/8/14
to python_in...@googlegroups.com
I don't have much in-depth knowledge about rigging practices or expressions, but I wonder if some of the reasons people aren't doing it involve performance impacts? As far as I know, expressions are evaluated often and can be slow. Have you tried out these approaches and found them to work well?
On Thu, Oct 9, 2014 at 8:05 AM, notanymike <notan...@gmail.com> wrote:
http://forums.cgsociety.org/showthread.php?p=7909562#post7909562I'm not sure why I didn't get any replies on CGSociety about this. Hopefully it'll get some thoughts & discussion over here...
--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/fa5e41e3-216d-482f-a400-b81c62d1af41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
notanymike
Oct 8, 2014, 5:00:57 PM10/8/14
to python_in...@googlegroups.com
I imagined this would be a one-time evaluation that occurred when the file was loaded and everything. It should be as quick as a regular software installation via an executable. I wasn't able to go this far because I wasn't good enough with the rest of the rigging process that came before this step, and like I said I don't have a Maya license anymore, seeing as I'm no longer a student (they required validation on my last renewal attempt)...
On Wednesday, October 8, 2014 1:53:38 PM UTC-7, Justin Israel wrote:
I don't have much in-depth knowledge about rigging practices or expressions, but I wonder if some of the reasons people aren't doing it involve performance impacts? As far as I know, expressions are evaluated often and can be slow. Have you tried out these approaches and found them to work well?
On Thu, Oct 9, 2014 at 8:05 AM, notanymike <notan...@gmail.com> wrote:
http://forums.cgsociety.org/showthread.php?p=7909562#post7909562I'm not sure why I didn't get any replies on CGSociety about this. Hopefully it'll get some thoughts & discussion over here...
--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
Joe Weidenbach
Oct 10, 2014, 12:34:45 AM10/10/14
to python_in...@googlegroups.com
Just a few thoughts--haven't worked in
the Feature Animation/VFX "industry" as a rigger (yet), but I do
rig/do Tech Art in games for a living, and am a lead at an indie
studio when I'm off the clock. I also know/talk regularly with a
lot of pros. So, please take my thoughts with a grain of salt,
but here they are.
1) Expression nodes are slow. Production rigs need speed above almost all else, for the animators. In a full-on production environment, you're going to tend to have Development teams to build C++ plugins to speed things up, and IT staff to keep the pipeline running/ensure tools are installed properly. This has been my experience even at smaller startup studios, where Development/IT could even be one person (Heck, it's pretty much my day job currently, and we're a team of 5). I've never known student animators to like having to do all of the setup, but generally in production the tools are already in place for one-click loading for the animators. Even for tiny studios, things like OpenPipeline make this kind of thing fairly easy. This is one area where schools could improve--most have a standardized lab setup and an IT department that doesn't allow outside tools to be installed on a persistent basis, which is the source of most of the frustration of the rigs you mentioned with shelves/pickers/etc. In a production environment, these would usually be installed once, and then wouldn't need to be touched (and would thus just be available) unless being updated.
2) The type of "all-inclusive" rig you mention is really nice for students. However, it doesn't at all approximate the types of rigs I've seen in production. Most rigs are highly specialized (and built on top of a standardized scripted biped setup), and once a studio has something that works well, there's no real reason to update it--doing so would involve re-investing the development time for the tools, which is extremely expensive. It's an investment vs return proposition. Also, in production, file sizes are key, and the types of functionalities that you're trying to implement would more likely be set up across a shared interface that could be reused for every character using the base rig (less scripts, less places for things to break).
3) Most riggers I've worked with (myself included) tend to thrive on solving new problems. That's a nice way of saying we don't like repetition :). As to what this means--unless I find one of my rigs is slowing things down for development, I'll tend to use the scripts I wrote 4 years ago to do the jobs, even if I know there's a shiny new technique that will work. Unless that shiny new technique is going to speed things up significantly or make my animators' jobs easier/quicker, I'm not going to spend the time to implement it. This isn't because I'm not interested in picking up the latest skills, it's more because I have other things to do that make a more significant business impact. Again, time is money, and this is a business.
As I said, I've only worked on small teams, so I can't speak with more than hearsay for the larger houses (although I have friends at most of the larger studios). If I got anything wrong I'd love to hear it--I also teach rigging in my off time, so I'd be glad to update my knowledge base as well.
Hope this helps,
Joe
1) Expression nodes are slow. Production rigs need speed above almost all else, for the animators. In a full-on production environment, you're going to tend to have Development teams to build C++ plugins to speed things up, and IT staff to keep the pipeline running/ensure tools are installed properly. This has been my experience even at smaller startup studios, where Development/IT could even be one person (Heck, it's pretty much my day job currently, and we're a team of 5). I've never known student animators to like having to do all of the setup, but generally in production the tools are already in place for one-click loading for the animators. Even for tiny studios, things like OpenPipeline make this kind of thing fairly easy. This is one area where schools could improve--most have a standardized lab setup and an IT department that doesn't allow outside tools to be installed on a persistent basis, which is the source of most of the frustration of the rigs you mentioned with shelves/pickers/etc. In a production environment, these would usually be installed once, and then wouldn't need to be touched (and would thus just be available) unless being updated.
2) The type of "all-inclusive" rig you mention is really nice for students. However, it doesn't at all approximate the types of rigs I've seen in production. Most rigs are highly specialized (and built on top of a standardized scripted biped setup), and once a studio has something that works well, there's no real reason to update it--doing so would involve re-investing the development time for the tools, which is extremely expensive. It's an investment vs return proposition. Also, in production, file sizes are key, and the types of functionalities that you're trying to implement would more likely be set up across a shared interface that could be reused for every character using the base rig (less scripts, less places for things to break).
3) Most riggers I've worked with (myself included) tend to thrive on solving new problems. That's a nice way of saying we don't like repetition :). As to what this means--unless I find one of my rigs is slowing things down for development, I'll tend to use the scripts I wrote 4 years ago to do the jobs, even if I know there's a shiny new technique that will work. Unless that shiny new technique is going to speed things up significantly or make my animators' jobs easier/quicker, I'm not going to spend the time to implement it. This isn't because I'm not interested in picking up the latest skills, it's more because I have other things to do that make a more significant business impact. Again, time is money, and this is a business.
As I said, I've only worked on small teams, so I can't speak with more than hearsay for the larger houses (although I have friends at most of the larger studios). If I got anything wrong I'd love to hear it--I also teach rigging in my off time, so I'd be glad to update my knowledge base as well.
Hope this helps,
Joe
On 10/8/2014 12:05 PM, notanymike wrote:
http://forums.cgsociety.org/showthread.php?p=7909562#post7909562
I'm not sure why I didn't get any replies on CGSociety about this. Hopefully it'll get some thoughts & discussion over here...
--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/fa5e41e3-216d-482f-a400-b81c62d1af41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Joe Weidenbach
Oct 10, 2014, 12:54:09 AM10/10/14
to python_in...@googlegroups.com
And, I just realized, I missed a key
point of your question--why this wasn't something being done on
rigs for the public.
I think the biggest reason for this is that most rigs released to the public are either made by aspiring professional riggers, or by teachers. I've made one of these fully self contained rigs, although I haven't released it to the public (it was made for a student production when I was working on my Master's, and I give it out to my students with permission from the director, but I can't distribute it beyond that). So, why aren't there more of these? The biggest reason is that it takes forever to make one. As compared to my normal rigs that I can have in the animators' hands in a matter of hours from getting the rough model (and then usually render ready (dynamics, cloth, etc) within a few weeks, depending on the needs), this all in one rig took months. Now, to be fair, it was done in my off time (working a full-time job and a part-time job on the side, as well as my indie studio, plus the homework for my Masters). So, I think most people who build production rigs just plain don't have the time to write tools that would make it a quick process.
Just another two cents.
I think the biggest reason for this is that most rigs released to the public are either made by aspiring professional riggers, or by teachers. I've made one of these fully self contained rigs, although I haven't released it to the public (it was made for a student production when I was working on my Master's, and I give it out to my students with permission from the director, but I can't distribute it beyond that). So, why aren't there more of these? The biggest reason is that it takes forever to make one. As compared to my normal rigs that I can have in the animators' hands in a matter of hours from getting the rough model (and then usually render ready (dynamics, cloth, etc) within a few weeks, depending on the needs), this all in one rig took months. Now, to be fair, it was done in my off time (working a full-time job and a part-time job on the side, as well as my indie studio, plus the homework for my Masters). So, I think most people who build production rigs just plain don't have the time to write tools that would make it a quick process.
Just another two cents.
Joe
On 10/8/2014 12:05 PM, notanymike wrote:
http://forums.cgsociety.org/showthread.php?p=7909562#post7909562
I'm not sure why I didn't get any replies on CGSociety about this. Hopefully it'll get some thoughts & discussion over here...
--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/fa5e41e3-216d-482f-a400-b81c62d1af41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages