XSIBlog

Introduction

Hello and welcome to the second part of this article!

I’d like to introduce the following concepts as the result of procedurality, an extension to the non-linear workflow discussed before.

During our career, we have, and we will share quite a lot of production time with co-workers from different backgrounds, with different philosophies and ways of working. We keep learning from each other and I wish that in a perfect world, the tools that we use were crafted to serve the imagination of every one of them.

Doors wide open as a standard

First, is it conceivable to implement a GUI able to manage a whole dynamic engine serving everyday production needs to big scale hero shots out of the box? Answer: It has to. And to be 100% honest, I find XSI to be the most favorable product for this challenge. The point being to give non-technical users everything they need to create quickly, without of course limiting the more technical ones.

Quick anecdote: when we made the switch from Soft|3D to XSI, I recall some people complaining about the intermediate conversion nodes in the render tree. You know the ones that get automatically created between a color and a vector or a scalar to an integer? Well, they’d probably be shy talking about it today considering how indispensable they are for somebody earning his daily bread from shaders!

Another question is: could scripting be completely avoided if a simulation language was implemented into an appropriate graphical support? I am not sure I can answer that question but in fact, I doubt it could. However, the render tree shows us a good example about this. It grants the user with a vast library of operations, allowing him to interact as close as possible with Mental Ray. A good ruled-based dynamic system, on its end, should work similarly except that instead of returning the intersection point, should reach an individual then its attribute then pass its modified value down the tree. It’s the pixel-parser for dynamics!

One sure thing is that there’s a huge amount of connections and attributes behind any simulation engine which leads us to ponder upon opening vs. user friendliness.
The way that workflow is implemented should be the result of the combined knowledge of the artists who use the software and the one engineering it. Dynamic addicts, please speak up!

Customizing the rules

Softimage came near to this with the arrival of pEvents. Along with some pre-defined conditionals and user-defined attributes, they represent a big step forward to a rule-based dynamic system. Unfortunately there has been a bit of laisser-aller in their development. Anyone willing to push the practice further noticed that he quickly hits limitations, forcing him to get back to scripting. Unless you’re scripting savvy, you probably want to see conditionals exposed as logical operation nodes and then piped in attribute overrides.

On the other hand, nothing should prevent one to script his own functions for attributes, forces, triggers or any kind of interaction with the scene objects. One should be allowed to branch scripted operator nodes, acting as procedure calls in the tree while being able to communicate between each other by the mean of variables global to the environment.

Conclusion

It seems that we just skimmed the surface of the topic. Other subjects such as the performance cost, the open architecture of caching files, the SDK, simulation seeds and the connection to the rendering engine would have all been appropriate matters of discussion.

This entry was posted on Tuesday, August 16th, 2005 at 6:29 pm and is filed under Simulation, Thoughts. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.