Use of Proxy tables for dynamic chooser table selection.

Development Character & Animation
, ,
1

Hello,

We’re looking at how to dynamically feed in a chooser table with Evaluate chooser node in Blueprints. My understanding of how to accomplish this based on the Docs is as follows:

  1. Create a proxy asset with a matching schema to the chooser we want to evaluate
  2. For each chooser we want be able to dynamically pick create a proxy table with the proxy being the new proxy and the value being the chooser we want to use
  3. Call evaluate proxy and pass in the proxy table that has the chooser we want.

This means for every chooser we create we’d have to make a matching proxy table. Ideally we’d just be able to expose the chooser as a pin, and set one as the template so the I/O pins get created correctly. Is there a reason for the indirection in order to be able to dynamically pick the chooser table to evaluate? Apologies if I am missing something obvious. Just wanted to ask before creating a bunch of extra assets.

2

There are two reasons the system works this way:

  1. The main reason is that it’s designed for groups of things which go together that you may want to swap out - eg, like all the animations for a character, where each animation has a proxy asset, and each character type or weapon or whatever controls the swapping of animations has a proxy table. You can make hierarchies of proxy tables, where some characters for example share certain animations and override others (and it prevents the base versions of overridden entries from being loaded). So while the workflow is ok for that use case (still needs lots of work anyway) , in the case where you just have one thing you want to swap out dynamically, it isn’t very good.
  2. The evaluate chooser blueprint node needs to know the schema at editor time so that it can create the input/output pins, and that needs to live somewhere.

To answer your question about an input pin.

Yes, that workflow has been requested and there are plans to support it. Part of the solution for that has been implemented, which relates to #2 above. There is a new asset type called ChooserSignature which defines the input/output parameters (ChooserTable is now a subclass of ChooserSignature, so it’s possible to just plug an example ChooserTable in where a Signature is needed). This has not been integrated with the blueprint node, but the plan is that the blueprint node will have a mode where you provide a ChooserSignature editor side, and that is used to generate input/output pins, and then the actual chooser table to be used at runtime can be provided dynamically by a pin.

3

Okay, that makes sense for the non chooser cases for the use of proxies as sets of animations.

Good to know about the input pin work flow. We’ve just nativized it to solve the input pin problem for us. We’ll keep an eye out for the signature selection feature. It will be a big help to our animators if we can avoid creating proxies if we just want to swap out our table.