Creating 3ds Max deployments
A very informative post on the Autodesk forums about making 3ds Max deployments.
I planned to do a similar how-to here, on this blog, in the future. Possibly a videotutorial, so, stay tuned…
A very informative post on the Autodesk forums about making 3ds Max deployments.
I planned to do a similar how-to here, on this blog, in the future. Possibly a videotutorial, so, stay tuned…
So far I haven’t had much luck transforming my render farm to a fully virtualized environment for easier management of the render nodes’ software config.
I’ve tried Microsoft’s Hyper-V technology at first as it seemed like the easiest path, but I couldn’t have achieved what I’ve wanted from the setup:
I’ve even tried the SCVMM, but it was way too complex and complicated so I didn’t actually spend too much time fiddling with it.
I’m currently looking at my #2 option (mainly due to added cost and software layers), VMWare. Especially the VMWare View and vSphere products.
So, no virtualization tips from me right now, all is still one big work in progress, but I’ll be posting updates as soon as I have them.
I recently had a problem with Deadline 5 and its (awesome) Power Management setup. The issue was that the server that was running the Pulse on wasn’t waking my machines up from their shutdown states (WOL).
The weirdest thing was that I was able to wake those machines up from any of my workstations via the Deadline Monitor app, but Pulse wasn’t able to. So, after speaking to the Thinkbox Software support (which is also top-notch and very helpful, by the way), they recommended me a few network traffic sniffing apps to monitor what is going on on the NICs.
The problem was that the NIC connected to the network was not actually sending the magic packet, so, no machines were, obviously, able to receive it. After a bit of further investigation, I found out that the WOL packet was actually being sent through the secondary NIC on the server, which wasn’t physically connected to the switch (mainly because the server also acts as a DC). So, the simplest solution seemed to disable the secondary NIC in Windows and have the primary NIC take care of the whole business.
This, however, presented a lot of trouble. By disabling the secondary adapter, you completely disable the NIC (in Windows, that is), so, with that you also disable any licenses that are bound to that particular adapter’s MAC! After that I wasn’t able to start Nuke, Mari, or even Deadline Slaves!
So, I had to dig deeper. The answer was Interface Metrics. In the Advanced tab under the IP properties, you can manually override Interface Matrics. See the link for more details, but basically, any lower value has higher priority. In my case, the secondary NIC (not physically connected to the switch), got automatically assigned a higher priority matric (a lower value), than the primary NIC. I manually overrode those and voila!, all traffic was being directed through the primary NIC.
To check what settings you’re at, use this command in the command prompt:
netsh interface ip show address
Hope this helps…
After having a very interesting discussion with a friend and collegue of mine, Michal Mocňák, on the topic of IT infrastructure virtualization, I realized that this is something I’ve needed even for my small, but growing “data center”!
The “data center” is still currently offline (except for the license server), so, I’ve been thinking of how to improve upon my previous setup with the future in mind. With a semi-constant grow of my render farm, the management, upgrades, installations and maintenance of the individual machines from the software point of view is becoming more and more problematic. I’ve written a few tools to help me automate the process, but still, managing the actual OS, the actual installed applications, the updates, hotfixes and service packs etc… is a hassle. I currently only have nine nodes in my farm, but being able to abstract from any number of physical machines and be able to easily manage my nodes from a one-person point of view (yeah, I am the only TD/IT guy here
) would be a bless!
If you’re interested in a live demo or more information about the duber Python and Shotgun integration in 3ds Max, drop me a line via e-mail at: ldubeda[at]duber.cz
I’ve had a few customers and clients asked me specifically about getting Dictionaries from 3ds Max to Python using our 3ds Max Python plugin, but I wasn’t able to answer with an elegant or productive way of handling these data types in the MAXScript environment.
Until recently, I’ve been handling Dictionaries two ways:
String parsing is the worst possible way of handling such an issue. It’s very cumbersome, highly unintuitive and with MAXScript string capabilities, extremely difficult. Manual wrapping, on the other hand, is rather more elegant, faster and you can use other, known, data types to construct your future Dictionary and have that converted in Python natively. The down side is, you have to be very careful with the way you’re handling the future Dictionary. The thing is, only a tuple of list pairs can be successfully converted to a Dictionary in Python. This is a bit limiting as we don’t have any specific way to tell what is a Tuple and what is a List in our Python implementation in MAXScript as there are no such data types available. So, what I did was I had an Array sent to Python (an actual .NET Array object, by the way) I had that converted first to a Tuple, which is pretty straight forward and then have that converted to a Dictionary. Worked fine, but it was a bit difficult to construct more complex Dictionaries, especially nested Dictionaries, in MAXScript.
Unfortunately, on tuesday, this week, the primary file server acting also as a domain controller at the studio, failed. The issue was caused by an error on the primary RAID array where the OS was installed. This lead to a complete loss of the OS and the entire studio setup.
I don’t know what caused the problem, but when I returned to the studio, all my machines were restarted, running, but restarted. The Internet Router I used for external access was also down. I had to manually start up some services and buy a new router. Then, when Windows Update popped up on the file server and I hit “Install Updates”, since I figured when it was all down anyways, I may as well update the system. That was the biggest mistake! The server crashed into a BSOD and I had to restart it manually which resulted in the failed RAID array and the complete loss of the OS.
The other issue was with the MD1000 DAS with all the company and projects data on. Since I configured it as a software RAID I lost the complete array with the OS. The data is still on the drives, but I can’t access them, since the OS is down.
An example of the limitless possibilities how to customize your Deadline installation in order to make it work in your specific production pipeline.
Since Max 2008 (I believe) we have the great SciTE MAXScript editor in Max. It’s an awesome IDE. Very flexible, very lightweight, fast and powerful. Sure, there are much more robust or more beefed up IDEs out there, but for an integrated, dedicated, MAXScript IDE, it’s simply awesome. It’s so good I installed SciTE standalone and use it as an IDE for my Python and other scripting tasks.
So, I’ve been trying to unify my code page across the SciTE editors (the standalone and the integrated Max’s editor) and settled on a standard UTF-8 encoding, which seemed to work just great. However, I just bumped into a very strange bug where Deadline reported a “bad syntax” error on my jobs which were using PostLoad scripts to automatically repath all my assets in my scenes.
The worst part was, the scripts were perfectly fine. They worked just fine in my local Max sessions, but they refused to work when run on the farm. I accidentaly discovered that it was related to the file’s encoding. When I resaved the file in Notepad (on my server) using the ANSI character encoding, the jobs suddenly started to work.
So, if you’re using a UTF-8 encoding in your SciTE editors, including and especially in the integrated Pro Editor in 3ds Max, make sure to save the scripts in a different encoding before executing them on the render farm.
I just bumped into a very weird thing.
I have a master object that stores a Custom Attribute definition with some reserved value containers and a function that gets called from withing scripted controllers (float_script()) that calculates a wheel’s circumference based off of the input data (wheel radius, distance traveled etc…).
Now, I’ve noticed there is a constant call to this CA function when I have a graph editor open and simply move my mouse cursor on screen across the viewports! This is pretty bad for the setup I have since it forces the wheels to update their rotation values many times more often through a single frame than it should! I have no idea why this is or how to stop it, but it’s something you should consider when tweaking your rigs!
This happened on 3ds Max 2011 x64, not sure about other versions, though.