Hi Rudi,
Just because I believe I understand where those two confusion points were
coming from (I'm a rigger myself): The stretchy IK flag to the "makeIK"
method would make sense to keep as a flag (with either an if statement
depending on the flag OR another additional method in your class that you
jump to from within makeIK if stretchyIK is on). Keeping this all in one
function that becomes a generic way to create an IK with added
functionality rather than new classes built just to support this
functionality would make things just a bit too fragmented like he was
mentioning based on being in the "subclassing is cool" situation.
in essence you class COULD become:
class Limb():
def __init__(self, stretchy=True):
makeIK(stretchy=stretchy)
def makeIK(self, stretchy=True):
create the IK
if stretchy:
makeStretchy()
def makeStretchy(self):
make it stretchy.
Or just keep the code from makeStretchy in the if statement (although you
can end up with some mega huge code blocks per method that way and this
makes it harder to test). Now instead of having to use a different class
for a different style of rig your Limb class can make many different kinds
of rigs from within itself and you don't waste time defining lots of other
classes for different styles of arm rigs and people who want to make Limbs
using your code just need to use the Limb class rather than a host of other
classes they would need to know about based on fringe use-cases. I have
personally seen many Limb modules written this way and NOT subclassed but
obviously this all is just a guideline for best practices and it seems like
most people just don't agree with subclassing to that granularity in this
specific situation (feel free to subclass...this just seems like overkill
on a limb).
His second comment had nothing to do with telling you that your code
doesn't make useful things and that you haven't put effort in so your
showreel doesn't factor into this. He was merely mentioning (I think) the
idea of unit testing which relies on the fact that all of your code logic
branches have test cases you write that can be auto-run and you have 100%
confidence that changes to your code will no break anywhere and all of your
code is able to mature and progress without worrying that it might cause
issues for people using it. It's a methodology that is really quite nice
when you do it (I believe it's called test driven development). Before you
even write your actual code you're just writing tests for ways you THINK
the functions should work and the input/output you expect from them THEN
coding the actual functions themselves to match the test cases. I've found
that writing code this way extends the life of said code since it tends to
be well designed and thought out as a result.
On Wednesday, June 8, 2016 at 10:30:58 AM UTC-4, Rudi Hammad wrote:
>
>
>
> El miércoles, 8 de junio de 2016, 12:11:43 (UTC+2), Cesar Saez escribió:
>>
>> Hi Rudi,
>>
>> Why not pass the stretchy to makeIk as a argument? (i.e.
>> foo.makeIK(stretchy=True) ) same with the method of the twist?
>>
>
> That´s how I use to do it. Stetchy was an argument in the makeIk. But I am
> trying to layer things.Becuase maybe I makeIkStretchy has arguments on it
> own. You can make a stretch Ik by translation or scaling, so the method
> would be something like
> makeIkStretch( stretchType = "translation") or makeIkStretch( stretchType
> = "scale"). Same goes with the twist method. what if I discover a new setup
> of twisting in the future? if I put in the same method
> makeIk(stretchy=True, twist=True), I should go into the makeIk method to
> change the part of the code that do the twists. That doesn´t make sence to
> me...is that the perfect reason to layer things? if you want to change your
> twist sistem, why would go into makeIk method?
>
>
>> put some effort into testing so you can deliver solutions with some
>> confidence
>>
>
> if you have 3 minutes please check my showreel I posted at the begining of
> this post, because that´s were I am coming from and were I put all my
> effort. So I am trying to avoid making the mistakes. For example, when I
> was going to rig ironman with that tool, I though: "wait, I don´t want
> stretchyik here nor twisting because it is a robot", so that why I tough
> that layering would be nice, because strechyIK would have arguments on it´s
> one, and twits too.
>
> what about the last example I posted? did I use incorrectly extension,
> override and inheriting?
>
> Anyway....I think I am heading to McDonalds to give my CV
>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/e757adc5-5814-48ce-88e4-57da4562668e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
