Using .NET controls in .NET Forms in MAXScript

loocas | 3ds Max,dotNET,maxscript,technical | Sunday, September 11th, 2011

If you’re used to scripting your GUIs in Max with the standard rollouts via “createDialog …”, you might be a little confused and lost when you first try to use a 100% .NET Form object instead.

Whatever your reason might be for using .NET Forms instead of standard dialogs, you’ll still want to:

  • Create the main form and define its properties
  • Define other UI controls, such as buttons, checkboxes etc…
  • Define event handlers for specific control objects
  • Initialize and display the entire Form with all the controls and functionality tied in

All this is done a little differently in the .NET realm than what you’re used to in MAXScript. But before you start, check out Paul Neale’s great .NET tutorials on his site. Paul provides some great info for anyone trying to use .NET controls in their scripts.

Now, there is one thing I bumped into, you can actually use .NET objects in MAXScript rollouts, however, you cannot use regular max controls in .NET Forms! So, trying to assign a standard button to a .NET Form will result in an error.

You might think that this creates a burden on the TD to actually skin and customize the .NET controls to look like native 3ds Max GUI elements. You can do this, of course, but it’d really be a lot of additional work to hassle around with color classes, HWNDs etc… you actually don’t need to worry about this as there is an Assembly available in standard Max installations. It’s a little .dll, found in the root of Max, called MaxCustomControls.dll. This Assembly contains some of the more exotic controls, such as SceneExplorer, but it also contains a complete Form control that has already been modified so it reflects your 3ds Max environment, including all the colors, themes and even an initialization method for showing the control as a part of the max process/window.

(more…)

Shotgun and 3ds Max integration preview

loocas | 3ds Max,maxscript,Python,showcase,software,technical | Friday, April 29th, 2011

Get the Flash Player to see this content.

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

Using Dictionary data types in 3ds Max

loocas | maxscript,Python,software,technical | Thursday, April 28th, 2011

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:

  1. String parsing (i.e. a very primitive way of handling foreign data types, not really recommended)
  2. Manual wrapping (i.e. passing in a List or Array object and converting it back to a Dictionary object)

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.

(more…)

Character encoding in MAXScript

loocas | 3ds Max,maxscript,technical | Thursday, April 14th, 2011

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.

Weird behavior of scripted controllers in 3ds Max 2011

loocas | 3ds Max,maxscript,technical | Wednesday, March 30th, 2011

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.

NukeOps. Tools for 3ds Max to Nuke workflow.

loocas | 3ds Max,maxscript,Nuke,software,technical | Sunday, January 2nd, 2011

Get the Flash Player to see this content.

To celebrate a new, fresh year ahead, I sat down and wrote a script that I’ve wanted to write for some time. A simple to use, yet powerful set of tools that’d help out anyone working in 3ds Max and Nuke to get the 3ds Max Cameras and locators (be it geometry, point helpers or anything between) to Nuke, flawlessly and with as little effort as possible.

So I condensed two essential functions into a single-click button in your toolbar. :) Watch the vieo above for a thorough description with examples.

The functionality could be described as Save To File and Copy To Clipboard methods. The first one will take all the selected objects and will generate a .chan file for each of them which can then be imported back in Nuke’s Axis or Camera nodes. The second one is pretty cool and rather powerful. I wrote a set of functions that take the selected objecs and generate a full Nuke script in the memory, which is then stored in the clipboard. A simple Ctrl+V in Nuke’s node editor will then paste in the generated Nuke script with all the Cameras and Axis nodes as they were in 3ds Max’s scene. Very cool, fast and useful for more complex comping in Nuke.

Anyways, the tools are licensed under the Creative Commons License, so, feel free to enhance and share the scripts as you like, as long as you give me credits for it. ;)

DOWNLOAD, install by drag and dropping onto you 3ds Max scene. Don’t forget to copy the import_chan_file.tcl to your Nuke plugins directory.

Enjoy!

EDIT: If you’re having trouble installing the script using the .mzp installer, just open the NukeOps.mzp file with WinRAR or WinZIP (or directly in TotalCommander for example), extract the files and copy them to the appropriate folders of you 3ds Max installation (in my case it’s the C:\Program Files\Autodesk\3ds Max 2011\ folder):

  • duber_NukeOps.mcr to C:\Program Files\Autodesk\3ds Max 2011\ui\usermacros
  • NukeOps.ms to C:\Program Files\Autodesk\3ds Max 2011\Scripts\Startup
  • all the .BMP files to C:\Program Files\Autodesk\3ds Max 2011\ui\usericons

Setting up Environment variables from MAXscript

loocas | 3ds Max,maxscript,technical | Thursday, October 14th, 2010

Just a note on this topic as I just recently needed to set up some Env. variables via MAXScript for certain in-house tools to work correctly and I bumped into a weird behavior of the .NET classes I used. So, for anyone out there with a similar task at hand, read on to save some time figuring it out. :)

Basically, all you need in order to get or set environment variables via .NET are two classes:

  • “System.Environment”
  • “System.EnvironmentVariableTarget”

Then, you simply need to call a method on the “System.Environment” class, called, simply, SetEnvironmentVariable() or GetEnvironmentVariable().

The “System.EnvironmentVariableTarget” class is used to invoke an Enum of:

  • Process – this Enum will get/set the Env. variable for the actual, live, process. The Env. var. will basically die with the process as well.
  • Machine – this one asks for the System Env. variables available to all users and processes
  • User – this one, obviously, only applies to the given user

So, my initial approach was as usual, calling the methods this way:

sysEnv = dotNetClass "System.Environment"
envTarget = dotNetClass "System.EnvironmentVariableTarget"

sysEnv.SetEnvironmentVariable("MyVariable", @"MyValue", envTarget.Machine)



However, this threw an error:

-- Syntax error: at ),, expected 
--  In line: sysEnv.SetEnvironmentVariable("MyVar", @



In such a case, I recommend using the showMethods() method for investigating .NET methods in MAXScript. This partially reveals syntax as well as actual methods available:

showMethods(dotNetClass "System.Environment")
  .[static]<System.Boolean>Equals <System.Object>objA <System.Object>objB
  .[static]Exit <System.Int32>exitCode
  .[static]<System.String>ExpandEnvironmentVariables <System.String>name
  .[static]FailFast <System.String>message
  .[static]<System.String[]>GetCommandLineArgs()
  .[static]<System.String>GetEnvironmentVariable <System.String>variable
  .[static]<System.String>GetEnvironmentVariable
<System.String>variable <System.EnvironmentVariableTarget>target
  .[static]<System.Collections.IDictionary>GetEnvironmentVariables()
  .[static]<System.Collections.IDictionary>GetEnvironmentVariables
<System.EnvironmentVariableTarget>target
  .[static]<System.String>GetFolderPath <System.Environment+SpecialFolder>folder
  .[static]<System.String[]>GetLogicalDrives()
  .[static]<System.Boolean>ReferenceEquals <System.Object>objA <System.Object>objB
  .[static]SetEnvironmentVariable <System.String>variable <System.String>value
  .[static]SetEnvironmentVariable <System.String>variable
<System.String>value <System.EnvironmentVariableTarget>target



So, after doing this, the correct syntax is:

sysEnv = dotNetClass "System.Environment"
envTarget = dotNetClass "System.EnvironmentVariableTarget"

sysEnv.SetEnvironmentVariable "MyVariable" @"MyValue" envTarget.Machine



Hope this helps anyone with similar issues.

duberPython features demonstration!

loocas | 3ds Max,maxscript,Python,software,technical | Thursday, March 4th, 2010

duberPython banner

I’m trhilled to be able to finally showcase, at least, some of our very own Python implementation into 3ds Max!

First off, our primary reason for writing our own, proprietary, Python connection to 3ds Max is Tactic by Southpaw Technology. An awesome asset management system entirely written in Python that I decided to invest in and integrate our tools and software packages into. Another reason for this connection, later came up, was the need for writing much more complex scripts with complex GUIs, since, as you probably know, a few functional lines of code are hardly enough in a modern, efficient, VFX production of today. ;)

The heart of our Python integration is dotNET from Microsoft. I can’t express myself enough how much I appretiate this framework! The brain of our Python integration is IronPython. Also a product from Microsoft, completely open source and free, which are two very important aspects for any pipeline tool in any production facility of any size. Not the price as much as the availability of the software. And with IronPython and Microsoft, I am certain that this piece of software will be around for years!

(more…)

duberPython is coming to life!

loocas | 3ds Max,maxscript,Python,software,technical | Friday, December 11th, 2009

duberPython banner

I am very excited to present a very early development results for our own Python implementation in 3ds Max.

First a bit of an intro. At duber, I’ve setup everything around Python, the most versatile and powerful language I’ve ever seen. I felt in love with Python so much that it even influenced my decision to leave Fusion (my favourite compositing app) and dive into Nuke (my, now, most favourite compositing app). I even invested in a commercial data and asset management system, Tactic, that is entirely written in Python. I run tons of custom Python scripts to tie together programs such as Tactic, Nuke, FrameCycler, Photoshop etc… etc… But the last missing piece to the entire pipeline puzzle was 3ds Max.

(more…)

An interesting concept behind Structs in MAXScript

loocas | 3ds Max,maxscript,technical | Tuesday, December 8th, 2009

I bumped into this issue of referencing values inside of Structs, which is a very elegant solution to using variables across your code, while avoiding global declarations. The issue was pretty much that I wasn’t aware of the implementation design of Structs in MAXscript.

Basically, Structs are these overly simplified custom classes know from such languages as Python (to which I’ll try to compare these). However, Structs are really so simple that they don’t even implement such functionality as inheritance (a pitty by the way), or more advanced functionality known from Python. Structs, rather than classes, could be called groups. That’s what I’ve been using them for mainly. I grouped a bunch of functions and called them via a standard attribute reference paradigm.

(more…)

« Previous Page | Next Page »

Powered by WordPress | Theme by Roy Tanck