Page 1 of 2
the realPoints
Posted: Tue Jun 07, 2022 10:00 pm
by dunbarx
I use LC a lot to draw stuff.
I made a line graphic that I want to rotate under user control. I have set several custom properties to manage this, restricting the action depending on this or that. Anyway, to rotate such a graphic:
Code: Select all
on mouseStillDown
if the shiftKey is down then
set the idleTicks to 3
revRotatePoly the name of the target,3
end if
end mouseStillDown
Perfectly repeatably, a new custom property, the "realPoints" appears in the custom property set whenever I do a little rotating. If I delete that property, it stays deleted, whatever I do to that graphic,
until I rotate again.
The property has what seem to be points, and, for example, look like this:
3358.568027,7419.037661
3365.35241,7423.277017
This property is not in the dictionary. It does no harm, and seems overly precise for points, though the parts before the decimal point have the same relative differentials as the actual points.
I am just wondering...
Craig
Re: the realPoints
Posted: Wed Jun 08, 2022 4:43 pm
by jacque
It has to be how revRotatePoly keeps track of the current rotation. It's an old command that's scripted in one of the rev libraries.
Re: the realPoints
Posted: Wed Jun 08, 2022 7:28 pm
by dunbarx
Jacque.
OK. Glad to know they calculated to one millionth of a pixel width on whatever giant plane they did the rotation.
Craig
Re: the realPoints
Posted: Wed Jun 08, 2022 7:31 pm
by dunbarx
This comes to about 3 billionths of an inch. I cannot see that, even on my retina display.
Craig
Re: the realPoints
Posted: Wed Jun 08, 2022 8:57 pm
by FourthWorld
That precision turns out to be helpful in the math of rotation.
At the core of this issue is that round-trip rotation tends not to work well, not for any reason specific to LC but just given the nature of the problem. At least some of the rotated points will be approximations of their original relative positions, so rotating over and over and then attempting to rotate backwards the same number of steps will often produce a shape slightly different from the original.
So by capturing the original points, rotations can be done from those rather than from any interim approximations made from the results of other rotations.
And of course this necessitates storing those points, hence the property.
Re: the realPoints
Posted: Wed Jun 08, 2022 10:33 pm
by dunbarx
Richard,
Fair enough, and no surprise. But why store them, and only in their most recent state, in a custom property? It just seemed strange to me that a user-accessible gadget like that would be the repository for what seems to be an entirely internal matter.
Anyway, easy to ignore.
Craig
Re: the realPoints
Posted: Thu Jun 09, 2022 1:25 am
by FourthWorld
Only in their most recent state? That would undo my hypothesis.
If you don't delete them do you see them change with each call to the revRotatePolygon command?
Re: the realPoints
Posted: Thu Jun 09, 2022 2:35 pm
by dunbarx
If you don't delete them do you see them change with each call to the revRotatePolygon command?
Sure, they change (or are recreated) with every call to the command.
I was really wondering not why they exist at all, but rather why they appear in the custom properties of the graphic, since there is no reference to them in the dictionary. And they are created by the engine whether I want them there or not. I assume they are read-only, and guess maybe that was just a convenient place to keep them. Clutter notwithstanding, I would have thought they would be in some internal location.
Anyway, the integral part of their values as the arc rotates are in a range from -20,000 to 20,000. If, at the same rotational position, I get a value for them near the topLeft of a 400 pixel width and height card, and then a value near the botRight, they are about 300 apart. So they are screen locations, though I do not know what they refer to.
Craig
Re: the realPoints
Posted: Thu Jun 09, 2022 2:42 pm
by dunbarx
Richard.
The realPoints are not read only. But one cannot directly change the rotational value of a graphic by:
Code: Select all
set the realPoints of grc 1 to realpointValue
The setting of any new value only takes effect with another call to the "revRotatePoly" command:
Code: Select all
set the realPoints of grc 1 to realpointValue
revRotatePoly the name of grc 1,0
Craig
Re: the realPoints
Posted: Thu Jun 09, 2022 4:24 pm
by FourthWorld
dunbarx wrote: ↑Thu Jun 09, 2022 2:35 pm
If you don't delete them do you see them change with each call to the revRotatePolygon command?
Sure, they change (or are recreated) with every call to the command.
I was really wondering not why they exist at all, but rather why they appear in the custom properties of the graphic, since there is no reference to them in the dictionary. And they are created by the engine whether I want them there or not.
Are they created by the engine or by the scripted revRotatePolygon handler?
Re: the realPoints
Posted: Thu Jun 09, 2022 6:32 pm
by jacque
My guess is that the current rotation has to be stored so that the next calculation knows where to start. For scripted commands, the only choices for permanent storage are to store values in the script or in a custom property. Rather than interfere with user scripts, LC chose to use a property.
The engine isn't directly involved here, it's just a script in a library.
The above is speculation of course.
Re: the realPoints
Posted: Thu Jun 09, 2022 6:52 pm
by SparkOut
My guess is that jacque is right. My other guess is that the realPoints are stored with enough precision (as Craig mentioned 3 billionths of an inch) that repeated calculations for subsequent rotations are sufficiently accurate to render faithfully for all use-cases so far encountered.
Re: the realPoints
Posted: Thu Jun 09, 2022 7:31 pm
by FourthWorld
SparkOut wrote: ↑Thu Jun 09, 2022 6:52 pm
My guess is that jacque is right. My other guess is that the realPoints are stored with enough precision (as Craig mentioned 3 billionths of an inch) that repeated calculations for subsequent rotations are sufficiently accurate to render faithfully for all use-cases so far encountered.
I had
thought the same thing, but if the property is indeed updated after
every rotation I can't see the benefit there. After all, the points after rotation are directly available from the object.
If the points are updated only to contain the last ones used before the current rotation, that may be there to support Undo. But that's just a guess. Until one of us reads the revRotatePolyon scripts it's all just a guess.
Re: the realPoints
Posted: Thu Jun 09, 2022 8:38 pm
by dunbarx
Hmmm.
This is what I get by reading both the realPoints and the ordinary points of a line graphic after a handful of calls to the revRotatePoly command using:
Code: Select all
on mouseStillDown
revRotatePoly the name of grc 1,10
put line 1 of the realpoints of grc 1 & "--------" & line 1 of the points of grc 1 & return &\
line 2 of the realpoints of grc 1 & "--------" & line 2 of the points of grc 1 & return & return after fld 1
end mouseStillDown
And in field 1:
-18780.676846,4891.092553--------795,215
-18828.702613,4756.253671--------747,80
-18573.685473,1702.555557--------783,218
-18597.567095,1561.425594--------759,76
-17816.155126,-1401.596722--------771,219
-17815.166971,-1544.729604--------772,76
-16531.10298,-4327.046189--------758,218
-16505.275074,-4467.83297--------784,77
If I go all the way around, that is, after 36 calls, I get exactly the first "entry" of both types of points. As I should.
I can instantly set the points of that grc to any of the several "ordinary" points, and like any good property, the grc will jump there. But as I mentioned earlier, it requires both setting the realPoints AND a subsequent call to revRotatePoly to have the grc do the same.
All academic, of course. Everything works fine. But it seems the resolution of the realPoints indicates that those are the real calculations used in rotating graphics, and the resultant "ordinary" points are just the closest match to "real" screen pixel values, and are set by the engine as best fit. So perhaps that extra layer of precision is needed in order for me to have the luxury of being able to just use the standard points, in and of themselves not accurate enough, given a pixel-built grid, to keep the faith.
Like many who never keep the faith, and I am one of them, we tend to wander.
Craig
Re: the realPoints
Posted: Thu Jun 09, 2022 10:10 pm
by SparkOut
dunbarx wrote: ↑Thu Jun 09, 2022 8:38 pm
But it seems the resolution of the realPoints indicates that those are the real calculations used in rotating graphics, and the resultant "ordinary" points are just the closest match to "real" screen pixel values, and are set by the engine as best fit. So perhaps that extra layer of precision is needed in order for me to have the luxury of being able to just use the standard points, in and of themselves not accurate enough given a pixel-built grid to keep the faith.
Yes, this is exactly what I was guessing, in that the mathematics was using the realPoints to make the calculations and then translation on screen to the points. I nearly muttered about sub-pixel rendering too but not so sure about that.