Re: Challenge: How can we set the rect of a polygon to its visual rect? (and a tentative solution)
It appears that Rev defines the rect of a regular polygon to be the rectangle that encloses all possible rotations of that polygon. To see this, create a regular polygon as graphic 1, create a rectangle as graphic 2, in the message box "set the rect of grc 1 to the rect of grc 2," and then set the angle of grc 1 to various numbers. This seems like a useful enough feature that I wouldn't call it a bug. David Epstein ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Challenge: How can we set the rect of a polygon to its visual rect? (and a tentative solution)
On Sat Aug 15, 2009, capellan capellan2000 at yahoo.com wrote:
Hi Wilhelm,
(snip)
Some time ago, i posted a stack named "export_regular_polygons"
than shows a formula to convert regular polygons (3 to 20 sides)
in polygons:
http://www.geocities.com/capellan2000/export_regular_polygons.zip
Wilhelm Sanke, FB01 wrote:
>
> I conclude: I think it should be a relatively easy task for the
> programmers of Revolution (or Transcript, RevTalk etc.) to abolish the
> inconsistency of regular polygons of having different sizes for visual
> rects and their proper rects as a graphic.
>
i agree. if you fill an enhancement request in the Runrev Quality
Control Center, i will vote for it.
Have a nice weekend.
al
Hi al (or "Al" - or whatever is behind "al" - but no need to out yourself),
Amazing! Your stack indeed really "crops" a regular polygon and converts
it to a normal polygon.
This - your approach to the conversion - was exactly what I was looking
for and had imagined to be feasible.
I took the liberty to set the lockloc of grc "Test" to false to see how
your script handles regular polygons when the polygon is being
"distorted", i.e. when the angles of the regular polygon are not
identical. In this case your script nevertheless determines the points
for the normal polygon on the basis of an ideal shape of the regular
polygon with identical angles, but at the same time considering the set
angle (the possibly rotated angle of the whole polygon) of the regular
polygon.
This "ideal" form of the converted polygon could of course then be
distorted manually to be identical with the visual shape of the regular
polygon. I assume this part of the conversion could also be scripted?--
Just to mention it for the sake of completeness, my own way to convert
regular to normal polygons has been a simple "hands-on" approach - like
in the case of cropping an image to its visual rect, which I had
described in an earlier post:
- I either have traced the regular polygon with the free-hand polygon
tool, which procedure needs a steady hand and in most cases later
fine-tuning of the gained points for the polygon, or
- I clicked at the vertexes of the regular polygon ("put the mouseloc")
to establish the points for the normal polygon, which also may need some
fine-tuning afterwards.--
I believe that the Rev engine internally must know the values of the
vertexes of a regular polygon, otherwise it would not be able to display
the shape of a regular polygon, both in its ideal and distorted form.
So, the task for the Rev team to produce an enhancement that would make
it possible to reduce the rect of a polygon to its visual rect would be
simply to make the values of the vertexes available and retrievable, and
then let the user choose to set the style of the polygon to "polygon"
based on the given points/vertexes.
Best regards,
Wilhelm
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Challenge: How can we set the rect of a polygon to its visual rect? (and a tentative solution)
Hi Wilhelm, Wilhelm Sanke, FB01 wrote: > > Could it be that "the option to crop" is contained in a different > version of your stack? > This the part of the script that crop the image to the size of the user created cropping rectangle: if cropImage = "true" then repeat until foundGraphic = 1 -- or qfl = the number of lines of tSelection put line qfl of tSelection into tGraphic if qfl = the number of lines of tSelection then put 1 into foundGraphic if word 1 of tGraphic is "graphic" and the forecolor of tGraphic = cropColor then put 1 into foundGraphic set the name of tGraphic to "tCropGraphicRectangle" set the layer of graphic "tCropGraphicRectangle" to the layer of tMaskedImage + 1 put the rect of graphic "tCropGraphicRectangle" into zxy do "crop" && tMaskedImage && "to" && zxy else add 1 to qfl end if end repeat end if Wilhelm Sanke, FB01 wrote: > > The question is, how do you compute the points of a polygon (that will > extend to the full size of the rect of a regular polygon without > differences between rect and visual rect) if you do not have a normal > polygon as a template? > Some time ago, i posted a stack named "export_regular_polygons" than shows a formula to convert regular polygons (3 to 20 sides) in polygons: http://www.geocities.com/capellan2000/export_regular_polygons.zip on mouseUp if the hilite of btn "Leave Trails" is false then repeat with i = the number of grcs of this stack down to 3 if the name of graphic i contains "Test" then next repeat else delete grc i end repeat end if -- if fld "sides" is a number then set the polysides of me to fld "sides" set the polysides of me to the short name of btn id 2114 put the polysides of me into asdfg put 360/asdfg into regularPolygonAngle if fld "grcangle" is a number and fld "grcangle" < 361 then set the angle of me to round(fld "grcangle") put the angle of me into qwerty put item 1 of the loc of me into mX put item 2 of the loc of me into mY put the rect of me into lkjhg put abs(item 1 of lkjhg - item 3 of lkjhg) into plm1 put abs(item 2 of lkjhg - item 4 of lkjhg) into plm2 if plm1 <> plm2 then if plm1 > plm2 then put (plm1 / 2) into polarRadius else put (plm2 / 2 ) into polarRadius else put (plm1 / 2) into polarRadius end if if fld "exact" is a number then put polarRadius - fld "exact" into polarRadius -- this is very interesting, because this operation make the figure more exact! repeat with i = 1 to asdfg -- the sides of the reg poly put (regularPolygonAngle * i) + qwerty into ang put (ang * pi )/ 180 into radians -- find rectangular coordinates of ( polarRadius,radians) if the hilite of btn "Use statRound" is true then put statround(mX + (polarRadius * cos (radians))) & "," after rfv put statround(mY + (polarRadius * sin (radians))) & return after rfv else -- the hilite of btn "Use round" put round(mX + (polarRadius * cos (radians))) & "," after rfv put round(mY + (polarRadius * sin (radians))) & return after rfv end if end repeat put item 1 of the first line of rfv,item 2 of the first line of rfv after rfv -- put line 1 of rfv after rfv -- using this line produces an strange bug on -- polygons of 8 sides. It puts letters instead of numbers in the last line set the style of the templategraphic to polygon create grc set the points of it to rfv -- set the rect of it to the rect of me -- lkjhg if the hilite of btn "Put Points into Msg" is true then put rfv choose browse tool end mouseUp Wilhelm Sanke, FB01 wrote: > > I conclude: I think it should be a relatively easy task for the > programmers of Revolution (or Transcript, RevTalk etc.) to abolish the > inconsistency of regular polygons of having different sizes for visual > rects and their proper rects as a graphic. > i agree. if you fill an enhancement request in the Runrev Quality Control Center, i will vote for it. Have a nice weekend. al -- View this message in context: http://www.nabble.com/Re%3A-Challenge%3A-How-can-we-set-the-rect-of-a-polygon-to-its-visual-rect--%28and-a-tentative-solution%29-tp24988110p24989177.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Challenge: How can we set the rect of a polygon to its visual rect? (and a tentative solution)
In the meantime I managed to have a look at the two stacks Scott and Capellan offered in this context. Capellan had written: Hi Wilhelm, Take a look at the script of this stack, to check if some code is useful: http://www.geocities.com/capellan2000/mask_bitmap02.zip This version included the option to crop the image while masking. Your stack that demonstrates possibilities to use masks is surely impressive, but I failed to find a script in the stack that includes a cropping algorithm. Could it be that "the option to crop" is contained in a different version of your stack? === Scott Rossi had offered a sample stack for cropping in his first post of this thread: "http://www.tactilemedia.com/download/crop2alphaRect.rev"; The stack generates a random regular polygon and then creates a matching image cropped to the extents of the original graphic. Thanks again for your contributions to this thread, Scott. Your carefully scripted cropping procedure indeed manages to crop an image - snapshot-generated from a graphic - to its visual rect precisely to the last pixel. I changed the polysides property in your script for higher values and learned that (with the exception of a rhomb - a 4-sided regular polygon) indeed all regular polygons possess "visual" rects that differ from their proper rects. In the case of a 13-sided regular polygon - given the size of your graphics in your sample stack - this difference still is one pixel, certainly negligible, but the difference is there. My own approach to crop images to their visual rects has so far been a simple and manual one: I place a rect over the image, adjust it manually to the edges of the visual contents of the image, and then crop the image to the rect of the overlying rect.-- === What has been overlooked to some extent in your responses was that my original question concerned the "cropping" of a *graphic* and as a *graphic* to its "visual" rect. As selection tools (to access a portion of an image for further processing) I have used freely painted polygons - as distinct from "regular polygons" - for quite a long time in my image processing stacks. My G.W.Bush caricature, which I had presented to this list two years ago and which elicited very diverse responses, was produced with my "Photo Patchworks" stack using among other selection graphics also normal hand-drawn polygons. With normal hand-drawn polygons there are *no* differences between rects and visual rects. The sense or the reason why "regular" polygons should possess such differences escape me. Maybe it is just a case of "sloppy" programming, "sloppy" meaning in this case that the relevant script parts of the engine could be easily improved to abolish such differences in regular polygons. I have experimented a bit and offer here some thoughts and script examples how to convert "regular polygons" to "polygons" without rect differences: Polygons have "points" that determine the shape of the graphic. If you ask for the points of a "regular polygon" you just get the rect values. The shape of a regular polygon is defined by the polysides property and its angle. You can convert a polygon to a regular polygon and vice versa by using "set the style of grc x to "regular" (or "polygon")". If you convert a polygon to a regular polygon you inevitably get a four-sided rhomb, no matter how many sides your original polygon has possessed - unless you determine the number of polysides beforehand. The other way round, converting a regular polygon to a polygon leaves you with an *empty* graphic, because the points of its rect are not acknowledged as valid points for the polygon. But you can define the points of a regular polygon - for example by setting its "points" to the points of a normal polygon. Nothing will happen here when you set these points, until you then convert the regular to a normal polygon. After such a conversion you can switch between the two "styles" of the polygon (set the style of grc x to ..) and will see the different shapes of the styles. Of course it is not reasonable to set the points of a regular to that of a normal polygon, because this normal polygon already exists and can be used for any purposes. The question is, how do you compute the points of a polygon (that will extend to the full size of the rect of a regular polygon without differences between rect and visual rect) if you do not have a normal polygon as a template? Example 1: Create a regular three-sided polygon and set its angle to 30. You will get an upright triangle with a substantial transparent part at the bottom of its rect. Get the dimensions of the rect, compute the points, and then convert it to a normal polygon using a script like this: on mouseUp put the topleft of grc "Test" into TL put the bottomleft of grc "Test" into BL put the bottomright of grc "Test" into BR put the width of grc "Test" into twidth put trunc(twidth/2) into
