am I using instance variables right...(also link my showreel)

[Rudi Hammad]

hello,

so I spend a couple of months making my show reel which is a rig builder tool. Here you have the link if you want to check it

riggin/programing reel

I learned a lot doing it, and I want to thank this forum for helping me with my questions (even the stupids ones....)
Any way, now I want to rewrite my code avoiding making some mistakes I did previously, so I wanted to ask you If I am using the instance variables right.( code in pastebin link )

http://pastebin.com/yxMNRXHT

I thought that arguments like side, or name are very used in all the methods, so is it okey to out them in the __init__? this way, I don´t have to keep using those arguments over
and over again in the rest of the methods.
But of course that obligates me to create the class instance.

I now about classmethods to call directly the class. But then, should all my methods be classmethods?
I don´t know, a programer told me that scripting for 3d I don´t have to care too much about all that, but I don´t want my code just to work, I want to make a proper code too when
I am applying it to rigging.

cheers

[Justin Israel]

On Sun, Jun 5, 2016 at 8:20 AM Rudi Hammad <rudih...@gmail.com> wrote:

hello,

so I spend a couple of months making my show reel which is a rig builder tool. Here you have the link if you want to check it

riggin/programing reel

I learned a lot doing it, and I want to thank this forum for helping me with my questions (even the stupids ones....)
Any way, now I want to rewrite my code avoiding making some mistakes I did previously, so I wanted to ask you If I am using the instance variables right.( code in pastebin link )

http://pastebin.com/yxMNRXHT

I thought that arguments like side, or name are very used in all the methods, so is it okey to out them in the __init__? this way, I don´t have to keep using those arguments over
and over again in the rest of the methods.
But of course that obligates me to create the class instance.

If you have a class with only 2 methods, and one of them is __init__(), then you actually want a function:  Stop Writing Classes

Now, if you haven't shown us the entire implementation, and you actually have more methods, then maybe a class is correct here. It all depends on whether you need to accept "options" and store state, in order for the rest of the methods with similar purpose can operate.

The only suggestion I would have to the way your class is currently written, is to rename your class variable from axex -> Axes (or AXES) to indicate that they are a class variable, and to use a tuple instead of a list to make the collection frozen:   AXES = ('x', 'y', 'z')

 

I now about classmethods to call directly the class. But then, should all my methods be classmethods?

Again, if you have a class and all the methods are classmethods, then you just want functions, and to put your class variables into private global variables like:

_AXES = ('x','y','x')

def makeIk():

    ...

Classes are for collecting similar behavior and to maintain state. 

 

I don´t know, a programer told me that scripting for 3d I don´t have to care too much about all that,

Hah. That is very stereotypical. It is what pipeline people refer to as "TD Code". No offense intended here. It is just the term for those that fulfill the stereotype about figuring that code can just be written sloppy since your real goal is to get your artist tasks done now. But what ends up happening is that someone else will need to use it, or fix it. And they will find it doesn't work in a bunch of cases because it was designed for a specific purpose, or it is just so messy that it is hard to understand the intent. The code then becomes throw away code.

Point is, if you are going to write code, you might as well develop good habits, while still trying to find a balance between intense over engineering and fast iteration. Basically write your code like someone else is going to read it.

 

but I don´t want my code just to work, I want to make a proper code too when
I am applying it to rigging.

Nice. Go with that. 

 

cheers

--
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/7bea2fb9-4b04-4a60-a42c-e95b0c776422%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rudi Hammad]

If you have a class with only 2 methods, and one of them is __init__(), then you actually want a function:  Stop Writing Classes

That was just an example, of course I have a lot of methods. It was just to understand if using in the __init__ the args "side" and "name" is okey., because the rest of the methods use those variables
at some point.

They way I am wrote my last code to do the tool in the reel I linked is:
1. coreTools class that has methods to gets distances, vectors, vertexcountes etc..etc..so generic stuff you use usally
2. then in another module I have a jointTools class, that has methods to do basic rigging stuff, like iks, fk/ik, etc...
3. a more detailed class that inherits from joint jointTools class to make methods like softIk, stretchyIk, bendings etc..etc...

Is this approach correct for OOP?

thanks for the tuple()  and _private tips

[Justin Israel]

On Sun, 5 Jun 2016 10:35 AM Rudi Hammad <rudih...@gmail.com> wrote:

If you have a class with only 2 methods, and one of them is __init__(), then you actually want a function:  Stop Writing Classes

That was just an example, of course I have a lot of methods. It was just to understand if using in the __init__ the args "side" and "name" is okey., because the rest of the methods use those variables
at some point.

Oh ok. Then sure, those seem fine. If they are the required variables that drive the functionality of the other methods then it makes sense to be able to construct and instance with them. 

They way I am wrote my last code to do the tool in the reel I linked is:
1. coreTools class that has methods to gets distances, vectors, vertexcountes etc..etc..so generic stuff you use usally
2. then in another module I have a jointTools class, that has methods to do basic rigging stuff, like iks, fk/ik, etc...
3. a more detailed class that inherits from joint jointTools class to make methods like softIk, stretchyIk, bendings etc..etc...

Is this approach correct for OOP?

If coreTools class needs state for each instance, then sure. If it's just a bunch of utility methods that don't access "self" other than than to call another method, then maybe not. And coreTools would be expected to be CoreTools if it's a class ;-) 

thanks for the tuple()  and _private tips

--
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/81667cab-892c-4e07-a0e7-e3c989a7fbdc%40googlegroups.com.

[Rudi Hammad]

ok. I think I get it. I wrote this example to see if I am on the right path

http://pastebin.com/AqVCPpet

you right about the CoreTools with capital "C", I try to follow the python styling. There are somethings I don´t agree with. For instances, I tend to put more blank lines
than recomended by python gurus. For example I read better

my def():

El domingo, 5 de junio de 2016, 0:40:31 (UTC+2), Justin Israel escribió:

On Sun, 5 Jun 2016 10:35 AM Rudi Hammad <rudih...@gmail.com> wrote:

If you have a class with only 2 methods, and one of them is __init__(), then you actually want a function:  Stop Writing Classes

That was just an example, of course I have a lot of methods. It was just to understand if using in the __init__ the args "side" and "name" is okey., because the rest of the methods use those variables
at some point.

Oh ok. Then sure, those seem fine. If they are the required variables that drive the functionality of the other methods then it makes sense to be able to construct and instance with them. 

They way I am wrote my last code to do the tool in the reel I linked is:
1. coreTools class that has methods to gets distances, vectors, vertexcountes etc..etc..so generic stuff you use usally
2. then in another module I have a jointTools class, that has methods to do basic rigging stuff, like iks, fk/ik, etc...
3. a more detailed class that inherits from joint jointTools class to make methods like softIk, stretchyIk, bendings etc..etc...

Is this approach correct for OOP?

If coreTools class needs state for each instance, then sure. If it's just a bunch of utility methods that don't access "self" other than than to call another method, then maybe not. And coreTools would be expected to be CoreTools if it's a class ;-) 

thanks for the tuple()  and _private tips

--
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.

[Rudi Hammad]

El domingo, 5 de junio de 2016, 1:15:50 (UTC+2), Rudi Hammad escribió:

ok. I think I get it. I wrote this example to see if I am on the right path

http://pastebin.com/AqVCPpet

you right about the CoreTools with capital "C", I try to follow the python styling. There are somethings I don´t agree with. For instances, I tend to put more blank lines
than recomended by python gurus. For example I read better

def foo():

          bla bla bla bla
          bla blabla bla

than

   def foo():
          bla bla bla blabla
          bla blablablabla


or myTuple( "a", "b", "c" ) than ("a", "b", "c")

I know those are minor details, but I don´t know if that might annoy other python coders

          bla blab la blabla

   

[Justin Israel]

On Sun, 5 Jun 2016 11:19 AM Rudi Hammad <rudih...@gmail.com> wrote:

El domingo, 5 de junio de 2016, 1:15:50 (UTC+2), Rudi Hammad escribió:

ok. I think I get it. I wrote this example to see if I am on the right path

http://pastebin.com/AqVCPpet

See from from that example, to me, classes don't make sense. You didn't show any usage of state. They just look like namespace of functions 

you right about the CoreTools with capital "C", I try to follow the python styling. There are somethings I don´t agree with. For instances, I tend to put more blank lines
than recomended by python gurus. For example I read better

def foo():

          bla bla bla bla
          bla blabla bla

than

   def foo():
          bla bla bla blabla
          bla blablablabla


or myTuple( "a", "b", "c" ) than ("a", "b", "c")

I know those are minor details, but I don´t know if that might annoy other python coders

          bla blab la blabla

I don't follow every aspect of pep8 either. 

   

El domingo, 5 de junio de 2016, 0:40:31 (UTC+2), Justin Israel escribió:

On Sun, 5 Jun 2016 10:35 AM Rudi Hammad <rudih...@gmail.com> wrote:

If you have a class with only 2 methods, and one of them is __init__(), then you actually want a function:  Stop Writing Classes

That was just an example, of course I have a lot of methods. It was just to understand if using in the __init__ the args "side" and "name" is okey., because the rest of the methods use those variables
at some point.

Oh ok. Then sure, those seem fine. If they are the required variables that drive the functionality of the other methods then it makes sense to be able to construct and instance with them. 

They way I am wrote my last code to do the tool in the reel I linked is:
1. coreTools class that has methods to gets distances, vectors, vertexcountes etc..etc..so generic stuff you use usally
2. then in another module I have a jointTools class, that has methods to do basic rigging stuff, like iks, fk/ik, etc...
3. a more detailed class that inherits from joint jointTools class to make methods like softIk, stretchyIk, bendings etc..etc...

Is this approach correct for OOP?

If coreTools class needs state for each instance, then sure. If it's just a bunch of utility methods that don't access "self" other than than to call another method, then maybe not. And coreTools would be expected to be CoreTools if it's a class ;-) 

thanks for the tuple()  and _private tips

--
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/81667cab-892c-4e07-a0e7-e3c989a7fbdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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/046b0a5e-0300-408c-a23d-ebf8535f05e1%40googlegroups.com.

[Rudi Hammad]

See from from that example, to me, classes don't make sense. You didn't show any usage of state. They just look like namespace of functions 

no? hmmm....I inherited the method getDistance() to use it in the makesterchy()

   getDistance() could also be used in more methods. Is that not okey?
  
  I don´t get then what is a good use of oop apllied to rigging. I thought I was going from generic to specific.
 

[Cesar Saez]

How many instances of your classes will you have around? If it's only 1 or it's not holding any state get rid of it and use functions (you can aggregate them in a module if you like).
Also your class method makes no sense, class methods are supposed to return an instance (typically constructors). If you want to define methods not using requiring the instance you probably need to decorate it as a static method.

tl;dr: object oriented programming include the world object, not class, in the name/description. Make sure you understand the difference between those and everything will make sense.

Cheers

[Rudi Hammad]

El domingo, 5 de junio de 2016, 16:41:13 (UTC+2), Cesar Saez escribió:

How many instances of your classes will you have around? If it's only 1 or it's not holding any state get rid of it and use functions (you can aggregate them in a module if you like).

Yes I have many instance, this just an example. I might have 15 methods in a subclass that would inherit the one or more methods from the superclass
 

tl;dr: object oriented programming include the world object, not class, in the name/description. Make sure you understand the difference between those and everything will make sense.

I understand a class as a 'container' of similar methods and variables( class vars and instances vars). So I might have a class that operates on joints, another one related to skinning etc... 
the object is the instance of the class. so if I have a class Human, the object will be man = Human(). So now man will get the attributes ( the attributes being the vars and methods of the class ) 'via' dotted access
Is that right? I know than instance vars are the ones passded in the __init__(), etc..etc...I think I understand the basics of OOP. Of course correct me if what I said is wrong.

So, can someone give me a specific example of OOP applied to rigging. I don´t want another example about how the Vehicle is the superclass and the Car, Bike etc...are subclass because they are all vehicles, etc...
I just would lke something specific, a real example of OOP applied to rigging because apparently I am doing it everything wrong.

thx

[Cesar Saez]

Classes can be used as a container but that's not necessarily a good reason in a language like python (thinking about inheritance as an usage for a class is a bit misleading imho, I would recommend to forget about subclasses at the beginning and go one step at a time).

Classes define the behavior of your entity (think of 'features', what the thing is capable to do) and the instance/object hold the state (the data associated to your entity, this usually changes as you go through the execution of your program).

It's hard to give you a rigging example without going into too much details, but a very obvious use case could be a modular rigging system, where you define components (limb, fkchains, some sort of curve based component and so on) and then put everything together by instantiating those components and assigning different states (the position of the arm is not the same as the leg, but both are instances of the Limb class, same with what they are connected to and stuff like that.... all that state belongs to the objects, but its features are shared between both arms and legs on a biped rig).

Cheers

[Rudi Hammad]

but a very obvious use case could be a modular rigging system, where you define components (limb, fkchains, some sort of curve based component and so on) and then put everything together by instantiating those components and assigning different states (the position of the arm is not the same as the leg, but both are instances of the Limb class, same with what they are connected to and stuff like that.... all that state belongs to the objects, but its features are shared between both arms and legs on a biped rig).

But that is exactly how I was working on my modular rigging tool. Here is the link if you want to check it: https://vimeo.com/168109200
I have a superclass that has numerical methods, that I inherit to use in another class that has methods related to joints...So that is why I am getting confues now, I think I am not explaining my self.
Anyway, thanks for the tips guys

cheers

[Justin Israel]

I get what you are saying. You have classes that collect functions with similar applications I to "themes". And then you create new themes by subclasses them into new collections of methods with similar application. 

What I hear (and saw from your code examplea) that may be missing is the idea of state. You pass in a couple options through your unit for some methods to use. It is possible that those methods could be functions that take arguments. The reason being, if none of of those methods set and new data in your instance as state, then the internal state never changes. Thus you end up with those saved options as just plain functions arguments. 

Cheap example of what I mean :

class Pants(object):

    def __init__():

        # initial state

        self._nFoo = 0

    def foo(self):

        # foo'd your pants

        self._nFoo += 1 

    def fooTimes(self):

        # how many times did you foo your pants? 

        return self._nFoo

So you can see here here that your class starts with some initial state in the init. It may or may not accept arguments to make additional options to the state. Them you call different methods that perform work and modify the state of the instance. Now you can have multiple instances of your class with different states, depending on how they are used. 

You can also see see that an instance variable is not just something you pass in to init. It is any member that is any member that gets store on the instance at any time. 

Justin 

Anyway, thanks for the tips guys

cheers

--

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/64ce1dd3-99ee-410a-a960-4ea230aa7586%40googlegroups.com.

[Justin Israel]

Wow I had tons of typos in that last reply, from my phone.

[Rudi Hammad]

okey, now I understand. As you said, I do classes according to themes. So it is more a way of organizing methods in themes than exploring the power of OOP. So when I inherit the method distance() from a superclass to use it
in another subclass I am not doing anything really. It just like having 2 modules with funcions, and importing functions from one modulo to another. I can do that without OOP. But is it that bad to use class just to organize your "themes"?

I think I understand what you mean now with idea of state. You are creating an initial variable that is used or modified in the rest of the methods. So can I use for example as instance variable self._side="", or self._name="" to avoid having to right
every time in every method side and name as arguments?
Can you also use the __init__() to create objects . I don´t know why I have this idea that creating an object inside a module or an init to use its methods is messy. Is this why @classmethods are used? to avoid creating having to create the object?

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

[Justin Israel]

On Mon, Jun 6, 2016 at 11:45 AM Rudi Hammad <rudih...@gmail.com> wrote:

okey, now I understand. As you said, I do classes according to themes. So it is more a way of organizing methods in themes than exploring the power of OOP. So when I inherit the method distance() from a superclass to use it
in another subclass I am not doing anything really. It just like having 2 modules with funcions, and importing functions from one modulo to another. I can do that without OOP. But is it that bad to use class just to organize your "themes"?

I wouldn't call it bad. It is just not necessary or not the full purpose of classes. It is just replacing the usage of modules for classes to achieve namespaces. I would definitely call it bad though if they are not classmethods or staticmethods and require you to create an instance to even use the methods. 

 

I think I understand what you mean now with idea of state. You are creating an initial variable that is used or modified in the rest of the methods. So can I use for example as instance variable self._side="", or self._name="" to avoid having to right
every time in every method side and name as arguments?

Yea that is a way of looking at it. They are just part of the state that happens to be exposed in settings on the constructor. You could also do stuff like:    

def setName(self, name):

    # validation

    # ...

    self._name = name

 

Can you also use the __init__() to create objects . I don´t know why I have this idea that creating an object inside a module or an init to use its methods is messy. Is this why @classmethods are used? to avoid creating having to create the object?

I dont realy undertand this. Can you give an example?  I feel like you mean that earlier point about using a class as a namespace for your functions, and having to construct an instance in order to call methods. As Cesar had also pointed out, classmethods can be used as factory functions or alternate constructors to return instances of the class. They can also be used to perform operations that don't require an instance but may want to reference class attributes.

 

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/64ce1dd3-99ee-410a-a960-4ea230aa7586%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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/1131a9c0-a0a2-42e7-aa19-0356c9f1fd15%40googlegroups.com.

[Rudi Hammad]

I dont realy undertand this. Can you give an example?  I feel like you mean that earlier point about using a class as a namespace for your functions, and having to construct an instance in order to call methods. As Cesar had also pointed out, classmethods can be used as factory functions or alternate constructors to return instances of the class. They can also be used to perform operations that don't require an instance but may want to reference class attributes.

 

yes you are right, that´s like the example I meant earlier using class as namespace. I don´t know what factory functions are, I am going to google it to get some info.

So, okey. This thread was very clarifying.I wasn´t quite exploring the real power of oop. I wish I could see more examples in depth of oop in rigging, but I guess it is too hard to lustrate here.
Thanks again to both of you

[Cesar Saez]

> But is it that bad to use class just to organize your "themes"?

There's no such a thing as good or bad, there are many shades of gray in between, but using that pattern forces to instantiate the class just to use one of its methods, which is inconvenient in any scenario except sub-classing. It's important to give a decent interface and not force the user of your library/framework to subclass in order to achieve even the most common use cases (e.g. imagine if pymel enforces you to subclass a PyNode in order to do anything, it would be _very_ inconvenient).

> Is this why @classmethods are used? to avoid creating having to create the object?

Nope, a class method take the class as first argument and is supposed to return an instance of said class, so you can do checks before and after instantiate the class (or even cancel), it's typically used to implement convenient constructors (i.e. QInputDialog's getDouble/getInt/getItem/getText).

If you want to define a method not requiring an instance (aka self) or a class (typically notated as cls) as first argument, you can decorate the method as staticmethod, but at that point it's probably a good idea to ask yourself why not keep it simpler and use a simple function (said that, there are cases where it's convenient to use static methods, but usually the KISS principle applies on top of everything).

Best regards,

Cesar

[Marcus Ottosson]

> Nope, a class method take the class as first argument and is supposed to return an instance of said class

Just so we don't confuse Rudi, a @classmethod is like a regular method, except that it doesn't have access to its instance. There are no expectation or restrictions on what it returns.

class MyClass(object):

  def regular_method(self):

    return self
 

  @classmethod

  def class_method(cls):

    return cls

myclass1 = MyClass()
myclass2 = MyClass()

assert myclass1.regular_method() != myclass2.regular_method()

assert myclass2.class_method() == myclass2.class_method()

​

[Cesar Saez]

AFAIK the point of a class method is to call it directly from the class (think of it as a __new__ equivalent plus the ability to define custom signatures), you can also call it from the instance in which case your example is correct, but if you do so it will be trickier to take into account this duality while @staticmethod does exactly what Rudi was asking for (no instance, no class, no side effects... just a static function defined within the namespace of the class).

>>> class Foo(object):
...     @classmethod
...     def fancy_constructor(cls, is_valid=True):
...         if is_valid:
...             return cls()
...
>>> class1 = Foo()
>>> class2 = Foo.fancy_constructor(True)
>>> class3 = Foo.fancy_constructor(False)
>>>
>>> print class1, class2, class3
<__main__.Foo object at 0x7fca725fb7d0> <__main__.Foo object at 0x7fca725fb710> None

--

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/CAFRtmOAkM4%3DrH%2By14JmsiZXDFTBZNxT30wmc5VvvQo-DhZ6EPg%40mail.gmail.com.

[Rudi Hammad]

El lunes, 6 de junio de 2016, 15:46:10 (UTC+2), Marcus Ottosson escribió:

> Nope, a class method take the class as first argument and is supposed to return an instance of said class

Just so we don't confuse Rudi, a @classmethod is like a regular method, except that it doesn't have access to its instance.

I just read what I wrote before :

"avoid creating having to create the object" .....avoid create having to create...oh my god, what does that even mean!!

what I meant was that the advantage of classmethod is that you don´t have to create the object, meaning that you can call it directly from the class. Sorry about that.

Going back to general OOP with an example cesar said, i know it looks I am reapting myself but bear with me for one second
 What about a class Limb() that has methods to creates armJoints(self), legJoints(self), spines.They have all in common being limbs right?
 Then I have a subclass MakeIkLimb(Limb)  that has methods create simpleIk(self), or a reversefootIk(self), etc.... and then another subclass called CartoonFeatures(MakeIkLimb)  that will take those existing iks and perform more operations like makeStretchyIk(self) etc..

Then way I would use that is:
 · If I am rigging a realistic character, I don´t want any cartoon features so I would create the object >> realLimb = MakeIkLimb(); and then doing something like realLimb.simpleIk() I would create the ik sistem
 · If I am rigging a cartoon character, I would create the object >> cartoonLimb = CartoonFeatures(); cartoonLimb.makeStretchy()

To sum up, I going from generic to specific.If I want realistic I go for the class that creates just an ik sistem. If I want cartoon I go for the class that requieres the ik from her superclass, and operates one it. I mean, I can´t make a stretchyIk if I don´t have an ik
In my previous codes, I had makeStretchyIk as an argument of the makeIk() method. But separating them in classes makes it cleaner because if I discover a new way of makeStretchyIk, I don´t have to mess with makeIk(), so that is safe no matter what.

Is that better? or am I still going over and over again about the same thing I didn´t understand before

ps: I just bought on cgcircuit intro to pymel to see If I get a better understanding of OOP

[Justin Israel]

No it's not really better. Because you haven't said that makeIk() behaves any different depending on the derived classes. You have only said that you add more methods. So basically you don't achieve real generic polymorphism here because you basically just have to pick the right concrete class always to have the methods you want to call. They are like method sets without any different behavior. Also you arent defining a "Limb" as a thing. You are defining a collection of Limb-related tasks. 

Consider this modification to your example... What if your Limb class was a base class that contained all the behaviours of a generic limb. It could tell you about its properties as a limb as well (number of joints, etc). Then you can make a cartoon limb and override various methods or set different properties that would make that Limb behave and report in a way a cartoon limb would. The idea is that it can reuse the generic standards of a limb and override other behaviours to specialise it. The same makeIk() would behave differently for a cartoon and be stretchy, as opposed to it adding a makeStretchy. Point being, I could blind fold you and hand you some random subclass of Limb and you could use the common interface to make and operate a limb without knowing it's concrete type. I should be able to hand you a list of mixed Limb subclass instances and they would all be useful through the base interface. 

And yea there are times when you need need to type check or duck type check and use the unique features of the derived classes as well. 

ps: I just bought on cgcircuit intro to pymel to see If I get a better understanding of OOP

--
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/42005abc-18d3-4f20-b375-7bf678327d7a%40googlegroups.com.

[Cesar Saez]

I totally agree with Justin, forget about subclassing for a second and just go with the generic case. Limb can implement many features but you are not forced to use them all! You can call methods selectively on each instance/object setting different states (class define behaviour, instance hold the state).

I.e.
# stupid example typed on my phone

import Limb

# ik/fk arm
arm = Limb(name='arm', side='L')
arm.addFK()
arm.addIK()  # assuming you can stack features
arm.makeStretchy()
arm.build()

# ik only leg
leg = Limb(name='leg', side='R')
leg.addIK()
leg.build()

# and so on...

[Rudi Hammad]

No it's not really better.

 wow I am completly useless!!! XXXXD. Okey okey, I will get there and finally get a good oop example. I see my mistakes thanks to all of you.
 Next time I´ll get it right. And if I don´t , I´ll devote my life to work at McDonalds.

[Justin Israel]

I didn't mean any offense (hope none was taken?). Was just being honest. i completely understood your explanation of how you set things up, but didn't agree that it was the best usage of classes and inheritence, as it was intended. You should look up "mixins", as it sounds like what you are using classes for.

Don't head to McDonalds yet, unless its for a 6 piece nuggets and a Big Mac. 

 

--
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/583bb317-d152-40e6-b024-bc93ad01e5ce%40googlegroups.com.

[Rudi Hammad]

hahaha, of course I take no offense, on the contrary. I really appreciate all the feedback. It is good to know that I misunderstood the concept of OOP. That´s how you learn.You make, or I make  mistakes over and over again, and I learn from them.
The problem is not admitting your errors, and I´ve seen many people stuck in their old ways, because they refuse to admit they are wrong. Not me

Now I need to understand better the concepts of state and behavior  I think. I am going to watch the pymel course for now. And then I´ll get back again on all that.

cheers!

El martes, 7 de junio de 2016, 2:08:45 (UTC+2), Justin Israel escribió:

On Tue, Jun 7, 2016 at 11:54 AM Rudi Hammad <rudih...@gmail.com> wrote:

No it's not really better.

 wow I am completly useless!!! XXXXD. Okey okey, I will get there and finally get a good oop example. I see my mistakes thanks to all of you.
 Next time I´ll get it right. And if I don´t , I´ll devote my life to work at McDonalds.

I didn't mean any offense (hope none was taken?). Was just being honest. i completely understood your explanation of how you set things up, but didn't agree that it was the best usage of classes and inheritence, as it was intended. You should look up "mixins", as it sounds like what you are using classes for.

Don't head to McDonalds yet, unless its for a 6 piece nuggets and a Big Mac. 

 

--
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.

[Rudi Hammad]

Quick question about inheritance diagrams in pymel
I´ve read that usually the arrow in a inheritance diagram points to the superclass. diagram pymel
So if Transform is the superclass of Joint, DagNode the superclass of Transform,etc.. shouldn´t the arrows be pointing up?
I guess it is not relevant at all, but just in case

[Justin Israel]

As far as I can tell, Sphinx uses a default built in extension for drawing class inheritance, by using graphviz to generate a standard node graph:

http://www.sphinx-doc.org/en/stable/ext/inheritance.html

But this is not the same as UML, which would depict specialised classes pointing TO the generalized class they inherit from. Looks like you could use plugins to generate UML style graphs:

https://pypi.python.org/pypi/sphinxcontrib-plantuml

--
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/c57199ee-bdb7-4c2f-9dcb-35de74faaf31%40googlegroups.com.

[Rudi Hammad]

Okey...my future is in your hands. I have my McDonalds outfit next to me ....

another oop attempt

I´ve explained all in the code, so I will not extend myself here. So if I am still not getting it, well....burgers are okey

[Justin Israel]

Would you expect a Cartoon limb to always create a stretchy IK as part of its standard behaviour? If so, then you would probably override makeIk() in your CartoonFeatures, and do:

def makeIk(self):

    # do normal ik logic

    super(CartoonFeatures, self).makeIk()

    # do stretchy part here

In this version, it would mean that no matter what kind of BaseLimbRig you had, you could always call makeIk() on it. Because of it being OOP, the message dispatches to the correct receiver and you get different implementations.

 

--
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/1e3de1ed-af92-403a-bfc3-11e1c035c547%40googlegroups.com.

[Rudi Hammad]

Would you expect a Cartoon limb to always create a stretchy IK as part of its standard behaviour?

yes
 

def makeIk(self):

    # do normal ik logic

    super(CartoonFeatures, self).makeIk()

    # do stretchy part here

In this version, it would mean that no matter what kind of BaseLimbRig you had, you could always call makeIk() on it. Because of it being OOP, the message dispatches to the correct receiver and you get different implementations.

I don´t understand that. It is the first time I see super() in a method that is not __init__() so I don´t quite get 

 

[Justin Israel]

On Wed, Jun 8, 2016 at 11:38 AM Rudi Hammad <rudih...@gmail.com> wrote:

Would you expect a Cartoon limb to always create a stretchy IK as part of its standard behaviour?

yes

Then it would make more sense to do what I suggested instead of introducing a new special method name that only works if its a CartoonFeature. If you just override existing functionality from what you inherit, then you can keep treating them all as the same interface (polymorphism).

 

 

def makeIk(self):

    # do normal ik logic

    super(CartoonFeatures, self).makeIk()

    # do stretchy part here

In this version, it would mean that no matter what kind of BaseLimbRig you had, you could always call makeIk() on it. Because of it being OOP, the message dispatches to the correct receiver and you get different implementations.

I don´t understand that. It is the first time I see super() in a method that is not __init__() so I don´t quite get 

You should read up on it. It is a way to call a method on the right super class. Just like you would call the super class __init__, you may want to override other methods and at some point call the superclass behaviour, in addition to your extended logic

 

 

--
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/9227446d-47d5-42ef-94b7-4fd8f1cc7f9b%40googlegroups.com.

[Cesar Saez]

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? adding classes and changing method's names forces the user to import more stuff and learn how to use each one individually, it only adds complexity to your project.

I've said this before, but it looks like you are in your 'subclassing is cool' time (I've been there) so I will repeat the recommendation, please _forget about subclassing_ for now, you are so focused on implementing stuff using classes as categories that it ended up harming your code, all those subclasses are so annoying to maintain and potentially hard to understand (assuming this toy example sets the foundation of a big enough project).

Keep it simple, start from the usage code to make sure your interface makes sense, put some effort into testing so you can deliver solutions with some confidence, learn about python types/std-library and use it wisely... all that adds much more value to the quality of your code and generally cannot be done properly as an after thought (but you can always split your classes into subclasses).

Said that, I'm not advocating to not subclass ever, all I'm trying to say is don't start layering 'all the things' (tm) just because it's OOP, there are more aspects into it.

Cheers!

[Rudi Hammad]

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

[Andres Weber]

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.

[Rudi Hammad]

 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.

Of course, I agree. what I meant referring to the reel is that all the questions I am asking derive from that tool I did. I mean that you can consider it as a "hugh" test. That´s why I want to rewrite all from scratch, but this time doing it
right and applying OOP as I should.
And all of you are right, you got obsessed with subclassing. Now I consider do "theme" modules with regular functions instead of modules with classes that only collect themes without using any OOP for real.
But I also want to figure out the right way of subclassing.
I think that you took too literally , and that is my fault for not explaning it better, this code:

http://pastebin.com/zGx0KQ6h

this was just a test to see if I am understanding polimorfism, inheritance and override.

[Rudi Hammad]

.

And all of you are right, you got obsessed with subclassing.

sorry, I meant I got obsessed with subclassing

[Cesar Saez]

>> Why not pass the stretchy to makeIk as an argument?
>
>... Because maybe I makeIkStretchy has arguments on it own....
>... Same goes with the twist method. what if I discover a new setup of twisting in the future?

That is usually handled by abstracting the computation as a solver and passing a reference to said solver as an argument (it is what Maya does with its ik, there are not multiple subclasses per type of ik). Think about the code using your classes, your future self, when all the implementation details are not so clear in your mind, isn't it painful to have to import and learn how to use different things in order to create a limb with slightly different features? What about maintenance?

And yes, by testing I meant unit/integration/automated testing (hopefully test-first or tdd), sorry if I wasn't clear enough.

Anyway, good luck with the project,
Cheers!

[Justin Israel]

On Thu, Jun 9, 2016 at 11:05 AM Cesar Saez <ces...@gmail.com> wrote:

>> Why not pass the stretchy to makeIk as an argument?
>
>... Because maybe I makeIkStretchy has arguments on it own....
>... Same goes with the twist method. what if I discover a new setup of twisting in the future?

That is usually handled by abstracting the computation as a solver and passing a reference to said solver as an argument (it is what Maya does with its ik, there are not multiple subclasses per type of ik).

And for google-ability: "Composition over Inheritance". 

 

Think about the code using your classes, your future self, when all the implementation details are not so clear in your mind, isn't it painful to have to import and learn how to use different things in order to create a limb with slightly different features? What about maintenance?

And yes, by testing I meant unit/integration/automated testing (hopefully test-first or tdd), sorry if I wasn't clear enough.

Anyway, good luck with the project,
Cheers!

--

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/CAPamJi_Ge58xuR8652veqq2T16vmJtgmo4UfdQEN77yCwetoYw%40mail.gmail.com.

[Rudi Hammad]

That is usually handled by abstracting the computation as a solver and passing a reference to said solver as an argument

okey...okey..i read that sentence 10 times and still have no idea what it means. I think I going to get a lo deeper with oop before asking again here because I am starting to feel that I am wasting everybody´s time.

cool,I´ll check compositing over inheritance now

[Rudi Hammad]

after googling a little bit about super, now i undestood that.

def makeIk(self):

    # do normal ik logic

    super(CartoonFeatures, self).makeIk()

    # do stretchy part here

In this version, it would mean that no matter what kind of BaseLimbRig you had, you could always call makeIk() on it. Because of it being OOP, the message dispatches to the correct receiver and you get different implementations.

but what if I did an extension in the CartoonFeatures

def makeIk(self):

    # do normal ik logic

    self.makeIk()

   # do stretchy part here

isn´t that the same that you proposed?

 

[Marcus Ottosson]

def makeIk(self):
    self.makeIk()

Try it.

super() does what you think this does.

--

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/1d6ed251-9d88-4918-9d77-75b5809f99ee%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Rudi Hammad]

El jueves, 9 de junio de 2016, 10:41:00 (UTC+2), Marcus Ottosson escribió:

def makeIk(self):
    self.makeIk()

Try it

it gives an error. So that´s why there is super(). it allows to have the same method in a subclass, and use that same method existing in the superclass. right?
isn´t that technically an extension, because you are using the same method from the superclass and add more functionality?
In this case isn´t the same talking about overriding and talking about extension?

[Justin Israel]

I haven't heard the term "extension method" used before in the context of Python, so I had to look it up 

https://en.wikipedia.org/wiki/Extension_method

The definition doesn't seem to apply to how you are using it to describe this python code. Its defined as adding a method to a class after its type spec has already been defined (or compiled). So in python the closest thing would be to monkey patch an existing class by adding a new method to it (not to an instance but to the actual class, so that any instance will gain access).

When you redefine an existing method from a super class in the derived class, that would be called "overriding" in Python. You are making an existing method do something different than the super class implementation. Whether you choose to also call the the super class implementation at any point in that new overload is up to you. 

--
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/0b3b06f8-945d-42f3-b999-72ae18fd2edd%40googlegroups.com.

[Rudi Hammad]

can you check this video for on second?
Hear what raymond hettinger says in the min 22 second 05. He says that if the parent is called it is extending, if not, overriding.
He says literally " we extend the parent´s method ", so he says that he is extending a method

raymond hettinger

El jueves, 9 de junio de 2016, 13:04:07 (UTC+2), Justin Israel escribió:

On Thu, 9 Jun 2016 9:48 PM Rudi Hammad <rudih...@gmail.com> wrote:

El jueves, 9 de junio de 2016, 10:41:00 (UTC+2), Marcus Ottosson escribió:

def makeIk(self):
    self.makeIk()

Try it

it gives an error. So that´s why there is super(). it allows to have the same method in a subclass, and use that same method existing in the superclass. right?
isn´t that technically an extension, because you are using the same method from the superclass and add more functionality?
In this case isn´t the same talking about overriding and talking about extension?

I haven't heard the term "extension method" used before in the context of Python, so I had to look it up 

https://en.wikipedia.org/wiki/Extension_method

The definition doesn't seem to apply to how you are using it to describe this python code. Its defined as adding a method to a class after its type spec has already been defined (or compiled). So in python the closest thing would be to monkey patch an existing class by adding a new method to it (not to an instance but to the actual class, so that any instance will gain access).

When you redefine an existing method from a super class in the derived class, that would be called "overriding" in Python. You are making an existing method do something different than the super class implementation. Whether you choose to also call the the super class implementation at any point in that new overload is up to you. 

--
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.

[Justin Israel]

On Thu, 9 Jun 2016 11:42 PM Rudi Hammad <rudih...@gmail.com> wrote:

can you check this video for on second?
Hear what raymond hettinger says in the min 22 second 05. He says that if the parent is called it is extending, if not, overriding.
He says literally " we extend the parent´s method ", so he says that he is extending a method

raymond hettinger

He said if you re-implement the method and you don't call the parent method, it is overloading, and if you do call the parent method you are "extending". 

First, he didn't refer to it as an "extension method", which is defined elsewhere to be something completely different. Also, I can't seem to find any other information that backs up this particular distinction that he made. None of the info on method overloading that I can find contains this detail. They just say if you redefine a method with the same signature on a derived class, you are overloading. Calling parent implementation seems to have no bearing on classifying it as such. 

Can you find anything else to back up this statement he made? 

 

El jueves, 9 de junio de 2016, 13:04:07 (UTC+2), Justin Israel escribió:

On Thu, 9 Jun 2016 9:48 PM Rudi Hammad <rudih...@gmail.com> wrote:

El jueves, 9 de junio de 2016, 10:41:00 (UTC+2), Marcus Ottosson escribió:

def makeIk(self):
    self.makeIk()

Try it

it gives an error. So that´s why there is super(). it allows to have the same method in a subclass, and use that same method existing in the superclass. right?
isn´t that technically an extension, because you are using the same method from the superclass and add more functionality?
In this case isn´t the same talking about overriding and talking about extension?

I haven't heard the term "extension method" used before in the context of Python, so I had to look it up 

https://en.wikipedia.org/wiki/Extension_method

The definition doesn't seem to apply to how you are using it to describe this python code. Its defined as adding a method to a class after its type spec has already been defined (or compiled). So in python the closest thing would be to monkey patch an existing class by adding a new method to it (not to an instance but to the actual class, so that any instance will gain access).

When you redefine an existing method from a super class in the derived class, that would be called "overriding" in Python. You are making an existing method do something different than the super class implementation. Whether you choose to also call the the super class implementation at any point in that new overload is up to you. 

--
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/0b3b06f8-945d-42f3-b999-72ae18fd2edd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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/92f6da08-e7a0-4ad2-9fa1-2d47682f7f1d%40googlegroups.com.

[Rudi Hammad]

Can you find anything else to back up this statement he made? 

nop. This guy is one python "creators" I think, so he must know what he is talking about. But anyway, the important thing is understanding what is he is doing i guess

[Justin Israel]

On Fri, 10 Jun 2016 8:52 AM Rudi Hammad <rudih...@gmail.com> wrote:

Can you find anything else to back up this statement he made? 

nop. This guy is one python "creators" I think, so he must know what he is talking about.

He looks to be a consultant and trainer. Not a "creator". Guido was the creator  

Either way he is obviously a smart and experienced dude. But he still didn't day they are extension methods. Just that you are extending functionality. 

But anyway, the important thing is understanding what is he is doing i guess

Yep I have no argument about the process. I was just getting into the part about accepted terminology since you had made the statement earlier about your approach being called extension methods 

--
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/e9ae0909-c389-40b7-b267-d4135c5749a5%40googlegroups.com.

[Rudi Hammad]

On Fri, 10 Jun 2016 8:52 AM Rudi Hammad <rudih...@gmail.com> wrote:

Can you find anything else to back up this statement he made? 

nop. This guy is one python "creators" I think, so he must know what he is talking about.

He looks to be a consultant and trainer. Not a "creator". Guido was the creator  

At some points of his lectures he says stuff like: "in python 3.0 you don´t need to write xrange anymore, because range will act as xrange in python 3.0. I did that"
he also says, when there is something new he talks about: " I don´t remember if I implemented that or Guido did.."

Anyway, it just out of curiosity knowing who did what.

[Justin Israel]

Cool. He is a Python 3 contributor. Obviously very experienced.

 

--
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/e125005c-bbb5-4107-ac88-b7ae983dfd8f%40googlegroups.com.

[Kyle Burris]

Jumping in here about the demo reel.

Overall nice work, it looks like you have your head around cartoony setups. Two things I noticed.

1: slow the reel down. I rewound the video 4 times to try and see if the rear dog leg keeps the femur and the metatarsals parallel and it was just to fast to see what the hell was going on. I've always found that rigging reels that just show someone wiggling every attribute on the rig don't really convey much. You can speed things up a bit but focus on a few things you solved in an innovative way.  I'd rather see you show 3-5 rig setups slowly so I understand what problem you solved and how than see everything on every rig.

2: The illustration you use in the rig UI is cute, but ultimately it doesn't lend its self to adding new setups. What would happen if you had to add another setup? Would you have to redraw the illustration? How would that work in production?

Keep it up though, there are some things in there I'd like to take a better look at if they weren't flying by me at 100km/h :)

Kyle

On Saturday, June 4, 2016 at 4:20:36 PM UTC-4, Rudi Hammad wrote:

hello,

so I spend a couple of months making my show reel which is a rig builder tool. Here you have the link if you want to check it

riggin/programing reel

I learned a lot doing it, and I want to thank this forum for helping me with my questions (even the stupids ones....)
Any way, now I want to rewrite my code avoiding making some mistakes I did previously, so I wanted to ask you If I am using the instance variables right.( code in pastebin link )

http://pastebin.com/yxMNRXHT

I thought that arguments like side, or name are very used in all the methods, so is it okey to out them in the __init__? this way, I don´t have to keep using those arguments over
and over again in the rest of the methods.
But of course that obligates me to create the class instance.

I now about classmethods to call directly the class. But then, should all my methods be classmethods?
I don´t know, a programer told me that scripting for 3d I don´t have to care too much about all that, but I don´t want my code just to work, I want to make a proper code too when
I am applying it to rigging.

cheers

[Rudi Hammad]

hi,
thanks for the feedback.
I know it to fast. I had to put a lot of stuff in less than 3 minutes.
About you first question, the setup if just an ik that goes from the "knee" equivalent to the ankle, as a standar biped leg, and the the femur joint is outside the ik. it had an aim to the foot that you can turn on and off. Like an autoclavicle almost that you can turn on and off, or blend the following values, so it follows the foot as you want. This setup is the one that animators where I worked liked. It is simple and they where happy with it.
about the second question, the UI intend to show a way to keep adding element. It is true that it looks like a biped rig builder, but as shown in the reel you can build anything. 

I am working on the second version now, which is completely different. The fist version shown on the reel works great for creatures, but, I can´t build a Tank rig, or a simple book rig.
So what I want is to build a new system to be able to create anything. It will be less user friendly, but much more powerful. This one is cool because it is fast and easy to use.

Anyway, thanks for the feedback