XSIBlog

Introduction

When it comes to discussing the future implementation of XSI’s new simulation engine, everyone has a vague idea of what should or should not make it through the next version.

We all agree it should be procedural, open to unlimited possibilities and of course, user friendly. The following article tries to stimulate a mutual reflection on these subjects by providing some ideas and questionings. It is not meant to be an in-depth review of the ultimate simulation software, rather a kick in our imagination’s butt, if I may say. This chapter shall become the conductor to my other articles on the dynamic matter until Softimage reveals its plans.

Procedurality

It is pretty weird to kick off an article with a word that doesn’t even exist, isn’t it?

Procedurality as we know it comes from the way to proceed and describes the method used to obtain a result. A procedural simulation system should represent a collection of rules and forms required to achieve a particular animation effect. As it seems to be an up-and-coming standard to have one global environment for all dynamics (that is, all kinds of dynamics sharing the same environment attributes), visual effect artists show more and more interest in working in one global graphical pane, in a procedural manner.

The node-based editor

As you might already know, the idea behind a node-based workflow is essentially to provide non-destructive connections between different particle operators, allowing one to mute, collapse or reorder branches of the tree. It’s also much more convenient for propagating values by granting an output connection to every individual’s state, at any point in the arborescence.

Say you’ve emitted some particles, applied gravity to them and animated their color as they slip down the Y axis. A well designed editor should let you pick the red value of the particle anywhere in the tree from the bottom of the simulation stack to the top raw condition. From a user point of view, it’s also plain better for keeping an eye on what’s going on in the scene with this kind of layout.

Simple examples of the workflow

I imagine a graphical representation able to display the members of different environments, as introduced in XSI’s explorer some time ago with rigid body dynamics. I imagine an operator tree inside an operator, sharing relations from the inside-out.

Improving what’s already there

Let’s say you’re building up from scratch a simple particle simulation for the first time in XSI. That should be easy enough right? You probably don’t want to assemble all the pieces of the puzzle yourself and waste precious time with what’s going on under the hood. Unlike a few well-known packages, XSI already provide a carefully designed interface for this. I guess the idea is to let the left simulation toolbar put things together and use the node-based interface for editing as the simulation shapes up.

One note though about the way one can go get a node and put it into play. It seems a bit awkward the way the render tree works; having to dig into the sub-menus is something that could easily ruin the workflow in particle dynamics. I can’t help mentioning the way Side Effects tackled this issue, by simply typing over the interface the first letters of the operator name.

Conclusion

Speed + workflow = way to go! That was nodal dynamics at a glance. There’s a lot potential in that area, but in the end, it’s only a matter of personal taste.

This entry was posted on Monday, August 15th, 2005 at 11:00 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.