Guides Farger Timeline Community Sharing

[Case]

Just had a look at the "animation-loading via subscene" scene ... ever tested this with large animations?

There's eg some creators like FlyRoxy who partition HUGE animations into three or four pieces bcs otherwise, their scene json would gp past the 500mb limit (afaik, VaM can't handle scene jsons past 500mb. At least until 1.20.77.x, it couldn't).

So your idea could be an alternative to mergeloading - at least until AcidBubbles implements triggerable loading of animations in Timeline - keep all the scene-elements & logic static, load new animations via subscene.

One problem might be triggertracks, though - you'd have to pre-plan all the triggers you want to use throughout all "episodes" of the scene, and if you have a trigger that's only used in, say, "Episode 3", but not in "Episode 1", you'd have to have a "placeholder" already built into "Episode 1".

Maybe one could use atani's "QuickDress"-idea to manage that - ie. create an Empty that contains all the "Back-office Logic" (Relays, SelectChoice-Bricks, VamStory etc) together with the resources (clothing, audiobundles), place Timeline on the Person, and the Timeline-triggers point to storables on that "QuickLogic"-atom. The trick is to use the Empties' preset-save/load function, instead of the Person-atom's presets. That way, you can swap out the content of the Empty without Triggers in the scene breaking.

 

[Farger]

Just had a look at the "animation-loading via subscene" scene ... ever tested this with large animations?

There's eg some creators like FlyRoxy who partition HUGE animations into three or four pieces bcs otherwise, their scene json would gp past the 500mb limit (afaik, VaM can't handle scene jsons past 500mb. At least until 1.20.77.x, it couldn't).

So your idea could be an alternative to mergeloading - at least until AcidBubbles implements triggerable loading of animations in Timeline - keep all the scene-elements & logic static, load new animations via subscene.

One problem might be triggertracks, though - you'd have to pre-plan all the triggers you want to use throughout all "episodes" of the scene, and if you have a trigger that's only used in, say, "Episode 3", but not in "Episode 1", you'd have to have a "placeholder" already built into "Episode 1".

Maybe one could use atani's "QuickDress"-idea to manage that - ie. create an Empty that contains all the "Back-office Logic" (Relays, SelectChoice-Bricks, VamStory etc) together with the resources (clothing, audiobundles), place Timeline on the Person, and the Timeline-triggers point to storables on that "QuickLogic"-atom. The trick is to use the Empties' preset-save/load function, instead of the Person-atom's presets. That way, you can swap out the content of the Empty without Triggers in the scene breaking.

I don't see an issue with large animations, except longer load times.

I believe that the upload limit on the VAM hub for a VAR is 500mb, so I am not sure how many jsons exceed that. I welcome others to test huge animations and share their findings.

I have never had anything but chaos when using mergeload in VAM, so I don't even try anymore. I did exactly as you stated with logic and static elements and load new animations to progress the scene, this is how the test scene that you mentioned is structured. I did something similar in "Beam Me Up." In that scene, Saiko and the animations are static, and it is all the objects that change around her in subscenes.

Trigger tracks take some thinking, this is true. It can be complicated when there are multiple options, this was the case when I made "2049." In Scene 3 of that resource it is built to progress in sequence from one landing pad to another, like pad 1, 2, and 3. But it could get quite complicated if I made it so one could fly from one to the other with multiple choices, like 1 to 2, then 2 to 1, then 1 to 3, etc.

I found that anytime that Timeline itself is used to switch subscenes, that it causes all instances of Timeline to restart, then that negated the event to switch subscenes, so it just went immediately back to the first subscene. Thanks for sharing some thoughts on the matter, and appreciate sharing any testing results that you encounter.

 

[Case]

I don't see an issue with large animations, except longer load times.

I believe that the upload limit on the VAM hub for a VAR is 500mb, so I am not sure how many jsons exceed that. I welcome others to test huge animations and share their findings.

I have never had anything but chaos when using mergeload in VAM, so I don't even try anymore. I did exactly as you stated with logic and static elements and load new animations to progress the scene, this is how the test scene that you mentioned is structured. I did something similar in "Beam Me Up." In that scene, Saiko and the animations are static, and it is all the objects that change around her in subscenes.

Trigger tracks take some thinking, this is true. It can be complicated when there are multiple options, this was the case when I made "2049." In Scene 3 of that resource it is built to progress in sequence from one landing pad to another, like pad 1, 2, and 3. But it could get quite complicated if I made it so one could fly from one to the other with multiple choices, like 1 to 2, then 2 to 1, then 1 to 3, etc.

I found that anytime that Timeline itself is used to switch subscenes, that it causes all instances of Timeline to restart, then that negated the event to switch subscenes, so it just went immediately back to the first subscene. Thanks for sharing some thoughts on the matter, and appreciate sharing any testing results that you encounter.

Iirc, TGC stumbled onto the 500mb limit for scene-json files a while ago - it's not just the Hub, it's VaM that'll crash with scene-jsons larger than 500mb. Not totally sure that still holds today (Meshed made some improvements to json parsing in his latest updates), but at least for the 1.20.77 version of VaM, 500mb was a hard cap. Like Crash-to-Desktop kind of hard cap ...

Wrt "huge animations" - My concern is whether "old" animation data is deleted whenever you load a new animation via subscene-loading. If the old animation data were retained in system memory, you could easily crash VaM, even if all the animation "pieces" themselves are small - that'd make the method useless for "parcelling" large animations into smaller pieces (I'm thinking particularly about large mocap animations - it's hard to build "multi-station" mocap scenes for that reason).

Mergeloading/VaM-mocaps - Yeah, VaM's builtin functions are incredibly brittle. Mocaps recorded with VaM's native function are prone to triggerbreaks (you can't even rename atom UIDs - even though Meshed implemented UID-rename callbacks awhile ago). And mergeloading ... that was a viable option before we all started using plugins like LogicBricks for scene control.

 

[Farger]

Iirc, TGC stumbled onto the 500mb limit for scene-json files a while ago - it's not just the Hub, it's VaM that'll crash with scene-jsons larger than 500mb. Not totally sure that still holds today (Meshed made some improvements to json parsing in his latest updates), but at least for the 1.20.77 version of VaM, 500mb was a hard cap. Like Crash-to-Desktop kind of hard cap ...

Wrt "huge animations" - My concern is whether "old" animation data is deleted whenever you load a new animation via subscene-loading. If the old animation data were retained in system memory, you could easily crash VaM, even if all the animation "pieces" themselves are small - that'd make the method useless for "parcelling" large animations (I'm thinking particularly about large mocap animations - it's hard to build "multi-station" mocap scenes for that reason)

When I execute the switch in the trigger, the new subscene is loaded in place of the previous one, but I have no clue what is going on with the system memory. Sometimes my scenes get elaborate, I'll see if I can crash the system.

 

[Case]

When I execute the switch in the trigger, the new subscene is loaded in place of the previous one, but I have no clue what is going on with the system memory. Sometimes my scenes get elaborate, I'll see if I can crash the system.

I'll do so too.

Maybe test with different names for the animations? If all your animations are called "Animation 1", then I guess it's likely each one gets overwritten when you load the new subscene. More advanced test would be if each animation in each subscene had a different name.

My hunch is that if smth happens, it'll likely be the number of "objects" rather than sheer filesize. Ever heard of the dreaded "Too many heap sections" error? The going theory is that this isn't caused by simple memory overload, but rather, there's a hard cap on how many "objects" 2018 version of Unity can handle (Don't ask me for a precise definition of "object" - my current definition of object is "Unity-thingy" ). I have 64Gb of Ram, and I regularly run 3rd party diagnostics run alongside VaM - never seen RAM usage exceed 40Gb. But I have seen several crashes due to "Too many heap sections" ...

Current number of objects gets printed to "output_log.txt" - and I think also the new memory optimizer function gives out some statistics on that.

 

[CheekiBreeki]

I've been trying to figure out better ways to load multiple large animations as well.
The ideal way would be to have 'presets' to be able to load entire set of Timeline animations into the plugin with a trigger.
Since we don't have that functionality in the plugin yet, the only way that has worked cleanly for me is to use plugin presets to save and load Timeline as a whole. That's what I did for the Kpop Dances scene where I have 4 set of animations all around 500mb. To switch to a different set, I load the Timeline plugin preset (on a person) and then merge load the remaining person plugins. Only issue I see is if some required person plugins can't be merge loaded properly.

Another issue is any triggers to play Timeline animations depend on the plugin# in the order and animation name as well. So you need your Timeline plugin be the same plugin# when you switch animation sets. But overall, this approach helps to keep rest of the scene intact and just switch out the Timeline animations.

 

[Farger]

In the "Continuing Voyages" scene that I posted today, this is another example of using animation patterns to control subscene progression.

 

[CheersMate]

1. I dont know if it should not be used that way, but there are advantageous to assigning it to the specific resource, such as being able to save seperate components of the scene to a subscene. It can also be easier to know what each plugin is assigned to do because it is logically attached to it.
2. I am not sure, I may try switching with subscenes to see how that goes. I did notice the same thing when i made my lightsaber swing rather quickly. I'll try some tests tomorrow and reply back.

1. You can put the timeline plugin just about anywhere. I'd say the biggest advantage to associating it with the person(s) or object(s) vs a global timeline instance is organization & de-clutter. If you want a single centralized plugin, then think of the Timeline Controller Plugin as such. And the person/object instances as another level of hierarchy.
2. Subscenes and external triggers (or vise versa) don't always play nice together. Use the timeline pose tab to prevent physics issues when switching anims. Jumping around within a single anim is a little more complicated though. If you have an anim in which a person moves dramatically (e.g. flips front to back), I'd suggest temporarily splitting into 2 separate anims while tweaking (with starting poses), then recombining when you're done.