Allow the rotate function to specify an axis in 2D

[olleicua]

Most appropriate sub-area of p5.js?

• Core/Environment/Rendering

Feature enhancement details:

I want to be able to rotate objects in 2D without the center of rotation being the origin. I noticed that it is possible to move the origin using the translate function but this then requires me to reposition objects with respect to the new origin and that won't work if I want different objects to rotate around different centers (for example to make a 2D simulation of a planetary system with moons).

I'm hoping to support the following syntaxes:

rotate(angle, centerX, centerY);
rotate(angle, createVector(x, y));

Implementation

I'm planning to try to implement this myself but any thoughts others have on implementation details are welcome :)

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, be sure to follow the issue template if you haven't already.

[joemckay5]

You can translate from your translate if you push without popping. Here's a sun-earth-moon example
https://editor.p5js.org/Joemckay/sketches/GHYH1-ugr

[limzykenneth]

Hi, if you need help with your own code, please direct your questions to the forum. We use GitHub issues mainly for bug reports and feature requests only. Thanks!

[olleicua]

Thanks joemckay5. Using the translate function in this way works but I still find it a bit counter-intuitive because it requires me visualize a rotating frame of reference. I can do this if I have to but I'm not sure it is the easiest way for everyone. Given that part of p5's goal is to be accessible to as many coders as possible I think it would be best to support both the method in your example and the syntax I proposed above. We should be able to accomplish this by internally calling translate before and after the rotation if an axis is passed in.

@limzykenneth I'm working on a PR for this right now. I'm not able to re-open the issue. Is there a formal decision making process for deciding whether a contribution will be accepted? Should I abandon my PR? Please advise.

[limzykenneth]

In general we don't try to make the library do everything in every way possible so I would not recommend adding the complexity of a special rotate signature that ignores translate (would it ignore rotates as well?).

I would suggest holding off on a PR for now until there is a concensus about whether to add this feature or not.

[olleicua]

It wouldn't ignore translate. It would do the translate for you. It would work like the transform-origin css property. Basically the user passes in the coordinates within whatever the current frame of reference is (including any translates that have previously happened) and then internally the library could call translate(x, y) then rotate then translate back with translate(-x, -y). The reference already describes this interface for the 3D case so it seems more consistent to make it work in the 2D case as well. The implementations is pretty simple and I think it would make it a lot easier to use while still being backwards compatible.

[limzykenneth]

I find in this case the solution suggested by @joemckay5 easier to work around, the reference frame can be prevented from rotating by having a pair of push() pop() around them.

In the 3D case it is different. The rotation origin still stays the same and controlled by translate(). The second argument is the axis in which to rotate (normal to the plane of rotation), not the origin (since there is more degress of freedom in 3D, and there's only one valid axis to rotate around in 2D).

[olleicua]

You say here "there's only one valid axis to rotate around in 2D". This is completely false it is possible to rotate a 2D object around any point.

I recognize that there are ways of doing this without my feature. The point I'm trying to make is that for some people the existing ways feel counter-intuitive. Forcing the developer to visualize a transformation of the reference frame in order to rotate one object in an intuitive way (something they may not even consider trying) introduces unnecessary friction. Reading the p5 website and github page gives the impression of a community interested in welcoming anyone and everyone and respecting that different people may have different ways of approaching code. If you are serious about these goals of inclusivity then it seems like rejecting my proposal out of hand might be a mistake.

Let me put it this way: what is the down-side of accepting my PR. It adds minimal complexity. It doesn't break any existing code. I'm offering to write it and test it. Please reconsider.

[joemckay5]

I'm not fully understanding how your proposed code would make the sun-earth-moon simulation easier.
If you just want the earth to rotate around the sun then rotateAround(locSun, locEarth, angle, radius) makes sense. But then how do you rotate the moon? P5 doesn't have a screenX screenY function like processing, so if you're using translate and rotate how does your rotateAround function return the location of the earth? I can't write rotateAround(locEarth, locMoon, angle, radius) if we don't know the location of the earth. We'd need to nest a rotateAround() inside another rotateAround(), but now we're duplicating the complexity you're seeking to avoid.
The easiest answer is to avoid push, translate, rotate, pop, all together, and just use trig to get the actual locations of all the celestial bodies. But to my thinking, the simplicity of this sketch doesn't beg out for more simplification.
https://editor.p5js.org/Joemckay/sketches/EgMjCFkeY

[olleicua]

https://editor.p5js.org/olleicua/sketches/CSpYx_IFS

The above is what I am proposing and it is definitely simpler than the trig solution for someone less familiar with trigonometry as wells as avoiding all of the complications of push/pop that a novice programmer might find more challenging. I really want to emphasize that it isn't really relevant whether you or I feel that a solution we have found begs for simplification. What is relevant is whether the p5 library provides tools that will allow any given novice programmer to build whatever they might want to build. If some people find using translate or trigonometry less intuitive and we are able to provide them with tools they might find more intuitive (without taking away any of the current options) then I see no reason we shouldn't do that. Not to put too fine a point on it but saying "this way works and it makes sense to me" feels dangerously close to code snobbery which I was led to believe we don't do here.

[olleicua]

As a side-note, an advantage of the code I linked in my most recent comment is that if you comment out either or both of the calls to proposedRotate you get exactly the result you would expect. This makes debugging easier (something a lot of novice programmers struggle with).

[joemckay5]

Try drawing anything after you call your function and it will also be rotating. Push and pop are necessary because it resets the rotation as well as the position.
At this point I agree with limzykenneth that this conversation belongs in a different forum. I think a lot of what you're perceiving as snobbishness is due to the context and in another setting people will be more interested and generous in helping you think through your idea. Good luck.