# [Processing] Unfolding columns

Hello!
I’m sharing the latest iteration of my morph explorations. Recently, I’ve been exploring 2D to 2D, 3D to 3D (you can check some of it on my instagram @WakeMeAtThree). This time I wanted to explore 2D to 3D. I started off designing a simple module that can alternate between these two states, and I thought of unfolding a cuboid to form a X shape that can be tiled.

After tiling and adding a radial delay, I came up with this:

Up to now, I’ve been exploring morphing between two different states, and my explorations revolved around 2D to 2D, and 3D to 3D. Eventually I would like to set up 3 or more states to morph in between, and also mess around more with different dimensions.

Code is available here

6 Likes

Great stuff I need to Explorer around with p3d. Keep Us updated and let us know if you have any questions. Good luck on your project

Beautiful work. When you say 2D to 3D, I’m guessing you don’t mean you are cross-fading P2D and P3D layers… do you mean you are unfolding / flattening the point set onto a 3D plane in P3D?

I’m curious because arranging 2D-in-3D can sometimes entail perspective distortions – although your demo animation looks very clean.

Thanks @dan850 + @jeremydouglass

Yes. They’re all 3D shapes. They’re essentially two lists of vertices: one that is flattened onto a 3D plane, and one that has depth. I’m using shear, rather than rotate, to show the depth of the unflattened shape. That way, the top side of the shapes maintain the 90 degree angles, and when combined with `ortho()` mode, keeps lines parallel in an oblique projection. What I meant by 2D to 3D is the perceptual sense, that one state looks like it’s a 2D pattern and another state looks like it’s 3Dimensional.

In the earlier iteration that preceded this, I used rotate to show the depth and the 2D portion looked like it’s 2D on a 3D plane (which I wasn’t happy with and tried to avoid later on):

1 Like

That is a really useful tip. Thanks!

Beautiful work (is my continued reaction)…

Right now is each point your animated primitives doing a linear point-to-point transform, or do any of them have multi-step paths? I ask because I’ve been toying for a while with submitting list-based interpolations (lerp -> lerps, lerpColor -> lerpColors) as a Processing feature proposal or as a lightweight library.

Your animations seems like a perfect example of how a lerps primitive might be useful for the processing audience – e.g. rather animating across two frames PVector[12][2] it could be PVector[12][3] and the inverted L would grow up first to the angle joint, then over.

1 Like

This is a really useful tool, thanks! It’s exactly the next step I intend to explore as I add more key frames.

Yes, I’m using a linear point to point transform. I’ve been using `PVector.lerp` and a different variant I made that lerps the vertices as Polar coordinates. The visual difference is that of an arc vs line. Sometimes it’s subtle, but sometimes it doesn’t make much difference.

I’ve modified your code for the lerpVectors function (also applicable to others) like so:

``````PVector lerpVectors(float amt, PVector... vecs) {
if (vecs.length==1) {
return vecs[0];
}

float spacing = 1.0/(vecs.length-1);
int lhs = floor(amt / spacing);
int rhs = ceil(amt / spacing);

try {
return PVector.lerp(vecs[lhs], vecs[rhs], amt%spacing/spacing);
} catch(Exception e) {
return PVector.lerp(vecs[constrain(lhs, 0, vecs.length-2)], vecs[constrain(rhs, 1, vecs.length-1)], amt);
}
}
``````

Just to accommodate for an out of bounds issue when indices point to exactly 0 or 1, or when you want to go beyond the [0,1] domain when you’re interpolating. I sometimes let the lerp amount go beyond 1 or 0 for unpredictable results that may turn out to be interesting.

I’m going to add more keyFrames (>2) in the future and tag you when I post the results.

1 Like

Thanks for sharing – nice adaptation to PVector.lerp(), and interesting about allowing out-of-domain values; I’ll need to take a look at that. Excited to see what you do with it!

1 Like