ActiveX component can’t create object: ‘Scripting.FileSystemObject’


Looking back, I find this error popping up in my case notes once or twice every year.
Sometimes we’re able to help fix the problem, sometimes not, because it’s a problem with their system, not with Softimage itself.

Typically, a user will report seeing errors like this at start up:

// ERROR : Automation server can't create object - [line 22 in c:\Program Files\Autodesk\Softimage 2012 SP1\Addons\ICEFlowBuilder\Application\Plugins\ICEFlowCreateParticlesPlugin.js]
// ERROR : Automation server can't create object - [line 70 in c:\Program Files\Autodesk\Softimage 2012 SP1\Addons\sdkui\Application\Plugins\AddonDoc.js]
// ERROR : Automation server can't create object - [line 141 in c:\Program Files\Autodesk\Softimage 2012 SP1\Application\Commands\GlobalVarPlugin.js]
// ERROR : 2006-SetGlobal - Unexpected failure.
// ERROR : Automation server can't create object - [line 141 in c:\Program Files\Autodesk\Softimage 2012 SP1\Application\Commands\GlobalVarPlugin.js]
// ERROR : 2006-GetGlobal - Unexpected failure.
// ERROR : Automation server can't create object - [line 141 in c:\Program Files\Autodesk\Softimage 2012 SP1\Application\Commands\GlobalVarPlugin.js]
// ERROR : 2006-GetGlobal - Unexpected failure.
// ERROR : Automation server can't create object - [line 141 in c:\Program Files\Autodesk\Softimage 2012 SP1\Application\Commands\GlobalVarPlugin.js]
// ERROR : 2006-GetGlobal - Unexpected failure.

Sometimes users miss the startup errors and report seeing the error when they try to do something in Softimage, such as import dotXSI.

// ERROR : ActiveX component can't create object: 'Scripting.FileSystemObject' - [line 352 in c:\Program Files\Autodesk\Softimage 2012 SP1\Application\DSScripts\Model.vbs]
ImportDotXSI(null, null);

Note that the errors all give a line number in a specific file. If you check any of these, you’ll see that all the errors happen when Softimage tries to create an ActiveX object like
Scripting.Dictionary or Scripting.FileSystemObject. These are standard objects in the Microsoft Windows Script runtime, so these errors indicate that something’s wrong with Windows.

If you’re lucky, you can fix this by re-registering C:\windows\system32\scrrun.dll with regsvr32.

If that doesn’t work, then my guess would be that it’s some kind of registry or permissions problem. In the past (on XP systems), I’ve seen cases where it was specific to a user profile, and where it was because the Scripting.FileSystemObject registry key didn’t have an owner assigned.

If you don’t believe it’s a general Windows problem, try this. It should give the same error.

  • Open a command prompt.
  • Run this command: notepad test.vbs
  • In notepad, paste in this VBScript and save the file:
    set fso = CreateObject("Scripting.FileSystemObject")
    set fout = fso.CreateTextFile("c:\Test.txt", true)
    fout.WriteLine Now
    fout.Close
    WScript.Echo "Testing"
    
  • In the command prompt, run this command: cscript test.vbs

Tip: Using ICE to drive the OpenGL vertex color display


Courtesy of Vladimir Jankijevic, here’s ” a really handy way of showing
arbitrary colors on a polygon mesh in the viewport, without having to create
a vertex property.”

  • Create an ICE tree that sets self.Color in a per-point context.
  • In the Material node property editor, set Vertex Color Display Property
    to Color.

Screenshot by Vladimir Jankijevic:

Another screenshot of the same thing:

Context matters: from PolygonToVertices to VertexToPolygons


This came up last week on the XSI mailing list. The goal, as I understand it, was this: for each polygon, build an array that contains the indices of all polygon neighbors.

So, to start, you can get an array of vertex locations for each polygon:

But when try to use those locations to get VertexToPolygons, that’s when you hit a problem:

Usually if it’s a context mismatch, you won’t be able to plug in the connection. In this situation, you can plug the result of Point Index to Location into the Get VertexToPolygons, but as soon as you do, both nodes go red. The tooltip indicates that ICE cannot figure out the structure of the data, that is, is this a single value or an array of values? The error goes back up to the Index port on Point Index to Location (if you right-click Point Index to Location and click Show Messages, you’ll get “ERROR: The type of port ‘Index’ is not defined.”).

If you unplug Get PolygonToVertex, then things are ok:

So, it is possible to use a Repeat node to build the per-polygon array of neighbor polygons.

Crash recovery in Softimage


Successfully saved scene before system failure
When Softimage crashes, it tries to save a crash recovery file. When you start up Softimage again, it asks you if you want to recover (“Improper exit detected. Do you want to recover?”)

If the crash recovery file isn’t usable, Softimage will try to load an AutoSave file, if there are any available (see this softimage-blog article on AutoSave).

Crash recovery files (and auto save files) are located in the [hidden] system\USER folder of the active project. For example:

C:\Users\blairs\Documents\Support_Project\system\blairs

where

  • Support_Project is the PROJECT name.
  • C:\Users\blairs\Documents\Support_Project is the project location.
  • blairs is the USER name.

Crash recover creates:

  • A system\blairs\CrashSave file
  • A system\blairs\CrashBackup folder with AutoSave files (AutoSave files are scene files without the .scn)

NOTE There’s a Scene Debugging preference for turning Crash Recovery on or off.

Friday Flashback #39


Code names for Softimage release through the years.
Thanks to Luc-Eric for the suggestion and the information.

“When all you have is a hammer, everything looks like a nail.”

Hubble (reference models), Big Bang (handling large number of objects), Spliff (new shader IDE authoring environment) were projects that were developed independently of any release and then merged into a release when they were ready.

Moondust was the node-based particles project that grew into ICE.

Stardust and Apollo were projects that never came to fruition or were folded into other work.

Text version of the codename listing:
Continue reading

Scene defaults for primitives and operators


Here’s a bit of trivia for ya…

The first time you create a primitive, or create an operator, Softimage creates a property under the Scene_Defaults. This property serves as a “cache” for the default values in the PPG for a primitive or operator. Each time you create a new primitive (or operator), it will take the default PPG values from the Scene_Defaults. So for example, after you create one primitive cube, you could go to the Scene_Defaults and change the default cube size to 1.

These scene defaults are not saved with the scene, which limits their usefulness.
There may have been grander ambitions for the Scene_Defaults back in the very early days, but they were abandoned and it remains an incomplete, undocumented feature.

Context Matters: weight maps and polygons


I saw a few questions about context recently, so I thought I’d try to work my way through those questions, starting with some basic scenarios. First up, then, is a question about using weight maps to control subdivision.

In this case, we’re dealing with per-point and per-polygon contexts.

A problem with using weight maps to control subdivision is that weight maps are per-point:

So you’ll end up with a context mismatch if you try to do something like this:

The context mismatch makes sense, since every polygon has more than one point, so what can a per-point weight map value mean for a polygon? One way around this would be to do something like this, and use the average of the per-point weight map values, but in a per-polygon context:

Here’s the full ICE tree:

Another approach would be to somehow use a per-polygon location, because with a location you can get the interpolated value of the weight map values: