good news: I was able to get multi-instance puppetstring v21 working on both of my webcams.
bad news: my CPU did not appreciate the extra workload haha ORZ
Siranea
11
Posts
43
Followers
72
Following
A member registered Mar 03, 2014 · View creator page →
Creator of
Recent community posts
comment: okay, I did some testing. note that not all bugs found were restricted to the use case or test case below.
use case: using keyboard controls to toggle emote blendshapes between 0 and 1 (key1..key9 toggling emote1..emote9) , accompanied by a separate group of keyboard controls mapped to the same key to set all emote blendshapes to 0 (a group of keybinds setting emote1..emote9 with key0). this would allow toggling independent emotes with key1..key9, and pressing key0 to turn off all emotes.
test case: keyboard control toggle; keybind (Alt)(1), blendshape "testShape", values {0,1}. keyboard control set; keybind (Alt)(0), blendshape "testShape", initial value {0}, set value {0}.
comment: Puppetstring 0.0.4 does not like it if you set multiple keyboard controls to the same blendshape. (that is, when several keyboard controls have their blendshape targets set to the same string.)
bug0: when a toggle keybind and a set keybind both target the same blendshape, the displayed values for the toggle keybind may appear to change correctly in Puppetstring, but the output blendshape communicated to session remains fixed regardless of keypresses. replicated successfully.
bug1: when a toggle keybind and a set keybind both target the same blendshape, clicking the edit button for the set keybind may instead result in opening the edit view for the toggle keybind, or opening the edit view for the set keybind as if it were an increment/decrement keybind. replication has been difficult; my conjecture is that the result of clicking the edit button for the set keyboard control may depend on variables or values that are persistent to a given instance of Puppetstring.
comment: as I was doing testing for this bug, additional bugs were discovered outside of the test case. keyboard set controls are hecked up, friendo. UI always goes like this lol
bug2: after editing a set keybind, future set keybinds may have an additional "Value 2" underneath "Key 1". for example, after three calls to edit any set keybinds, editing another set keybind might have a "Key 1" with the fields "Value 1", "Value 2", "Value 2", and "Value 2". partially replicated successfully; did not test whether or not the process is initiated by editing a set keybind which has multiple keys to set a blendshape to different values, or if it's initiated with any set keybind regardless of how many keys or values it has.
bug3: for a set keybind with multiple keys, the second key always sets the targeted blendshape to 0, regardless of the value entered for "Key 2" in its "Value 2" field. however, entering a value for "Key 1" "Value 2" will result in "Key 2" setting the blendshape to "Key 1"s "Value 2".
bug3 cont'd: "Key 1" "Value 1" {0.1}, "Key 1" "Value 2" {0.2}, "Key 2" "Value 2" {0.3}. this setup will cause "Key 1" to set the blendshape to 0.1 and "Key 2" to set the blendshape to 0.2. Replicated successfully.
bug4: editing a set keybind may result in all "Value 2" fields being initiated with the value from "Value 1", and the "Value 1" field being initiated as {0}.
comment: these are all the bugs I recalled and found in this sitting. there may be others I can't recall right now. and unrelatedto the bugs reported here, I have a suspicion there may be other bblendshapes like psHeadFrontBack where the values sent to Session may not match the values Puppetstring has, but I haven't gotten to around to actually testing this so I'm not confident whether this is the case nor which blendshapes may be affected.
final comment: best of luck, AR14. don't forget to hydrate, get up and move around, and find a bit of time to get some serotonin in.
okay, feature requests.
(or maybe more like feature suggestions? idk, ignore these if you want, I'm not your mom)
(also sorry about the messy formatting, the comment field is deeply disagreeing with me)
keyboard controls
* toggles with transition times
* timed sets/toggles (automatically reverts to 0 after a user-defined amount of time passes)
* "held" keystroke type (sets a blendshape only while key is held)
* access to numpad keys
widget controls
* panel of tileable(?) widgets whose outputs can be mapped to custom blendshapes
* buttons (essentially keyboard controls but mapped to a UI object)
* 1D sliders/dials
* 2D touch pads (basically just a square you click in)
misc. blendshape management
* blendshape aliases
> if blendshape has arg1 name, send its value as arg2 name (maybe averaging values if multiple are aliased to the same name? or just let Session handle it)
* custom blendshape expressions
> custom blendshapes that are calculated from other blendshapes, using expressions (Javascript?) provided by the user
* tracking-activated toggles
> custom blendshapes that are set/toggled/incremented when a set of user-defined conditions are met (various blendshapes equal/greater/less than user-defined values or other blendshapes).
* tracking loss blendshape
> a blendshape that toggles to 1 if tracking is lost, or a "tracking lost" condition for custom blendshape expressions
I have use cases in mind for all of these, but also I'm not going to perish if 0 of them appeal to you lol