Sorry for the delay in my blog writing it’s been a while since my last post. What a whirl wind! We have been busy bees in ADN! The run down:
In February, we finished off our new release Developer Day Conferences in Bangalore, Chennai and Mumbai, India which went very well, lots of interest in the new API features for the next release. I got the unique opportunity to take a week vacation in India, and it was amazing, I had a great time! Then we headed off to San Francisco where my colleagues and I completed 3, two day training courses on these products 3ds Max SDK, MotionBuilder SDK, and Maya API, good turnout, lots of good questions, and best of all we got to put faces to names of our customers we have been supporting for the past few years! Thanks to everyone that attended. I also did a GDC Autodesk sponsored speaker session on the Thursday of GDC, in the South Hall, on Introduction to Maya API Programming and Custom UI; the recording should be in the GDC Vault if you have access to that, thanks to all that came!
Back in Toronto now and I am spending some time prepping for a training I am delivering in a week on Introduction to Maya API Python. While I was looking over some stuff, I came across this Python tip:
The low-down on the Python pyc files – Compiled Bytecode
Python Interpreted Language Whenever you read about the Python language you hear that it’s an interpreted language, however Python is more of a hybrid between an interpreted and compiled language, here is why below.
Compiled Bytecode Version of your Module Whenever you import a module, it creates a .pyc file in the same directory, which is a compiled bytecode version of your module. This bytecode file is created the first time you import a module, and is only re-created if deleted or the modified date on the module file and the bytecode file don’t match anymore, in other words as long as things don’t change in your module then it uses the compiled bytecode module it already has when importing.
Compiling is Automatic, behind the Scenes The cool thing about Python (among other things) is that this compile step is hidden from the user, you don’t need to do anything extra to make it happen, and you might not even know this happens, but go check to see if your imported module has this additional file now in your directory where the .py fle is. For example, Kristine.py should now have the sister file Kristine.pyc.
What’s the point of the bytecode file? The reason the Python language creates this bytecode module file is so when you import your module’s namespace it reads the file faster. Think of the difference between a person learning to read and an expert speed reader, if we didn’t have this we might be waiting a while every time we ran a module for the namespaces to be available to use in our code.
Bonus Side Effect of Bytecode Normally, 'we' (the general we) list for Python, that one of the weaknesses of the language is the open source-ness (Is that a word?!? It is now ;))or lack of discloser when you’re trying to hide your code. However you can send people compiled .pyc bytecode to people without the .py source code.
Python will load the .pyc file when it cannot find a .py file for the module; you just need to make sure the .pyc file is in the PYTHONPATH.
Can Maya benefit from this pyc file? Yes and no. For Maya’s scripted plug-ins’s, unfortunately this .pyc file is not generated when you are loading them into Maya. However if you create a bunch of functionality in a separate module and then import this into your Scripted Plug-in, this will generate a .pyc file for the imported module, this also goes for Maya Scripting using the Script Editor.
Is this your solution to prevent OpenSource? No :(, It doesn't take much to crack the the bytecode to find what Python source code is behind the curtain. The wonderful world of Google will tell you how to do it.
It can be time-consuming enough to set up your render layers: assigning objects, assigning material overrides...but you could also be in for a nasty surprise when you browse through your render layers and Maya spits out errors, like this one:
In this post, I'll tell you how to avoid these errors, and how to keep those render layer assignments.
Our users regularly have Installation & Licensing questions, especially around the annual product release cycle. We don’t want you struggling to install and get the product running, when you are excited to fire it up and check it out!
We have created an Installation Help landing page on autodesk.com to help you with these specific issues. From that page you can also go to the Installation & Licensing forum, where Autodesk Product Support is now a regular monitor, to make sure all users can get their products up and running quickly!
You must create a reference object before you animate or deform the original surface.
A reference object for a polygonal surface must have the same topology (number of faces) as the original surface. When you create a reference object, the topology of the reference object is identical to the original surface. However, if you make subsequent changes to the topology of the original surface, you must create another reference object.
A scene can contain any number of reference objects, but each surface in the scene can only have one reference object.
When working with a complicated Shader , it’s easy to get lost looking at all the available node. As a tip you can arrange the nodes to your liking then go to Bookmarks > Create Bookmark. Now you can go back and forth for that exact node arrangement