Finding the camera used by a texture projection Part II


Part I

Another way to get the cameras for the camera projections on the selected object. This time with no loops (well, except for the list comprehension on line 22).

from siutils import si
if Application.Version().split('.')[0]>= "11":
	    si = si()                   # win32com.client.Dispatch('XSI.Application')
from siutils import log		# LogMessage
from siutils import disp	# win32com.client.Dispatch
from siutils import C		# win32com.client.constants

# Get all CameraTxt operators
ops = si.FindObjects2( C.siOperatorID ).Filter( "CameraTxt" )

# Filter function to get the CameraTxt ops under the selected object
def f(x):
	o = si.Selection(0)
	return o.IsEqualTo( x.Parent3DObject )

# Get list of cameras
cams = [ x.InputPorts(2).Target2.Parent3DObject for x in filter( f, ops ) ]

if len(cams) > 0:
	print 'Projection cameras for %s:' % si.Selection(0)
	for c in cams:
		print '   %s' % c.Name

This script is based on the observation that you can get the camera from an input port on the CameraTxt operator.

10 thoughts on “Finding the camera used by a texture projection Part II

    • dispFix is still needed sometimes…but as it turns out, not in this case…Thanks!

      I had stuck it in an earlier version of the script when something wasn’t working, and then just carried it forward.

      • I am afraid I am going to have to beg you for a new post on this dispatch issue. In what kind of cases is a dispFix still needed?

      • I don’t know really. But sometimes you find some method or property doesn’t work on an object, so you try dispFix(). Search this site, there’s two examples. One is the ViewportCapture object.

  1. Okay, I’ll try to live with the uncertainty… 😀
    But wouldn’t that mean the classic fix (the “__init__.py file hack”) still is the best option as it should eliminate the problem once for all? Or is this not true either?

    • I’ve never tried the classic __init__.py hack.
      I suppose if I kept running into more and more problem areas, then I might try it.
      But so far I’ve hit only three cases, and iirc two of them were kind of ‘corner cases’ like the ViewportCapture object, which is hard to get at if you don’t use Dictionary.GetObject.

      • But if the problem still exists and Softimage does have its own “internal” Python now and even if only a few occasions are still problematic, wouldn’t it still be an idea to incorporate the __init__.py hack in future basic internal Python installations?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s