Extract rotations for an alembic as a channel

   1366   4   1
User Avatar
Member
305 posts
Joined: 7月 2012
Offline
I've seen some posts on the forum regarding this, but I can't seem to get anything working regarding this.

I have an alembic, and I want to be able to extract the intrinsic rotations on the alembic, scale them down, then use that new channel to apply the scaled rotations to the original alembic. This should be able to work with translations as well.

Ultimately, Im trying to reduce the inherited velocity from an alembic, so reducing the movement of the alembic itself is my only option at the moment. If anyone can provide a sample file, or have advice, it would be much appreciated!
User Avatar
Member
141 posts
Joined: 9月 2011
Offline
Not clear on what you're trying to do exactly, but I've limited experience with alembics. When you say you're trying to reduce the inherited velocity, what exactly do you mean?

Scaling rots and translates... it sounds like you're not trying to slow the animation down (ie run it longer) but rather just scale down motion blur, or scale down the velocity that's getting passed into a sim. In which case you may as well just deal with the v attribute directly. Unpack the alembic, add point velocities with a Trail SOP (which has a velocity scale parm right there too, saving you a wrangle).

Or have I misinterpreted what you're after?
User Avatar
Member
305 posts
Joined: 7月 2012
Offline
There's a type of inherited velocity from the movement of geometry, that can't be scaled by simply multiplying the velocity on the geometry before it goes into a sim. Ultimately what I want to do is be able to read the rotations off an alembic, scale them down, then re-apply them (post sim). That way, if my alembic is a head turning that turns very fast, I can dampen the amplitude of rotation, sim, and then apply the rotation back after the sim.

I was already able to grab the pivot for the intrinsic attributes, scale that down in chops, and reapply it. That took care of the translations. The rotations are more complex though.
User Avatar
Member
305 posts
Joined: 7月 2012
Offline
Okay, after breaking down what's happening, I believe what I'm actually seeing is too much collision velocity. The collisions with the smoke is what is causing the look of inherited velocity, and without collisions, it isn't a problem. I believe that's why my workaround was dampening the movement of the alembic so we didn't get as much "collision velocity" for lack of a better term. I've attached a hip file where I'm able to scale the translation of the alembic, sim, then add that translation back. Ultimately what I need to do next, if possible, is scale the rotations as well, so that they remain in the right location/axis. The head turning alembic example I gave you is a good example of how, despite having essentially no translation, we still get the head twisting in each direction, pushing smoke further than I'd like. If I could get a channel for that rotation, scale the rotation down, then re-apply it, I'd be able to limit the "collision velocity" of any alembic I receive. Any help would be appreciated!

Attachments:
Import_Alembic_Intrinsics_Problem.zip (310.5 KB)

User Avatar
Member
141 posts
Joined: 9月 2011
Offline
Hopefully someone more experienced than me will chip in, but I still can't quite put my finger on what it is you're trying to do, and despite that, this smells like the wrong approach (!)

You have an object moving and spinning, and it's sourcing smoke. There are no collisions set up, and no velocities are being read into the sim, so the smoke's only motion is upward (from the temperature differential) plus dissipation.

What are you hoping to see?

As an aside: if you want to uniformly scale down the speed of an animated transformation - ie reduce rotational and translational speeds by the same factor - it's the same as scaling time, which you can do by adjusting the frame / frame-rate parms on the Alembic SOP. No need to extract components.

If you absolutely have to "scale down" how much an object rotates over a frame, you could slerp between the current and next frame's orients, but I'm not sure what that'd achieve here that couldn't be done more simply.

It'd make the scene easier to understand and debug if you only import the alembic once (make a dedicated "get_the_alembic" geo, say, with an Alembic SOP wired straight to a null called "OUT") then object merge that null into the various places you need it.
  • Quick Links