It is currently May 29th, 2020, 8:14 am

## [Solved][Lots of Math] Moon Icon Rotation on a Sky Dial

Help with creating, editing & fixing problems with skins
Yincognito
Posts: 1662
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

### Re: [Lots of Math] Moon Icon Rotation on a Sky Dial

So, raiguard, do you still have the problem, or you found a way of solving it? Because if you still have it, I would be tempted to share my opinion on the matter (I'm not scared of math, but I'm a bit lazy, LOL). For a start, my visual impression was confirmed by the measurements I've made in Photoshop: the great arc that you (apparently) move the moon shapes on is not perfect. Take a screenshot and measure with a rectangluar marquee tool the width of the space between the left of the arc and the green "dot" and compare it with the with of the space between the green dot and the right of the arc. For me, it yielded 248px for the former and 254px for the latter. Slight note: the size of the "center" of that arc should also be considered in a formula, if any.

Secondly, the fact that the skin width is modified when the moon starts approaching the 180 degree on the arc doesn't seem ok to me. There is most certainly an error in the formulas that make the movement of the "limb" (the illuminated part of the moon) incorrect. I would suggest slowing down the motion to better see what's going on (add 0.1 to the #moonDialAngle# variable and set Repeat Move, 16, 1800 in the [MeasureActionTimer] measure), or better, complete a Debug Dial Rotation to 180 degrees and just test Debug Limb Rotation in that point, until you fix it.

It's my first encounter with the Arc shapes in Rainmeter, so I don't know yet the specifics (help is available, but I must be "in the mood" to get that in my brain, LOL), but to me, there shouldn't be many exceptions / conditional operations in the formulas and things should be always calculated from the center (and not the margins) in elliptical formulas, because the center is always the stable reference. For example, instead of:

Code: Select all

``````moonArcStartX=(#dialStartX# - #dialObjectRadius#)
``````
I would write something like

Code: Select all

``````moonArcStartX=(#dialCenterX# - #dialRadius# - #dialObjectRadius#)
``````
where dialCenter would be the green dot (aka the center of the moon movement arc). Also, make you're considering every space you deal with (margins, borders, etc.). Last but not the least, when I tested the limb rotation at the 180 degrees point on the moon movement arc, I noticed that you restrict the limbs coordinates to a rectangle (it appears like bouncing from the rectangle's corners) - maybe an elliptical / circular restriction area would be more appropriate, since, after all, it should fit and be placed within a circle (delimited by the moon's border).
kysko
Posts: 4
Joined: June 21st, 2019, 3:07 am

### Re: [Lots of Math] Moon Icon Rotation on a Sky Dial

This thread's getting old, hoping I'm not necroposting... So here's my take.

From the OP, I seem to get the crescent form/orientation isn't supposed to be rotating as the moon is moving along the arc.

A solution would be a transformation of the shapes' coordinates, without additional Shape rotation which would affect all the shape's content. As Yncognito said, things should be calculated from a center, let's call it (cx, cy); where both are larger than R+mR, say cx = cy = R + 50, where R is the dial radius and mR the moon's radius.

The shapes will be moved along the point (mx, my) = (cx - RcosT, cy - RsinT), there T is the angle (signs are so because of the way things are set up: we're dealing with cos and sin of 180-T in fact).

Now the shapes of the moon can be constructed as if done with a coordinate system with origin at center of the moon, and then simply "patched" onto the moving point (mx,my) above.

Example 1: An ellipse moving along the path would be written:

Code: Select all

``Ellipse cx, cy, mR``

Example 2: your limb is made by considering two points, p=(-miR,0) and q=(miR,0), where miR is the moon's inner radius. In "pseudo-code":

Code: Select all

``p | ArcTo q  , miR, phaseRadius, 0, 0 | ArcTo p , miR, miR, 0, 1``
and when "patched" onto the moving point:

Code: Select all

``````p+(mx,my) | ArcTo q+(mx,my)  , miR, phaseRadius, 0, 0 | ArcTo p+(mx,my) , miR, miR, 0, 1

or

(-miR + cx - RcosT, cy - RsinT)
| ArcTo (miR + cx - RcosT, cy - RsinT)  , miR, phaseRadius, 0, 0
| ArcTo (-miR + cx - RcosT, cy - RsinT) , miR, miR, 0, 1``````
You can then rotate the limb with a Transform, and this should be unaffected by the relative move on the dial.
And you don't need the redundant moon to combine, nor some of the other corrections you had to make.

I've attached a mod of the ini found on your Github page as a "proof of concept".
You do not have the required permissions to view the files attached to this post.
raiguard
Posts: 660
Joined: June 25th, 2015, 7:02 pm
Location: The Sky, USA

### Re: [Lots of Math] Moon Icon Rotation on a Sky Dial

Thanks for the reply kysko. However, I am no longer attempting to solve this problem. I realized that the interface I was trying to make wouldn't actually work for what I wanted it to do, so I completely redesigned it:
astrodial obselete.gif
This chart only has the moon shape move up and down, so it only requires one rotation, making the entire problem nonexistent.

Thanks a bunch for your help though! I do appreciate it.
You do not have the required permissions to view the files attached to this post.
”We are pretty sure that r2922 resolves the regression in resolution caused by a reversion to a revision.” - jsmorley, 2017