Phoenix Tools was a plugin company for Softimage 3D, and I was one of the founders. We did good and bad, and we eventually closed down in 2002.

Arete had an excellent reputation for their ocean and atmospheric library, called Digital Nature Tools. I think their main business was in military simulation, however they had a part in every cg-generated ocean in the movies of the 90s.

In 2001 we joined forces to port their software under XSI (I think it was 2.0). Unfortunately, after the first version came out, both companies shut down.

8 years later, I am working on a feature animation with a few shots in water, and I realized I still had on some cd the arete psunami libraries. So, I decided to give it a try. I removed the license check from the shaders and I compiled them with good old Visual Studio 6, linking against the oldest mental ray library I could find (3.3), and in the end it worked. I was kind of touched when I finally saw the displaced grid rendering in Softimage 2010.

I think I will do no harm to anybody releasing these shaders. Both companies are dead since long, and this is my little tribute to them and the talented people who worked there.

The addon is only available for win32, and no, no chances for other platforms. That Arete library is the only one I have. If you do, use it at your own risk (and fun, i would say. There are probably better ways to do oceans nowadays).

And, you know what, I don’t even know how the full package works. I don’t have anymore the documentation, nor the scripts we provided. If my old companions will find them, I will post them later.

The basic usage however is easy. You have to connect a DNT_Ocean_Sh and DNT_Time to a DNT_Ocean_Evolver. What come out is the ocean instance, that can then go into the other nodes. Also, you want to apply DNT_Air as environment to have nice reflection and the atmosphere.

Callbacks in XSI plugins are functions in the global scope who’s name must be defined exactly the way XSI expects to find them.

I would have preferred callbacks to be supplied by the user in a way that allows them to have any name and in a way that allows them to be changed on the fly. In all fairness, Softimage probably has some very good reasons for the way they did things.

So this is where we, as users, exploit the power that has been given to us and take things into our own hands. Here is my implementation of dynamic, interchangeable, replaceable callbacks.

Code Time!

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

import win32com.client
from win32com.client import constants as c
from vg.xsi.dynamic import *
 
def XSILoadPlugin( in_reg ):
	in_reg.Author = "Patrick Boucher"
	in_reg.Name = "dynCbCommandPlugin"
	in_reg.Major = 1
	in_reg.Minor = 0
	in_reg.RegisterCommand("dynCbCommand", "dynCbCommand")
	return True
 
def XSIUnloadPlugin( in_reg ):
	strPluginName = in_reg.Name
	Application.LogMessage(str(strPluginName) + str(" has been unloaded."),c.siVerbose)
	return True
 
def dynCbCommand_Init( in_ctxt ):
	oCmd = in_ctxt.Source
	oCmd.Description = ""
	oCmd.ReturnValue = True
	return True
 
@dynamic
def dynCbCommand_Execute():
	Application.LogMessage('In original callback!')
	setCallback(dynCbCommand_Execute, callbackTwo)
	return True
 
def callbackTwo():
	Application.LogMessage('In %s!' % callback(dynCbCommand_Execute).func_name)
	setCallback(dynCbCommand_Execute, callbackThree)
	return True	
 
def callbackThree():
	Application.LogMessage('In callback three!')
	restoreCallback('dynCbCommand_Execute')
	return True	
 
setCallback(dynCbCommand_Execute, callbackTwo)

The first time you run this command it will run the code in callbackTwo and switch itself to new code. The next time it will run callbackThree and the next time it will run the original callback code. It will then, with each consecutive invocation of the command, continue on in this loop. This plugin, as you have guessed, is just a demo of the dynamic callbacks.

The lines you have to concentrate on are the following:

from vg.xsi.dynamic import *

and

@dynamic

These are the lines that provide the core of the functionality which is imported from the vg.xsi.dynamic module. Here it is…

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

import sys
 
__all__ = ['dynamic', 'setCallback', 'callback', 'restoreCallback']
 
class Wrapper(object):
    def __init__(self, cb):
        self.__defaultCb = cb
        self.__cb = cb
 
    def call(self, *args, **kwargs):
        return self.__cb(*args, **kwargs)
 
    def setCallback(self, newCb):
        self.__cb = newCb
 
    def callback(self):
        return self.__cb
 
    def restoreCallback(self):
        self.__cb = self.__defaultCb
 
def dynamic(func):
    cbWrap = Wrapper(func)
    return cbWrap.call
 
def setCallback(bound, newCb):
    bound = _getCallable(bound)
    newCb = _getCallable(newCb)
    return bound.im_self.setCallback(newCb)
 
def callback(bound):
    bound = _getCallable(bound)
    return bound.im_self.callback()
 
def restoreCallback(bound):
    bound = _getCallable(bound)
    return bound.im_self.restoreCallback()
 
def _getCallable(req):
    if callable(req):
        return req
 
    if type(req) is str:
        g = sys._getframe(2).f_globals
        return g[req]

I’ve removed any comments or docstrings for the sake of brevity.

About Decorators

The import line I said was of particular interest. Well it is but only in the sense that it will allow you to use the module in which the features are implemented… Moving on quickly.

The real fun is with the @dynamic decorator. What is a decorator and what happens when we use one (or this one in particular)? Before we look at what a decorator is and does, let’s look at what happens when we define a function.

1
2

def func():
    pass

When a function is defined, what is happening is that an identifier is created in your current scope and this identifier is given the name of your function. Now let’s add the decorator. A decorator is just a simple function, but a function who’s purpose is very specific and a function that must return a callable (another function most of the time).

1
2
3

@myDecorator
def func():
    pass

What happens here is that the identifier func is still created but what lies ‘in’ this identifier is not the function itself but the result of passing said function to myDecorator. To help you visualize, the above code could just as easily been written like so:

1
2
3

def func():
    pass
func = myDecorator(func)

Let’s Get Specific

The decorator @dynamic takes your callback and wraps it inside a Wrapper object and returns the call method of this new object. When XSI tries to call what it thinks is just a simple callback it is actually calling the call method of an object that in turn calls your original callback. Whew!

This means that you now have the liberty of querying and editing the callback object and telling it to call something different depending on context. This functionality is provided by the setCallback, callback and restoreCallback functions.

These three functions either take the callback function objects or the callback’s names (as a string) as arguments.

There are some more particularities to this code such as the use of sys._getframe, the im_self attribute or the use of the call method on the Wrapper object instead of implementing __call__ but I think they might be outside the scope of this article. If there are requests for it I can expand in the comments or another post.

Meanwhile you can download the example. Drop the plugin into a plugin folder (user, factory or workgroup) and drop the vg folder somewhere in your Python path.

Cheers!

You all remember the idea of a proxy parameter where editing a parameter in a custom PPG (lets call this one the source) will in fact be changing another elsewhere in the scene (this one we will call the target). Extend this idea to a selection where selecting a source will in fact ‘transfer’ the selection to another object. This could be useful, among other cases, in a rigging scenario.

As it was suggested in the thread, there are many use cases for a functionality like this that can be addressed with native XSI tools and methodologies but nonetheless, I felt like there might be some cases where an actual proxy select could be useful. So I cooked one up for Bryan, and here it is.

Select one or more targets and then go to Get -> Property -> Proxy Select and then pick one or more source objects. From then on whenever you select a source object, it will unselect itself and select the targets instead. There is some sanity checking in there to try and avoid dependency loops and the like, just in case.

There are also three menu items in the MCP Select menu that will toggle proxy select functionality in six different ways.

• Toggle on proxy select for all objects – when nothing is selected
• Toggle off proxy select for all objects – when nothing is selected
• Toggle/Inverse proxy select state for all objects – when nothing is selected
• Toggle on proxy select for selected objects
• Toggle off proxy select for selected objects
• Toggle/Inverse proxy select state for selected objects

I can already hear you asking: “How can I select a proxy select source to toggle it’s functionality if it is already on and automatically transfers it’s selection?”

Well,

• If it is only one object you wish to toggle you can go directly to it’s Proxy Select custom property.
• If you wish to act on multiple objects with these toggle menus, you can multi select the objects and toggle them all together. When multiple objects are selected, no selection transfer takes place.
• This also means that you can multi select a proxy select source with any other object and then use the menu items, any object that isn’t a proxy select source will be safely ignored.

And then came Thiago

One of the people involved in the thread was Thiago Costa from Nervo.tv. He is actually the one who suggested an approach for creating the Proxy Select plugin in the first place. Well, about the same time I had sent Bryan my first draft Thiago posted his version. I said it in the thread and I will say it again, it is very nicely executed.

One of the things he did is that he anticipated the user’s needs and thought for a second about what you would like to do with the resulting select.

Something that happens to often (well for me anyway), and especially in the heat of production, is that we fail to properly establish requirements.

These requirement will inevitably change.

When the first wave of requirements is put down on paper some time should be spent trying to anticipate the user’s needs as well as possible future requirements. Even if these extra features aren’t initially implemented, having this foresight will allow the resulting code to better accomodate change.

Downloads

Check out the thread at Softimage|Net for Thiago’s version.

Download my version from here.

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/219#utm_source=rss&utm_medium=rss&utm_campaign=points-of-light http://www.softimageblog.com/archives/219#comments Wed, 06 Jun 2007 02:56:18 +0000 Vladimir Jankijevic http://www.xsi-blog.com/archives/219 Some time ago, I stumbled across the MapVIZ node in Maya and was surprised, that Softimage didn’t implement something like this in our beloved software package, XSI. Well, last weekend I decided to code it myself.

The first step to take, was to decipher the the file structure of the FG and Photon maps. Since the files are written in binary, this wasn’t that easy. But with the help of UltraEdit, a HEX editor for Windows, and some trial and error, the main file structure mystery was unveiled. Here is an example of how this looks like in a FG map:

The blue marked part is the file type and the version of MentalRay. The green part is a 32 bit integer value which is the total FG Point count. Next comes the FG Point itself. One FG point is represented in 104 bytes in total. That’s the first bright block. The first 12 bytes are the x, y and z coordinates in 32bit floating point numbers. And so on…

Final Gathering maps have another structure than Photon maps and thus it took me twice the time to build the file structure.

Once this was done, I had a little look into OpenGL programming and had a little talk to Andrea Interguglielmi. He helped me with the Logic behind the connection between XSI and OpenGL.

What this tool does is in fact pretty simple. When the plugin is loaded, it registers a new DisplayCallback and allocates some basic memory. Then, after you select a map and press on the “Show Map” button, it reads the chosen file and creates an array of position and color values which are stored in the memory and then displayed through some basic OpenGL functions.

With this tool you have the ability to view your saved FG and Photon maps in your 3D-Viewport of XSI. After installation, you can find it under Get-> Property-> JV_MapMiner. It is provided as is and nobody is responsible in any way for any possible damage.

I hope this tool can help people to optimize their renderings and make their lives a little bit more comfortable.

You can download the .xsiaddon (tested on XSI 5.x and 6.1) and a demo project with one FG map, one GI map, one Caustic map and one GI+Caustic map combined (27mb).

You are welcome to send me bug-reports or suggestions.

FG Quicktime
GI Quicktime
Caustics Quicktime

Buddha 3D-Model courtesy of the Stanford Computer Graphics Laboratory.

Missing Normals?

The normals weren’t missing per say. His geometry had deformations, displacement and bump mapping. In the render tree, normals could be accessed after displacement and after bump but we couldn’t access them before displacement to save our lives.

This is when we decided to create an XSI Operator that would convert geometry normals prior to displacement into vertex colors that could then be used in the render tree through a Vertex_rgba node. It did the job quite nicely.

Results

Here is a screen grab from a slightly mushed sphere with the Operator applied:

You can also view a quicktime movie (requires QT7) of a preliminary test of the sea recipe that uses this operator.

If you wish you can download the operator and dump it into your favorite Application/Plugins folder.

Get a poly geometry and apply the op through Render -> Get -> Property -> Normal Vertex Color

Cheers,
Patrick

Well, a colleague of mine, Etienne Pellerin, and myself are starting to work in C++ in XSI so the Jitter tool was rewritten.

New in Jitter v1.5:

• Installation is smoother – just drop it into your favourite Application/Plugins folder
• Performance is increased when you have large numbers of Jitter Ops
• You can now apply the operator to parameter groups such as kine.local.ori.euler

You can download the new version and beat the snot out of it if you wish. I can’t guarantee it’ll survive though, and if it doesn’t drop me a line and I can fix bugs.

I only have a windows version but if someone has a Linux box and would care to recompile I can host both versions.

Cheers,
Patrick

Lets start. One easy way to approach this problem is to create a mesh including all objects we want to envelope, and then simply set the envelope weights of all points of a single instance to the exact same weight, aka:

In this image we have a mesh with 6 cubes (all merged together) enveloped to a two-bone chain.
By default the weight is blended in the middle part,

which results in a deform for the middle two cubes:

by using the weight editor, I adjusted the weight of all cubes so they only target one bone:

which results in movement, but not deformation for each one:

So this is all working, why bother dealing with a system to deal with these things? Well, as long as we are dealing with six cubes it is all cheesy and simple, but as soon as we start dealing with something like feathers on a bird, we can’t just go in and envelope each feather with the weight editor, well, we could, but it would just take forever.

What I used to do in those cases is to build an instancer operator, which would take a mesh containing “where-and-how-to-instance” information, and a single mesh which is supposed to be instanced. First, lets clarify the “where…to-instance” part:

When instancing an object, all you need is a position, orientation and scaling, which can be stored as three points really, but in this example I am going to use 4 points:

1. Pos: The position of the object to be instanced
2. Cns: The Z-Direction of the object (seen from pos)
3. Upv: The Y-Direction of the object (seen from pos)
4. Bnd: An additional point to be used for deformation (later)

So basically we could draw a quadrangular polygon instead of four points, like below, where we are instancing ten grids:

Now: Instead of enveloping the objects we want to be instanced, we envelope the mesh containing the quads. This is going to be called our “Instancing-Cloud”. It contains all of the information we need to instance our objects. Moreover, it is easy to envelope, as we know exactly which points are to be enveloped where. Every first out of four points is the position, every second out of four points is the z-direction etc… All we need to build is a couple of scripts:

1. One which adds a quadrangle to a mesh based on a transform of a null.
2. One which creates a new mesh and instances an object onto an Instancing-Cloud.
3. One which generates clusters for the instance-cloud for easier enveloping.

A finished setup could look something like this: We see the quads representing the instances:

When deformed: The quads deform, but the instances will not:

Including the instances it should look like this:

When deformed:

As we have point clusters for each type of point in the instance-cloud (pos, cns, upv and bnd) it is quite simple to rig the cns for example to a bunch of rotational controllers:

And when we rotate them, only the cns points are deformed, therefore the instances rotate as well:

Additionally we can deform the cloud overall:

So now lets discuss the last part of the story: What’s the bnd position for?
The bnd position is used for deformation of each instance. As this is quite limited, all I am going to do is move the instances points using a sinus function, to get somewhat of twisting and bending going on. This is up to your imagination, as I said, this setup has been used for feathers, that’s why the bnd position is used for bending (and named like that as well: bnd = bending).

In the next image I rigged the bnd position to the rotational controller earlier used for cns, to show what happens:

So now when I rotate them:

Or along another axis:

As always – I’d like to share the progress so far, but I have to warn you, it is not at all documented:

Put the file into one of the plugins folders, and run the following script to get some feather setup going:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

NewScene(false, false);
var cloud = mt_createFeatherCloud();
 
var grid = CreatePrim("Grid", "MeshSurface", null, null);
SetValue(grid+".grid.ulength", 0.4);
SetValue(grid+".grid.vlength", 3);
SetValue(grid+".polymsh.geom.subdivu", 1);
Translate(grid+".pnt[*]", 1.4, 0, 0, siRelative, siLocal, siObj);
FreezeObj(grid);
 
var mesh = mt_createFeatherMesh(cloud, grid);
var feathers = new ActiveXObject("XSI.Collection");
for(var i=0; i<10; i++)
{
feathers.Add(mt_createFeatherNull());
feathers(i).kinematics.local.posx.value = i;
}
 
mt_addFeathersToCloud(cloud,feathers);
mt_createCloudClusters(cloud);
 
DeselectAll();

Let me know how it goes,

enjoy!

Well you can, these are called Phenomenon. A Phenomenon is group of shaders exposed to the users as a single entity. You can hide or show, as you see fit, any parameter of the enclosed shaders making a Phenomenon a very powerful tool for sharing shader recipes or building tools for larger productions.

The advantages are:

1. Have a more compact and readable rendertree.
2. Allow for only a set of significant parameters to be tuned by the artist.

Let’s see how it is possible to make up a phenomenon starting from a basic rendertree.

The Goal

The following network returns red if the x coordinate of the point is lower than 1, blue elsewhere. The picture should be quite self-explanatory:

In this case study we want to make a new node enclosing the four primary shaders of the tree, and exposing only three parameters: the two colors and the “threshold” value.

Creating Our SPDL

We need to create a spdl file, which will be later registered.

For those who want a bit of a primer, a SPDL file is a file that defines how XSI will display a certain PPG or Shader. Check the wiki page on SPDL for more info.

The first part of the file contains a header and the declaration of the parameters we want to expose. All the guids must be randomly generated, except the one identifing the output (color) parameter.

SPDL
Version = "2.0.0.0";
Reference = "{19671971-1008-0000-8410-6A45FDB990DD}";
PropertySet "PhenoTest_params"
{
    Parameter "out" output
    {
        title = "PhenoTest";
        guid = "{4C6879FF-7EC8-11D0-8E3B-00A0C90640EC}";
        type = color;
    }
    Parameter "threshold" input
    {
        guid  = "{19671971-1008-0002-8410-6A45FDB990DD}";
        type  = scalar;
        value = 1.0;
        texturable = on;
    }
    Parameter "color1" input
    {
        guid = "{19671971-1010-0001-8410-6A45FDB990DD}";
        type = color;
        value = 1.0 0.0 0.0 1.0;
        texturable = on;
    }
    Parameter "color2" input
    {
        guid = "{19671971-1011-0001-8410-6A45FDB990DD}";
        type = color;
        value = 0.0 0.0 1.0 1.0;
        texturable = on;
    }
}

The bottom part is also quite standard. It just defines the parameter’s defaults and their position in the layout.

BEGIN "{24810490-56FF-11d2-BF23-00A0C982CE5D}"

Defaults
{
    threshold
    {
        Name = "Threshold";
        UIRange = -10.0 to 10.0 by 0.01;
    }
    color1
    {
        Name = "Color 1";
        UIType = "rgba",4;
        Commands = "{F5C75F11-2F05-11d3-AA95-00AA0068D2C0}";
    }
    color2
    {
        Name = "Color 2";
        UIType = "rgba",4;
        Commands = "{F5C75F11-2F05-11d3-AA95-00AA0068D2C0}";
    }
}

Layout "Default"
{
    Name;
    threshold;
    color1;
    color2;
}

Logic
{
}
END

What interests us is the middle section, where you hardcode the connections between shaders. This is, in essence, the part of the SPDL where you create your mini Render Tree.

MetaShader "PhenoTest_declare"
{
    Name = "PhenoTest";
    Type = texture;
    Renderer "mental ray"
    {
        Name = "PhenoTest";

        BeginText

        Node "vector_state"      = guid "{BDE291C7-077A-11D2-8A1A-00A0C9892542}";
        Node "vector_2_scalar"   = guid "{A4F08C3F-AA3A-11D2-AFD4-00A024191B9D}";
        Node "scalar_math_logic" = guid "{4D9E6800-AC2F-11D3-AE56-00A0C96E63E1}";
        Node "boolean_switch"    = guid "{85C16046-BCFA-11D1-90E9-0000F804EB21}";

        Connection "vector_state::mode"	    = value 2;

        Connection "vector_2_scalar::input"     = "vector_state";
        Connection "vector_2_scalar::component" = value 0;

        Connection "scalar_math_logic::input1"  = "vector_2_scalar";
        Connection "scalar_math_logic::input2"  = interface "threshold";
        Connection "scalar_math_logic::op"      = value 2;

        Connection "boolean_switch::input1"     = interface "color1";
        Connection "boolean_switch::input2"     = interface "color2";
        Connection "boolean_switch::switch"     = "scalar_math_logic";

        Connection root                         = "boolean_switch";

        EndText
    }
}

Aching for more details? Read on…

My workflow was to write quick run-once scripts in the script editor, use curves and nulls to be sure that everything was ok and then write the scripted operator. But, if scripting is meant to make your life easier, this case makes you change your mind a bit. So I decided to take advantage of both c++ and scripting by wrapping some simple OpenGL drawing functions and exposing them to scripting.

Since the result seems to be quite handy, I decided to make this little utility available on XSIBlog. Lionhead, the company I work for, kindly allowed me to publish it.

So here is the ScriptedSequencer, a small utility to draw vectors and rotation axis on screen.

The tool uses a JScript object to wrap some c++ registered commands, you can use this object from Python and VBScript as well.

First get an instance of the object:

1

var s = NewSequencer();

then call one of the drawing functions:

1
2

var vec = XSIMath.CreateVector3(); 
vec.Set(0, 1, 0); s.DrawVector(vec);

to erase the stack and start again use:

1

s.Flush();

All the drawings are collected by the c++ plug-in and then rendered at the right time using the GraphicSequencer, so you don’t have to care about synchronizing with the viewport’s OpenGL rendering, which means in other words that you can draw OpenGL stuff from wherever you are, run once scripts, scripted operators or compiled plug-ins at any moment.

As it is nothing more than a debugging utility it doesn’t support multiple clients, it means that every time you’ll flush the stack all the drawings drawn by every script will be flushed at once.

By typing NewSequencer().Help() you’ll get a quick help about the sequencer object and its methods.

I hope you’ll find it useful to debug your scripts!

Please note that this utility is not released by Lionhead Ltd., it is not covered by any guarantee and nobody is responsible in any way for any possible troubleshoot.

Download the ScriptedSequencer addon and a sample scene here (XSI 5.X required).

You are more than welcome to report possible bugs or give me suggestions, just drop me a line at andrea@ray-t.net.