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! :)

The rendertrees have all kinds of materials, with bump, transparency and reflection in place.

The most obvious approach to solve the problem is brute force: writing a script that would traverse all the materials, and substitute each material with a constant one, using as color the diffuse color of the original material, and inheriting all the subtrees for the transparency and reflection mixing. This would have required a couple of days of scripting, and, as any brute force approach, is not really elegant.

Another idea we tried was tuning the normal. We replaced all the lights with a single directional white light, pointing downward. Then, we connected a constant vector to the bump port of each material, pointing upward (0,1,0). The light has no specular contribution and the ambience is set to black. This way, only the diffuse component of the materials is returned, and since the normal always points upward, the incidence with the light is always 1, so all the materials behave like constant.

Unfortunately this method has a major disadvantage: since the direction of the reflected and refracted rays leaving a (reflecting/refracting) material depends on the normal, the result is completely wrong for secondary rays, because we are moving the normal to an arbitrary (up) direction. So, using the bump port was not a solution.

However, this failure pointed us towards a better solution.

Again, we just had to fix the diffuse component. In all the material shaders (except a few exceptions like hair, which we treat separately), the way the diffuse component is computed is as follows:

1. Get the light color
2. Multiply it by the incidence
3. Multiply the result by the diffuse color

So, if you want to get back the plain diffuse color, you just have to tell the light to return 1 (white) divided by the incidence. This way, the material shader returns diffuse * incidence * (1 / incidence) == diffuse.

This the starting case (a phong sphere – top), and our first result (bottom)

And this is the rendertree for the light

Also in light shaders, the normal can be used (it’s the lit point normal). The dot product of the normal with the light direction L0 is the incidence, which we then use to divide 1, and return the result as the intensity of the light.

That was ok for a half dome, but what about the rest? A possibility is simply to double the light, specularly to the xz plane, cloning the rendertree (and L0 becoming 0,-1,0 for the other light). That would cover 99% of the cases, being any oriented surface sample being lit only by one of the two lights at most.

The “at most” is the remaining problem. If you have a cube, its vertical faces won’t be lit by any!

So, we have to expand a bit this setup. We start setting up a minimal light rig, ensuring that al least one of the lights will always hit any oriented surface. The minimum number of lights for such a rig is 4, equally distributed in space.

So, we take a tetrahedron of radius 1, centered at the origin, and cluster constrain a directional white light to each vertex, all pointing toward the origin.

Each light has the following rendertree (with a small change for each of them)

This is the tree for light L0: the left side vectors are the four lights positions, set by expression. Since The tetrahedron has radius one, they also represent the direction toward each lights. All their incidence with the normal is computed and sent to a positivity check, and this check drives a switcher between zero and one. So, the sum of these 4 switchers is the number of lights (1 to 3) visible from the rendered point.
This number is multiplied by the light incidence and the result divides 1, as in the single light case.

Why do we need the number of visible light? Since we have 4 lights, the total amount of light that gets received by the point is
L = L0*I0 + L1*I1 + L2*I2 + L3*I3, for each positive Iight. In fact, the material shaders won’t even query a light if its incidence is negative.
So, as before, we still return 1 divided by the light incidence, but also divided by the number of visible lights, so that the overall sum of the visible lights is always 1.

The other 3 lights have the same rendertree, except the dividing incidence comes from I1, I2, I3 respectively. For instance, this is the tree for light L1.

And finally, we have our constant result. You can download the rig here.

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

Everyone complained (including me) that the old particle system was too weak, too limited…. But it was fast to get some things done. To randomize a value, for example, you simply had to open a property page and set a variance parameter. Partly because ICE is so open, to vary a parameter, you have to search for the desired compound or node modifier, drag & drop, connect ports and then set values in the new compounds. Read me right, ICE is very powerful but if you have to modify dozens of parameters hundreds of times in one typical work day, this work flow becomes redundant an inefficient. There must be a way to be quicker.

Softimage proposed a work flow that can be described as follows: a technical director connects basic nodes, designs compounds and exposes ports. An artist, who is not necessary knowledgeable of ICE, then sets the different values of the exposed parameters. Some problems may arise with this approach. How can a TD predict every alteration needed by the artist? In the context of a particle simulation of falling rain, for example, a TD may have to design his compounds to support, for a simple shot, wind and gravity. Then, another shot may require water splashes from the droplet hitting the ground. Another still, requires the same rain but with the added effect of coagulating droplets on a smooth surface. And so on. You can easily imagine multiple variations of the same effect. So how are TDs supposed to tailor their compounds to fit all of the artists needs? One obvious solution is to build a system of compounds rather than a top level one. Yet the artists would need to be taught and learn how this system works and therefore, learn how to use ICE. Yes, maybe… but unlikely. I know many technical XSI users that were clueless on how create a simple simulation; artists, even less probable. How can technical directors empower artists without limiting them with a simple set of parameters? There should be a window to deliver the power of ICE to artists without being too painful. Artists should be able to easily create simple particle animation. You do not need to be a mechanic to drive a car.

With these observations in mind came the search for a way to simplify the ICE work flow which any Softimage user would understand and produce simulations in no time. The intent is not to replace the current work flow but to complement it and accelerate the multiple iterations needed in order to design particle simulations. Subsequent refinements, complex connections or relationships can and should be achieved the traditional way by connecting nodes and compounds in the ICE tree. But once a new solution is found, it should be easy to re-integrate it in a simpler work flow system. It should also be seen as an added value to cut the time to help generate about 75% of particle animation scenarios.

You do not need to look very far to find solutions. By simply looking at the different ways shaders can be modified, it is easy to wonder why ICE property pages were not designed the same way. Isn’t it faster in many situations to create connections by using the plug icon in a shader’s property page rather than opening it in the render tree, dragging and dropping a node, then making the connection? It should be the same in ICE property pages. No?

Also, all parameters affecting the simulation should reside in the same property page. With a typical ICE tree containing easily 20 compounds or more, finding a parameter often requires a search through many compounds. Too many doubles clicks are required to access the compounds’ parameters; why not put them in one location. When a scalar is randomized for example, the parameters associated with randomization should replace the original scalar in the top property page. You say: isn’t the top compound intended for that? Yes, but it doesn’t expose ports automatically. Remember, the goal here is to create particle simulations in a production environment; not to design ICE trees in a R&D context.

In the following video, I demonstrate a working prototype. It shows the above ideas in action with the exception of having iterations made through parameter contextual menus instead of the plug connection icon menu. The Softimage development kit does not give access to this type of UI widgets for ICE compounds property pages. Also, for clarity’s sake, it would have been beneficial to have used tabs in the property page to seperate emission, particle type, forces, triggers and events. This was not implemented. This prototype was written about a year and a half ago with a beta version of XSI 7.0 and unfortunately has not been updated to work with the current version of Softimage but would be relatively simple to rewrite. I must also credit my colleagues at the time, Jeff Wilson, who helped with the original concept and Javier von der Pahlen who co-wrote the prototype. It is important also to say that I was an employee of Softimage at the time when that prototype was written. As a long time user of Softimage’s products, I was trying to push solutions that made the work of technical directors easier. Unfortunately, this concept was not accepted. But it remains a great concept on how technical directors can go beyond compounds and integrate ICE in production pipelines more efficiently. It clearly illustrate the ability to build a simple particle animation rapidly without having to access the ICE tree. All iterations are made through the property page.

I simply wanted to share these ideas with the Softimage community and start a discussion. As, hopefully, more and more people will be using ICE, I’m sure that work flows will evolve to more efficient ways to manage ICE trees. Maybe it’ll lead to similar solutions, whether it comes from Autodesk or the community. I think it’s really cool concept and it would save many users time and headaches. What do you think? Is this type work flow worth exploring?

PPG Based Particle Animation Work Flow With ICE from Hans Payer on Vimeo.

HDRShop
HDRShop plugin Diffuse_SH.

I used to work for a 2 years at Framestore-CFC in London. That mean I use Maya and PRMan as my main application. During this year I learn a lot of thing but also hear a lot of false assumtion about rendering in general. Typically the common comment was that PRman was more suitable to render complex character and that MR was very slow for this kind of job. In fact people arguing about this doesn’t not really know what are the status of modern rendering such as MR, V-ray or any others assuming everything was frozen since 5 years or just repeating what the veteran keep repeating.

But I am not engaging a new flame wars between renderer. Actually I don’t care which is the better today in 2008 you can produce beautiful picture with any renderer available in the market ( and yes that include maya’s software render well known to be a piece of crap ;) ) The most important is the guys behind the scene. But I need to put everything in their respective context to elaborate and may be justify what and why I will describe later.

Actually mental ray is very fast, if you do things correctly. If you don’t do things correctly ( such as massive spatial and/or temporal oversampling ) it as well as any other renderer will be very slow. But I always get this "PRMan displaces faster" stuff. Of course it does…. until you actually trace a ray.
You have to know that PRMan lives in a mindset where raytracing is so slow that you avoid it at all cost. The thing is that in PRMan, if you try to shoot a ray, it too has to do all those things that a raytracer do by nature. So the minute you actually shoot a single ray, PRMan has to do what mental ray always does…. and the comparasion suddenly isn’t so much in favour of PRMan any more.

So people using PRman developed a completely different approach to same problem : Lighting and Rendering a scene while trying to avoid at all cost raytracing. That what is interesting. What will happen if I use these approach with Mentalray within XSI ? Maybe I can have a hybrid solution keep the best of the two world to render my character(s) ?

Diffuse Convolution on Environment map

What’s that ? To keep it simple you can assume that a diffuse convolved map is envmap where you apply a smart blur that will give you the result of sampling this envmap with an infinite number of rays with the Final Gathering on a perfect lambertian surface. For more information you can refer to Debevec’s research ( the father of HDR images ).

Having your envmap pre-blurred is a great advantage because you don’t need to sample it several times to get the correct illumination. Only one sample suffice to get the illumination on your surface. Actually you must cast only one ray. Otherwise you will average twice the map and the illumination will not be correct any more.

The ray direction that you will cast must also be in the same direction as your surface normal. The Xsi’s Ambient Occlusion setup correctly will do perfectly the job. You need one sample , the spread will be very small to not deviate from the normal ( 0.01 ) and the mode should be set to environement sampling. Obviously you can code a shader that do the correct environement lookup. I am using the XSI’s AO shader because it’s available out of the box.

Render Balls simple test.

Env sampling brute vs FG vs Diffuse Conv

The way I set up the scene is very simple. I tried to get the contribution of the envmap once convolved and only this. So there is no illumination model just different approach.
The HDR used for this test the one called beach.hdr that you can find at debevec’s website. The map that you download is an angular map so you have to convert it to spherical coordinate system. The easiest way is to HDRshop and convert to angular map to longitute/latitude map. Once the map ready, I put it in my scene as an environement map.
The first sphere is the result of an AO shader set to environement sampling mode with a spread of 0.8. I had to crank up the sampling to 1024 to get a smooth solution. AO env sampling is brute force approach. There is no importance sampling so that mean you have cast a lot of ray to get a smooth result specially with high dynamic range image. And obviously that be very slow. It’s the slowest render.
With the second sphere I used to FG to sample env. Same settings as before except that I use a shader that return irradiance and activate FG. FG is a lot faster that the previous method because it doesn’t sample every point with 1024 rays. Instead FG will sample a certain amount of point and interpolate the result between the point calculated. But for this comparaison I pushed the number of rays to 4096 to make sure I got enough accuracy to have fair comparaison with the quality of the next approach. Even by pushing the number of rays to 4096, it was still faster to render with FG.

With last sphere I made a diffuse convolution in HDRshop ( using the SH_diffuse plug in because it ’s a lot faster than HDRshop’s function), applied the resulting image as an environement map and use the XSI’s AO shader with the sampling set to 1 and the spread to 0.01.
The render time is ultra fast and match FG solution. It ’s actually realtime because the convolution has been already calculated once in HDRshop.

Render Balls too simple let’s try with something that got balls.

We got a exact match with the FG for a fraction of time. We can conclude that the diffuse convolution is good enough to simulate FG. But in our test we were using simple sphere. This an ideal case but we needed to check first if the lookup was correct before to move on something more serious.

I like buddha. I like him because it’s a one million polygon model that can be compared to any displaced model push out from Zbrush or Mudbox.
I have simply applied what I did with the spheres.
The first render is with an diffuse convolved envmap. It took approximately 50 sec to render with a large part of preprocessing the scene. If I had a realtime shader could get the same result ( minus anti aliasing ) in realtime. Obviously there is no occlusion calculated but that due to fact I asked only an environment lookup around the normal of the surface.
The second image is what you get if you were using FG and third one is a difference done in shake
to highlights the difference between the two renders.



As you can see only the occlusion and the FG colored bounce are missing. If you apply a simple occlusion on the top you will endup with an image that is fairly close to the FG solution but with only a fraction of the time involved by the process.

OK but in production is it worth to use it ?

Well I will say yes and no. It depand the number of shot you have to do and the time you got to complete them. This technique involve a bit of setup at the shading level while the using FG is straight foward. So if you are working on movie that need a 2K ( or more ) render then yes. Memory foot print is very low and it’s damn fast to render it specially with very heavy object like displaced object or Hair object..
At the moment you need to set this at the shader for every object. Ideally the best will be to set this as a global ambience. Unfortunately you can’t plug anything in the global ambience parameter. So the best if to use a light that cast only ambient light. And for that you need to code it so ask your favourites shader writer to do it.

Publications :

An Efficient Representation for Irradiance Environment Maps

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