the realPoints

[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

[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.

[dunbarx]

Jacque.

OK. Glad to know they calculated to one millionth of a pixel width on whatever giant plane they did the rotation.

Craig

[dunbarx]

This comes to about 3 billionths of an inch. I cannot see that, even on my retina display.

Craig

[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.

[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

[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?

[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

[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

[FourthWorld]

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?

[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.

[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.

[FourthWorld]

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.

[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

[SparkOut]

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.