Customizable Attribute Distribution in Simulations
August 18th, 2005 by Vincent Fortin - Viewed 3849 times - Popularity: 8%Introduction
What is attribute distribution?
It is the way a different value gets spread among every member’s attribute of a simulation, at birth. It is one of the most important (and often neglected) aspects in faking real-life behaviors. I would like to demonstrate its importance through some workflow ideas brought in this article.
A few examples of distribution are:
- setting the mass value in a fractal distribution fashion between 1 and 10
- setting the initial xyz velocity values from the rgb components of a map
- setting a different texture clip or shader attribute according to a randomize expression of your own
Note that this concept mainly applies to particles but should also be considered for any kind of simulation based on a per-object basis. Objects not having a lifespan (therefore no birth properly said) would see their attribute distribution determined at the first frame of the simulation.
What’s available in XSI to control attribute distribution?
Not much to say the truth.
- Texture maps: They are only available for emission attributes of the particle system. Simply put, they retrieve, on a given projected texture or weight map, the sample color from each particle’s birth position and send its value to the attribute.
- Distribution methods: These are XSI’s defaults. Uniform and Gaussian. They are available beside each attribute but cannot be customized. There is actually a trick consisting in binding a dummy fcurve to some particle event scripting but in this article, we’ll try to discuss workflow ideas, not workarounds.
- Expressions: They find their equivalent in pEvents which is in fact the particle scripting module, quite powerful on its own but requires the artist to understand more than what’s needed to create simple expressions.
What should the artist need to control attribute distribution?
- Texture maps: Texture Maps as we know them should be exposed at their simplest expression: The Texture Map Node should retrieve a sample color and return its value. period. The data returned shall be used to serve the artist’s imagination. It could be directly piped in an attribute or divided by 10, multiplied by the size, added to the instanced object index and so forth to finally end-up applied to the mass, for example. The math involved in this example should be available from different nodes (à la render tree) or via common expressions or expression nodes described below. For those familiar with Maya, this is similar to colorAtPoint MEL command, but available to anyone of us.
- Fcurves: This is pretty self-explanatory and is something XSI is good at. Ultimately, they should be implemented to replace default Uniform and Gaussian distribution methods and allow the artist to visually draw any kind of distribution in the animation editor. I’d tend to append the texture gradient to this category as it provides similar results with a different visual approach.
- Expressions: So you’re familiar with logical operators and math and want to write your own distribution expression? Go get an expression node and connect it to, let’s say, the landing distance of your Goal Operator. Remember, this is per-particle! The expression node should provide a connection to every attribute passed down the tree and allow a scripting dialog to override them. Plus, one extra input for conditionals (in our case, something like: particle.age = 0).
Note that if the time variable isn’t specified by any condition, the expression runs for every frame. If no particle attribute is specified by any condition, the expression runs for each particle. This is indeed very close to what pEvents can provide in term of opportunities except that in the current version, not all attributes are exposed. Our version also allows unlimited conditionals, fitted into each other, with no obligation to rely on scripting at all.
The condition leads the expression’s role-play in time and state while the position of the expression op in the tree determines the order of execution.
Conclusion
Attribute distribution is in fact a very small aspect of a dynamic engine (surprise!). I avoided talking about the difficult details of the implementation simply because I am no software developer. I believe that, properly exposed in the interface, attribute distribution could lead to an unlimited amount of creative effects and provide an easier access to procedural attribute management and scripting.
