PDA

View Full Version : Bug with Sticky motion plugin revealed when network rendering animation



inkpen3d
06-03-2013, 07:07 AM
Hi folks,

I've encountered a possible bug with the "Sticky" motion modifier plugin which only reveals itself when network rendering an animation and was wondering if any of you have also encountered this problem.

Here's the set up:


A simple subdivided plane with the Ripple texture applied as a deformer so as to obtain a gentle wave action on the surface. This object has the "Sticky Surface" motion modifier applied to it.
A simple capsule object is positioned in the middle of the subdivided plane and has the "Sticky" motion modifier applied to it.
The scene is saved and the 125 frames network rendered using Amleto (with the frame render block size set to the default value of 5 frames).


When the rendered frames are played back the capsule's position/rotation jitters every 5th frame (i.e. frames 1, 6, 11, 16, ...). The capsule's motion in the 2nd, 3rd, 4th and 5th frames of each block of frames rendered by each node appear to be okay in that the motion follows on smoothly from the 2nd, 3rd, 4th and 5th frames of the previous block.

It looks to me as though the Sticky plugin is "looking" for the position/rotation values from the previous frame to feed into the calculations for the current frame. Consequently, when a new block of frames is started on the given render node this information is not available for the first frame (note, jittering every 5 frames still happens if all the frames are rendered on just a single node). Dropping the "Velocity Delta Time" down to zero (or increasing it from the default of 0.1) has no affect on the problem.

Is this problem with the Sticky plugin unique to Amleto, or is it a general network rendering problem? A rather messy workaround is to increase the render block size so that you end up with fewer erroneous frames to manually re-render, but this is obviously a pain to do every time and also not an efficient way to operate a (small) render farm.

If anyone wants to try this out for themselves and confirm that this is a bug, I've attached the project files.

Any suggestions as to a viable workaround/solution to the problem will be very welcome.

Kind regards,
Peter

UnCommonGrafx
06-03-2013, 08:04 AM
I think most would say baking is the cure.

It makes sense, too, since sticky IS looking for what was going on in the previous frame(s).

inkpen3d
06-03-2013, 08:51 AM
I agree with you totally regarding baking the motion, and for a simple set up such as I've outlined above, baking works okay.

However, for a project that I am currently working on the capsule object will be replaced by a cloud of points (which will have hypervoxels applied to them). If I scan the motion of this point cloud using clothFX's Scan Motion option (and save the MDD file) and then switch off the Sticky plugin, the point cloud remains stationary and does follow the undulating surface (although, interestingly, the bounding box of the point cloud does move as expected). I am not sure why this is, maybe using clothFX to record the point cloud motion is the wrong way to go about it, or that somehow the hypervoxels are being decoupled from the point cloud once its motion is driven by the MDD file - any suggestions?

Cheers,
Peter

UnCommonGrafx
06-03-2013, 09:36 AM
I presume you mean it does NOT follow...

If the bounding box is getting the results, and you don't see the vertices moving, something is amiss.
The bounding box has often been my indicator that something is working but a singular switch, for example, isn't in the right state. Sounds like, for example, what happens when working with subds and they need to be before or after motion.

If the points move, which is suggested by the moving bounding box, then the hypervoxels aren't the issue. But some decoupling may have occurred if names were changed.

Greenlaw
06-03-2013, 10:00 AM
Wouldn't it make more sense to bake the motion of the capsule? If this is a non-deforming object, you only need to bake the motion path, no MDD scanning required. Alternatively, MDD should work too.

G.

UnCommonGrafx
06-03-2013, 10:28 AM
Ah
Greenlaw's statement makes the question: are you wanting the point cloud to sense, and thus move with, the moving mesh?
Or do you want the whole of the point cloud moving with the motion of the singular capsule?

The latter suggests that you could use clothfx or bullet on the cloud with the ground mesh acting as a sticky collision, for example.

inkpen3d
06-03-2013, 10:50 AM
The point cloud should sense/move as a rigid whole with the undulating mesh (like a buoy bobbing on water). The capsule will not be present in the scene I am working on and, in the test scene I provided, was just a proxy for the point cloud. I've been using clothFX to record the motion of the point cloud, but as I said earlier, although the points move using the MDD data, the hypervoxels do not move along with them, which is strange and frustrating.

As suggested, I have also tried using the Makepath option from within the clothFX applied to the point cloud (with Sticky applied to it), but the null that is created does not exhibit any motion whatsoever, so it is not picking up information from the Sticky induced motion.

Many thanks guys for all the suggestions - much appreciated.

Cheers,
Peter

Greenlaw
06-03-2013, 11:07 AM
Oh, okay...I think I understand what you're trying to do. As UnCommonGraFX suggests, this does sound like a Bullet Cloth task--this should move the point cloud and also deform it to the shape of the mesh. You'll need to make both objects Deformable to read the displacements. That's what I think anyway--I don't think I've used Bullet Cloth quite this way before--usually I have proxy objects parented to bones for deforming collision objects. I think a deforming mesh will work as a collision object if it's set to be Deformable though. The point cloud should stick to the surface of the mesh using gravity and a little friction.

Sorry, I haven't actually looked at your test scene yet (duh!)--I'll check out in a little bit. :)

G.

inkpen3d
06-03-2013, 11:23 AM
I've attached a new scene which illustrates the problem of hypervoxels uncoupling from a point cloud who's motion has been recorded using clothFX - you can clearly see the points moving and the hypervoxels remaining stationary. If you disable clothFX on the point cloud and then reactivate Sticky in its motion options, you'll see the hypervoxels tracking the points correctly.:bangwall:

Cheers,
Peter

UnCommonGrafx
06-03-2013, 03:55 PM
This is a funky one.

Ok, try this:
Turn off Clothfx on the point_Cloud.
Go to the deform tab and add the MD_Reader. This is how you really should add back in an MDD, or with DP nodes.
In the panel that comes up, change "Apply Cache to" Object space.
Should be visible that it works.

inkpen3d
06-03-2013, 03:58 PM
This is a funky one.

Ok, try this:
Turn off Clothfx on the point_Cloud.
Go to the deform tab and add the MD_Reader. This is how you really should add back in an MDD, or with DP nodes.
In the panel that comes up, change "Apply Cache to" Object space.
Should be visible that it works.

Hi Robert,

Many thanks for that tip - I'll give it a try out a.s.a.p. and report back what happens.

Cheers,
Peter

inkpen3d
06-04-2013, 02:24 AM
This is a funky one.

Ok, try this:
Turn off Clothfx on the point_Cloud.
Go to the deform tab and add the MD_Reader. This is how you really should add back in an MDD, or with DP nodes.
In the panel that comes up, change "Apply Cache to" Object space.
Should be visible that it works.

Hi Robert,

That worked a treat! Can't thank you enough - that use of the MD_Reader was the essential step I was missing out! Seems I'd only half-remembered the correct procedure that I'd previously seen demonstrated in a video tutorial by, I think, William Vaughan!

All the best,
Peter