PDA

View Full Version : DPKit: simultaneous opposite direction rotation?

jeric_synergy
08-09-2012, 08:46 PM
see attached jpg

I've crafted the illustrated sphere (an "eyelid"), with the w.map values you see. The "rot1" morph map was generated with one application of the Rotate Tool in Modeler, set to "Weight Map" falloff.

I would like to use DPKit to enable the same operation, 'live', in Layout. That is, I want to rotate one null, and have both upper and lower eyelids rotate in opposite directions.

This puzzle is reminiscent of the pie chart unfold methodology Brian Phillips instructed me in a couple years back, but I haven't been clever enough to adapt his approach to this particular problem. (see http://3dproj.com/2011/03/29/node-of-the-week-using-the-gradient-node-to-remap-numeric-values/ ).

Things that I'm shaky on (thinkin' out loud here):

The working node network in the blogpost above uses the COLOR output of the Gradient Node to drive the rotation displacement: is RGB directly translated to HPB, or is any info lost? Can I rely on G being passed thru to P?
Since this weight map contains both negative and positive values, I'm pretty sure I need to alter the keys in the Gradient node, but I'm not sure what the values should be.
And that makes me wonder: COLOR is only a positive value-- is it even possible to encode negative rotation in a COLOR channel?? (The pie chart only needed to rotate in one direction.)

--Yeah, I'm not sure my network (attached) is any help at all. 8~ :compbeati

Thanks for any help. Good puzzle, no? :hey:

jeric_synergy
08-09-2012, 10:52 PM
OK, here's my second run at the puzzle.

I'm hoping this makes more sense.

The Rotator null's rotational value is multiplied by the value of the weight map,
--so zero-value points shouldn't be displaced and 100% points SHOULD be displaced--
which is piped into DPKit: Rotation to be converted into a delta
which is applied as a Displacement.

BUT, still doesn't work, so I'm getting something wrong.

BTW, is the MAKE VECTOR node in there strictly necessary?

Fun fact: the MULT node doesn't appear to be covered in the PDF dox. ADD is. I'm hoping the Vector Mult node just multiplies A1xA2, B1xB2, C1xC2, and isn't doing some weird vector calculation.

jeric_synergy
08-09-2012, 10:55 PM
Got it. The illustrated network allows users to use one item to rotationally displace appropriately weighted geometry in two opposing directions.

Sensei
08-09-2012, 11:00 PM
There is Math > Vector > Scale. Plug weight and vector and it'll be doing the same thing.

But I still don't get what you want to achieve..

For testing purposes plug Const node e.g. vector at various stages, and enter manually values to see whether node network is working.

jeric_synergy
08-09-2012, 11:10 PM
But I still don't get what you want to achieve..

Exactly this. (attached)

Sensei
08-09-2012, 11:16 PM
Simpler.

jeric_synergy
08-09-2012, 11:26 PM
Simpler.
True, but I'm just proud I finally figured one out. :hat:

For I am but a simple mouse pusher, and have no dealings with the worlds of math.

Sensei
08-09-2012, 11:43 PM
Home work: eye that opens and closes in time automatically, without rotating null. No key-frames! One wink per second.

Don't look at picture. Only when you will have it done by yourself.. ;)

SplineGod
08-10-2012, 03:47 AM
what about using weight maps with bones?

erikals
08-10-2012, 05:09 AM
i guess, a node setup seems more powerful though...

jeric_synergy
08-10-2012, 09:24 AM
what about using weight maps with bones?
In the (very) long run that would be more flexible, like the Morfy setup, but this is quick and simple.

It also keeps Layout very sparse and clean. One control to blink the eyes.

For a cartoonish look, it's very adequate.

Sensei
08-10-2012, 02:08 PM
For a cartoonish look, it's very adequate.

I disagree. It should blink every second in normal state, and in alternative state have eyes closed.

So you're key-framing only when eyes are closed (which is not very often).

jeric_synergy
08-10-2012, 02:21 PM
I disagree. It should blink every second in normal state, and in alternative state have eyes closed.

So you're key-framing only when eyes are closed (which is not very often).
So? I animate a null, it moves the lids. That's all I need.

Actually, more than I needed: it was a setup for a still, all I needed it to do was adjust the lids. :tsktsk: