I’m talking about spontaneously disconnecting shaders.

Background info (read these):

• The issue as described in a thread on the mailing list.
• A workaround as described by eX-SI Support

The following script partly automates the solution described by eX-SI Support so if you have many libs it almost eliminates human error. It seems to have worked for us so far as a preemptive measure before scenes break or after having spent too much time fixing a scene. Import an asset, material preset or fix a broken scene, go through the hoops. This is not fun but until there is an official fix, we’re kinda stuck.

Run Application.MatLibFixStep1() which will convert material libraries to external references, prompt you to save the scene and quit Softimage.

Restart Softimage, open the scene you saved previously and run Application.MatLibFixStep2() which will reconvert the material libraries to internal storage.

Jean-Sebastien’s workaround is also worth investigating if the above doesn’t work for you (see the Softimage mailing list thread linked above).

One of the clients showed me a pretty cool use of the geometry stack in conjunction with Momentum’s DeformRigidBody operator. This operator is able to treat every polygon-island inside a polygonmesh as a separate rigid body, and, since it is connected to the geometry stack, is able to keep the shape of the rigid bodies in sync with the deformation happening below. This way you can create animated shapes, and have them influence the rigid body simulation in Bullet.

While I implemented this feature, I was not aware of all of the possible uses, of course. Since the interactive creative environment has been introduced into Softimage, the possibilities are endless, and it is very hard to imagine what users will come up with once additions to ICE are released into the community.

The client, who had to deal with a very complex effect for a commercial, used Momentum just for the rigid body simulation, while the deformation was done through ICE. What’s interesting here is that he is simulating the deformation using a turbulence method, and driving the rigid body engine with this deform.

By offering small building blocks that work well together with ICE, or even integrate into ICE as compounds, Momentum 2.0 opens a whole new world of possibilities for simulation. Goal-based simulation and user driven results are in reach. What thrills me the most though, is to see unexpected setups like this one. The community’s amount of creativity really produces so much inspiration for developers like myself.

I will continue to talk about techniques and tricks with Momentum on this blog, and try to contribute users’ experiences and solutions.

Here’s a capture of the effect:

Click here to view the embedded video.

Here’s a link to Momentum 2.0 product page:

http://www.exocortex.com/simulation/momentum

We have posted a series of other videos, including tutorials, trailers etc on vimeo, you can find them in our Momentum group:

http://vimeo.com/groups/exocortexmomentum

This is a good place to stay up to date on new releases and latest information.

Please let me know what you think, I like to be intrigued for other topics and solutions for complex effects.

There is a strange user interface lag that affects Softimage XSI when you use a Wacom tablet. With heavy scenes or simulation, you may never be able to stop playback. Other users have reported problems with the render region.

The best work-around is to disable tablet support in Softimage (any version).   This will not affect any other program.

To do this, start a  “Command Prompt” using the link in the Autodesk Softimage Start menu group.  If you are running under Vista or Windows 7, it’s best to run it as an administrator.

A command prompt will will start in the ‘bin’ directory of the application.  Type this command:

C:\Program Files\Autodesk\Softimage 2011\Application\bin> copy xsi.bat wintab32.dll

And re-launch the Softimage.  You should now be fine.

The only place Softimage uses the tablet is for pen pressure in Weight Painting and in the compositor, and it doesn’t work very well anyway. To restore tablet support, simply delete wintab32.dll from the bin directory from that command prompt.

Softimage 2011 SP1 and Later

Table pressure support is now disabled by default in new versions of Softimage, eliminating this problem.  If you want to renable it, you need to set the environment variable

XSI_ENABLE_WINTAB_SUPPORT=1

There are few  benefits to doing this; the pen pressure is only used in Weight Painting (where it is a bit  hard to control) and painting in the paint node compositor. You pen tablet will probably work better if you don’t mess around with this.

Linux

There is no support in Softimage for pen tablet on Linux and therefore no known problems with it.

time to release another plugin under the flag of Sixbirds Barcelona!

As already shown in a teaser video on vimeo.com, we worked on a plugin to use particles as pixels to unleash the power of ICE to textures.

This plugin requires Autodesk Softimage 2010 SP1, Windows 32, 64 or Linux 64 bit.

Provided in the plugin is a C++ operator, a custom ICE-Node, some compounds to drive the pixels as well as a sample project.

So what does it do? Let’s have a look:

Thanks to Steven Caron for food for thoughts, thanks to all of the beta-testers!

Once again I am proud and happy that the company I work for is enabling me to publish these tools under GPL, so source-code is included!

Please comment, let me know what you think.

Here’s the download link:

http://www.sixbirds.com/development/sixbirds_pixelparticles.2010_SP1_1.0.xsiaddon.zip

Later!

Helge @ Sixbirds Barcelona

PS: I noticed during the beta-phase of the plugin that is it fairly easy to create a basic feather system with this setup, I demonstrate this in the vimeo video also. How ironic! :)

Edit: I upgraded the addon to version 1.3, see the 13th solver for new description of the Nulls 2 Nurbssurface. Additionally I fixed two bugs and removed some nasty logmessages from the Null 2 Curve solver. Some solvers are NOT compatible with the version 1.3, so I will keep the link to the previous versions around.

So finally after a good first round here at Sixbirds in Spain we decided to release some of the tools we are using for production to the community. At this point we are sharing our rigging solvers, a collection of custom operators for “solving” certain equations, like IK, Bezier projection, curve lookup etc. The collection includes 12 different solvers. Please have a look at this video, which gives you a quick runover of the technology…

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Requirements: Softimage 2010 SP1, Windows 32, 64 or Linux 64 with installed Python 2.52 or higher. For installing python see
http://softimage.wiki.softimage.com/index.php/Python#Installation

The addon also includes a very handy custom command, called “sixbirds_rigging_inspect_op”, which allows you to look at the settings of the solvers without having to dig for them in the explorer. I usually map this command to F4, since I don’t use the F4 UI Slider feature all that much. Furthermore the addon provides a simple toolbar to apply all of these solvers, and adds a new simple “bone” primitive to the Get->Primitive menu, which is handy when creating custom IK chains. Also the addon will come with a sample project, one scene for each solver demonstrating the features.
The addon is provided under the GPL license, without warranty, and, as we like to say in R&D: As is. Please don’t ask for fixes or further features at this point, we don’t have the resources.

All of the solvers are applied by selecting objects in a particular order and creating the solver. I want to quickly summarize these selection orders so you can properly use the addon.

One note: All solvers use X as their main axis. This decision was made since the Softimage Bone primitive uses X as the axis along the bone. So all other solvers use this axis as well. This means, for example, that you will have to rotate controllers or the spline solvers or the squash and stretch for example, if you want the spline to point along Y.

1. SRT Spring
This is a solver which is able to simulate a simple transform based spring. You can select the channels you want to use for simulation (scaling, rotation and/or translation). To apply this solver just select any 3d object and it will create a null as a child of this object with the solver applied.

2. Direction Spring
The direction spring solver simulates a spring which is driven by a global direction, not an orientation. Just select any 3d object and it will create a bone as a child, with the solver applied. To see the difference between the SRT Spring and the Direction Spring just play with it or have a look at the sample scenes.

3. IK 2 Bone
This solver can calculate one of the different outputs of a typical IK chain, but also provides soft stretching and some more features like inverting the solve etc. To use this solver, please select a) the root, b) the effector, c) the upvector and d) the output object. This solver does not create 3d object by itself, so if you want to apply to a bone you will have to create a single bone first (Get->Primitive->Bone). The solver also creates a property on the root object to drive all output objects (if you create more than one) in a central place.

4. IK FK 2 Bone
This solver has the most complicated selection order of all solvers provided in the addon. To apply it you nee to select a) The root, b) the IK effector, c) the IK upvector, d) the FK first bone, e) the FK second bone, f) the FK effector (wrist for ex) and g) the output object. This solver, like the IK 2 Bone, does not create output objects itself. This solver also creates a centralized property on the root object.

5. Simple Spline
This solver calculates a transform on a piece-wise-bezier defined by as many 3d objects as you want. The tangent of the bezier are the local X axis of the 3d objects driving the solver. To apply it simply select at least 2 objects (or more) an apply the solver. This solver creates a null as a child object of the first controller. The Simple Spline also creates a property on the first controller, to drive all created output objects in a central place.

6. Rolling Spline
This solver calculates the same bezier transform, but requires a secondary layer of controls to allow for continuous rolling along the spline. For using this solver you need to have a two level hierarchy (like parent_ctrl -> child_ctrl) or at least two controllers. Please select the child controllers ( at least 2 ) and apply the solver. It will create a null as a child of the first selected controller. Please have a look at the sample scene to get a better idea. The rolling spline, as the simple spline, creates a centralized property on the first controller.

7. 4 Point Surface
This solver computes a transform on a iso surface build by 2D bezier curves. These curves are defined by 4 controllers (the corners of the iso surface). To use this solver select 4 objects, it will create a null object as a child of the first corner object.

8. Interpolated Pose
The interpolated pose solver calculates a pose in between two other poses. To use it simply select two 3d objects and apply the solver, it will create a null as a child of the first selected object.

9. Squash and Stretch
This solver can calculate a scaled output transform based on the distance of two objects. The scaling for this effect is done along Y and Z. To apply the solver, select the first object of the distance calculation (hip, for example), the second one (chest) and the parent object for the new null. This can be for example a vertebra on the spine.

10. Null 2 Curve
This solver projects  an object onto a curve. This is useful for facial rigging and for anything that has to travel on a path, while being driver by a visual controller. To use this solver select a) the driver ctrl, b) the upvector ctrl, c) the input curve) and (optionally) d) the output curve. The solver will create a null as a child of the output curve (or the input curve if you just had one curve selected).

11. Curve Sliding
This solver reprojects a curve along itself while maintaining the length. This is useful for keeping the length on a curve, even it is deformed. To use this solver, just select one curve and apply it. If you want to use the sliding on top of enveloping, for example, ensure you have the animation construction mode selected before applying it.

12. Curve Collision
This solver does a simple collision with soft distance of a curve to a nurbs surface. This is useful for having curve being pushed by a teeth proxy in a facial rig, for example. You can use this solver in conjunction with the curve sliding solver. To use it, select a) a curve and b) a nurbs surface. Ensure that the surface is closed, please test with a nurbs sphere first. The collision object is supposed to be really, really simply to give you good feedback.

13. Null 2 Surface
This solver projects  an object onto a nurbssurface. This is useful for facial rigging and for anything that has to travel on a surface, while being driver by a visual controller. To use this solver select a) the driver ctrl, b) the upvector ctrl, c) the input surface) and (optionally) d) the output surface. The solver will create a null as a child of the output surface (or the input surface if you just had one curve selected). The solver uses a relative mapping, similar to a pen table (tablet space to screen space). Feel free to post questions if you need additional assistance.

Ok, after all of this information let’s have a look at a second video, in which I will go over each solver, reapplying it and test-driving it.

I hope you all enjoy the videos and find something useful in them. We are trying to design more tools in a way that they are easy to share, and we at Sixbirds want to follow that move of being able to publish more production tools.

Please let us know what you think at

development (at) sixbirds.com

Or feel free to post comments here at XSI-BLOG.

Last but not least: Thanks to all of the other providers of free software / plugins and the helpful Softimage Community!

There you go!

http://www.sixbirds.com/development/sixbirds_rigging_solvers.2010.SP1_1.3.xsiaddon.zip

(older versions:)

http://www.sixbirds.com/development/sixbirds_rigging_solvers.2010.SP1_1.1.xsiaddon.zip

Best!

Miquel & Helge @ Sixbirds

Note: For those of you who would like a bit of background information on decorators you can check out this page.

Keeping things quiet

Let’s look at the code and we’ll go for a few explanations afterward.

1
2
3
4
5
6
7
8
9
10
11

def suspendXSILogging(func):
    def closure(*args, **kwargs):
        logPrefs = getXSILoggingPrefs()
        try:
            ret = func(*args, **kwargs)
        except Exception, e:
            setXSILoggingPrefs(logPrefs)
            raise
        setXSILoggingPrefs(logPrefs)
        return ret
    return closure

The first function suspendXSILogging can be used as a decorator and will disable all logging features of XSI. This has the advantage of making large scripts that may be command dependent a bit quicker.

You could always implement a plugin with a custom command but sometimes a script is simpler. Even in the command context this decorator could be useful if you wanted part of the command to log to the script editor while keeping other parts silent.

Another advantage of this decorator is that it puts your original function in a large trap that, if an error should occur, will make sure that logging is reset to the users original preferences.

Time for decorating

1
2
3
4
5
6
7
8
9
10
11
12
13

def timeExecution(func):
    def closure(*args, **kwargs):
        startTime = time.time()
        try:
            ret = func(*args, **kwargs)
        except Exception, e:
            delta = time.time() - startTime
            log.error('Failed in %f seconds' % delta)
            raise
        delta = time.time() - startTime
        log.info('Finished in %f seconds' % delta)
        return ret
    return closure

This second function, timeExecution, can decorate almost any function and will print to the script editor the amount of time the decorated function took to execute. This can be used as a debugging or performance tracking tool or as a way to provide feedback to your users. Again, a trap is implemented that will log execution time even if an error occurs.

Please not that this decorator uses a logging system described here. If you would rather use simple logging you should replace log.info( instances by log(, xsi.LogMessage( or Application.LogMessage( depending on your scripting habits.

Usage example

1
2
3
4
5

@timeExecution
@suspendXSILogging
def main():
    # Do some fun useful stuff - well... more useful than this!
    xsi.CreatePrim("Cube", "MeshSurface", "", "")

You can chain decorators without hesitation like in this example, one thing to note in this particular case is that you’ll want timeExecution higher in the decorator chain than suspendXSILogging otherwise the time information will never make it to the script editor. Duh!

Support code

Before I sign off on this latest article, here are two functions that, if useful on their own, are essential to the functioning of the suspendXSILogging decorator.

1
2
3
4
5
6
7
8
9
10
11

def getXSILoggingPrefs():
    prefs = xsi.Preferences
    vals = {}
    for n in ['scripting.cmdlog', 'scripting.msglog', 'scripting.msglogverbose']:
        vals[n] = prefs.GetPreferenceValue(n)
        prefs.SetPreferenceValue(n, False)
    return vals
 
def setXSILoggingPrefs(vals):
    for key, val in vals.iteritems():
        xsi.Preferences.SetPreferenceValue(key, val)

Cheers!

You’ve probably seen the following idiom used many times on this website and in other places that do XSI scripting in Python:

1
2
3

from win32com.client import constants as c
xsi = Application
log = xsi.LogMessage

It is a shortcut that allows you to use log as if it was the native LogMessage call:

1

log('This is an info message.', c.siInfo)

Here is a way to extend this by using the standard logging module in a way that can help you be more proactive. I suggest you get familiar with the logging module from the standard Python docs, it’s bound to eventually be helpful.

Logging in XSI

Here is a construct I’ve started using lately that I am starting to enjoy, its advantages are:

• Concise and self documenting
• It has a trap to catch any unexpected error and log it
• Logs both to the script editor and to file
• Easily extensible to other logging mechanisms (email, event viewer)
• You can pass non string messages and it will convert to string for you (Yay!)
• Easily useable in scripts and other modules

1
2
3
4
5
6
7
8
9
10
11
12
13

from hookolo.xsi import *
 
def main():
	log.comment('comment')
	log.debug('debug')
	log.info('info')
	log.warning('warning')
	log.error('error')
	log.fatal('fatal')
	log.critical('critical')
	raise Exception('Totally unexpected exception!')
 
run('demoScript', main)

The code above would produce the following output in XSI’s script editor.

# comment
# VERBOSE : debug
# INFO : info
# WARNING : warning
# ERROR : error
# ERROR : fatal
# FATAL : critical
# ERROR : Trap reached in demoScript
# Traceback (most recent call last):
#   File "C:\hookolo\libs\hookolo\xsi\__init__.py", line 18, in run
#     func(*args, **kwargs)
#   File "<script Block >", line 11, in main
# Exception: Totally unexpected exception!
# ERROR : Traceback (most recent call last):
#   File "<script Block >", line 13, in <module>
#     run('demoScript', main)
#   File "C:\hookolo\libs\hookolo\xsi\__init__.py", line 21, in run
#     raise StopScriptError('Check the logs!')
# StopScriptError: Check the logs!
#  - [line 13]

The calls to log.comment, log.debug, log.info, log.warning, log.error and log.critical are all self explanatory as they are all equivalent to LogMessage calls with the appropriate severity argument. The call log.fatal is an addition of my own who’s severity is equivalent or just a tiny bit lower than critical. Fatal errors will not pop a dialog box.

In the setup I have here, both fatal and critical, will be logged to a file in the users’ XSI_HOME directory that looks like follows.

2008-10-04 23:46:13,720 - hookolo.xsi - FATAL - fatal
2008-10-04 23:46:13,720 - hookolo.xsi - CRITICAL - critical
2008-10-04 23:46:13,720 - hookolo.xsi - FATAL - Trap reached in demoScript
Traceback (most recent call last):
  File "C:\hookolo\libs\hookolo\xsi\__init__.py", line 18, in run
    func(*args, **kwargs)
  File "<script Block >", line 11, in main
Exception: Totally unexpected exception!

By having a file like this, I don’t have to wade through XSI’s scripting log as I have a file that only includes important script errors. I also don’t have to worry about a user coming to me and saying: “Your script exploded.” Followed by the inevitable: “No, I don’t remember the error and I don’t have it in my scripting window anymore.” Now I can just open up this file from their XSI_HOME directory and look for myself.

The usage of a main() function and a run() function allows to build a trap for any unexpected errors that might occur and allow for logging. By putting the runner in a library we can benefit from it with very little hassle in even the tiniest of scripts.

Pushing the envelope

A system such as this one could even easily be extended to allow for sending of fatal and critical errors via email. You would know that a script failed even before the artist had walked the corridor to your office to tell you about the failure. This extension wouldn’t even be that hard as the logging module includes an SMTPHandler for just this purpose.

Support code

Here is the library that makes this all possible.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

import logging
import os
import sys
import types
 
from win32com.client import constants as c
from win32com.client import Dispatch
 
__all__ = ['xsi', 'log', 'c', 'run', 'XSIError']
 
COMPANY_NAME = 'Hookolo'
COMPANY_PREFIX = 'hookolo'
 
xsi = Dispatch('XSI.Application').Application
 
def run(scriptName, func, *args, **kwargs):
	try:
		func(*args, **kwargs)
	except:
		log.log(45, 'Trap reached in %s' % scriptName, exc_info=1)
		raise StopScriptError('Check the logs!')
 
class XSILogger(logging.Logger):
	def fatal(self, msg, *args, **kwargs):
		self.log(45, msg, *args, **kwargs)
 
	def comment(self, msg, *args, **kwargs):
		self.log(5, msg, *args, **kwargs)
 
class XSIHandler(logging.Handler):
	def emit(self, record):
		if record.levelno == logging.CRITICAL:
			xsiLvl = c.siFatal
		elif record.levelno in [logging.ERROR, 45]:
			xsiLvl = c.siError
		elif record.levelno == logging.WARNING:
			xsiLvl = c.siWarning
		elif record.levelno == logging.INFO:
			xsiLvl = c.siInfo
		elif record.levelno == logging.DEBUG:
			xsiLvl = c.siVerbose
		else:
			xsiLvl = c.siComment
 
		if isinstance(record.msg, types.StringTypes):
			msg = self.format(record)
		else:
			record.msg = str(record.msg)
			msg = self.format(record)
 
		xsi.LogMessage(msg, xsiLvl)
 
def getLogger(name=None):
	if name is None:
		return logging.getLogger(COMPANY_PREFIX + '.xsi')
	else:
		return logging.getLogger(COMPANY_PREFIX + '.xsi.' + name)
 
if not hasattr(sys, 'XSI_LOGGING_CONFIGURED'):
	logging.setLoggerClass(XSILogger)
	logging.addLevelName(45, 'FATAL')
	logging.addLevelName(5, 'COMMENT')
	log = logging.getLogger()
	xsiHandler = XSIHandler()
	xsiHandler.setLevel(0)
	fileHandler = logging.FileHandler(os.path.join(os.environ['XSI_USERHOME'], 'xsiScriptLog.txt'))
	fileHandler.setFormatter(logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s"))
	fileHandler.setLevel(45)
	log.addHandler(xsiHandler)
	log.addHandler(fileHandler)
	log.setLevel(0)
	sys.XSI_LOGGING_CONFIGURED = True
 
log = getLogger()
 
class XSIError(Exception):
	pass
 
class StopScriptError(XSIError):
	pass

Note: To see your full effect, make sure when you stack multiple waves onto each other, that the mute and solo checkboxes be clear and that the “last wave” checkbox be only active on the Gerstner Wave compound plugged lowest into the terminal node or your ICE tree.

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

If you wish to purchase this set of wave tools, you can go here.

Have fun!

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

At their current price of 40$ they’re a steal, as far as I’m concerned.

If you want to get your mitts on your own copy, check out the purchase page where you can securely buy via credit card or PayPal.

For those of you who don’t care about waves but would still like to show your appreciation for XSIBlog you can still donate.

Cheers,
Patrick