Friday Flashback #142

Posted on by
Reply

Thanks to Emilio for suggesting this topic for a flashback.

MODMEN

Start_menu

Before Softimage started shipping with Phoenix Tools ParticleSuite in 1999, SOFTIMAGE 3D had its own standalone particle system. If you wanted your particles in a SOFTIMAGE 3D scene, you had to follow this procedure:

  • Render the SOFTIMAGE 3D scene within SOFTIMAGE 3D, using the SOFTIMAGE renderer with the Render Z Channel option selected in the Render Setup dialogue box.
  • Load the SOFTIMAGE 3D rendered images into the Particle renderer as background images.
  • Render the particle animation. Then composite the particle animation using the depth information from the z-channel of the SOFTIMAGE 3D rendered images to create seamless three-dimensional
    animation with a particle effect.

Here’s an overview of the SOFTIMAGE|PARTICLE interface (from the Particle User Guide) and a few screenshots of the viewport.
Particle_interface

3DAREADX

GRAVITY2

LCLELEC2

Dispatching XSI.Factory versus using the intrinsic XSIFactory object

Posted on by
Reply

The other day in the comments, A asked about some Python I had posted a few years ago: Why did I manually dispatch XSI.Factory instead of just using the global XSIFactory object? Honestly, I don’t know why I did. I had seen other code do it that way, so I did it too. And I see that the sipyutils.py also dispatches objects like XSI.Application, XSI.Utils, and XSI.Math, so I figured I was in good company.

A little research shows that XSIFactory uses late bound automation (aka dynamic dispatch) and so avoids any possible problems with the pywin32 cache. Late-bound automation means that PythonCOM doesn’t know what properties or methods the object supports; whenever you try to access a property or method, PythonCOM will query the object to find out if the property/method is supported.

In contrast, when you dispatch XSI.Factory, PythonCOM uses the pywin32 cache to support early-binding, where all the available properties and methods are known beforehand.

You can read more about this Chapter 12 of Python Programming on Win32, Advanced Python and COM

Here’s a little Python snippet demonstrating the differences between a dispatched XSI.Factory and the global XSIFactory object. Note in particular the output of dir() for each object.

from win32com.client import Dispatch as disp
sifact = disp('XSI.Factory')

print sifact
print XSIFactory
# <win32com.gen_py.Softimage|XSI Object Model Library v1.5.XSIFactory instance at 0x564246344>
# <COMObject XSIFactory>

print dir(sifact)
print dir(XSIFactory)
# ['CLSID', 'CreateActiveXObject', 'CreateFCurveKeyCollection', 'CreateFCurveParamDef', 'CreateGridData', 'CreateGridParamDef', 'CreateGuid', 'CreateObject', 'CreateObjectFromFile', 'CreateObjectFromFile2', 'CreateObjectFromPreset', 'CreateObjectFromPreset2', 'CreateParamDef', 'CreateParamDef2', 'CreateScriptedOp', 'CreateScriptedOpFromFile', 'CreateShaderDef', 'CreateShaderParamDefOptions', 'RemoveShaderDef', '_ApplyTypes_', '__doc__', '__eq__', '__getattr__', '__init__', '__module__', '__ne__', '__repr__', '__setattr__', '_get_good_object_', '_get_good_single_object_', '_oleobj_', '_prop_map_get_', '_prop_map_put_', 'coclass_clsid']
# ['_Close_', '__doc__', '__getattr__', '__init__', '__module__', '__repr__', '__setattr__', '_scriptItem_']

print sifact.__module__
print XSIFactory.__module__
# win32com.gen_py.269C4D8C-E32D-11D3-811D-00A0C9AC19A9x0x1x0.XSIFactory
# win32com.axscript.client.pyscript

Why you cannot use shortcuts to access the ViewportCapture settings

Posted on by
Reply

In the comments, G asks:

Why do you have do this:

si = Application
oViewportCapture = si.Dictionary.GetObject( "ViewportCapture" )
oViewportCapture.NestedObjects( "Start" ) = 10

and not this:

si = Application
oViewportCapture = si.Dictionary.GetObject( "ViewportCapture" )
oViewportCapture.Start = 10

CaptureOptions
The answer is that the ViewportCapture object is not a ProjectItem, and so does not support the Parameters property. ViewportCapture is a CollectionItemLegacy object (and before that, it was an SIObject). 

si = Application
p = si.Dictionary.GetObject( "ViewportCapture.Start" )
p.Value = 10
#si.SetValue( "ViewportCapture.Start", 10 )

Using environment variables in .wkg files

Posted on by
Reply

I couldn’t find this in the docs anywhere, but I did find it mentioned in some old emails. You can use environment variables in the .wkg file, like this:

$SITOA_WKG_PATH
$MOOTZOID_WKG_PATH

or this:

${SITOA_WKG_PATH}
${MOOTZOID_WKG_PATH}

Either syntax worked for me when I tried it.

There does seem to be some weirdness with loading workgroup shaders this way, but that’s still under investigation.

Scripting – Creating an empty polygon mesh

Posted on by
Reply

There’s several ways to create an empty polygon mesh with the Object Model.

from sipyutils import si			# win32com.client.Dispatch('XSI.Application')
from sipyutils import log		# LogMessage
from sipyutils import C			# win32com.client.constants

si = si()
o = si.Selection(0)

if o.IsClassOf( C.siX3DObjectID ):
	o.AddPolygonMesh()
	o.AddPrimitive( "EmptyPolygonMesh"  )
	o.AddGeometry( "EmptyPolygonMesh" )

AddPolygonMesh() courtesy of Vladimir