Random retiming of alembic instances
6474 9 1-
- papsphilip
- Member
- 387 posts
- Joined: July 2018
- Offline
Is there a way to retime alembic instances?
i would like to have an attribute on my points (before the copy to points sop) that sets the speed of the alembic animation and the frame it starts.
is possible to use an agent setup? that has this functionality built in as far as i have seen..although my alembic file is very simple geometry - not a rig or anything like that.
Any tips?
i would like to have an attribute on my points (before the copy to points sop) that sets the speed of the alembic animation and the frame it starts.
is possible to use an agent setup? that has this functionality built in as far as i have seen..although my alembic file is very simple geometry - not a rig or anything like that.
Any tips?
-
- tamte
- Member
- 9083 posts
- Joined: July 2007
- Online
-
- papsphilip
- Member
- 387 posts
- Joined: July 2018
- Offline
-
- papsphilip
- Member
- 387 posts
- Joined: July 2018
- Offline
-
- papsphilip
- Member
- 387 posts
- Joined: July 2018
- Offline
-
- papsphilip
- Member
- 387 posts
- Joined: July 2018
- Offline
animation offset works using the abcframe but speed is a bit tricky to change without a retime sop node. there needs to be some kind of geometry interpolation
Any thoughts on that?
i have to say it is a bit strange that there are no nodes to handle the retiming of alembic / fbx instances.
something like the agent workflow..
Here is my file for anyone interested
Any thoughts on that?
i have to say it is a bit strange that there are no nodes to handle the retiming of alembic / fbx instances.
something like the agent workflow..
Here is my file for anyone interested
-
- tamte
- Member
- 9083 posts
- Joined: July 2007
- Online
- you are in complete control over the time therefore over the speed with the direct value as you did in test.hip
- alembic handles interpolation automatically
- no unpack should be necessary even though there used to be viewport glitch which would not update the time but render used to be fine
however in the build I opened test.hip in (18.5.408) it at first didnt vary the time, but bypassing and unbypassing the wrangle triggers it and updated fine in the viewport
- don't unpack/repack, you will loose all optimisation
- alembic handles interpolation automatically
- no unpack should be necessary even though there used to be viewport glitch which would not update the time but render used to be fine
however in the build I opened test.hip in (18.5.408) it at first didnt vary the time, but bypassing and unbypassing the wrangle triggers it and updated fine in the viewport
- don't unpack/repack, you will loose all optimisation
Tomas Slancik
CG Supervisor
Framestore, NY
CG Supervisor
Framestore, NY
-
- papsphilip
- Member
- 387 posts
- Joined: July 2018
- Offline
tamte
- you are in complete control over the time therefore over the speed with the direct value as you did in test.hip
- alembic handles interpolation automatically
- no unpack should be necessary even though there used to be viewport glitch which would not update the time but render used to be fine
however in the build I opened test.hip in (18.5.408) it at first didnt vary the time, but bypassing and unbypassing the wrangle triggers it and updated fine in the viewport
- don't unpack/repack, you will loose all optimisation
thank you for checking the demo scene!
I tried bypassing and unpybassing and in my case its not working. The correct animation registers after i unpack for some reason!
For now this hasn't affected my scene as far as i can tell. i feed the repacked geometry into an rbd simulation.
What kind of optimizations am i loosing this way?
-
- tamte
- Member
- 9083 posts
- Joined: July 2007
- Online
papsphilipwell, technically not much in terms of instancing if you have completely different time per copy
What kind of optimizations am i loosing this way?
but you are losing transforms and pivots for example
however there is also benefit to keep packed alembic geo till render as then Mantra can directly reach for the original alembic at the specified time rather than passing unpacked/repacked geo which doesn't have any connection to original alembic
unpack forces it to evaluate that's why you are seeing it correctly, the same would happem at rendertime, and probably also if you just used in RBD without unpacking/repacking
it's just the viewport that seems to cut corners and therefore not always showing the correct data in this case of the same alembic reference with different time offsets
Edited by tamte - April 30, 2021 12:42:37
Tomas Slancik
CG Supervisor
Framestore, NY
CG Supervisor
Framestore, NY
-
- papsphilip
- Member
- 387 posts
- Joined: July 2018
- Offline
thank you! everything works now. there is some kind of viewport bug sometimes but that carried on inside dops. After a couple bypass/unbypass efforts my setup is stable so far.
Here is a very helpful tutorial also for anyone interested.
https://www.youtube.com/watch?v=crSMvytzQD0&list=PLgYcMX8FouybC_ujNMACeY0-bXg-QLv71&index=6 [www.youtube.com]
Here is a very helpful tutorial also for anyone interested.
https://www.youtube.com/watch?v=crSMvytzQD0&list=PLgYcMX8FouybC_ujNMACeY0-bXg-QLv71&index=6 [www.youtube.com]
-
- Quick Links