Emit RBD objects from particles

[Nerox]

Hi,

As a proof of concept I'm trying to emit a RBD object from a particle. I'm almost there, I got stuck on the angular velocity.

Because I would like to have random objects I can't use the RBD point node, so I use a copy Sop and a RBD fractured object node.

Where the RBD point node does, the fractured object node doesn't seem to take the angular velocity of the object in account. With other words the RBD objects aren't willing to turn till they collide. According to the help, the RBD fractured object should be able to use the objects angular velocity (I've 'Inherit Velocity from point Velocity' checked).

I think the angular velocity isn't piped correctly or not at all to DOP's.

So the main question is: "How can I bring the angular velocity from SOP's to the RBD fractured object DOP's?"

Attached you'll find the scene I'm currently working on. If you wish to check the velocity on the particles, in the pop sop just set the visibility to the node above the kill sop. (Don't to for get to set it back ;-)

emitRBD_V01.hip

[Nerox]

I use a particle system with particles that live for only 1 frame, the particles are born from geo points with a velocity from a sertain min value like 0.1. On to these particles I copy random objects using the copy sop. This is piped in to a RBD fractured object in DOPs. The idea is that the velocity (including the angular rotation) is used by the RBD Fractured Object to mimic the effect of little pieces braking of a object.

It is quite interesting, I just discovered that for what ever reason, particles don't have any rotation velocity on them when they are born.

Which basically means that if you kill them on there first frame, they didn't had any rotational velocity on them and how logical, the RBD object won't have any when they are born in DOPs.

I was thinking about a time warp and than copying the angular velocity from the second or third frame to the first, but that's probably a stupid idea.

I think faking the initial angular velocity is the only option, any idea's for a node which allows me to ajust the angular velocity without affecting the velocity?

The RBD configure node is able to alter these value's, I can't find a variable to pass the velocity thru.

Edited April 20, 2009 by Nerox

[Nerox]

Well I figured out that the angular velocity is stored in the w(xyz) attribute. Still they're totally ignored by the RBD objects.

Another possible solution could be reading out the velocity that comes in from the objects, but there's no variable for that. Is there a expression within DOPs which can extract the value of a certain attribute?

In that case I could uncheck the 'inherit Velocity from point Velocity', pipe thru the velocity by a expression and manual(or by a random expression for instance) set the angular velocity.

I'm almost at the point where I give up, but still I'm desperate to figure it out one way or another.

Edited April 21, 2009 by Nerox

[johner]

Well I figured out that the angular velocity is stored in the w(xyz) attribute. Still they're totally ignored by the RBD objects.

Another possible solution could be reading out the velocity that comes in from the objects, but there's no variable for that. Is there a expression within DOPs which can extract the value of a certain attribute?

In that case I could uncheck the 'inherit Velocity from point Velocity', pipe thru the velocity by a expression and manual(or by a random expression for instance) set the angular velocity.

I'm almost at the point where I give up, but still I'm desperate to figure it out one way or another.

I took a look at your file, and to be honest I'm not sure I understand what you're going for here. If all you want to do is impart some random initial angular velocity to your RBD pieces, you might be better off putting that in the "Angular Velocity" parameter on the Initial Data tab of the RBD Fractured Object. You can use $OBJID as a seed if you need different random behavior. Or am I missing the point of the particle system?

You can use any expression to pull values into DOPs, so use something like the "point" expression to get attributes from points. The trick is to get the point number of the point you want to reference, but if you know that your SOP network will always be outputting only one particle per frame, you can just use 0.

The idea behind "Inherit Velocity from Point Velocity" is that if you have deforming geometry, you can put a Trail SOP in there (or calculate it another way) and DOPs will calculate an initial linear velocity and angular velocity for the RBD object based on the linear velocity of each point and its position relative to the center of gravity of the object. So you can have a smooth transition from animated geometry to geometry controlled by DOPs. I'm attaching an example that shows it working. The first 24 frames are animated, then DOPs takes over. If you toggle off "Inherit Velocity", you'll see the tube just drops abruptly.

Edit: I looked at the file again: are you trying to get your pieces to inherit their motion from the underlying twisting surface? If so, I would increase the resolution of the grid by a lot to get better samples of the motion for your Trail SOP, then just AttributeTransfer the velocity from the grid onto your pieces as you create them. You don't really need a particle system for this: just scatter points onto the grid, copy pieces onto them, then transfer the velocity onto the points of each piece. Because you've now got a fairly high-res grid, the velocity of the pieces should match the grid pretty well, and DOPs will calculate the proper initial angular velocity from the velocity at each point. See attached example.

DOPS_ptvelocity.hip

emitRBD_scatter.hip

Edited April 21, 2009 by johner

[Nerox]

... you trying to get your pieces to inherit their motion from the underlying twisting surface? If so, I would increase the resolution of the grid by a lot to get better samples of the motion for your Trail SOP, then just AttributeTransfer the velocity from the grid onto your pieces as you create them. You don't really need a particle system for this: just scatter points onto the grid, copy pieces onto them, then transfer the velocity onto the points of each piece. Because you've now got a fairly high-res grid, the velocity of the pieces should match the grid pretty well, and DOPs will calculate the proper initial angular velocity from the velocity at each point. See attached example.

Johner you're a hero, this works great.

Interesting to see that the trial sop needs more density to calculate the proper velocity, I ether didn't know that it also calculated the angular velocity. The hole point of this is, that I can in a realistic way emit RBD objects from the cracks of a breaking object. The breaking animated mesh comes from maya.

I've been on this thing for day's, but I just couldn't figure it out. I've tried to fake it by manually setting the velocity or w parameter, but I couldn't get any result from it. Funny to see it can be solved by adding just 1 transfer attribute node.

Thanks dude.

[few_a_fx]

Nerox could you post a quicktim of the animation and the .hip file? working on something similar.

[johner]

Johner you're a hero, this works great.

Interesting to see that the trial sop needs more density to calculate the proper velocity, I ether didn't know that it also calculated the angular velocity.

...

Thanks dude.

You're welcome. I realize I didn't explain the higher-res grid thing very well, so let me try again. Increasing the resolution of the grid is not to improve the accuracy of the Trail SOP, it's to improve the accuracy of the AttributeTransfer. With default settings, AttributeTransfer works by finding the closest point on the reference geometry (the grid in this case) for each point on the target geometry (the fractured piece). If you've got very small pieces and a grid with not very many points in it, each point on the fractured piece will have the same grid point as its closest point, so all of the points will get the same linear velocity value from those points. While that will certainly work, you won't get any angular motion (spinning) at all since each point is moving in the exact same direction. By increasing the grid resolution, you're ensuring that at AttributeTransfer time, each point on the fractured piece will have a different point on the grid as its closest point, so each point gets a slightly different linear velocity and you get more interesting and accurate angular motion. Does that make sense?

Because your animation on the grid is procedural (using the Twist SOP), you can essentially add unlimited resolution to the grid and get more information. But if you've got an incoming animated mesh from Maya, that may not be the case, i.e. subdiving won't actually give you any more detailed information about the movement of the mesh. So the short answer is I wouldn't worry about increasing resolution unless you're not getting the kind of angular motion you want from the pieces coming off the animated mesh.

Also, the Trail SOP is not calculating angular velocity, DOPs is. If you look at the tube example file, the only attribute created in the input geometry by the Trail SOP is "v", i.e. linear velocity. DOPS then takes that input geo and on the RBD object's creation frame, calculates the Center of Mass and any initial angular velocity that should be given to the RBD Object based on the linear velocity of each point on the object.

[Nerox]

Johner,

That makes sense dude, thanks for this great explanation. It's totally clear to me now. Although I do use a simplified particle network, due to the birth/emission characteristics of the source POP.

Few_a_fx,

I'm still working on a test, I'll post a mov when I've got something show able.