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

Charge The Dragon

loocas | miscellaneous,showcase | Wednesday, February 19th, 2014

Have you seen this beauty? :) It’s worth the watch.

Get the Flash Player to see this content.

I had the privilege of contributing with my rigging and some other technical thingies, including some rendering here and there. :) Enjoy!

Wacom vs. Microsoft, again…

loocas | miscellaneous,technical | Saturday, January 4th, 2014

Here it goes again.

After reinstalling Windows (7 x64, SP1) I installed all my drivers and peripherals, etc… and the tablet is making trouble again.

I konw I had to uninstall the standard Windows Tablet and Touch input piece of shit, disable flicks, or better yet, disable the Tablet input service for good. Luckily Wacom fixed their driver and the right-click button doesn’t hang in programs such as Total Commander etc… so kudos for that. However, I wasn’t able to get rid of one last little annoying feature: the touch/click rings that splash under your cursor every time you hit the tablet plate.


Until a post deep on some internet forums by a guy calling himself juzerneem suggested a very elegant solution (better than most, suggesting editing registries etc.)

Just go to the Local Group Policy Editor (gpedit.msc) and:

  • Navigate to User Configuration – Administrative Templates – Windows Components – Tablet PC – Cursors
  • Set Turn Off Pen Feedback to Enabled

Done! :)

Hope this helps anyone trying to get rid of that overly-annoying feature that I can’t even grasp why it was implemented.

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:


« Previous Page | Next Page »

Powered by WordPress | Theme by Roy Tanck