I’ve searched high and low in the docs, but i cant find how to get the 4 vertices coordinations of a rectangle… so how do i get them?
Michael is probably right, but if you’re not looking for that and simply want to know the <x,y> positions of a rectangle’s vertices, do this:
local rect = display.newRect( 200, 200, 300, 400 ) -- upper left local ul\_x = rect.x - rect.contentWidth/2 local ul\_y = rect.y - rect.contentHeight/2 -- upper right local url\_x = rect.x + rect.contentWidth/2 local ur\_y = rect.y - rect.contentHeight/2 -- lower right local lr\_x = rect.x + rect.contentWidth/2 local lr\_y = rect.y + rect.contentHeight/2 -- lower left local ll\_x = rect.x - rect.contentWidth/2 local ll\_y = rect.y + rect.contentHeight/2This does not work, only if the rectangle has no rotation.
I would like to know for rotated rectangles as well =)
No, the above works fine for the question you initially asked which didn’t mention rotation.
To get the positions of the vertices, you need to use basic trigonometry or geometry depending on the way you want to think of the problem.
Googling this: calculate vertices of rotated rectangle
resulted in this (and other options)
Combine these calculations with known quantities about Corona SDK objects, just as:
- The position of a rectangle is typically the centroid of the rectangle (when anchors are 0.5)
- To get the width and height of a rectangle, regardless of rotation, access the .width and .height fields.
- The rotation of an object is .rotation.
That and the math is all you need to get your answer.
Oh, and don’t forget that in Corona (and other rendering systems), +Y is down, not up as per the usual Cartesian system.
This will affect the signs of the calculations.
Start off calculating for a non-rotated rectangle where you know the vertices to test your calculations, then rotate it 90 degrees at a time to verify that math.
Once you have that working you’ll be good to go.
Yes I resorted to math. I am just very surprised the api doesnt support providing me the vertices.
Btw, correct me if i am wrong, but a rectangle is still a rectangle if it is rotated… right?
I’m detecting a hint of smart-mouth… However, I will just assume you’re playing with me.
So ha ha…
- Yes, a rectangle is a rectangle if rotated.
- No, you are wrong in your implication. Getting the vertex positions for rectangle becomes less trivial if it is rotated.
Please remember, as I have already stated, you didn’t mention rotation in you original question.
You left me (and others) with the open question, “Does s/he mean rotated or non-rotated?” The prior is non-trivial but still achievable, while the latter is straight-forward.
I asked myself that question and decided, “Until s/he clarifies, I will assume s/he means non-rotated or I’ll be wasting my time explaining something s/he doesn’t want to know.”
re: API
You said the API should just provide this, but I disagree (at least partly). If you think about it for a second, It doesn’t really make sense for the API to pre-calculate vertex positions. Why? Because this would imply four costly calculations per-frame when the result of those calculations will 99.9% of the time go unused.
A feature that might be useful and for which you can certainly submit a feature request, is the ability to have the API calculate these values on demand. http://feedback.coronalabs.com/forums/188732-corona-feature-requests-feedback
the problem is frame of reference - there are at least 4 ways to properly answer the original question:
(examples use a 100x50 rect positioned at 100,100 rotated 45 degrees)
-
local coords, untransformed (ex: +/- <50,25>)
-
local coords, transformed (ex: +/- <~53,~17>)
-
content coords, untransformed (ex: <100,100> +/- <50,25>) <-- what was answered
-
content coords, transformed (ex: <100,100> +/- <~53,~17>) <-- what OP apparently wants
(btw, this is equiv to asking yes/no to applying position/rotation transforms individually, thus 4 combos)
(btw, the first and last are most commonly encountered - being no/no and yes/yes re: pos/rot individually)
(btw, ALL of those answers are valid as long as you specify which frame you’re referencing - the problem in this thread seems to be that the desired frame wasn’t originally stated)
(btw, this also leaves aside any consideration that the rect may be nested in yet other groups with their own reference frames, each one of which would double again the number of possible valid answers as to “which frame(s) do you want your coordinates in reference to?”)
(btw, scale is also a part of a frame transform, but isn’t separately considered herein)
regardless of all those btw’s, proper use of this and this can solve any of these cases
Michael is probably right, but if you’re not looking for that and simply want to know the <x,y> positions of a rectangle’s vertices, do this:
local rect = display.newRect( 200, 200, 300, 400 ) -- upper left local ul\_x = rect.x - rect.contentWidth/2 local ul\_y = rect.y - rect.contentHeight/2 -- upper right local url\_x = rect.x + rect.contentWidth/2 local ur\_y = rect.y - rect.contentHeight/2 -- lower right local lr\_x = rect.x + rect.contentWidth/2 local lr\_y = rect.y + rect.contentHeight/2 -- lower left local ll\_x = rect.x - rect.contentWidth/2 local ll\_y = rect.y + rect.contentHeight/2This does not work, only if the rectangle has no rotation.
I would like to know for rotated rectangles as well =)
No, the above works fine for the question you initially asked which didn’t mention rotation.
To get the positions of the vertices, you need to use basic trigonometry or geometry depending on the way you want to think of the problem.
Googling this: calculate vertices of rotated rectangle
resulted in this (and other options)
Combine these calculations with known quantities about Corona SDK objects, just as:
- The position of a rectangle is typically the centroid of the rectangle (when anchors are 0.5)
- To get the width and height of a rectangle, regardless of rotation, access the .width and .height fields.
- The rotation of an object is .rotation.
That and the math is all you need to get your answer.
Oh, and don’t forget that in Corona (and other rendering systems), +Y is down, not up as per the usual Cartesian system.
This will affect the signs of the calculations.
Start off calculating for a non-rotated rectangle where you know the vertices to test your calculations, then rotate it 90 degrees at a time to verify that math.
Once you have that working you’ll be good to go.
Yes I resorted to math. I am just very surprised the api doesnt support providing me the vertices.
Btw, correct me if i am wrong, but a rectangle is still a rectangle if it is rotated… right?
I’m detecting a hint of smart-mouth… However, I will just assume you’re playing with me.
So ha ha…
- Yes, a rectangle is a rectangle if rotated.
- No, you are wrong in your implication. Getting the vertex positions for rectangle becomes less trivial if it is rotated.
Please remember, as I have already stated, you didn’t mention rotation in you original question.
You left me (and others) with the open question, “Does s/he mean rotated or non-rotated?” The prior is non-trivial but still achievable, while the latter is straight-forward.
I asked myself that question and decided, “Until s/he clarifies, I will assume s/he means non-rotated or I’ll be wasting my time explaining something s/he doesn’t want to know.”
re: API
You said the API should just provide this, but I disagree (at least partly). If you think about it for a second, It doesn’t really make sense for the API to pre-calculate vertex positions. Why? Because this would imply four costly calculations per-frame when the result of those calculations will 99.9% of the time go unused.
A feature that might be useful and for which you can certainly submit a feature request, is the ability to have the API calculate these values on demand. http://feedback.coronalabs.com/forums/188732-corona-feature-requests-feedback
the problem is frame of reference - there are at least 4 ways to properly answer the original question:
(examples use a 100x50 rect positioned at 100,100 rotated 45 degrees)
-
local coords, untransformed (ex: +/- <50,25>)
-
local coords, transformed (ex: +/- <~53,~17>)
-
content coords, untransformed (ex: <100,100> +/- <50,25>) <-- what was answered
-
content coords, transformed (ex: <100,100> +/- <~53,~17>) <-- what OP apparently wants
(btw, this is equiv to asking yes/no to applying position/rotation transforms individually, thus 4 combos)
(btw, the first and last are most commonly encountered - being no/no and yes/yes re: pos/rot individually)
(btw, ALL of those answers are valid as long as you specify which frame you’re referencing - the problem in this thread seems to be that the desired frame wasn’t originally stated)
(btw, this also leaves aside any consideration that the rect may be nested in yet other groups with their own reference frames, each one of which would double again the number of possible valid answers as to “which frame(s) do you want your coordinates in reference to?”)
(btw, scale is also a part of a frame transform, but isn’t separately considered herein)
regardless of all those btw’s, proper use of this and this can solve any of these cases