What we’re more comfortable with eventually ends up being what we’ve learned first. In some cases XSI keys have been preserved in the Qwerty keymap. For example, if you’re used to pressing ‘8’ to open the Scene Explorer, it’s available on Ctrl+8 in the Qwerty keymap. The Model isn’t meant to fool anyone into thinking that they’re using M***, but it’s convenient for many users coming from M*** and M*x. It’s also convenient for us because we can experiment with a few changes in there without affecting the majority of XSI.

Now that said, the Qwerty Interaction Model changes the current keyboard mapping AND a few user preferences.

The biggest thing is changing the keying method to ‘Key All Keyable’. Keyable parameters are a very good thing, but keying them is not on by default in XSI. In this case, I’ll agree: focusing on keyable parameters instead of marked parameter and marking sets is an evolution of the Design Philosophy of XSI. We are not doing this only for the purpose of the Qwerty Interaction Model. Keyable Parameters are cool because they can help us simplify the user interface, for example by limiting the numbers of viewing filters. And yep, we have decided to name these animation parameters the same name that another application is using.

What Qwerty Interaction Model changes (compared to the “Softimage|XSI” model) :

Keymap is set to “Qwerty Keymap”

Save Key Command is set to “Key all keyable”

Camera Tool User Preferences

• Mouse Mapping is set to Alternate (orbit, pan, zoom)
• Use Alt Key is set to On

Transform Tool User Preferences

• “Click Outside Manipulator” is set to “Select Tool”
• “Show Selected Manipuators only during interaction” is on
• “Transform Hidden Objects” is on
• “Modify Object Pivot” is on

Selection Tool User Preferences

• “Click to Deselect” is on
• Rectangle Select: “Surround Polygons” is off

Display Options

• “Headlights” is on

Animation Editor

• “Selected Mode” is on
• “Prevent Movement on LMB” is on
• “Translate on MMB” is on (it’s also on in the XSI mode in 6.0)

1. A binary file called DSModalBrowse . It stores whether you are in List View mode or Thumbnail mode, the column settings for List View mode, and the position of the splitter bar. I’ve recommended user delete this file when the file browser crashes when opening. The problem it fixes is that perhaps an image in the current folder is making the thumbnail display crash, and deleting the file reverts the browser to List View mode. I haven’t heard of this problem in many years, however.
2. The binary file BrowserProperties store the favorites you have added manually with the button at the top left of the dialog. There is no real reason to delete this file. If your list of projects in the File Browser has become too long, it is the text file default.xsiprojects that you need to edit. Projects, addons, are not favorites. Favorites are in the button that’s at the left of the dialog, and not the Path button on the right.
3. In the standard user preference text file, default.xsipref. It stores the default position of the File Browser. You need to delete these four lines if you are switching between single and dual monitor setup, and the File Browser is opening off screen.
   xsiprivate_unclassified.DS_MODALBROWSER_B = #INTE#891
xsiprivate_unclassified.DS_MODALBROWSER_L = #INTE#479
xsiprivate_unclassified.DS_MODALBROWSER_R = #INTE#1442
xsiprivate_unclassified.DS_MODALBROWSER_T = #INTE#345


I apologize. :)

It’s my first post in here, so I take the opportunity to thank Patrick for this great XSI site!

You’ll find here some nice discoveries I made trying to use wxPython inside XSI. For that I will assume that you, dear Reader, have some knowledge of Python and UIs…

Animal Logic is also kindly giving you an example XSI Plugin that should be a good starting point if you want to implement a wxPython interface in XSI.

I apologize in advance for the technical and boring stuff ahead… it’s the unfortunate price to pay to get nice and shiny UIs!

You can download the plugin here.

But why would one do that, Custom Properties should be enough?

Mainly, the absence of a Tree widget, the clunkiness of the Grid widget, the need for finer control on callbacks for complex UIs, the difficulty of having session-persistent UI (ones that don’t get trashed on a New Scene).

The main goal of being able to write wxPython UIs inside XSI is for pipeline tools. I would not try to do better than Softimage for animation controls for example. But when it comes to streamline your pipeline, having consistent UI across your applications will save a lot of development time and user frustration.

Prerequisites

• XSI version 5.11 or 6
• WinXP 32 (win2k supported)
• Python (2.5 recommended, 2.4)
• pywin32 210
• wxPython (2.8.0.1 recommended, older supported)

A look at the plugin!

In the Python XSI plugin called wxPythonXSIExplorer.py I implemented a really crude XSI Selection Explorer. This is an highly useless tool, but it shows how this is possible to nicely interact with XSI using a set of basic wxPython widgets. Please consider the explorer itself as a proof-of-concept tool!

The interesting part of this plugin is the class called XSISubFrame. This is the class that implements all the gritty details described below, and I highly recommend you start your new wxPython XSI frame by looking at how I inherited from this class to create the XSIExplorerFrame. And how I use the XSISubFrame.create static factory method to create a new instance of the explorer.

I also implemented a SelectionChange event to detect the selection change in all the running instances of the wxPython XSI Explorer. Unfortunately there is no general hook for data change in XSI so if you move an object, the parameter value won’t update in our explorer.

And now for the gritty details…

The base trick to get a wxPython frame nicely displayed inside XSI, meaning on top of the XSI main window, but behind other XSI views when they have the focus, is to create the main frame as a child of the XSI top-level window. And for that we need to get its MS Window Handle.

The pywin32 package is here to help us: we can use it to list all the running windows and filter them by process ID, then pick the one which names begin with SOFTIMAGE. It sounds like a hack, but it’s just a small hack, believe me, MS Windows programming can get far more hacky than that!

The real magic happens when you use the AssociateHandle method on a dummy wxFrame so that wx believes that the XSI top level window is an actual wx window…

Then we just create our own sub frame using the wx.FRAME_FLOAT_ON_PARENT flag, which does what we want.

Then don’t forget to call DissociateHandle on your dummy frame, if not, XSI will not get some critical events anymore, like EVT_CLOSE, meaning you can’t close XSI anymore…

You will also need to do some cleanup when closing the wx window. The main problem is that wxWindow::Destroy does not destroy the top level window, it just waits for the
wxApp to destroy it on it’s next event loop. But as we don’t have a wx loop running, we need to destroy the top window by hand using the win32gui module again.

Some warnings!

wxPython is great, but it can crash easily if you do something wrong. In XSI 6 where there is no standard output from Python displayed in the script logging window (as there is in 5), it’s better to handle all exceptions, and display them yourself, or you might miss some important message from wxPython that causes a crash in the app (see line 370 of the plugin).

This is Windows-Only stuff for now!

Fortunately for Windows users, the wxWindows framework uses standard MS Windows event loop, and wxPython integrates amazingly well inside XSI. I haven’t tried under Linux, but the big problem over there is that wxWindows is using GTK as its UI framework, and I don’t think MainWin and GTK will go very well together unless Softimage builds a version of wxMSW using their version of Mainwin and give it to us…

BTW, wxPython works well in Maya as well, using the still experimental python for Maya plugin from cgkit, meaning that mixed pipeline could use the exact same UI in XSI and Maya!

Some native widgets have been “hacked” by Luc-Eric and his team to look better, the base TextCtrl is one of them. If you use it, its background will never refresh at all. I didn’t find an easy way of making it refresh. But you can get a nice text control by using the TE_RICH2 style, which has not been hacked. I provide a class called XSITextCtrl in my plugin that sets the style automatically as well as the background color.

Modality is a problem… The problem is that wx and XSI do not know well each other. If a wx dialog is shown modal, you can still work in XSI, and if a XSI dialog is shown modal (lik a new scene prompt), you can still do stuff in wx. And that could be really dangerous!

I worked around it by providing a custom showModalDialog method that disactivate the XSI top level window while the wx modal dialog is shown. And I implemented a EVT_ACTIVATE event to detect if there is a modal dialog running in XSI and I disable the content of the wx activated window until the top level window is activated.

This is not perfect, but it gives the right functionality!

Conclusion

This is surprisingly possible to seamlessly run wxPython UIs inside XSI!

I hope you will find some use to this and push Softimage to support this unknown feature, especially under Linux.

Have fun!

Aloys Baillet
R&D, Animal Logic

Material Libraries are not the list of material presets that Softimage ships with the software. We call those Presets, and they are presently organized them into Shelves of type “Toolbar”. (A shelf in XSI can contain a toolbar, a browser, or a Driven Shelf.)

Rather, Material Libraries are method for users to organize their own materials so they can reuse them, and maintain them centrally. The first clients for this are in games, which is a very large segment of Softimage users. In games, the material can be thought as an asset on its own that is distinct from the 3D objects. How many materials there are and how they are built has a significant impact, and the artist usually works with a defined set of guidelines. This can be also true in other segments, but due to performance constraints, it has been critical in games to reuse and share materials as much as possible. Materials could also need to be updated after the assets are have already begun using them.

Starting in XSI 4, when you applied a material to an object or a cluster, the material was first added as a source in the material library, and then added to the object as a secondary owner. This allows one to have access to all the materials used in the scene from the library. It also means that a material could now exist in scene without having been applied to an object or a group.

An XSI scene can use many material libraries, and the libraries can be “Referenced Libraries” which means that they are saved outside the scene, in a dotXSI file, and then modified externally without loading the scene. In that case they are also locked, which prevents the user from modifying these referenced materials.

In XSI 4.2 we introduced a relational view Material Editor. This view was created in collaboration with a large console game client in Japan, who eventually went on to develop an even more powerful, and a little hairy (imho!), version customized to their needs.

This view really tries to “fake Shader Balls”, and there are some limitation with that you can do with relational view and VBScript, so the Material Editor view is usable, but clumsy and slow, and we did not actively promote this view… In XSI 6.0 this view has moved to the SDK samples. It has actually benifited a lot “for free” from the changes we made to the Driven Shelves, as all similar custom views will.

But now in XSI 6 we have the slick new Material Manager.

The first thing the Material Manager does is show the materials in the scene organized by libraries. In order to get this off the ground, we added Shader Balls to XSI, and gave a big boost to the views we called “Driven Shelves“. These shelves, available since at least XSI 4.0, are views that show a list of icons for a given list of objects in the scene. They are called “driven” because a script must drive their content, so they are only found in Relational Views like the old Material Editor and the examples in the XSI SDK for this feature.

In XSI 6.0 the Driven Shelves have been extended to automatically show a shader ball for objects that support them, and checkmarks and lock icon to indicate used, shared, and locked materials. If the object has no user thumbnail assigned or a shader ball, the shelf now uses the same icon as Scene Explorer and the overall look has been enhanced.

Object on a driven shelf now have the context menu from the Scene Explorer, drag and drop for multiple objects is now supported, and the selection workflow has been enhanced to be more like the views in Windows’ explorer, including being able to type-in the first few letters of an object to select, and being able to rectangle select in empty areas. A “list view” display mode has also been added, which shows the label to the left of the icon instead of underneath it.

In the screenshot for this article, you can see a shelf at the top with the material, and one at the bottom, in the new List View mode, which displays where this material is used in the scene.

The shelves in the Material Manager also have quick filter similar to iTunes, which allows you to type in a string and it filters the content of the shelf as you type. This is a great way to quickly isolate materials or image clips by name, and you don’t have to use wildcards, although they are also supported.

The Material Manager was designed using large scenes, which were provided by game console clients, and we also looked at the custom solutions that the clients had created on their own using the Relational View services to see what were the problems they were trying to solve. We also had a lot of feedback during development.

I worked on this project personally, looking to create an elegant and simple UI design, while giving access to all the power that was required, by expressing the problem through a set of simple verbs. Basically, it’s about finding information quickly and making sense of a lot of data.

The view works from left-to-right, top-to-bottom. (should this be the reverse for our asian client? :-D )

In the left pane, you have access to a Selection Explorer that shows you what you have selected in the scene, and what material it has. We have added a new filter in the Scene Explorer that shows only objects, polygon clusters and their material, so you can quickly see materials at-a-glance without all the other nodes being in the way. With a click, or a drag and drop, you can assign a new material to part, or all, of that selection. You will select objects in the 3D viewports or any other means that seems appropriate.

The Selection Explorer can show “Local Materials” or “Inherited Materials”. These filters are also available in the full Scene Explorer.

The left pane also has the Image Clip Shelf, with thumbnails, can show All Image Clips, or only the ones that are Used, or Unused Image Clips in the scene. Those filters can be used to quickly find and delete all unused image clips.

The Image Clip Shelf is useful on its own but also can be used to drag-and-drop into to the Render Tree, or even the Image Clip viewer. The image clip shelf also features thumbnail size settings, list view mode, and again the iTunes-like filter to quickly find what you need.

You can quickly create a batch of image clips by drag and dropping images onto that shelf, or right into the 3D viewports. (In previous versions, drag and dropping images into the viewport only created image sources, which would require another step to create an image clip.) The Image Clip shelf will immediately show thumbnails for those new images.

At the top of the right side is the Material Shelf, which can show either “All Materials”, “Used Materials”, “Unused Materials” or show only the libraries and materials that are highlighted, for example by using the Highlight From Selection button, or when you select an object from the Scene Explorer.

You can drag and drop shader balls to move materials between libraries. Select one material and use the Render Tree or Texture Layer Editor below to edit the material. There are buttons to duplicate, delete, highlight from selection, assign to selection, and launch an eyedropper tool in the viewport that can be used to highlight cluster materials on a selected model by moving the mouse on top of them.

Select one or many Materials in the shelf and the Image Clip tab will show all the clips used, and the “Who Uses” tab shows all the objects that use this or these materials. The Who Uses tab understands groups, passes and partitions and will show them as the correct users and not, for example, all the objects inside that group. It’s immediately obvious why driven shelves need to use the same font and icons as the Scene Explorer, and we hope in the future to have more graphical query tools like this.

If you click an object in either of these two tabs, it is selected in the scene so you could delete or group them, for example.

I have no doubt that, in time, users will find all the cool workflow tricks that this view is capable of. As scenes are getting bigger and more complex, we are working at creating cool & slick new tools to get to your data faster without having to call on the local scripting guru for a custom solution. The Material Manager is only the first step.

Enjoy,
Luc-Eric
Senior Principal Engineer/Team Lead
Softimage User Interface

First and foremost, only the user preferences that are different from the factory defaults are saved. This was partly done to allow overriding a user preference with a workgroup user preference file.

They are saved in your user account, which for historical reason is in c:\users in Windows, in a file called default.xsipref. This is an ASCII file you can open and edit in Notepad.

One window that’s often overlooked is the grid control that is displayed when you open the User Preference window. You can sort by columns; if you click twice on the last column, all the user preferences you have modified will be grouped at the top.

One trick that very few people know about is that you can right-click on a user preference family and choose “Restore Default” to reset that group to the factory defaults.

This is a real life-saver if you have been playing around with the Scene Colors and now you don’t know how to put it back. Resetting them this way will only change back the Scene Colors and will not change anything else.

Pretty much everything that is remembered from session to session is saved in that user preference file. One exception are the settings for the file browser dialog. These settings are saved in a binary file in your user account called “DSModalBrowser” and include the size and position on screen of the file browser and list view or thumbnail mode setting (but not the thumbnails themselves).

If you switch between a dual monitor and single monitor and the file dialog is offscreen, or the file browser crashes in thumbnail mode, simply delete this “DSModalBrowser” file to reset it to the default settings.

This article discusses some aspects of object model programming and also serves as a tutorial to design your own code to look and behave like the XSI Object Model. I will talk about Python, classic classes, operator overloading, and code design. I will re-implement at a part of the XSI Object Model in Python.

INTRODUCTION

For some time I wondered how exactly is the XSI Object Model working under the hood. More precisely, I was not interested in the details of the C++ implementation, but rather how I could design my own code and data structures in Python so I could “navigate” these data structures the same way I navigate the XSI OM. For example, I wanted the ability to do the same thing as Object.Properties("Property Name").Parameters("Parameter Name").Value, but with my own data structures instead of XSI’s.

The only problem is that I didn’t really have a need for this, it was merely curiosity. I was thinking “maybe some day…”. But recently, while working on a rather large scripting project, I ran into a wall. I felt that it could be the right time to experiment with the idea. I have this library of scripts that use a significant amount of constants from the same file. Over time, that file had become a huge mess: highly fragmented, disorganized, very long. Thus, hard to maintain. Beyond a major overhaul, I wanted to hide all the data (many lists and dictionaries) and have a really simple, clear and clean way to access it.

After a bit experimentation, I have found some ways to accomplish this, which I shall present in this article. Keep in mind this is by no mean an exhaustive study, I don’t intend to present the guide to replicate all the features and behaviors of the XSI Object Model.

WHY PROGRAMMING OBJECT MODEL

The decision to implement the object model in my code is entirely personal. In my experimentation, my goals were simplicity, clarity and readability, nothing else. These goals were driven by a need to organize and sanitize a part of my script libraries. As of this writing I have not made any measurement of memory and resource usage as well as performance.

1. DISCUSSION: DATA VS INTERFACE

Very early in the experimentation process I realized that the XSI Object Model is in fact only a user-friendly programming interface. However, I started with the assumption that the XSI scene and the data it holds was some sort of giant data structure that was organized exactly as the Object Model hierarchy.

If you look at some old XSI SDK documentation (like in XSI 3.5), the object model hierarchy is presented with diagrams made of red blocks. From such diagrams, one could be led to believe that each object, each part of that hierarchy, is actually holding fractions of the data of the scene. Also, the fact that the Object Model closely resembles how the scene data is structured in the Explorer view can only strengthen this belief.

It turned out that the exact structure of the data, when navigated through the Object Model, is highly irrelevant for the user. It could be arrays, dictionaries/hash tables, strings, classes and instances, whatever. The only thing that matters is to have structured data, and preferably consistently structured. From that point, one can build an object model interface to read and write this data.

But this is the XSI Object Model. In the XSI SDK, the “raw” data structures are hidden from the user. From scripting, you either use commands or the Object Model to work with it. But now I’m creating my own Object Model, with the data structures behind it, and I decide how the two work together.

In fact, designing the data structures would be the first thing to do. I see two main designs for data structures:

Data as member of classes
This design is one of the principles of object-oriented programming. Data and operations are both members of the classes they relate to. Methods that read or write the class data don’t need to lookup other name spaces than their own local scope. Each class has its own predefined data. We can talk of an homogeneous design.

Separate data
This design goes against the previous one. Here, the data-structures are kept completely separate from the classes. The programmer defines “rules” for the class and its methods so that they read and write data at the right location. We can talk of an heterogeneous design.

In the project I have worked on and will discuss later, I chose the second design rather than the first one. The reason is that I wanted all the data to be consolidated in one place (the top of the file). Because it is not scattered across many classes and without any class decorations, I can look at it quickly. It also allows classes to be kept compact, which enables me to look at these quickly. In this particular case, I find this design clearer and easier to maintain.

So how are the data structures designed exactly? Are they lists, tuples, dictionaries, or else? In my case, I used a combination of lists and dictionaries. In fact, for every dictionary there is a list. Dictionaries hold the values, and lists are there to sort the dictionaries (in Python, unfortunately, a dictionary cannot be arbitrarily sorted).

Now that I have talked about the data structures, let’s talk about the interface.

Since the data is completely separate from the interface (the classes), and that this data is exposed through dictionaries and lists, why bother at all with making an interface? Isn’t using “traditional” means of reading dictionaries and lists sufficient?

Indeed, using typical dictionary lookups and list indexing is perfectly acceptable:

1

print dGRANULES['vertexcolor']['clusterchannels']

or, through iteration:

1
2
3
4

for sGranuleType in dGRANULES:
    print sGranuleType
    for sClusterPropChannel in dGRANULES[sGranuleType]['clusterchannels']:
        print sClusterPropChannel

There is nothing wrong this this. However it may become convoluted with deeply nested dictionaries and lists. For example, one of my classes has this somewhat deep data structure that causes the code using using it to look like this:

1

self.dClusterProperties[sPropertyType][oObject.fullname][0].add(oProperty)

At this point, readability and clarity are starting to take a hit. Such a line of code is subject to misinterpretation. In other words, scripting errors, even for me. The data structure must be strongly documented (a data graph is hardly avoidable), and the coder can spend considerable time reading that graph. Such a graph might look like this:

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

"""
dictionary
    { cluster type (string) :
        property-file map (dictionary) {
            parent3dobject.fullname (string) : [
                XSICollection( cluster props ),
                asset internal ID
            ]
            parent3dobject.fullname (string) : [
                XSICollection( cluster props ),
                asset internal ID
            ]
            ...
        }
    }
"""

(I don’t recommend using such documentation ethics, this is just the kind of doc string I put in my code to help me program fairly any deep/complex data structures)

Also, maintaining scripts that access that kind of deep data structure with traditional means can prove problematic if the data structure design is modified.

Ideally, getting back to the first example, something like this could be preferable:

1

print data.granules('vertexcolor').clusterchannels

or, through iteration:

1
2
3

for oGranule in data.granules:
    for sClusterPropChannel in oGranule.clusterchannels:
        print sClusterPropChannel

Not especially shorter, but a lot clearer. Such style may prove useful in the context of deep data structures, as in the second example:

1

self.clusterproperties(sPropertyType).objectnames(oObject.fullname).properties.add(oProperty)

Again, not significantly shorter, but a lot easier to read, understand, and maintain. The big advantage is that while the programmer makes modifications to the underlying data structures, the top-level interface can hide those changes. Of course it’s not always as easy as it sound, but it least it gives the programmer more chances.

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…

I have written a codec which allows QuickTime to read .pic files.

A few people have manually associated .pic files with the XSI flipbook or another viewer, but most people have them associated with the QuickTime Picture Viewer by default.

Installing this will not change your current file associations, but will allow the Picture Viewer to view .pic files when you double-click them instead of being greeted with an ”Unknown Format” error, caused by QuickTime thinking these are Apple PICT file.
It’s not necessary to have Softimage installed on the machine, this is completely self-contained

Content of the Package

• SoftimagePic.qtr
• SoftimagePic.qtx
• QuicktimeTestPic.pic
• Install.bat

Double-click Install.bat, which will copy the three other files to %ProgramFiles%\QuickTime\QTComponent, and will launch the Picture Viewer on QuicktimeTestPic.pic to verify the installation.
On Windows Vista and up with UAC, don’t forget to use Run As Administrator for the batch file, otherwise it won’t be able to copy the files.

I am not aware of any installation problem, but if somehow QuickTime isn’t finding the codec try to log out and back on to restart it.

Batch file hackers might be interested in seeing how I got the batch file to work from UNC drives, which isn’t supported by cmd.exe, or testing if the command prompt is 32-bit or 64-bit.

SoftimagePicCodecWIN1_2.zip (69k)

Preliminary OS X Version

Here is a Universal Binary port of this codec for OS X 10.4 (Tiger).

It will allow the QuickTime Player and other QuickTime-enabled apps to load Softimage .pic files. Unfortunately, this will not work in Preview or Finder previews as they by-pass QuickTime for .pic files and use an undocumented Core Image image mechanism instead. It is best to re-associate .pic files with the QuickTime player instead of Preview to allow easy double-click viewing of images. Please read the instructions contained in the installer.

The file contains a disk image with an installer which simply copies the component to /Library/QuickTime. A restart of the system is necessary at this time for the component to be detected.

SoftimagePicOSX.zip (128k)

1. Shift+Click and drag to create a region around the keys on the timeline
2. Shift+Double Click to select a single frame
3. Hold Middle mouse button and drag that region to move keys
4. Ctrl+Drag on that region to copy keys
5. Middle Click on the extremities of the region to scale keys
6. There are some more timeline options in the right mouse click menu
7. You can view an audio wave in the timeline if you have an audio clip in the scene.

In a recent XSI 5.0 introductory book, I’ve read something that goes like this: ‘Users of ‘the other program’ may turn on an option called ‘Transform Manipulators’ in the MCP['.]‘. That comment raises an interesting question’ The question is, who are the users coming to XSI and where did they come from? The book had noted that manipulators are ’slightly miss-named’ because they’re visual indicators and aren’t really used to manipulate (which is true only if they’re turned off). It is also recommended to turn off sticky keys, setting Nil Tool as the default tool, and Softimage|3D Selection model.

These suggestions are ok, but these are the settings used for people coming from Softimage|3D, and they are not the default and recommended options in XSI. Which leads to another question: What exactly do the people who make XSI want to you to use, and how is the application actually tested and designed?

——————————————————————————————-

First thing, everyone who uses software gets used to them and do not want to change unless they absolutely have to. For software developers, you’ll have people who still use Emacs or vi even when there are better editors out there. But the vast majority of people do move on as the tools move on, and it isn’t clear that one is actually more productive than the other. It all seems to be about muscle memory and personal habits.

In the world of 3D it’s in my opinion a little worse. The main reason is that the main tasks have been completely different between applications. In a text editor, once you start typing text everything is the same as in every other applications; it’s the auxiliary tasks that change, like searching, copy/pasting, saving files, those that take a small percentage of the time. The major tasks seem to be different between 3D applications.

However, the language isn’t actually that much different between 3D applications as it first appears. The application that sticks like a sore thumb, here, is Softimage|3D. Softimage 3D is the only application that you’ll likely encounter on your computer where you need to hold down space bar and click to select something. Why that is, and what were the benefits to that, the original designers are not here to tell us. It might have simply been easy to program ‘ that’s the reason behind too many user interface items people have gotten use to. (Seriously, at least the “edlin.exe” guy can”t have had a good reason.)

I remember years ago before Avid acquired Softimage, we were looking at Media Composer and couldn’t understand why you couldn’t click a clip on the timeline and drag it to another location. That’s just the way it was, and some users were freaked out that you could ‘mistakenly’ move clips on the DS timeline with your mouse. That’s just the way these people were trained.

Now, when we designed Sumatra/XSI we designed it looking at the present and future, not backward. It was blissfully obvious then as it is now that anything you see on-screen, you should be able to click and move it.

When you introduce a backward muscle-memory patch such as the ‘nil tool’, i.e. a tool that does nothing when you click in the 3D view port, you’re satisfying an immediate transition need at the expense of the global interaction flow of the application, and the experience for users without that muscle memory.

One thing to keep in mind that in Softimage|3D, EVERYTHING required you to hold down a key and EVERYTHING worked the same. In the function curve editor, for example, you needed to hold down M to move keys. You couldn’t just click and move a key. Everything was very consistent.

XSI however, was designed with modern user interface elements and concepts. This includes standard controls like edit boxes, list views, the tree view in the Scene Explorer. Most of the muscle memory from Softimage|3D are incompatible with modern applications controls, however this does not bother old time users because they are used to dealing with inconsistent interactions as they switch between applications. New users should not be subjected to this.

Maya was also designed as a modern application, Alias have had a strong user interface design group and Max of course has been designed as a true Windows app (after years of dreadful DOS user interface).

The question at the top was: are developers admitting defeat when we are offering keymaps for users by other applications. The answer is: No. 3D applications are converging toward the same workflows and manipulations. These basic tasks isn”t where XSI will shine, it’’s in the more advanced stuff that it will.

We don’t really care if you use ‘S’ or ‘ALT’ to navigate your camera, or ‘W’ or ‘V’ to activate transforms, it ends up being the same. Past that, into the actual organization of the software, we do not intend to imitate other applications, because we believe that our organization does provide significant benefit, and it’’s our identify. Using the Z key over ALT, however, we don’t really care. The only issue is that the tutorials are harder to follow.

All applications are converging. However, Softimage 3D is quite a bit outside that convergence line, so if you’re using the compatibility switches we put in, you’re not really using the XSI we are building. The best thing you can do is use it with the default, and tell us what are the problems with these tools.
——————————————————————————————-
Manipulators are interesting issues on their own. XSI does not have manipulators to please Maya or Max users; it has them because we strongly believe that this is the future of human interface. It was in the Sumatra/XSI plans from day zero.

They have been around for about 15 years now, first in research and now all applications use them at one level or another. We’re designing our application around manipulators and are an active part of the collective research the industry is doing about them. Each application brings the concept and workflow a little further.

On the other hand, the Softimage 3D interaction has nowhere to go, and nowhere to grow. It’s based on having 3 mouse buttons, with one button for each axis, plus a series of settings on a separate panel to control its various settings. It’s a done deal.

Our philosophy about manipulators is simple and the same as other tools. If they don’t do the job in some cases then we need to fix them, not hide them. In the future we will likely be more aggressive about this.

If for every new user interface element we add to XSI, we have a switch to revert it back to the way the application was in 1995, then XSI will never go forward. Some great feedback we get now days are from people who have given up on Softimage, or have always been with another application, and are coming to us with a fresh look at what we are doing. They’ll ask, why is this? For example, why can’t you select keys directly in the DopeSheet? Sometime we must say, it’s because it was that way in Softimage|3D. It doesn”t necessarily bother the old timers.

Already in XSI 5.0, we made a very bold move. We changed the default Move Point tool! The M key, which has worked the same since 1994, was changed into the Tweak tool. We’ve also unitified the ‘S’ key for navigation in the various views. Sometime this broke an habit, but we think the trouble is worth finally having consistency; it’’s for the greater good.

So does that mean that XSI will be abandoning its legacy? No. The Softimage 3D keys and workflows in XSI that are there ‘ there are already serious holes if you expect the app to work like Softimage|3D ‘ will continue to work, but fewer and fewer people are going to care about them.

It will happen naturally; the goal is not to remove tools, but rather to offer something that is worth dropping the old habits. For example, the Tweak Tool is worth it. And manipulators? Well, supporting not using manipulators for the basic S, R, T is trivial, and we will never remove this ability. However, we do want to create more and better manipulators and make users switch to them because they are worth the trouble of changing the habit. Obviously we need to continue to work with users for this.

Already, most of Softimage|3D is gone, only some broken memories remain. In the first year of XSI, people complained that we were using Windows menu and they were not like the ones in Softimage|3D. Recently, people have complained that we do not use exactly the standard Windows menus’ time change.

In future releases, in addition to doing the obvious and looking at new things, we will also continue to move forward in traditionnal tool areas like the Dopesheet, the Schematic, and more.

We are not going to stand still. Some applications may need a total rewrite to move forward, but we’ve built XSI to move be able to grow for many years to come.