On Tue, Sep 14, 2021 at 7:52 AM Rudi Hammad <rudiham...@gmail.com> wrote:
> About V crypt, I got in thouch with them and they sent me the system to > test it in demo mode. It work pretty well, but as Justin anticipated and as > the video showed, all clients are requiered to have the app. > So maya is should be launched from V Crypt, and then you can open the > encrypted files. Which is not ideal because you are enforcing everyone to > purchast their system. > > So as an alternatively I tried to do something with addCheckCallback that > Marcus mention: > > mSceneMsgOpenCheck = OpenMaya.MSceneMessage() > def licenseCheckOnOpen(*args): # a function that reads your mac address > and if it doesn't match the hardcoded one, it won't open. > OpenMaya.MSceneMessage.addCheckCallback(mSceneMsgOpenCheck.kBeforeOpenCheck, > licenseCheckOnOpen) > > but that was a total fail....it work is you execute that at the beginning > of every maya session (for instance putting it in the userSetup.py), but > then you just have to find this part of the code and remove it... > > ps: let me know if this last part is offtopic and I'll just shut up about > it. > Oh I didn't even connect your MEL and callback questions to this topic. I see now that you were experimenting with related custom approaches. Yea I agree with you that it would be cumbersome to require everyone to purchase some encryption app license. But maybe the approach is that a temp license is given to the client on behalf of the owner of the media and the one imposing the workflow? Having full ownership of the Maya process, as V Crypt wants to do, seems like the only way to get close enough to securing the media. If you ever let the user have direct unregulated access to the source then they can disable whatever checks (callbacks or whatever). "Close enough" is maybe just making it hard enough to avoid mistakes and easily sharing things? > > El lunes, 13 de septiembre de 2021 a las 19:22:37 UTC+2, Rudi Hammad > escribió: > >> It was still kind in the context of encrypting a maya scene that derived >> from the main V Crypt topic, but we'll do. >> El lunes, 13 de septiembre de 2021 a las 19:07:28 UTC+2, >> justin...@gmail.com escribió: >> >>> Please make sure to start a new thread if you want to engage in new >>> topics. It seems two completely new questions have been asked since the >>> original thread was started about V Crypt, and are entirely unrelated. >>> Thanks! >>> >>> On Tue, 14 Sep 2021, 4:25 am Rudi Hammad, <rudih...@gmail.com> wrote: >>> >>>> That's it! thanks Juan >>>> >>>> El lunes, 13 de septiembre de 2021 a las 15:33:57 UTC+2, Juan Moraga >>>> escribió: >>>> >>>>> Try using "def onOpenCallBack(*args):" instead. >>>>> Callbacks may pass on arguments to you method, which you can use or >>>>> not. But you need to allow the function to receive these arguments, >>>>> otherwise it will raise an exception. >>>>> >>>>> >>>>> On Mon, 13 Sep 2021, 15:09 Rudi Hammad, <rudih...@gmail.com> wrote: >>>>> >>>>>> Hello, >>>>>> any idea why this is not working? >>>>>> I opened a scene and created this callback, and then saved the scene >>>>>> >>>>>> def onOpenCallBack(): >>>>>> print "this is a test" >>>>>> >>>>>> checkCallback = >>>>>> OpenMaya.MSceneMessage.addCheckCallback(OpenMaya.MSceneMessage.kBeforeOpenCheck, >>>>>> onOpenCallBack) >>>>>> >>>>>> Now when I open the scene I get this error: >>>>>> # TypeError: onOpenCallBack() takes no arguments (2 given) // >>>>>> // Warning: line 0: Python callback failed // >>>>>> >>>>>> but I didn't give any arguments. Why is it saying given 2? are they >>>>>> *args and **kwargs? Still, any idea why this is not working? >>>>>> Thanks >>>>>> >>>>>> El lunes, 6 de septiembre de 2021 a las 22:23:04 UTC+2, Rudi Hammad >>>>>> escribió: >>>>>> >>>>>>> oh, about the screenshots. If the rig is encapsulated in a black >>>>>>> box, maybe it would be possible set a callback preventing from unlocking >>>>>>> the blackbox? >>>>>>> That way you can check want is inside and take screenshot. >>>>>>> >>>>>>> El lunes, 6 de septiembre de 2021 a las 22:02:29 UTC+2, Rudi Hammad >>>>>>> escribió: >>>>>>> >>>>>>>> Quick question, I haven't use mel in 4 years now so it is probably >>>>>>>> something foolish but why is this not working? >>>>>>>> >>>>>>>> string $toEval = "def foo():import uuid; macAddress = >>>>>>>> uuid.getnode(); return macAddress; foo()"; >>>>>>>> string $macAddress = python($toEval); >>>>>>>> print $x; >>>>>>>> >>>>>>>> I would expect $x to print my computer mac address by it is empty. >>>>>>>> >>>>>>>> El lunes, 6 de septiembre de 2021 a las 15:39:02 UTC+2, >>>>>>>> golu...@gmail.com escribió: >>>>>>>> >>>>>>>>> Marcus, thanks for your comment! >>>>>>>>> >>>>>>>>> When I talked about export I meant not to ma or mb, I meant for >>>>>>>>> example to alembic or other, because as I knew alembic export is >>>>>>>>> like a >>>>>>>>> separate plugin, and .correct me if I am wrong export to alembic will >>>>>>>>> be >>>>>>>>> ignored by this callback. >>>>>>>>> >>>>>>>>> I've not understood you, sorry, yes it is already protected, but >>>>>>>>> if this protected scene to /myrig.mb will be referenced in the main >>>>>>>>> scene, >>>>>>>>> during the main parent scene opening, I will need to decrypt my >>>>>>>>> rig.mb and >>>>>>>>> any other child scene which is referenced and send to a remote worker, >>>>>>>>> or I understand you wrong) >>>>>>>>> >>>>>>>>> About RAM I'm sorry, that's my mistake, later edited the message, >>>>>>>>> but was too late, you absolutely right! >>>>>>>>> >>>>>>>>> понедельник, 6 сентября 2021 г. в 13:27:48 UTC+3, Marcus Ottosson: >>>>>>>>> >>>>>>>>>> The part of Maya that does the serialisation to ma and mb - be it >>>>>>>>>> via export or save - is a singular point of access. The scene >>>>>>>>>> callbacks >>>>>>>>>> should account for all ways in which creating those is possible, >>>>>>>>>> including >>>>>>>>>> via Python and MEL. It wouldn’t account for manual export to other >>>>>>>>>> formats, >>>>>>>>>> but there’s no end to that. Screenshotting your viewport is a format >>>>>>>>>> too, >>>>>>>>>> albeit a lossy one. But I’d argue that depending on what you want to >>>>>>>>>> protect, if that is rigs and animation, the Maya scene format should >>>>>>>>>> be >>>>>>>>>> enough. >>>>>>>>>> >>>>>>>>>> - OpenMaya.MSceneMessage.addCheckCallback() >>>>>>>>>> >>>>>>>>>> <https://help.autodesk.com/view/MAYAUL/2020/ENU/?guid=__py_ref_class_open_maya_1_1_m_scene_message_html#a2c26fb924ad7939fd6bf50253044a7d3> >>>>>>>>>> >>>>>>>>>> And all of it must be done recursively on the whole data tree in >>>>>>>>>> scene >>>>>>>>>> >>>>>>>>>> I’d argue not. The information you protect is the information in >>>>>>>>>> the scene file. If that scene file consists of an absolute path to >>>>>>>>>> e.g. >>>>>>>>>> c:\myassets\myrig.mb then that is *already* protected; nobody >>>>>>>>>> can access that file but you on your local machine. >>>>>>>>>> >>>>>>>>>> so at some point how to handle your RAM memory, because you can’t >>>>>>>>>> store this encrypted data somewhere…) >>>>>>>>>> >>>>>>>>>> I’d argue not (again :)). Is it to protect against >>>>>>>>>> hacker-animators and hacker-riggers? Or against the general >>>>>>>>>> workforce that >>>>>>>>>> has no clue about callbacks and encryption? If the latter, then >>>>>>>>>> saving it >>>>>>>>>> into a temp directory first, and encrypting it after should suffice. >>>>>>>>>> To the >>>>>>>>>> user, the file would end up where they said it should. But really, >>>>>>>>>> it’s a >>>>>>>>>> different file altogether. Then that file is copied back into a temp >>>>>>>>>> directory and decrypted whenever they open it. All of that can >>>>>>>>>> happen on >>>>>>>>>> disk. >>>>>>>>>> >>>>>>>>>> And besides, memory is just another location. A motivated-enough >>>>>>>>>> hacker-animator could access RAM as easily as any location on disk. >>>>>>>>>> Doesn’t >>>>>>>>>> increase the level of protection. >>>>>>>>>> >>>>>>>>>> On Mon, 6 Sept 2021 at 11:02, Andrew Golubev <golu...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> It is a very interesting discussion. >>>>>>>>>>> >>>>>>>>>>> Yeah, I will agree that it definitely must be invisible - so >>>>>>>>>>> artists don't even know that encryption happened. >>>>>>>>>>> But you can't stop on scene saving and loading, you should >>>>>>>>>>> create lots of workarounds in this "secure Maya client". >>>>>>>>>>> Somehow you need to lock any exporting of data inside in any >>>>>>>>>>> format, hide\lock\encrypt code of all used inside scripts, lock any >>>>>>>>>>> new >>>>>>>>>>> plugin loading\or current plugins disabling. >>>>>>>>>>> And lock script editor, or make some sort of interceptor, to >>>>>>>>>>> ensure, that no script will run to export or explore private scene >>>>>>>>>>> data. >>>>>>>>>>> Also, if I understand all correctly, it will give a lot of >>>>>>>>>>> restrictions for people who work with their tools(it will lock them >>>>>>>>>>> on the >>>>>>>>>>> layout of instruments you gave to them). >>>>>>>>>>> >>>>>>>>>>> And this only stuff that comes up to mind immediately, I think >>>>>>>>>>> during the development of such Maya launch wrapper lot's of >>>>>>>>>>> underwater >>>>>>>>>>> stones will come up eventually. >>>>>>>>>>> >>>>>>>>>>> Additionally, if in your scene you will have references, during >>>>>>>>>>> reference load you will need to decrypt this data, >>>>>>>>>>> the same will go to any geometry\textures or any files - you >>>>>>>>>>> will need to decrypt on the run. >>>>>>>>>>> All of it must be done recursively on the whole data tree in >>>>>>>>>>> scene, >>>>>>>>>>> so at some point how to handle your RAM memory, because you >>>>>>>>>>> can't store this encrypted data somewhere. >>>>>>>>>>> >>>>>>>>>>> And even this will not save you from attempt to try take this >>>>>>>>>>> decrypted data from RAM... >>>>>>>>>>> воскресенье, 5 сентября 2021 г. в 10:27:53 UTC+3, Marcus >>>>>>>>>>> Ottosson: >>>>>>>>>>> >>>>>>>>>>>> I agree with you. This would not solve all problems with >>>>>>>>>>>> working remotely, but it would solve some. Perhaps the biggest >>>>>>>>>>>> problems, >>>>>>>>>>>> namely accidental sharing and theft. I have also personally >>>>>>>>>>>> received >>>>>>>>>>>> material from artists at studios that really shouldn't have >>>>>>>>>>>> managed to >>>>>>>>>>>> leave the studio. Some even have limited internet access with local >>>>>>>>>>>> browsers accessible only through a virtual machine or local VNC >>>>>>>>>>>> connection, >>>>>>>>>>>> and assets *still* manage to leave the premises. >>>>>>>>>>>> >>>>>>>>>>>> That not only puts the studio at risk, but the recipient too. >>>>>>>>>>>> Both as a private person, as now your machine can leak confidential >>>>>>>>>>>> material, and as another business. If a leak should happen that >>>>>>>>>>>> leads to >>>>>>>>>>>> loss of cash for any larger entity such as WB there will be >>>>>>>>>>>> investigations >>>>>>>>>>>> and consequences. Private persons can get in trouble and >>>>>>>>>>>> businesses can >>>>>>>>>>>> crumble. >>>>>>>>>>>> >>>>>>>>>>>> The part I'm sceptical about is whether this particular tool is >>>>>>>>>>>> what solves this problem. If it complicates saving and loading of >>>>>>>>>>>> scenes >>>>>>>>>>>> (and even launching of Maya?) then I'd imagine people simply would >>>>>>>>>>>> not use >>>>>>>>>>>> it. But the idea sounds worth exploring, so off the top of my head >>>>>>>>>>>> I would >>>>>>>>>>>> try implementing a scene save/open callback to perform the >>>>>>>>>>>> encryption live >>>>>>>>>>>> and natively, rather than rely on an external tool. It could be as >>>>>>>>>>>> simple >>>>>>>>>>>> as letting Maya produce that binary `.mb` file of 1's and 0's, and >>>>>>>>>>>> reversing the whole thing on save, and then do the opposite on >>>>>>>>>>>> load. No one >>>>>>>>>>>> would know it happened, and it would unlikely have any noticeable >>>>>>>>>>>> effect on >>>>>>>>>>>> save/load time, and there are equal callbacks for exporting. >>>>>>>>>>>> >>>>>>>>>>>> On Sat, 4 Sept 2021 at 22:26, Rudi Hammad <rudih...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I think they must have thought about the export aswell. >>>>>>>>>>>>> Otherwise it wouldn't make any sense. >>>>>>>>>>>>> Of course ideally you would each person would work in their >>>>>>>>>>>>> office stations remotly, but it is not up to me. So if I choose >>>>>>>>>>>>> not work >>>>>>>>>>>>> with a client unless he guaranties remote workstation solutions, >>>>>>>>>>>>> I will >>>>>>>>>>>>> loose a lot of work. >>>>>>>>>>>>> Also many studios have not the resources , and even if they >>>>>>>>>>>>> do, the lag is some times to high to work remotly. >>>>>>>>>>>>> >>>>>>>>>>>>> Many times sharing is accidental due to the lack of control, >>>>>>>>>>>>> or planning in a production. In my experience I was doing a >>>>>>>>>>>>> freelance work >>>>>>>>>>>>> a couple of month a go. And we where all working remotly in our >>>>>>>>>>>>> personal >>>>>>>>>>>>> computers. >>>>>>>>>>>>> The supervisor at somepoint, sent me a rig from another >>>>>>>>>>>>> project as a reference. So obviously that was accidental because >>>>>>>>>>>>> working in >>>>>>>>>>>>> this situations like that, you do always thing that you are doing >>>>>>>>>>>>> anywrong. >>>>>>>>>>>>> So even if you sign NDAs, and you have good intentions, it can >>>>>>>>>>>>> leak. And of course, there is always people with bad intentions, >>>>>>>>>>>>> so we >>>>>>>>>>>>> can't be naive thinking that everyone will be professional. I >>>>>>>>>>>>> work with a >>>>>>>>>>>>> guy who managed >>>>>>>>>>>>> to get rigs that he shouldn't have. When I asked how did he >>>>>>>>>>>>> get them, he told me he took them out of the office in his last >>>>>>>>>>>>> day. >>>>>>>>>>>>> >>>>>>>>>>>>> My point being, that with a system like V Crypt, wheter it is >>>>>>>>>>>>> by accident or not, it might be the solution to encrypt files and >>>>>>>>>>>>> safely >>>>>>>>>>>>> work as freelance (specially for me since now I am full time >>>>>>>>>>>>> freelancer) >>>>>>>>>>>>> >>>>>>>>>>>>> I'll keep you posted >>>>>>>>>>>>> >>>>>>>>>>>>> El sábado, 4 de septiembre de 2021 a las 22:59:06 UTC+2, >>>>>>>>>>>>> justin...@gmail.com escribió: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun, Sep 5, 2021 at 8:38 AM Marcus Ottosson < >>>>>>>>>>>>>> konstr...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> That is true, that does sound like a good idea. Assuming the >>>>>>>>>>>>>>> software actually does what it says on the tin, it would at >>>>>>>>>>>>>>> least protect >>>>>>>>>>>>>>> against theft and accidental sharing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It wouldn’t protect against sending files though, because if >>>>>>>>>>>>>>> someone wanted to send some model or some rig, they could still >>>>>>>>>>>>>>> just export >>>>>>>>>>>>>>> it to a new .ma? For that, you’d probably be better off >>>>>>>>>>>>>>> intermingling it with custom nodes. Like how anything rigged >>>>>>>>>>>>>>> with mGear is >>>>>>>>>>>>>>> riddled with mGear nodes, making anyone attempting to open that >>>>>>>>>>>>>>> rig without >>>>>>>>>>>>>>> mGear loaded left with a sorely broken rig. And no amount of >>>>>>>>>>>>>>> exporting or >>>>>>>>>>>>>>> tampering with the scene file could fix it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> From the video it looks like you have to launch Maya from >>>>>>>>>>>>>> their launcher, which I assume installs a particular >>>>>>>>>>>>>> reader/writer plugin. >>>>>>>>>>>>>> I wonder if it's specific to ma/mb file types or if it hooks >>>>>>>>>>>>>> into every >>>>>>>>>>>>>> type. Because I was thinking that same thing you said about >>>>>>>>>>>>>> exporting to >>>>>>>>>>>>>> other formats, and would that go through the same hook? Also >>>>>>>>>>>>>> once Maya is >>>>>>>>>>>>>> launched, could someone turn off the plugin after the scene is >>>>>>>>>>>>>> loaded? >>>>>>>>>>>>>> >>>>>>>>>>>>>> When it comes to protecting stuff like code, usually you hear >>>>>>>>>>>>>> the best security is to just never let the source get onto the >>>>>>>>>>>>>> client side. >>>>>>>>>>>>>> But with DCC scene files if you have to work with them locally >>>>>>>>>>>>>> then it >>>>>>>>>>>>>> feels like there is going to be some way to defeat it. Once its >>>>>>>>>>>>>> unencrypted >>>>>>>>>>>>>> in the DCC, there must be a weakness that might just be more >>>>>>>>>>>>>> obscure to >>>>>>>>>>>>>> many people and the security is really just focused on the >>>>>>>>>>>>>> obvious act of >>>>>>>>>>>>>> copying files around. Probably the better approach is just not >>>>>>>>>>>>>> letting >>>>>>>>>>>>>> people work on their person workstations and only support a >>>>>>>>>>>>>> remote >>>>>>>>>>>>>> workstation solution like teradici. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, 4 Sept 2021 at 19:50, Rudi Hammad < >>>>>>>>>>>>>>> rudih...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes I am refereing to the actual file, not source code. >>>>>>>>>>>>>>>> Here's a usecase: >>>>>>>>>>>>>>>> due to covid a lot of production are done remotly. In >>>>>>>>>>>>>>>> somecase you can connect by logging remotly to office >>>>>>>>>>>>>>>> computers to work, >>>>>>>>>>>>>>>> in which case no protection is needed since it pretty much as >>>>>>>>>>>>>>>> if you where >>>>>>>>>>>>>>>> in the office. >>>>>>>>>>>>>>>> But in many cases, the files are sent to personal >>>>>>>>>>>>>>>> computers. Let's say you rig characters that are sent to 10 >>>>>>>>>>>>>>>> different >>>>>>>>>>>>>>>> animators to their personal computers. Despite the NDAs, its >>>>>>>>>>>>>>>> impossible to >>>>>>>>>>>>>>>> police everyone, >>>>>>>>>>>>>>>> specially if you don't know the client but you don't want >>>>>>>>>>>>>>>> to miss the opportunity to get a job. There is no guaranty >>>>>>>>>>>>>>>> that someone >>>>>>>>>>>>>>>> will not leak the file outside the production. >>>>>>>>>>>>>>>> So here is where you use in V Crypt system. It is not like >>>>>>>>>>>>>>>> you are recieving a file from an untrusted source because you >>>>>>>>>>>>>>>> are part of a >>>>>>>>>>>>>>>> production and you know that your .mb and .ma files are from >>>>>>>>>>>>>>>> the rigger not >>>>>>>>>>>>>>>> form a the prince >>>>>>>>>>>>>>>> of niggeria that is asking you for money XD. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That's seem a pretty secure way of working don't you think? >>>>>>>>>>>>>>>> you know you recieve a file that is encrypted because you know >>>>>>>>>>>>>>>> you are in >>>>>>>>>>>>>>>> production context. You can open it and work with it. It >>>>>>>>>>>>>>>> simply won't work >>>>>>>>>>>>>>>> outside you >>>>>>>>>>>>>>>> computer. >>>>>>>>>>>>>>>> El sábado, 4 de septiembre de 2021 a las 20:06:47 UTC+2, >>>>>>>>>>>>>>>> Marcus Ottosson escribió: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To protect the contents of a Maya file? Typically >>>>>>>>>>>>>>>>> protection would involve software, like Python source, but >>>>>>>>>>>>>>>>> you mean to >>>>>>>>>>>>>>>>> protect like a model or some animation? At that point, why >>>>>>>>>>>>>>>>> wouldn’t you >>>>>>>>>>>>>>>>> just hold onto the file, and not send it or make it publicly >>>>>>>>>>>>>>>>> available? >>>>>>>>>>>>>>>>> Maybe you have a particualr usecase in mind, because I can’t >>>>>>>>>>>>>>>>> quite see it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also I would be most weary opening an .mb from an >>>>>>>>>>>>>>>>> untrusted source. That’s what .ma is for, so you can >>>>>>>>>>>>>>>>> inspect it for any script-related things. I’ve been bitten >>>>>>>>>>>>>>>>> before and, as >>>>>>>>>>>>>>>>> they saying goes, fool me once. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sat, 4 Sept 2021 at 16:17, Rudi Hammad < >>>>>>>>>>>>>>>>> rudih...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> a while a go I create a thread about protecting your work. >>>>>>>>>>>>>>>>>> Along the same lines I saw this >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> V Crypt maya files >>>>>>>>>>>>>>>>>> <https://www.youtube.com/watch?v=kZc2-FcLuiI> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So in theory, you can generate a license for the computer >>>>>>>>>>>>>>>>>> mac address, and inside your >>>>>>>>>>>>>>>>>> .ma and .mb so some kind of assertion make sure sure that >>>>>>>>>>>>>>>>>> the file is being open in the right computer. And since both >>>>>>>>>>>>>>>>>> files are >>>>>>>>>>>>>>>>>> crypted, you can remove that block of the code. >>>>>>>>>>>>>>>>>> Also, if you try to saveAs, it is saved with th crypted >>>>>>>>>>>>>>>>>> format. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It seems like a good solution right? what do you think? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> R >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> 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/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com >>>>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/a1c4949b-eead-412d-b10a-6750ab07ef85n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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/e91cc054-a7ce-42d0-8d69-920dfdaa9ffcn%40googlegroups.com >>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/e91cc054-a7ce-42d0-8d69-920dfdaa9ffcn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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/CAFRtmOCpAua2TmorENN9OOzG%3Deg5T-cxotu%3DW8OBTA%2B-RacWjQ%40mail.gmail.com >>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCpAua2TmorENN9OOzG%3Deg5T-cxotu%3DW8OBTA%2B-RacWjQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>> 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/5eca697d-3760-42ec-af82-9663b5f963edn%40googlegroups.com >>>>>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/5eca697d-3760-42ec-af82-9663b5f963edn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>> 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/dbc66954-2d82-4c7f-b0d6-51e503f79942n%40googlegroups.com >>>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/dbc66954-2d82-4c7f-b0d6-51e503f79942n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>> 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/21a0260e-5f35-44c2-989d-4b249a37ee5cn%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/python_inside_maya/21a0260e-5f35-44c2-989d-4b249a37ee5cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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/1e2111c8-2c29-41d8-9846-2750b670abb4n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/python_inside_maya/1e2111c8-2c29-41d8-9846-2750b670abb4n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/6fbec95e-db8d-4a13-bff7-ac8cd59392bfn%40googlegroups.com > <https://groups.google.com/d/msgid/python_inside_maya/6fbec95e-db8d-4a13-bff7-ac8cd59392bfn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2LBDDNHQ4QKfAC4ohmEvBgkG_fMYAQG1ybz8PZ2Jq5mA%40mail.gmail.com.
