While the node takes care of a chunk of setup, it fails to take care of all the blinking / bias movement (bias of the blink between the upperLid and lowerLid positions)
So really the entire setup needed to be built in such a way that allowed me to consider those two requirements being created ON TOP of the underlying eyelid node network.
So looking at the pretarsal (the lip of the eyelid) this is the main area that moves the lid around.
This image shows the core network for the main lid control;
Below, for each output joint for the upperLid_pretarsal and lowerLid_pretarsal joints, I have setup the outputs from the eyelidNodes, upperLid_pretarsal, lowerLid_pretarsal and Blink to all pipe into a parent constraint per joint. For each of those, I plugged in a network created to change the weighting based on the blink/bias settings and change the weighting accordingly;
Here’s a look at the joints for the setup loosely weighted in;
The overall network for the setup;
A Tool to help me construct the network;
I realised I didn’t want to be testing this over and over by hand so I setup a small tool to help build the network up with
So the downside is that the pretarsals (the ones running through the middle of the lid) are blended between the orbital / pretarsal joints in a linear fashion. So when the bias is too high or low it’s possible for the blend to be too linear and slice through the eyeball.
Other than that, I’d say testing done.
Hope this provided an good look at one approach for lids. Successful? Well it’s definitely holding together for general usage.