3dsmaxcmd rendering error: Unknown error while loading application

loocas | 3ds Max,technical | Thursday, July 31st, 2014


Ever tried to render a scene file on your machine via the command line using the 3dsmaxcmd.exe program, just to save some time loading up the entire program only to hit F9 for a single frame, but then the program fails at frame 0, prior to any rendering?

The reason might be you might be missing Backburner on your machine.

Even though you’re not actually network rendering and you have everything installed properly, if Backburner is missing, this error will surely pop up.

I spent quite a few hours figuring this one out when it worked just fine on my company machines, but it wasn’t rendering on my home workstation.

So, simply run the 3ds Max installation and add Backburner only. Nothing else is needed. You should be fine afterwards.

3ds Max 2015 announced

loocas | 3ds Max | Wednesday, March 19th, 2014


Autodesk has announced its 2015 software line and Max seems to have gained some very nice additions, fixes and plugins!

I’m mostly psyched about the Python support (which was not so good in Max 2014) and the new Layer system! YAY!

Here’s the announcement: area.autodesk.com/3dsmax2015

Executing multiple instances of 3ds Max with dynamic environment variables

loocas | 3ds Max,technical | Saturday, October 5th, 2013

The title sounds a bit complicated, but basically what I needed to achieve was having multiple installations of 3ds Max on my machines and running them as needed.

The problems started when I needed to also include certain .dlls in the Environment for Max to recognize. I store my plugins and plugin libraries outside of Max’s root folder for easier portability, updateability and maintenance.

So, to sum it up, I needed to add to my %PATH% env var “C:\duber\3ds Max 2014\dlls” when running 3ds Max 2014, or “C:\duber\3ds Max 2011\dlls” when running 3ds Max 2011 and so on.

This sounds easier than it actually is, since we cannot assign various Env Vars to shortcuts in Windows (or as far as I know we can’t, please correct me if I’m wrong), which’d solve this issue rather elegantly.

What I had to do instead was to create a .cmd file (a Windows command batch file) with a few simple commands in it and execute that file instead of 3ds Max directly.

Basically put this text into your .cmd file:

@echo off
SET PATH=%path%;C:\duber\3ds Max\2013_x64\dlls
START "" "C:\Program Files\Autodesk\3ds Max 2013\3dsmax.exe"

This will make sure to copy all the global %PATH% variables to the local, current, %PATH% group and include a special directory where all your .dlls are stored so that 3ds Max can see them when starting up.

The last line calls the 3dsmax.exe with no parameters (the first set of quotes).

Link to this start3dsMax2013.cmd file instead to the 3dsmax.exe and you’re all set.

Enjoy. :)

P.S.: Of course you can apply this very same principle to any other program you like, not just 3ds Max.

Shotgun API 3.0.15 and duberPython, all OK!

loocas | 3ds Max,maxscript,Python,technical | Wednesday, July 24th, 2013


I updated my Shotgun wrapper for duberPython yesterday to support the latest and greatest Shotgun API ver. 3.0.15.dev. All seems to be working pretty well, without any issues.

I added all the methods available by the API to my MAXScript wrapper, so that everything is fully accessible, through duberPython, from inside 3ds Max!

I will be releasing this wrapper to the public real soon, so stay tuned!

duberPython Shotgun 3.0.15.dev

duberPython is available for download!

loocas | 3ds Max,dotNET,maxscript,Python,software,technical | Saturday, July 13th, 2013

duberPython banner

That’s right! duberPython is finally ready for it’s debut public release.

But that doesn’t mean it’s a fresh newb of a plugin. It has been used in high-end productions at studios such as Pixomondo or Orbit, etc. on feature films, commercials, full CG animations, etc.

duberPython came into life after a long search for a solution that’d allow us at duber studio have 3ds Max communicate and play nicely with other pipeline tools and DCC applications. duberPython was designed, mainly, to bridge 3ds Max and Shotgun (JSON API is fully supported!) and Tactic. I even wrote a dedicated Shotgun wrapper, so that you can call Shotgun methods directly from within MAXScript (available upon request), so that writing your studio pipeline tools is really, really easy and fun.


The current version runs on the IronPython engine 2.7.3 and is compatible and has been thoroughly tested with CPython 2.7.3 (though, compiled Python modules are not accessible via IronPython).

Currently you can directly call Python code (via string parsing) from within MAXScript, or you can call Python scripts externally and pass it any number of variables for Python processing. The variables will get automatically translated to and from Python, so that strings are strings, booleans are booleans, arrays are arrays, etc. Even dictionary data types are supported in MAXScript (via Hastable dotNET objects)!


So, do not hesitate, head over to python.duber.cz and give your full-featured 30day trial a go and if you find it useful, I’d be very happy if you purchase the full version for only $25 bucks, which is a bargain for what you get! (site licenses are available upon request).

By the way, the full documentation can be read here: python.duber.cz/documentation

Corona Renderer kicks ass!

loocas | 3ds Max,opinions,software | Tuesday, June 11th, 2013

Corona Banner

Have you thought that the market with renderers is full and thus there is probably nothing that could come up with something almost revolutionary to stir things up? So did I. But man, was I wrong!

Introducing Corona, the unbiased, CPU based renderer that will kick asses of even the most high-end and proven renderer on the market, such as VRay, finalRender or Arnold.

It’s still in its Alpha stage of development, but let me tell you, I’ve been using it for over a year and have done quite a few TV commercials with it without too much of a hassle.

Now, you can read more about the renderer on the official page, even download the full-functioning version and try it out for yourselves. So, I won’t go into how awesome, simple and brutally fast the renderer is, but instead, I’ll write a bit about how we used the renderer for a slightly different purpose than just final rendering.


Persistent Environment Variable creation in MAXScript

loocas | 3ds Max,dotNET,maxscript | Monday, May 27th, 2013

This is a quick note to anyone who wishes to set certain environment variables for whatever reason.

If you’ve already done this and know what the EnvironmentVariableTarget Enumeration is, you can skip this post. But to the rest of you, listen up.

If you try to set an Environment Variable in a running process, the default behavior is that the Env Var will be stored in a Process location. This is a sandboxed location available and only valid throughout the process, that created it, lifetime. When you exit the process, the Env Vars will die with it. What this means is you cannot depend on such Env Vars for future reference (i.e. when you restart your process).

This is where the EnvironmentVariableTarget Enumeration comes into play. The other two locations you can use are User and Machine. While the User location will only be available to the specific user that is logged in at the time of the Env Var retreival, the Machine location is global, meaning all users will be allowed to source such an Env Var.

So, in practice, let’s look at MAXScript’s code to do so:

To store an Environment Variable “FOO” containing “BAR” for the currently logged in user, this is what you want to write:

dnEnv = dotNetClass "System.Environment"
dnEnvTarget = (dotNetClass "System.EnvironmentVariableTarget").User

dnEnv.SetEnvironmentVariable "FOO" "BAR" dnEnvTarget

To store an Environment Variable “FOO” containing “BAR” for all the users on the machine, this is what you want to write:

dnEnv = dotNetClass "System.Environment"
dnEnvTarget = (dotNetClass "System.EnvironmentVariableTarget").Machine

dnEnv.SetEnvironmentVariable "FOO" "BAR" dnEnvTarget

And if you omit the dnEnvTarget variable completely, which is the default behavior, or if you use Process Enumeration, the Environment Variable will only be available throughout the lifetime of the running process, which is rather convenient if you only want to setup some variables temporarily (such as license paths on render slaves only during the rendering etc…)

Hope this helps.

dotNet iterables in MAXScript, a pain in the ass

loocas | dotNET,maxscript,Python,technical | Sunday, May 5th, 2013

Autodesk facepalm

Yes, that is true. Stuff that should be inherently and implicitly iterable, is not, when accessed from MAXScript.

I had to find out the hard way, so here I am sharing my findings and solutions so that you don’t have to waste time on this nonsense issue.

The problem I bumped into some time ago was when I tried to access Management Object Searchers in my code (for finding various HW IDs and serial numbers). When you call a dotNET iterable (or a collection) in MAXScript, you automatically assume you can iterate over its contents, just like with an array, for example.


Somebody at Autodesk decided that this isn’t the behavior you’d like and instead made you having to jump through hoops and obstacles to get to the object contents.

Anyways, lets look at this problem on a rather simple example of using Hashtables in MAXScript:


Autodesk cannot write good software

loocas | 3ds Max,opinions | Sunday, March 31st, 2013

stupid autodesk

I just realized that after seeing what Autodesk has been doing to the (at the very least) DCC software packages for a long time now.

They just can’t write good software. Nothing breath taking, let alone revolutionary. Just look at it. All they sell is software they bought from really smart and bold developers in the past. Then they pretty much kept it the same way it had been, including all the bugs, quirks and issues, but slapping on fancier and fancier GUIs they also bought or licensed from someone else (Qt anyone?). They don’t have the balls, even though they pretty much have a monopoly on the DCC field. Pussies.

Seriously, when was the last time you were excited a new version of anything from Autodesk is coming out soon? I haven’t. Hell, I haven’t been even excited about their betas in a long while. Autodesk doesn’t listen to the users, they don’t care much about the old time power users either. They just don’t give a shit, in my opinion.

So, with all seriousness, I’m truly considering cancelling my subscription and just don’t give a shit back.

Repathing 3ds Max assets externally, command line utility

loocas | 3ds Max,software,technical | Sunday, March 3rd, 2013

Repath Max Assets cmd

Do you remember my post about repathing 3ds Max assets in the .max and .mat files without actually running 3ds Max? Well, I cooked up a little utility that can be run from the command line without any IronPython installed. You can use this simple exe file to repath or simply just list all your external asset paths inside your .max and .mat files, should you need to. And since it’s a command line utility you can run it from within your programs and catch the outputs or batch feed it data for processing etc…

Anyways, the syntax is pretty simple:

You need to call the program and then pass it a .max or .mat scene file. If you provide only that, it’ll list the file’s asset paths. But if you provide a -p parameter followed by a new path, it’ll re-path all the file’s external assets to the new location you provided. Unfortunately, there is no way for me (afaik) to distinguish what is an actual render output or RE output and what are texture or cache data inputs, so everything will be linked to the new directory at once.

Should you need any help, just call the program without any parameters, or with the parameter -h for help.

Download the program from here.

Next Page »

Powered by WordPress | Theme by Roy Tanck