Path.area() doesn't calculate area correctly

[Grepsy]

// square 10x10
var path = new paper.Path([
    new paper.Point(0, 0),
    new paper.Point(10, 0),
    new paper.Point(10, 10),
    new paper.Point(0, 10)
]);

console.log(path.area); // outputs 120, expected 100

For a full demo see: http://jsfiddle.net/4hLqhmey/

[lehni]

Oh dear, indeed. @iconexperience could this be linked to our recent optimizations? Or has the calculation been wrong all along?

[lehni]

Here the sketch

[lehni]

And here's the mentioned change: b5af47a

[lehni]

Indeed, reverting it back, and we get the correct 100... @iconexperience could you look into this again?

[lehni]

Oh, it looks like it was my fault : ) #788 (comment)

[Grepsy]

Also strange behaviour is when using closed = true it returns half of the area. See sketch

[lehni]

You,re right, but it returns that regardless of the closed state, treating it as a triangle. It looks like the connecting curve is being ignored here...

[lehni]

Wait, that example only has three segments, so it is a triangle. For paths with straight lines, the closed state doesn't make a difference.

[Grepsy]

Ok, that's surprising to me because the documentation from closed states:

Specifies whether the path is closed. If it is closed, Paper.js connects the first and last segments.

So I assumed it would 'close' the polygon effectively making it a square. Am I misunderstanding what closed means?

[lehni]

Yes of course, but what's the area of a path that isn't closed? It could only return 0 if it was to take it into account. If you don't close a path, but fill it with a color (fillColor = ...), the first and the last segment are connected with a straight line. If you close the path, then the handleOut of the last segment and the handleIn of the first are forming the connecting curve instead. area behaves the same way, by always returning the area of the shape enclosed by the path.

[iconexperience]

@Grepsy: I think there may be a little misunderstanding with your sketch. Are you aware that the path in your sketch actually IS a triangle when being closed?

Here is the modified sketch drawing the stroke

I think you simple forgot the fourth point :)

But that does not change the fact that the calculated area is 20% too large.

[Grepsy]

I'm so sorry! You guys are totally right, please excuse me and forget those
last comments.

On Wednesday, 24 February 2016, Jan notifications@github.com wrote:

@Grepsy https://github.com/Grepsy: I think there may be a little
misunderstanding with your sketch. Are you aware that the path in your
sketch actually IS a triangle when being closed?

Here is the modified sketch drawing the stroke
http://sketch.paperjs.org/#S/ZY69DoIwEMdfpekECYGyOECcfAETR9qhlgsY6l3TFjUxvruH0cmb7v+R391Tor2C7ORpgexmWUlH46ZvNopg8yz2AuHOa4BYH9koBo2CZ1CVUKb6ivZPtcpoNGWvccPUzlOCkWk5rvAzU460wIE8RU60nCIAasmxRkeYyEPtaSo+ZRvBlr1oGkFrDmtOYsdn4BHAZSa3SvH3Zy4tgS6Yk+wG83oD

I think you simple forgot the fourth point :)

—
Reply to this email directly or view it on GitHub
#994 (comment).

[lehni]

No worries, these things happen all the time : )

[lehni]

@iconexperience do you think we should bring back getEdgeSum() to determine the orientation of a path? The calculation of the area is a bit more complex, but I quite like the idea that we could use the same code for both values, also since area already supports caching of the result.

[iconexperience]

Not sure, but I think the calculation of the area can be simplified a bit. At least grouping all those 1.5 *, 3.0 * and 0.5 * should be done, but I think a little more simplification is possible. At the end there will probably be not much difference to calculating the edge sum. I will look at it over the weekend.

[lehni]

Yeah I have that simplification in a stash locally, but wanted to wait for your opinion.

[iconexperience]

On the other hand, using the edge sum is quite elegant and the calculation of the orienation will always be a bit simpler when using the edge sum. But you will have a few extra lines of code. Difficult, but both solutions are acceptable to me. You decide :)

[lehni]

Haha, yeah... Can we be certain that both change sign in the same situations?

[iconexperience]

Alright, I tried to simplify the calculation of the area, and this is all I can come up with:

var getArea2 = function(v) {
   var p1x = v[0], p1y = v[1],      
        c1x = v[2], c1y = v[3],     
        c2x = v[4], c2y = v[5],     
        p2x = v[6], p2y = v[7];     
    return 1.5 * ((p2y - p1y) * (c1x + c2x)
        + c1x * (c2y - p1y)
        + (p1x - p2x) * (c1y + c2y)
        + c1y * (p1x - c2x)
        + p2y * (c2x + p1x/3)
        - p2x * (c2y + p1y/3)) / 10;
};

There are 21 mathematical operations instead of the 27 operations in the current implementation. This is an improvement, but I am not really happy with the result, because it is all but elegant. Actually, it is the opposite of cool.

@lehni It' really up to you to decide if we should use this simplified version. I would stick with the current implementation, or at least put the original calculation into the code comment, so others can later try again to find a better simplification.

Here is a sketch that compares the results of the original with the new implementation.

[lehni]

Well I think that's great, and pretty cool actually! Just not very symmetrical, if that's what you mean.

We could shorten it a bit more and use 3 * ... / 20 : ) Still works!

[iconexperience]

I found it incredibly difficult to work on that simplification, but I have a cold, so maybe I just couldn't concentrate very well. If someone else wants to try finding a better solution it may be easier to first replace the variables with a, b, c, d, e..., because all those 1/2, x/y really make your head spin.

Anyway, I am happy that you like it :)

[deanm]

I don't know much about paper but I just ran across this bug, and thought maybe this might be useful. Many graphics systems have paths that can be a mixture of lines / quadratics / cubics (and sometimes, unfortunately, conics). I believe what paper basically does now is compute the area by elevating everything to cubic degree. You could also calculate the area directly for line / quadratic / cubic. The math is not difficult, but just in case here is a writeup of the different cases.

http://deanm.github.io/graphics/2016/03/30/CurveArea.html

And JavaScript code for line / quadratic / cubic "signed area under curve".

function line_sauc(x0, y0, x1, y1) {
  return (x0*y1 - x1*y0) / 2;
}

function bez2_sauc(x0, y0, x1, y1, x2, y2) {
  return (  x2*( -y0 - 2*y1) +
          2*x1*(  y2 -   y0) +
            x0*(2*y1 +   y2)) / 6;
}

function bez3_sauc(x0, y0, x1, y1, x2, y2, x3, y3) {
  return (  x3*(  -y0 - 3*y1 - 6*y2) -
          3*x2*(   y0 +   y1 - 2*y3) +
          3*x1*(-2*y0 +   y2 +   y3) +
            x0*( 6*y1 + 3*y2 +   y3)) / 20;
}

[lehni]

In which version of paper.js are you observing the bug?

That's a great write up, thanks!

[deanm]

Sorry, by "this bug", I just meant the github issue, and that I just left a comment here in case it was relevant. I didn't mean that I encountered a bug in paper, just the "github issue". : )