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

It was so simple I can probably qualify it as being the biggest non event of my past few months… This same subject has been talked about a few times in the past but because historically it has been so complicated (read impossible), I thought I’d rehash it here. Here are some no nonsense steps to make it happen:

• On Vista64 or XP64 install XSI 7.0 32 and XSI 7.0 64
• Install VC++ redistributables (2005/32, 2005/64, 2008/32, 2008/64)
• Install Python 2.6 32 bits
• Install Python 2.6 x64
• Install PyWin32 32 bits
• Install PyWin32 x64

Notes:

• Install your two different Pythons in two different directories (I used C:\Python26-x86 and C:\Python26-x64)
• Python 2.6 is at RC2 as of this writing but is very solid. Release shoudn’t be too far off (scheduled for Oct 1st).
• For Vista users, turn UAC off for these installs.

Now whenever you launch one version or another of XSI you should set the system path to include the path to the appropriate version of Python. One nice way to do this is to use the UserTools to edit setenv.bat and add a line like the following at the top of the file:

set PATH=C:\Python26-x64;%PATH%

This is also a nice place to set your PYTHONPATH environment variable for any custom libraries as well. Most libs you develop yourself are likely to be 100% pure Python. As such they are usable by both the 32 and 64 bit interpreters and can be kept in a single central location and included by both versions. Some libraries that you download might require specific binary builds and you’ll need to install those twice, one for each Python version.

Why am I talking specifically about Python 2.6 even if it is only at RC2? I’m a strong advocate of moving to this new version as soon as you can, given any libraries you need for your tools are also available for the new version. This version adds or implements a lot of stuff that will be in Python 3.0 without breaking 2.x compatibility (too much). As such it becomes a great way to smooth your transition to the future version of the language. If you want to get up to speed with what is coming up in Python 2.6, you can check it out here.

Have fun!

The video below will give you a rundown on how to activate the feature within the context of a really simple example of getting a ball to float and bounce around on the top of a particle fountain.

Please note that ICE Kinematics are an unsupported feature that you would be using at your own risk. I’ve had a fair bit of success with it but if it goes boom and you loose time and assets, I will say: I told you so!

Have fun!

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

By the way… The line you have to add in the setenv.bat file that you can’t read in the video is:

set XSI_UNSUPPORTED_ICE_KINEMATICS=1

For about the past five years I’ve been doing pipeline stuff. ICE has gotten me yearning for production work again.