Is there any way to center odd shaped objects? (A triangle for example)
The current implementation seems to center on the bounding box rather than the average of the vertexes. This makes it impossible to properly center odd shaped objects.
Unless I'm missing something?
-- // Chris
On Tue, 07 Dec 2004 09:20:48 -0500, Chris <radical@...367...> wrote:
Is there any way to center odd shaped objects? (A triangle for example)
The current implementation seems to center on the bounding box rather than the average of the vertexes. This makes it impossible to properly center odd shaped objects.
Unless I'm missing something?
-- // Chris
The align dialog allows you to centre to page and others. Would that be what you're looking for? I believe when I last centred an equilateral triangle, it was to the triangle centre.
On Tue, 2004-12-07 at 10:00 -0500, Robert Crosbie wrote:
The align dialog allows you to centre to page and others. Would that be what you're looking for? I believe when I last centred an equilateral triangle, it was to the triangle centre.
Nope. Even an equilateral triangle is not centered correctly (at least in my tests). Try it. Anything with an odd number of sides will not be able to be centered, or rotated for that matter, at its true center.
I mainly need this type of feature when working with geometric shapes or other symmetric type drawings. Think of trying to draw a 5-spoked car wheel or something similar. In many cases eyeballing it might be good enough, but for things like logos that's unacceptably inaccurate. This is especially annoying with complex shapes where you might get artifacts when shapes are not perfectly aligned.
A "snap to point" feature would be nice and helpful in this situation also. If you could select and node and snap that node to another node or grid point, moving the entire shape, that would be useful. So the node would snap to a specific location without changing the shape of the object.
-- // Chris
On Tue, 7 Dec 2004, Chris wrote:
On Tue, 2004-12-07 at 10:00 -0500, Robert Crosbie wrote:
The align dialog allows you to centre to page and others. Would that be what you're looking for? I believe when I last centred an equilateral triangle, it was to the triangle centre.
Nope. Even an equilateral triangle is not centered correctly (at least in my tests). Try it. Anything with an odd number of sides will not be able to be centered, or rotated for that matter, at its true center.
I mainly need this type of feature when working with geometric shapes or other symmetric type drawings. Think of trying to draw a 5-spoked car wheel or something similar. In many cases eyeballing it might be good enough, but for things like logos that's unacceptably inaccurate. This is especially annoying with complex shapes where you might get artifacts when shapes are not perfectly aligned.
A "snap to point" feature would be nice and helpful in this situation also. If you could select and node and snap that node to another node or grid point, moving the entire shape, that would be useful. So the node would snap to a specific location without changing the shape of the object.
Yup, good ideas; we've actually had a number of feature requests along these lines:
[ 863735 ] GUIDES: Snapping for 'shape editing nodes' [ 863737 ] Snap indicator+ snap/guides dialog/palette [ 928027 ] advanced snap features [ 907478 ] RFE: snap to nodes of existing objects [ 903432 ] Snap selection to grid command
I also wrote up a summary of all the snapping/aligning features back in the Sodipodi days: http://www.sodipodi.com/index.php3?section=development/tasks/alignment_snapp...
I think I also did a proposal for a 'snap to centroid' feature but didn't run across it with a quick search. Perhaps you could add a comment about that (or other additional ideas you have) to one of the above feature requests?
Snapping has been on the radar for a LONG time. I think we need someone to get real gung ho on investigating and attacking snapping features. Several people have been interested in working on it, and a few people have improved it a little, but we really need someone to focus on it for a large chunk of time and to make it work very powerfully. I don't think it's super hard, just would take some creativity and passion.
Bryce
Up spake Chris:
The current implementation seems to center on the bounding box rather than the average of the vertexes. This makes it impossible to properly center odd shaped objects.
Is there any way to center odd shaped objects? (A triangle for example)
ITYM an irregular (i.e. not equilateral) triangle.
AFAIK, you can't use the gravitic center (my terminology), only the bounding-box center. If there's already an RFE, submit one. It sounds a useful feature.
AFAIK, you can't use the gravitic center (my terminology), only the bounding-box center. If there's already an RFE, submit one. It sounds a useful feature.
Will it be useful not only for triangles? If you use a gravity center for an arbitrary path, its curved parts with many nodes will be heavier than smooth parts. Is this what you want? Also not all objects have nodes (e.g. <image> has no nodes), and a line of text has so many scattered nodes that this metric becomes useless IMHO.
I think just going on nodes is wrong. A centroid would make more sense. However, this is not a simple calculation, you'd need to include the lines because it may only be lines, and do you weight differently if the centre fill is empty. And what is empty, is partial transparency partially empty? And if you fill in white when the background is white does this have weight? Visually it might not but computationally it would have to, otherwise it would be wrong when you changed the background colour.
And after all that I bet I'd move it again anyway because of the form and flow of the items I was aligning.
http://www.efunda.com/math/areas/Centroid.cfm
Cheers Jamie
-----Original Message----- From: inkscape-user-admin@lists.sourceforge.net [mailto:inkscape-user-admin@lists.sourceforge.net]On Behalf Of bulia byak Sent: Wednesday, 8 December 2004 9:32 a.m. To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] Centering odd shapes
AFAIK, you can't use the gravitic center (my terminology), only the bounding-box center. If there's already an RFE, submit one. It sounds a useful feature.
Will it be useful not only for triangles? If you use a gravity center for an arbitrary path, its curved parts with many nodes will be heavier than smooth parts. Is this what you want? Also not all objects have nodes (e.g. <image> has no nodes), and a line of text has so many scattered nodes that this metric becomes useless IMHO.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Up spake bulia byak:
AFAIK, you can't use the gravitic center (my terminology), only the bounding-box center. If there's already an RFE, submit one. It sounds a useful feature.
Will it be useful not only for triangles?
Well, I can't think of anything that I'd use it for, but is that any reason not to do something?
If you use a gravity center for an arbitrary path, its curved parts with many nodes will be heavier than smooth parts. Is this what you want?
I was thinking of center of gravity being based on area.
Let O be the object. Let G be the center of gravity of O. Let Ri be a ray from G to infinity such that the minor angle between the base ray and Ri is i. Let Rj be another such ray, such that the minor angle between Ri and Rj is j. Let Aij be the area of O between Ri and Rj. G is the point that best satisfies the following condition: (approximates (quotient (sum (n in 0 to (product 2 Pi)) ;; interval is 1 (radian) (sum (m in 0 to (product 2 Pi)) ;; interval is 1 (radian) Anm)) (product 2 Pi 2 Pi)) 0)
That's rather messy, slow and probably incorrect. It's two days past my bedtime.
Also not all objects have nodes (e.g. <image> has no nodes), and a line of text has so many scattered nodes that this metric becomes useless IMHO.
(Non-transparent) images are rectangles. Text follows the same algorithm, but it'd be as slow as a complex path.
On Wed, 8 Dec 2004, Trent Buck wrote:
Up spake bulia byak:
AFAIK, you can't use the gravitic center (my terminology), only the bounding-box center. If there's already an RFE, submit one. It sounds a useful feature.
Will it be useful not only for triangles?
Well, I can't think of anything that I'd use it for, but is that any reason not to do something?
Actually I've run into several cases with technical drawing where snap to centroid would have been useful. I ended up just manually fiddling it into position.
Imagine for example a drawing of a lamp with a power cord strung out behind it. Obviously you want the image to snap to the center of the lamp, and with centroids, the 'weight' of the cord would be negligible so you'd get (pretty close to) the true center. However with bounding-box centering you get a different centering location.
This may seem like kind of a corner case, but it actually comes up a surprising amount of the time when you're trying to create flow charts, network diagrams, and so on, where you're attaching irregular shapes to lines.
If you use a gravity center for an arbitrary path, its curved parts with many nodes will be heavier than smooth parts. Is this what you want?
I was thinking of center of gravity being based on area.
Let O be the object. Let G be the center of gravity of O. Let Ri be a ray from G to infinity such that the minor angle between the base ray and Ri is i. Let Rj be another such ray, such that the minor angle between Ri and Rj is j. Let Aij be the area of O between Ri and Rj.
G is the point that best satisfies the following condition:
(approximates (quotient (sum (n in 0 to (product 2 Pi)) ;; interval is 1 (radian) (sum (m in 0 to (product 2 Pi)) ;; interval is 1 (radian) Anm)) (product 2 Pi 2 Pi)) 0)
That's rather messy, slow and probably incorrect. It's two days past my bedtime.
If I remember from engineering class, there's several different schemes for calculating different sorts of centroids, including approximation methods (for highly complex shapes, centroids can be relatively expensive to calculate.) I imagine that it would probably be worthwhile to implement this in a way that would allow for more than one centroid calculation algorithm.
Bryce
I was thinking of center of gravity being based on area.
Let O be the object. Let G be the center of gravity of O. Let Ri be a ray from G to infinity such that the minor angle between the base ray and Ri is i. Let Rj be another such ray, such that the minor angle between Ri and Rj is j. Let Aij be the area of O between Ri and Rj. G is the point that best satisfies the following condition: (approximates (quotient (sum (n in 0 to (product 2 Pi)) ;; interval is 1 (radian) (sum (m in 0 to (product 2 Pi)) ;; interval is 1 (radian) Anm)) (product 2 Pi 2 Pi)) 0)That's rather messy, slow and probably incorrect.
If you can code this in C/C++ using our livarot/Path.h class which describes the path of an object, I will hook it up as an option for the pivot point (maybe it's best to make this a point to which pivot snaps when you drag it, with an appropriate message in the statusbar, e.g. "pivot snapped to the object's center of gravity"). That would indeed be useful. Slowness is not a too big concern since this calculation will only fire when you start dragging the pivot, not when you select something. Also your algorithm should return not only a point but the overall weight of the path, so that centers of gravity of several selected paths can be averaged based on their relative weights.
(Yeah, I realize it's the user list, and I was recently chastised for proposing to make a patch here, but since you already wrote some code I though it would be OK in this case :)
Up spake bulia byak:
(approximates (quotient (sum (n in 0 to (product 2 Pi)) ;; interval is 1 (radian) (sum (m in 0 to (product 2 Pi)) ;; interval is 1 (radian) Anm)) (product 2 Pi 2 Pi)) 0)That's rather messy, slow and probably incorrect.
If you can code this in C/C++ using our livarot/Path.h class which...
(Yeah, I realize it's the user list, and I was recently chastised for proposing to make a patch here, but since you already wrote some code I though it would be OK in this case :)
It's OK to ask, but there's *NO* way I can do anything that involved (observe that I have mediocre C and ~ no C++ experience, and am not familiar with any of the code base). Sorry.
Also note that the above algorithm doesn't suggest any way of picking a point to test. Maybe you could start at the bboux center, then head in the `heaviest' direction, but I dont know if that would work reliably for concave shapes.
-trent PS: The above `code' is about as far from imperative code as the limit of a geometric series.
I did some reading this afternoon[0], and I believe this is the correct algorithm for paths with straight edges (polygons):
Let S be a shape (path) with n points. Let x[i] and y[i] be the coordinates of the ith point. Let x[c] and y[c] be the coordinates of the centroid. (assign x[c] (quotient (sum x[0] x[1] ... x[n]) n)) (assign y[c] (quotient (sum y[0] y[1] ... y[n]) n))
[0] http://en.wikipedia.org/wiki/Center_of_mass
participants (6)
-
Bryce Harrington -
bulia byak -
Chris -
Jamie Walton -
Robert Crosbie -
Trent Buck