PPG Based Particle Animation Work Flow With ICE

August 7th, 2009 by Hans Payer - Viewed 14470 times -




About a year ago already, XSI 7.0 was released with much expectations and enthusiasm. Most of us, by now, have played with ICE and if you’re lucky, you even had the chance to squeeze an operator in a real production. Everyone is still marveled when new videos are posted online showing the latest tricks or achievements made with ICE. ICE is an amazing design tool and definitely opens many doors for all Softimage users. But for many, they hit a wall; in order to create even the simplest simulation, they have to learn the meaning of vectors, scalar, arrays and how to use them. If you do have the technical chops, great, new things to learn, but for the more artistically skilled users, the hill is steep.

Everyone complained (including me) that the old particle system was too weak, too limited…. But it was fast to get some things done. To randomize a value, for example, you simply had to open a property page and set a variance parameter. Partly because ICE is so open, to vary a parameter, you have to search for the desired compound or node modifier, drag & drop, connect ports and then set values in the new compounds. Read me right, ICE is very powerful but if you have to modify dozens of parameters hundreds of times in one typical work day, this work flow becomes redundant an inefficient. There must be a way to be quicker.

Softimage proposed a work flow that can be described as follows: a technical director connects basic nodes, designs compounds and exposes ports. An artist, who is not necessary knowledgeable of ICE, then sets the different values of the exposed parameters. Some problems may arise with this approach. How can a TD predict every alteration needed by the artist? In the context of a particle simulation of falling rain, for example, a TD may have to design his compounds to support, for a simple shot, wind and gravity. Then, another shot may require water splashes from the droplet hitting the ground. Another still, requires the same rain but with the added effect of coagulating droplets on a smooth surface. And so on. You can easily imagine multiple variations of the same effect. So how are TDs supposed to tailor their compounds to fit all of the artists needs? One obvious solution is to build a system of compounds rather than a top level one. Yet the artists would need to be taught and learn how this system works and therefore, learn how to use ICE. Yes, maybe… but unlikely. I know many technical XSI users that were clueless on how create a simple simulation; artists, even less probable. How can technical directors empower artists without limiting them with a simple set of parameters? There should be a window to deliver the power of ICE to artists without being too painful. Artists should be able to easily create simple particle animation. You do not need to be a mechanic to drive a car.

With these observations in mind came the search for a way to simplify the ICE work flow which any Softimage user would understand and produce simulations in no time. The intent is not to replace the current work flow but to complement it and accelerate the multiple iterations needed in order to design particle simulations. Subsequent refinements, complex connections or relationships can and should be achieved the traditional way by connecting nodes and compounds in the ICE tree. But once a new solution is found, it should be easy to re-integrate it in a simpler work flow system. It should also be seen as an added value to cut the time to help generate about 75% of particle animation scenarios.

You do not need to look very far to find solutions. By simply looking at the different ways shaders can be modified, it is easy to wonder why ICE property pages were not designed the same way. Isn’t it faster in many situations to create connections by using the plug icon in a shader’s property page rather than opening it in the render tree, dragging and dropping a node, then making the connection? It should be the same in ICE property pages. No?

dk9zhxb_72gnm2jkfk_b

Also, all parameters affecting the simulation should reside in the same property page. With a typical ICE tree containing easily 20 compounds or more, finding a parameter often requires a search through many compounds. Too many doubles clicks are required to access the compounds’ parameters; why not put them in one location. When a scalar is randomized for example, the parameters associated with randomization should replace the original scalar in the top property page. You say: isn’t the top compound intended for that? Yes, but it doesn’t expose ports automatically. Remember, the goal here is to create particle simulations in a production environment; not to design ICE trees in a R&D context.

dk9zhxb_73fgm8zwtz_b

In the following video, I demonstrate a working prototype. It shows the above ideas in action with the exception of having iterations made through parameter contextual menus instead of the plug connection icon menu. The Softimage development kit does not give access to this type of UI widgets for ICE compounds property pages. Also, for clarity’s sake, it would have been beneficial to have used tabs in the property page to seperate emission, particle type, forces, triggers and events. This was not implemented. This prototype was written about a year and a half ago with a beta version of XSI 7.0 and unfortunately has not been updated to work with the current version of Softimage but would be relatively simple to rewrite. I must also credit my colleagues at the time, Jeff Wilson, who helped with the original concept and Javier von der Pahlen who co-wrote the prototype. It is important also to say that I was an employee of Softimage at the time when that prototype was written. As a long time user of Softimage’s products, I was trying to push solutions that made the work of technical directors easier. Unfortunately, this concept was not accepted. But it remains a great concept on how technical directors can go beyond compounds and integrate ICE in production pipelines more efficiently. It clearly illustrate the ability to build a simple particle animation rapidly without having to access the ICE tree. All iterations are made through the property page.

I simply wanted to share these ideas with the Softimage community and start a discussion. As, hopefully, more and more people will be using ICE, I’m sure that work flows will evolve to more efficient ways to manage ICE trees. Maybe it’ll lead to similar solutions, whether it comes from Autodesk or the community. I think it’s really cool concept and it would save many users time and headaches. What do you think? Is this type work flow worth exploring?

PPG Based Particle Animation Work Flow With ICE from Hans Payer on Vimeo.

15 Responses to “PPG Based Particle Animation Work Flow With ICE”

  1. Hans says:

    If anybody is interested, I can email them the source code. Like I mentioned in the article, it needs to be updated to work with the current version of Softimage. We originally wrote it in JScript, but if I had to rewrite it, I would do it in Pyhton.

  2. Steven Caron says:

    great work hans and javier! i can see how useful this would be for the masses.

  3. Really useful Hans, thank you for not only doing this, but writing up a description and a tutorial video.
    Excellent work!

  4. Terry says:

    Hi,

    Yes I can see why it was initially not there, but now as time goes on I think this kind of tool is going to be more and more important, ‘exactly’ because of what you say in your text. Great work.

    So yes do email me.

    Cheers
    Terry
    LetterboxAnimationStudios.com

  5. gavin h says:

    nice work.

  6. Luc-Eric says:

    Cool, it was a good idea to post this

  7. Touffe says:

    i find it this very usefull…hope to see this feature implemented in ICE.

  8. Nick says:

    Hi, I understand the issues in the workflow mentioned above, but I disagree with your assertion that it will be more easy to create connections by using the plug icon in a production pipeline, or rather that there are great benefits in that.

    I’ve worked with LightWave, 3DS and XSI. And one of the reasons why 3DS infuriated me so much is the propensity to have windows nested upon windows some with na,es only 3DS users understand, lightwave had a similar problem but it is a lot more structured and space efficient than 3DS. The node graphic environment of XSI may be time-consuming at first but it is a lot more user friendly to create, organize and to read (very important when there is more than one person developing the particles)than the nested windows system of the other softwares. Furthermore, and this being crucial for me, there are two major problems in creating a system that simplyfies the choices for the users. One is that by simplifying the choices you ussually reduce their ability to manipulate them, I understand this affects more the TD than the artist but here ICE also offers an excellent solution, personalized compounds. the other mayor problem is that users get accostume to the nomenclature of the simplifyed system, which more often than not do not translate to the actual functions, and soon enough you will have people talking about “randomize the speed of the particle”, when in fact they may be saying “turbulize around value the initial speed of the particle.” This may sound a minor issue but it will only become more problematic as more functions get added to the particle system.

    Your option is tempting to explore only as an added function to the workflow described by Softimage”technical director connects basic nodes, designs compounds and exposes ports.” In other words it would be nice to expose windows as a switch goes on or off, or maybe to have a user friendly PPG compound, but the overall function of the ICE tree should not recreate the same problems that other particle system have.

  9. Hans says:

    As I wrote this should not seen as replacing the ICE tree; simple complement it. I don’t imagine having to manage a tree solely with plug icons. But if you can save a considerable amount of time with the original setup, I believe there is an important benefit. I’m convinced at one point we’ll see TDs wanting to accelerate trees creation and this is just an example.

  10. Lone Deranger says:

    ICE is very powerful, but working with it right now is still too technical and overwhelming for many. Mainly because of it’s unbridled power. It’s like trying to drink from a fire hydrant.
    I would love to see something like this complement the current methods of working with ICE.
    I’m convinced it would aid less technical/more artistic minded users of Softimage into getting acquainted and comfortable with ICE. Let’s hope the SoftImage development team considers this.

  11. Christopher says:

    This is an excellent idea, I’m finally reading more do think the way I do :)
    Nice idea, if the ICE nodes could be written in a way, Artist could brace it and Technical directors could enhance it making a beautiful harmony.

  12. LaurenceDodd says:

    I would love to have this, as I am a complete ice klutz and though I can get there, it seems to take me a long time compared to the old particles. I hope you keep it up.
    Cheers

  13. Joe Zeno says:

    I find it’s a good thing to have two “ways” working in ice, can’t be wrong :)
    Good work :)

  14. Cho Min says:

    I don’t know what should i say it was just I understand the issues in the workflow mentioned above, but I disagree with your assertion that it will be more easy to create connections by using the plug icon in a production pipeline, or rather that there are great benefits in that.

    I’ve worked with LightWave, 3DS and XSI. And one of the reasons why 3DS infuriated me so much is the propensity to have windows nested upon windows some with na,es only 3DS users understand, lightwave had a similar problem but it is a lot more structured and space efficient than 3DS. The node graphic environment of XSI may be time-consuming at first but it is a lot more user friendly to create, organize and to read (very important when there is more than one person developing the particles)than the nested windows system of the other softwares. Furthermore, and this being crucial for me, there are two major problems in creating a system that simplyfies the choices for the users. One is that by simplifying the choices you ussually reduce their ability to manipulate them, I understand this affects more the TD than the artist but here ICE also offers an excellent solution, personalized compounds. the other mayor problem is that users get accostume to the nomenclature of the simplifyed system, which more often than not do not translate to the actual functions, and soon enough you will have people talking about “randomize the speed of the particle”, when in fact they may be saying “turbulize around value the initial speed of the particle.” This may sound a minor issue but it will only become more problematic as more functions get added to the particle system.

    Your option is tempting to explore only as an added function to the workflow described by Softimage”technical director connects basic nodes, designs compounds and exposes ports.” In other words it would be nice to expose windows as a switch goes on or off, or maybe to have a user friendly PPG compound, but the overall function of the ICE tree should not recreate the same problems that other particle system have.

  15. Debdas says:

    Hey Buddy,

    I will definitely appreciate your effort… great work..
    it will be great if you publish your script and put a video to tell everyone how to manipulate the PPG according to our own choice in that script.

    I will love to give extra time to read your script.

    Cheers