There’s a Bar Here
oday, Enning was working on a 3D bicycle-like model in P5.js.
She had already learned to pass parameters to functions, reuse code, and work with nested coordinate transformations. For homework, she independently built two bars on opposite sides of the tire.
And she did it perfectly.
Her two bars were symmetric: one at z = 20, the other at z = -20. Both used the same rotation and then translated along the rotated local y-axis.
So the ability to construct the geometry was already there.
Then we brought the pieces together.
We first got one tire rotating correctly around its own center.
When we tried to make the other tire rotate too, something went wrong.
Instead of spinning around its own center, the whole tire orbited around the origin.
So we slowed down.
We examined the transformations step by step and fixed the problem together.
Then came the funniest moment.
She put one thick bar into the tire.
Enning looked at the 3D model and said:
“Nothing wrong, there’s a bar here.”
😂
She wasn't imagining anything incorrectly. The bar was right there on the screen.
Her problem was subtler.
She was checking:
“Is there a bar?”
Yes.
She wasn't yet checking:
“Does this bar have the right position and orientation relative to the tire?”
So I sent her outside to look at a real bicycle.
A few minutes later, Enning came back.
Now she had something concrete to compare with her model.
She said:
“The bar has to go towards my face. There is another one on the other side.”
That was the moment the 3D model changed in her mind.
She was no longer seeing a collection of primitives.
She was seeing a bicycle.
The bar had a direction.
The tire had a center.
The two bars had a relationship.
And the parts had to fit together in three-dimensional space.
Then she started looking at the transformed coordinate system itself.
She tilted her head to see where the rotated x- and y-axes had gone.
Then she understood that after
rotateZ(40)
the y-axis was tilted too.
So
translate(0, -50, 0)
meant moving along that tilted local y-axis, not simply moving upward on the original screen.
Artifact
Enning’s 8-second clip
A tiny piece of video from today's work captures the result of all that thinking.
The clip is short.
The learning behind it wasn't.
nning already knew how to build the pieces.
Her homework proved that.
What she was learning today was something different:
A correct collection of parts does not necessarily make a correct object.
To understand a model, we have to examine the relationships between its parts.
And in programming, that means learning to ask:
Where is this object?
Which coordinate system am I in?
What happened before this transformation?
Which direction is the local axis pointing?
Does the result match the object I'm trying to model?
Sometimes the computer gives us a strange result.
Sometimes we don't even notice that the result is strange.
And sometimes the best debugger is a real bicycle outside the house. 😂🚲
A learner who once checked only whether the required pieces existed can learn to examine how those pieces relate.
Type it yourself. Modify it. Make mistakes. Fix bugs. Fix your understanding. Test again. Compare the virtual model with reality.
Because programming is not only about making things appear. It is about understanding why they appear where they do—and whether they make sense as a whole.
Museum Note
The sentence that will probably stay with us:
“There’s a bar here.” 😂
Yes, Enning.
There was a bar.
But there was supposed to be a bicycle.
Today, you took one more step toward seeing the difference. 👣