I’ll also put in place a system to push central library changes to the local computers and insert the library location in the PYTHONPATH environment variable.

The XSI Wiki has a great page on the pros and cons of the module approach. One of the cons is that the Application global variable is only accessible in your script files and plugin files and not in your modules.

In the past I would put the following code at the top of my various modules:

1
2
3
4

import win32com
from win32com.client import constants as c
xsi = win32com.client.Dispatch('XSI.Application').Application
log = xsi.Logmessage

Following this would be a bunch of other shortcuts and dispatch commands for XSIUtils, XSIUIToolkit, XSIMath, etc…

Being tired of inserting these lines at the header of every module and a subset of this code (for shortcuts) at every script or plugin, I decided to centralize them and move them to their own module.

The library structure looks like so:

../libpath/
    vg/
        xsi/
            __init__.py
            xsiModule1.py
            xsiModule2.py
            [...]

In the __init__.py file I put the following code:

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

import win32com
from win32com.client import constants as c
xsi = win32com.client.Dispatch('XSI.Application').Application
log = xsi.Logmessage
# [... more shortcuts and dispatch commands ...]
 
def getShortcuts(g):
    g['win32com'] = win32com
    g['c'] = c
    g['xsi'] = xsi
    g['log'] = log
    # [... more shortcuts and dispatch commands scope transfers...]

This allows me to benefit from the shortcuts in the rest of the __init__.py file where some general XSI functions are kept but also start my other modules, scripts and plugins with the following two lines:

1
2

import vg.xsi as vx
vx.getShortcuts(globals())

By providing the getShortcuts function with a dict representing the global scope of my module, script or plugin, the function can edit the members of the scope and give me all the necessary symbols.

Another stupid trick rears it’s head! ;)
Happy scripting!

The weird wirings in my brain. That’s what.

Back to the beginning

At the end of last October Steven Caron sent me a plugin he wrote that allows an XSI user to drag and drop .obj files into the interface and have them import automatically according to settings in a custom preference. I was a bit swamped at the time putting up the infrastructure for a new VFX department at my new workplace. And then I totally forgot about it… Sorry Steven.

This past week Steven politely reminded me of my omission so I ran back to my email archives and installed it. Neat piece of work.

I didn’t want to just post up the tool as I don’t really see this blog being about tool distribution but about how said tools work and the neat tricks they use. With that philosophy in mind I cracked open Steven’s tool to dig out some of its sexier bits and maybe demystify them for the audience.

To my surprise there weren’t any sexy bits. Please don’t get me wrong, the tool works superbly, how much more intuitive can you get than drag and drop. The tool is also extremely well written, concise and straightforward. There just aren’t any weird tricks or convoluted syntax or things that would generally have you scratching your head.

Then I noticed this in his version trapping code (yes folks, the drag and drop event is new in XSI 6.5):

27
28
29
30
31
32
33
34
35

if int( tXSIVersion[0] ) < 6:
    xsiPrint( xsi.Version() + " doesn't support the 'siOnDragAndDrop' event!" )
    xsi.UnloadPlugin( in_reg.name, True )
    return False
else:
    if int( tXSIVersion[1] ) < 5:
        xsiPrint( xsi.Version() + " doesn't support the 'siOnDragAndDrop' event!" )
        xsi.UnloadPlugin( in_reg.name, True )
        return False

About the waste part

Bare with me…

Last week I was reading a really neat article in Wired by Chris Anderson entitled “Free! Why $0.00 Is the Future of Business”. I invite you to read it, especially the section beginning on page two: Waste and Waste Again.

…So if in the seventies you had to be really tight with your algorithms and optimizations because cpu cycles were so scarce, today I guess we can really waste them. Just the other day I setup an 8 core MacPro with BootCamp, XP x64 and XSI. Whatever I did to the machine, I swear, I could hear it yawn because it was bored.

Which brings me back to Steven’s code. Could it have been written like so:

27
28
29
30

if int( tXSIVersion[0] ) < 6 or int( tXSIVersion[1] ) < 5:
    xsiPrint( xsi.Version() + " doesn't support the 'siOnDragAndDrop' event!" )
    xsi.UnloadPlugin( in_reg.name, True )
    return False

Is it more or less readable by a programmer?
It probably executes in a few cycles less but is it worth it?
Python is interpreted so if the parser goes through this version quicker, is it worty of any mention?
Is it more maintainable?

This example is really simple but in a bigger project, or with more complex cases, should we really be worrying if today transistors and cpu cycles are so cheap as to not even matter anymore

When I'm stuck on a piece of code or when I hit that time of the afternoon where most of my energy is diverted to digesting, I'll often reread my code and tighten it, remove redundancy, put in functions instead of copying a few lines in two locations, consolidate if statements, etc... One of my colleagues used to tell me that "Premature optimization is the root of all evil."

Honestly, if I look back at a good proportion of the code I have written, it either executes in a blink of an eye on today's computers or it sits there waiting 90% of the time for user interaction. Should we, as technical XSI users, XSI scripters or TDs, even worry about optimization from a performance standpoint or a maintainability standpoint? What can be considered a good optimization and what should be considered a bad one?

And now that you're really wondering what I'm rambling about, I'll shut up and let you download Steven's addon.

Have a good weekend. ]]> http://www.softimageblog.com/archives/249/feed 19 http://www.softimageblog.com/archives/131#utm_source=rss&utm_medium=rss&utm_campaign=is-it-time-to-move-to-vista http://www.softimageblog.com/archives/131#comments Fri, 29 Dec 2006 20:46:17 +0000 Luc-Eric http://www.xsi-blog.com/?p=131 XSI 6.0 was being finished pretty much at the same time as Vista was on RC so we didn’t have to fully test XSI on Vista in depth, there was just too many things going on at the same time. New compilers, new MainWin, new render core, new setups, etc.

On one hand, 6.0 adds DirectX 10 support, which is an extremely significant departure from DirectX 9, and is exclusive to Vista. That’s right, neither Windows XP nor the XBox 360 will support DirectX 10, and users need a bleeding edge graphics card. Still, game developers need to get ready now for games that will come out in a couple of years, and they can do so with XSI. We’ve also fixed a few glitches that XSI had when running under Vista. For example, the buttons did not work in message boxes, due to a problem with our skinning mechanism. One can work-around the problem by using the keyboard to select the buttons instead. On the other hand, we do not presently have a dongle driver compatible with Vista, so this means it is required to run the license server off another machine. (I think this does not affect Foundation, which doesn’t have a dongle.) Softimage is very committed to having good Vista support, and will provide updates on the subject during 2007. Right now we do have a few users running under Vista and we’re very interested in your experience if you are doing this; do not hesitate to add your comments to this post.

Windows XP should still be available for general purchase for at least one year, and it is probably best to stay with it in the immediate future. At the other extreme, while we do not test and support Windows 2000 anymore, we do have several users that still use it. We are not at this time using any feature specific to XP, nor are we planning anything of the sort at this time. In my opinion, if you have a laptop it is a good idea to upgrade to at least XP, because it is faster, and graphic driver support for 2000 can be scarce. XP is also required for hyper-threading support and has newer and better drivers. You can turn on “classic mode” in XP to make XP continue to look like Windows 2000 :D

Defining Evenly Distributed

Some would argue that for points to be evenly distributed on a sphere the resulting polygonal object defined by the points needs to have faces that are equal as well as an equal number of faces leading into every vertex. These perfect shapes are known as Platonic Solids.

There are unfortunately only five platonic solids: the tetrahedron, cube, octahedron, dodecahedron and icosahedron each having 4, 8, 6, 20 and 12 vertices.

So unless that is exactly the number of points you wish to have around your sphere we must somehow redefine evenly distributed. There is a great discussion on this titled “Topics On Sphere Distributions” by Dave Rusin.

In our case, let’s ignore how the points would combine to create a solid and concentrate on the distance relationship to its neighbors considering the whole set. For any given number of points what we want is for the minimum distance between any two points to be as large as possible. Makes sense? If any two closest points in the whole set are as far apart as possible, all points should be equally distant from their closest neighbor. That is what we will define as evenly distributed.

How to achieve even distribution

One of the most precise ways to organize points on a sphere, given our definition, would be to simulate them repelling themselves with equal force until they settled (see this document by Simon Tatham). It would be exact but wouldn’t necessarily be quick. Then there are three algorithms that approximate the same result all the while requiring less computational power.

The first one is Dave Rusin’s Disco Ball. Although it will wield a very precise pattern the algorithm does not allow to specify an exact number of points which are then distributed.

The second one is the method of Saff and Kuijlaars. This second one packs the points much less tightly than the Disco Ball but manages to do so with any arbitrary number of points.

Finally there is an algorithm based on the greek golden ratio, the Golden Section spiral. This last stab at the problem can generate a set packed more evenly than Saff and Kuijlaars while being able to specify any number of points.

Here is a graphical comparison of the three methods.

My Golden Section Spiral

Here is a Python implementation of the Golden Section spiral:

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

import math
 
def pointsOnSphere(N):
    N = float(N) # in case we got an int which we surely got
    pts = []
 
    inc = math.pi * (3 - math.sqrt(5))
    off = 2 / N
    for k in range(0, N):
        y = k * off - 1 + (off / 2)
        r = math.sqrt(1 - y*y)
        phi = k * inc
        pts.append([math.cos(phi)*r, y, math.sin(phi)*r])
 
    return pts

By passing any arbitrary number of points to the function, it will return an array of points in space representing the locations of all points on a unit sphere. You can then multiply this unit vector by whatever length you wish to get the position on a sphere of any size.

Paste the above code in the script editor followed by this concrete XSI example and run it to see the results:

1
2
3
4
5
6

for pt in pointsOnSphere(80):
    n = Application.ActiveSceneRoot.AddNull()
    n.size = 0.05
    t = n.Kinematics.Global.Transform
    t.SetTranslationFromValues(pt[0], pt[1], pt[2])
    n.Kinematics.Global.Transform = t

Voilà! I hope this helps you on your way to the perfect spherical distribution. ;)
Yeah… I sometimes have a hard time remembering that our job is to make pretty pictures.

Cheers,

Aaron Holly
Disney Feature Animation

First Talk of Saturday was Aaron Holly, rigger at Disney. The talk was about deformable rigging in Maya. The idea is to enable animators, who often have a background in classical 2D animation, to achieve the exact pose they require including all kinds of squash and stretch.

The approach Aaron shared was to build simple skeletal structures that drive an intermediate deformation level whose controls can be torn off the skeletal structure thus achieving any exaggerated pose required.

Aaron, who studied philosophy before swerving into the 3D realm actually invoked Occam’s razor as being an underlying philosophy to his approach to 3D rigging. Occam’s razor states that, given two valid solutions to a problem, the simplest solution is invariably the best. Nice words to work by.

Another issue that Aaron talked about is linking stuff (secondary shape animation for example) to the rotation of a ball joint in a rig. A ball joint will usually have rotation on all three axes while you will typically want only two values to link your stuff to: a top/bottom rotation as well as a forward/backward. The approach showed was to project the end of the joint onto a plane at the root of the joint. The position on this 2D plane vis-a-vis the root of the joint thus represents in 2D space the amount of rotation applied to the bone. Interesting. I’m sure a custom operator for XSI can be written that would compute this in a flash. This to-do list of mine is getting way too long!

Mark Lefitz

Mark was showing a typical digital environment workflow. A lot of interesting stuff was shown, Mark’s production experience really shows.

Tips and tricks for easing the workflow such as working in half rez or 1K and then scaling up renders for final out.

All in all a neat talk. Mark has often worked in Maya and Renderman and mentioned some pass workflows that were interesting. XSI’s passes and partitions still seem to dwarf anything else I’ve seen though.

Chris Williams
Lucasarts

Having never worked in a games development house I never really realized how much the two industries of games and film have come together.

Chris of Lucasarts spoke a lot of convergence. We all know the Lucas empire is huge and as technologies have been moving to a common nodal point a lot of effort has been put into unifying pipelines and processes over at George’s place. Slick stuff.

We’ve all heard a bit about Zeno, ILM’s new development framework for custom tools. Well, it seems to be a much larger endeavor than I thought. The guys at ILM R&D seem to have almost come up with a full content creation system. Integrating game technologies to create film previs tools, moving editing tools from a film background to a cutscene blocking environment as well as providing a unified environment for the artists. It’s all proprietary so we can only fathom all the things Zeno can do.

Lastly, we were able to see a tech demo of euphoria technology jointly developed with UK-based Natural Motion who market a character simulation software called Endorphin. Seamless blending from animation to ragdoll to animation as well as simulated character motion reacting to environmental factors. Imagine a simulated character latching on to a second story railing after having been projected sky high by an explosion. Check out the Endorphin demo to get an idea of the technology.

Consumer technology is always pushed forward by a few R&D brainiacks going “I bet I can do this.” when everyone else is saying “Wouldn’t it be cool if…” or even “It can’t be done”. Looking at Stanford, UCLA, ILM, Disney, Sony Picture Imageworks and other large players as well as a host of smaller ones makes me say it’s a good time for digital content creation.

Jeremy Birn
Pixar

It was refreshing to see someone approach digital compositing from a more technical point of view. Most people, when they talk about compositing concentrate on the finished product and its artistic and aesthetic value but knowing what happens under the hood IMHO is a prerequisite to getting that extra edge.

Jeremy managed to explain some of the mathematics involved in very clear and simple terms. It was nice to have representatives of both the artistic comper (Mark Lefitz) as well as the technical comper (Jeremy) in the same conference.

Jeremy also covered the creation and management of passes/render layers in Maya and how these different outputs can then be recombined in Shake to produce final output. XSI’s implementation of this stuff rocks. The use of XSI in that last phrase wasn’t a typo.

… And Jeremy was the first speaker of the weekend I heard mention XSI. Is Maya really so pervasive and have so many people not yet discovered the strong points of Softimage’s product portfolio? You do know they’ve evolved quite a bit since Softimage|3D!

Emile Ghorayeb
Ubisoft

Emile is obviously a great animator with a lot of experience. His demo of the squash and stretch style of cartoon animation as applied to 3D characters was very enlightening. Emile often stressed that, as an animator, it is very important for him to be as close to the character as possible. For the riggers out there he is saying that the rigs you produce should keep the animator on the character and avoid as much clutter as possible. For the animators out there he is saying that you are as much an actor as an animator and you should live and breathe through your character while you are working. Anything in your 3D environment that could tare you away from the performance should be avoided. Even if Emile seems to be the strong silent type, or maybe he was just really nervous, he is obviously passionate about his work and it shows through his results.

Eddie Pasquarello
ILM

Pirates of the Caribbean 2: Dead Man’s Chest
What an impressive show.

If a lot of movie critics talked about digital makeup or flesh extensions for Davey Jones, ILM is working hard to debunk that myth. Davey Jones and his crew are 100% digital, eyeballs and all.

The talk was pretty much a usual show and tell and when ILM does a show and tell you can be sure a lot of you questions will be replied with either:
- “It was proprietary software.”
or
- “We did it with Zeno”
which is proprietary software. I guess you can do that when you have one third as many coders and TDs as artists.

One thing that really blew me away is a proprietary tool ILM developed for this show called iMocap (taking a page from Apple’s marketing handbook are we?). This thing could pick up actor performance from a set with the main film camera and two witness cameras. The kick is that the iMocap system doesn’t care about lighting conditions and can pick up performance from many actors at once in an almost unrestricted set space.

… Say what?

Yep they built an uber flawless mocap system. I would love to get to the guts of this thing and see how it works but I guess I’ll have to get my own gears turning and figure it out on my own.

No matter how you did it, kudos to ILM. You did great work.

Arnaud Lamorlette
PDI/Dreamworks

Arnaud started with an overview of the production process over at PDI and he mentioned something called PDI pipeline. Yeah, don’t you love these large studios and all their proprietary tools.

Most of the talk was a show and tell about Shrek 2’s effects work and, refreshingly, a few details were given. One effect example that was dissected was the fireballs. Surprisingly few passes and rather simple solution of growing isosurfaces with fractal noise displacement and a normal-based color shader accounted for 90% of the effect. Neat.

All in all I had a great time because content was king at ADAPT 2006. For a first time conference it could have been otherwise but the organizers really did their homework.

I hope next year I’ll get to meet you all at the 2007 edition.
Cheers.

Cheers.

So I started trouble-shooting, and it finally came down to “as soon as there was a single character in the file, I would get these errors”. No matter what I would write in the file, either a “pass” statement or a # character, I would get the error. Also, while Python was reporting an error, it also gave me “no encoding declared” messages.

>>> from lighting.LightTools.modify import LT_ReorientInfiniteLight2
__main__:1: DeprecationWarning: Non-ASCII character ''\xff'' in file E:\workgroup\Data\Scripts\lighting\LightTools\modify\LT_ReorientInfiniteLight2.py o
n line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "E:\workgroup\Data\Scripts\lighting\LightTools\modify\LT_ReorientInfiniteLight2.py", line 1
     ?p
    ^
SyntaxError: invalid syntax

Notice the black square before the p. That made no sense, as the p was the first character (a “pass” statement).

I tried every possible thing, like ovewriting the file with a new one, etc. Basically I spent few hours to try to solve an impossible syntax error.

However I tried another text editor (UltraEdit), and I no longer had the error. So it became clear that my first text editor, SciTE (Scintilla Text Editor), was at fault.

So in SciTE, I went to File > Encoding, and I notice it is set to one of the two UCS encodings. I set it to Default.

Problem gone.

People in the OSS and free software world like to talk about free speach vs. free beer. Well, it seems to me like the ever widening 3D application userbase likes to have its free lunch.

Thursday, March 28, 2002 Alias Wavefront cuts the price of Maya down to $1,999 and $6,999 for their Complete and Unlimited versions respectively. To me, this was the start of a democratization process to bring inexpensive professional quality 3D content creation software to the masses. Then came out the learning editions, the tiered pricings and since August 2004 you can even get an XSI version for $495.

Then comes along Face Robot and people are aghast. They’ve quickly gotten used to their free lunch. They clamor for innovation yet they aren’t ready to back-up the company that provides such leading edge innovation.

I can’t even start to imagine the amount of research that was poured into Face Robot and that R&D cost needs to be offset by Softimage. They aren’t, after all, a non profit buisness. And if a product can help you achieve the same quality output in less time, or a better output in as much time, considering the size of animation teams involved in photoreal character animation projects, 95K isn’t that much a big deal.

And let’s not forget that Face Robot is a highly specialized tool.

If memory serves, Behavior was initially around 15K-20K. I don’t really have to remember, I wasn’t the one who coughed up the dough. The Buzz team I worked with at the time was among the first to use Behavior in a commercial advertisment context. As an early adopter of the technology we were one of the customers that helped Softimage offset R&D costs. This brings me to two points.

1 – Behavior is still not being used all that much. Face Robot, like Behavior is a very specialized tool and for most studios, would be nothing more than an experiment. After toying around a bit that studio would go back to their bread and butter shot that doesn’t include a human face or a crowd. Face Robot is aimed at projects, not studios and the studio that has a project to warrant the use of Face Robot should have the budgetary envelope for it as well.

2 – Look at what has happened since Behavior hit market. It is now included with every purchase of XSI Advanced. Behavior has been democratized fairly well by now so who knows where we’ll be later on down the road with Face Robot. For now the people that have already done their bean counting know if this technology is what they need.

The rest of us can wait for the R&D investments to be offset and the competition to heat up in, what is for now, a Softimage only arena.

After all this is what this all boils down to: how much are you willing to pay for exclusivity, new products and most of all: innovation.

Check out the press release and product pages for FaceRobot
If you think I woke up in a pissy mood and am way off track or if you think likewise on this issue, please feel free to comment!

Warning: If you’ve never used Behavior before or don’t care for crowd sim, skip this one. If you care for a stupid Behavior trick… Read on…

Behavior has a rendering pipeline that involves spewing a bunch of files into a directory and rendering them out with a nifty geometry shader and Mental Ray. Thing is, you have to run a simulation for every render pass you have. This means, you don’t have a choice but to cache your actor’s motion data in a first pass and then simulate all your other passes using the cache to output your .mi2 files.

When I did all this I wound up with characters that wouldn’t render at exactly the same spot from pass to pass even if I had used a caching mechanism. We’re talking pixels here but it was enough to show…

Ever notice all those .mrd files Behavior creates along with your .mi2 files? They contain your actor positions for every frame of your simulation. To get my passes properly aligned I just copied all the .mrd files from the output directory of one simulation into the output directory of another and voila!

I’m wondering if this is just a cosmic fluke that should be chaulked up to planetary alignment or if it’s a legal Behavior move but… It just saved my butt!

Carry on!

Simulations

You can deduce the units of a parameter rapidly with only a few tries. The Age of a particle is expressed in seconds, not frames. The Size of a particle is in scene units, not pixels. Starting from that, we can assume that the Rotation Velocity is in degrees per seconds, not degrees per frame, and that the Allowed Linear Velocity is expressed in units per seconds.

Things get a little more tricky when you want to animate a parameter according to the age of a particle. The key you set at frame 50 doesn’t mean 50 seconds, but 50 frames. This is not consistent with the other examples stated above, but it’’s a lot easier to figure by yourself as it’s more intuitive.

For a rigid body object, the help file says the Linear Velocity Limit is in units. Of course, experimentation shows it’s in units per seconds. Setting the Angular Velocity Limit is awkward. The help file says the value is expressed in radians. Experimentation suggests it’s in degrees per 2 seconds!

1
2
3
4
5
6
7
8

CreatePrim "Cube", "MeshSurface"
CreateActiveRigidBody "cube"
SetValue "cube.DynamicsInitState.angvelz", 90
SetValue "cube.RigidBodyProp.VelLimitsActive", True
SetValue "cube.RigidBodyProp.AngVelLimit", 60
SetValue "PlayControl.Format", 7
SetValue "PlayControl.Out", 25
PlayForwardsFromStart

After one second of simulation, the rotation is roughly half of the Angular Velocity Limit.

Displacement

Rendering parameters can also cause a considerable amount of confusion. Displacement and Final Gathering both have parameters that can be switched between absolute and camera view reference. In the Displacement tab of the GeoApprox PPG of an object, when set to Fine, there is a parameter called Length. This parameter is expressed in scene units. Mental ray will try to keep the triangles no bigger than Length. You must adjust this parameter to the scale of your object or scene. The render time can go through the roof if you activate View Dependent without modifying the value of Length because its units have changed. It’s now expressed in pixels, making the size of the triangles dependent on the distance to the camera, and in this case, smaller than half a pixel by default.

Final Gathering

The same goes for the Min and Max Radius in the Final Gathering tab of the Render Options PPG. Their values are normally expressed in scene units. When you click on the Automatic Compute button, XSI calculates the average bounding box size of all the objects in the scene in scene units and sets the two parameters accordingly. However, when you activate the View Dependent check box, the values of the radius are now in pixels. If you click on the Automatic Compute button, it will still calculate the values in scene units, and set the wrong values in the parameters, possibly increasing render time considerably and unnecessarily.

Volume Effects

I’ve seen many artists having problems with the Volume Effects shader. This is a fine shader even if it hasn’t evolved a lot since its early days in Soft|3D. It has a parameter called Step Size, which controls the spatial resolution of the marching algorithm. It’s expressed in scene units so it is very dependent on the scene scale. Applying this shader on a pass in a very big scene can lead to nightmares in terms of rendering time. It’s important to understand this parameter when using the Volume Effects shader, and the fact that its units are in scene units scaled by the size of the object it’s applied on. If you apply it to a scaled up cube (scaling = 100, 100, 100), the Step Size will be expressed in scene units * 100.

Depth of Field

The Depth of Field Shader is particular. Many of its parameters names say they are in inches, when in fact they are in scene units. I suppose the developer wanted us to use a scene scale of 1 unit = 1 inch to make sure the result would match reality. I don’t think this was a very good idea. It confuses more than anything.

I wish Softimage could add some space or some tooltips in PPGs to display the units. It would help the users determine the best values for certain parameters without having to go in the documentation all the time. In the mean time, experimentation is still our best resource.