Maya 2011 - nParticles rotation & fluid shade


Hi guys,
I’m testing the new rotationPP attribute in the nParticles, in particular when the particles are shaded with the fluid shape. Because I never found a way to rotate the particle so you don’t recognize that is always the same fluid shape, and I thought that with Maya 2011 finally I have the chance.
But this still doesn’t work. I mean…if I enable the “compute rotation” and then I put a creation expression in the rotation, just for have a random value, all the particle look the same.

From the documentation:

Rotations are initiated from the friction generated between the particles and the collision object. You can control the nParticle object’s tendency to rotate during collision by adjusting the Rotation Friction and Rotation Damp attributes. See [Rotation Friction](file:///usr/autodesk/maya2011-x64/docs/Maya2011/en_US/files/WS1a9193826455f5ff-2ade9d9118a20d4f81-d59.htm#WS73099cc142f487553bd5b66812435c29801-546b) and [Rotation Damp](file:///usr/autodesk/maya2011-x64/docs/Maya2011/en_US/files/WS1a9193826455f5ff-2ade9d9118a20d4f81-d59.htm#WS73099cc142f487553bd5b66812435c29801-5466). The Friction value of the collision objects can also affect the tendency of particles to rotate. Rotation Friction does not change how Friction affects nParticle motion during collision. See [Friction](file:///usr/autodesk/maya2011-x64/docs/Maya2011/en_US/files/WS1a9193826455f5ff-2ade9d9118a20d4f81-d59.htm#WS1a9193826455f5ff-2ade9d9118a20d4f81-d20).

Rotation PP (rotationPP) and Angular Velocity PP can be used with expressions to add and control per-particle rotations. Rotation PP is the current rotation of the particle and Angular Velocity PP sets the rotational velocity of the object about its origin.

I have also tried to have a collision, but still…
Then I tried to instance the fluid shape, but my maya seems to doesn’t like at all, because all the times that I press render it crash!


Does anyone remember how to make cloud nParticles shade with a fluid container preset?

The workflow is as follows…

  1. Create a thick cloud nParticle system.
  2. On nParticleShape turn on “compute rotation”.
  3. On the shape under add dynamic attributes select general and create the attribute userVector1PP from the particle tab (or any useVectorPP).
  4. Set this from the rotationPP. This could be done in an expression but one can also simply create a connection:
    connectAttr nParticleShape1.rotationPP nParticleShape1.userVector1PP
  5. Connect a particle sampler info userVector1PP to the texture rotate of the fluid shader.
    connectAttr -f particleSamplerInfo1.userVector1PP npThickCloudFluid.textureRotate;

The rendered texture will now represent the current rotate value on the particle. This rotation will be affected by collisions if compute rotation is on. If there are no collisions you could also set the AngularVelocityPP to make the particle spin. This velocity will damp over time based on the rotation damp value. The angular velocity is defined as a vector where the direction of the vector represents the axis of rotation and the length the velocity of rotation. If you just want to directly set rotation values, and don’t need them computed for you, then you may wish to only have a userVector1PP array and set that directly(leave compute rotation off… no need for the rotationPP array or connection from it)



thanks Duncan, that’s fantastic!
It was quite straightforward at the end, why I never think about that.



I suppose it is straightforward if you are familiar with Maya particles, but it still seems a bit complex to me. The setup for using rotate for instances is also a bit more complex than one might wish. Hopefully in future we can make the setups more automatic. (the setup I described above would be a pretty trivial mel script)



Yeah, I always have thought that the most commonly used methods for particle creation/interaction could be reduced to pull down menu items.

For instance, it is very common to want to have particles emitted from object A when it collides with object B or say “any geomentry”. The interface for collision events is cumbersome for this. It could literally be a pull down menu that has “emit on collision” under emit rate numeric value and then maybe an add or exclude list where you could specify which objects to add or exclude to the collision detection. Where nothing added in the list would equal “all on” or “all off” depending on say a check box determining the lists exclude or include function being set by the user…

The particle rotation seems like it could also be a numeric value “particle rot” x,y,z min/max. -rate.

Instead of a script or expression it is merely a numeric value that can be set just like emit rate.

I mean I don’t fully understand if the particles in maya actually have rotation or of the cloud shader is what is recieveing the rotation but in either case it does seem like it could be simplified to numeric values instead of scripts and expressions. I used a plug in for Lightwave 3 odd years agao called dynamite and it had the volumetric shading of particles and it had a min max rotation rate which allowed the particles to individually rotate the same way this method is achieving and it was simply a min max numeric value which could be set teh same for constant rotation rate OR use min and max values to randomize the rates of each particle.

Anyways, not sure if any of this helps. Just want to have that same simple funtion in maya without too much menu fussing. I mean I love the depth of the userPP setups but for commonly used setups like particle rotation there should be simple numeric values.


I love the particle system from 3DsMax…
Why is there never such a system made for Maya?


Duncan, could you help me to do the same thing, but intead of nParticles, I am trying Particles (cloud type).
My particles was build on a curve flow, and they have a fluid texture also. I tried everything to make those particles to rotate on creation and run time after, but nothing seems to work.



The rotation computation is for nParticles only currently, although you can manually rotate the texture per particle on classic particles. OK, just to confirm… you have a fluid shader assigned to the particle where the fluid shader uses the built in texture? Or did you apply a fluid texture to a particle cloud shader? At any rate the rotate of the texture needs a connection from the particle sampler info (userVector1PP as I described in my first post on this thread).

On the classic particle system you can hand create a userVector1PP attribute and just set it in a particle expression. (just think of this attribute as your texture rotate attribute ) A simple way of updating it is to just add a random value to the rotation each step.




Sounds like you might be the guy to help me out. I’m new to both particle systems and to writing expressions, although I think I get the basic concepts of each.

I’ve got another thread going where I explain my problem:

I’ve instanced geometry to the particles and want them to come in at different, random rotations. Nothing I do seems to make any difference, there is no rotation, everything is static. I’m guessing that I’m making a really fundamental mistake, but I have no idea what it is.

Also, I’ve got a few different objects in the instancer list, and I want them randomly instanced to different particles. Only the first object get instanced, unless I turn the “Cycle” to “Sequence”, then each particle cycles through all of the objects.

Don’t know if it makes any difference, but I’m using nParticles.

This is really driving me crazy, I’ve been working on it for 2 days, and I think my client is beginning to lose faith.



Thanks Duncan,

i have a fluidShape assigned to the particle. I added a randow expression for the rotationPP, and it worked now, as you described.

Thanks a lot!


To setup your particle instances set cycle to none and create a per particle attribute to determine which instance you will use (note that this attribute must be a float attribute as int arrays are not supported). For example create a per particle attribute “myObjectIdPP” then initialize it in a creation expression:

myObjectIdPP = rand(5); // if you have 5 objects will randomly select one for that particle

Now in the particleShape instancer options select “myObjectIdPP” in the ObjectIndex popup. You should now see your objects randomly assigned the particles.

To see rotations you need to set the rotation popup(in the same instancer block) to some attribute . If you want dynamic rotations turn on “compute Rotation” then set the rotation popup to rotationPP. You can then set rotationPP inside the particle creation expression to random values:

rotationPP = <<rand(360), rand(360), rand(360)>>;




Thanks, looked like your solutions should really work. Except that it didn’t. It’s almost as if the particle expressions aren’t being run.

Here’s the 2 expressions I created:

nParticleShape1.myObjectIdPP = rand(3);
nParticleShape1.rotationPP = <<rand(360), rand(360), rand(360)>>;

When I ran it, nothing happened. The particles were instanced to only the first object in the instancer list, and all the objects came in with no rotation.

Compute Rotation is on. Rotation Friction is at the default of 0.9. Under “Rotation” in the Instancer tab, it’s set to “rotationPP”. Does “Rotation Type” need to be set to anything? (Not like I haven’t tried.)

Oh, in the Object Index section of the particle shape instancer tab, myObjectIdPP isn’t available in the pop-up. Any idea why not?

I’ve tried a number of different solutions, and not a single one has even had the slightest impact on the particle system. Not even an undesired effect. Nothing.

I just don’t get it. Any ideas?


Did you create myObjectIdPP as a per particle attribute? It should show up in the popup( perhaps you need to scroll to see it?). If it only shows up when you select “allow all data types” then it could be you did not create it as the right type.

Rotation type does not need to be set.
Those two lines of code should both be inside your particle creation expression.

I’ve attached a file with the setup described. It works OK for me. I’m not sure what you may be doing wrong.




Got it to work. I was trying to make the changes to an instancer node that already existed. When I threw that away, and created a new instancer node from scratch, everything worked.

Thanks a bunch, you were really a great help. Now I’ll have a happy client.


Hi Duncan. I’ve broken down your smokeStackMR2 scene and it appears that userVector1PP and particleSamplerInfo1 is not working as I expected. Attached is the scene (Maya 2011.5) and image showing the problem. Texture is the same on all particles regardless of whether userVector1PP is connected or not.

Of course I maybe missing the point completely, does the fluid only rotate with the particle upon some form of collision, self collision or friction.

I guess what I want is each particle at creation to have a different texture (origin).

Hope someone can help.



Hi Wizlon,

does the fluid only rotate with the particle upon some form of collision, self collision or friction.

The computeRotation causes the simulation to update the rotatePP attribute base on the current rotational velocity (angularVelocityPP) and collisions. The rotationFriction determines the degree to which collisions affect the rotation. RotationDamp is the degree to which the angularVelocity is reduced each step( may be thought of as rotating friction with the air). You can set rotatePP0 to define a start rotation(or set rotatePP in a creation expression), as well as set the angularVelocityPP to make the particles rotate( instead of or in addition to using collisions). The angularVelocityPP is defined as the axis of rotation where the length of this vector defines the rotational speed.

So with the above you could create a random start orientation and random spin for each particle, without any collisions. Note that the self interaction using the liquid simulation method does not affect rotation. However instead of a liquid solve one could use selfCollisions with a very low collide strength to have continuously overlapping particles where the relative motion of overlapping particles would then affect the rotation( due to the self collisions, even though they would be very weak). However in the smokestack example the rotations are entirely caused by the initial collisions of the particles with the smokestack.

If you simply want each particle to have a different noise, you could connect particleSamplerInfo1.particleId into npThickCloudFluid.textureOriginX(however you might need to first pass the id through a multiply node to so that it is non-integer… the texture repeats at integer offsets ). Another thing that can be useful is to drive textureTime by particle age.



Thanks for your patient explanation Duncan.

Every couple of years I dip my toe back into particles and expressions, trying to relearn everything I’ve forgotten in the preceding years. I just need to jump start that part of my brain.

Thanks again.


Almost off topic, sry for that

If i try and set up a nParticle system with mel and turn on computeRotation i cant use rotationPP. I get errors that the attribute dose not exist but when i try it by hand(in expression editor) or Mel after error it works perfect.

I guess this has something to do with the slow update of available PP attributes. Can i some how force maya to finnish this before continuing with my Mel…



solved, created the attribute before i turned on computeRotation. Still think this suxx, dont like when programs start to think they can do things on there own. Thats when things like this happens. =)


Odd that you needed to create the rotationPP attribute. Normally it is automatically created when you toggle computeRotation ON (if it doesn’t already exist). Perhaps something in your setup or sequence is blocking its creation. (could be a bug)