Line length on circle scaled to ellipse is very wrong

baz

if you split the circles before the length of the two half curves remains the same when scaled regardless of sides...

Sorry, not quite following you there.

But to restate the question: If I draw a line at 100, Entity Info will tell me its 100.
If I draw an arc and explode, I will get an accurate line length.
However, if I scale a circle to make an ellipse, Entity Info gives me nonsense, and not even consistent nonsense. I just went back to my example model as shown at top and all the reported numbers are now different...

It's to do with scaling, I reckon. It confuses SU's little brain.

ely862me

This might be a bug..

baz

@ely862me said:

This might be a bug..

According to previous posters, it is a limitation of SU. But I can't see why a line shouldn't be a line, whether curved, stretched or otherwise abused.
Shall I load the skp?

Garry K

Circle1 144s at 400 mm - scale by factor of 2
Circle2 288s at 400 mm - scale by factor of 2

entity information reports ~5026.5 mm for both - I don't know where this number comes from

Then pushpull each ellipse into elliptical cylinder
Select arc and explode
entity information now reports ~3872.6 mm for Circle1
entity information now reports ~3875.3 mm for Circle2

Elliptical Circumference calculates out at 3875.38

baz

@garry k said:

Circle1 144s at 400 mm - scale by factor of 2
Circle2 288s at 400 mm - scale by factor of 2

entity information reports ~5026.5 mm for both - I don't know where this number comes from

Exactly! Or inexactly as it happens. Could you open that file again and see if the numbers have changed, they have on mine.

ely862me

Once you get to copy them around you get all kinds of lengths.

pbacot

@baz said:

@pbacot said:

if you split the circles before the length of the two half curves remains the same when scaled regardless of sides...

Sorry, not quite following you there.

But to restate the question: If I draw a line at 100, Entity Info will tell me its 100.
If I draw an arc and explode, I will get an accurate line length.
However, if I scale a circle to make an ellipse, Entity Info gives me nonsense, and not even consistent nonsense. I just went back to my example model as shown at top and all the reported numbers are now different...

It's to do with scaling, I reckon. It confuses SU's little brain.

It doesn't make sense. Really CAD programs should have an ellipse tool.

Screen Shot 2016-02-09 at 8.35.22 AM.png

slbaumgartner

I did some probing via Ruby, and it seems there is a chain of bugs causing this. First, when you scale a circle to make it an ellipse, SketchUp should drop the metadata defining it as a circle and treat it as just a closed loop of segments (a Curve). It does not do so, it continues to carry the center point, radius, and normal vector as if the loop is still a circle, and the edges still say they are part of an ArcCurve. This evidently triggers a second bug in the method that calculates the circumference of the loop. In some cases it still calculates the mathematical 2pir as if the circle hasn't been scaled. In other cases it calculates a strange value that has no evident relationship to anything. In no case does it return the sum of the lengths of the edges!

Wo3Dan

Lengths of (part of) an ellips do not show rigtht. This has been mentioned before.
I hope you can see this thread. See posts around 17/4/2008 and on.
https://groups.google.com/forum/#!searchin/sketchup3d/ellips$2Barea%7Csort:relevance/sketchup3d/z70T5xdUm_I/g-ChcSEcL2YJ

*"Taff, Google SU team,

Very nice approach Taff, almost precise. Here again there is the
lack of a precise ''snap to" with these rotations. But it's the best
you can do!

But I noticed an (important) bug in the "Entity Info" and "Text"
tool output.
The curve length shown is only half of what it should be.

Before you exploded the 1/4 ellipse curve the Entity Info reports
141.371669' as the curve length (also through Text tool)
It should however be: 282.743338'

16 segments out of the exploded curve add up to: 281.923143'
just a bit shorter which is obvious.
The more segments the more precise Taff's approach will be.
Even better when there were a "rotate snap" option to a curve.

Regards,
Wo3Dan "*

baz

Pilou. The actual line length is 2155 +/- 5. measured in the real world.

This thread is starting to make my brain hurt...so, respected elders, is it a Bug or not?

pilou

@unknownuser said:

Using Approximation 2, the perimeter would be 2118.265712279433

A nurbs program 400 * 900 ellipse gives 2118,2799332 length line perimeter

Sketchup gives 2118,276442 with circle 1000 segments

slbaumgartner

I think it is a bug. I looked up the formula for perimeter of an ellipse and compared that with what SketchUp's entity info returns. For a 10x20 ellipse, the result should be 96.88. SketchUp variously returned 62.83 (20*pi), 111.3, and 113.27.

ely862me

There was already a bug submitted for this, yes it is a bug. Also changing lengths when copying an ellipse is a bug. They are in the database and most likely sometime in the near future will be fixed.

mac1

There is no closed form equation for perimeter of ellipse
it is approximated by p=2PIsqrt[[[ a^2+b^2]/2]^1/2]
The correct value p=4aE where E is the elliptic integral where k=1/asqrt[a^2-b^2]

baz

@mac1 said:

There is no closed form equation for perimeter of ellipse
it is approximated by p=2PIsqrt[[[ a^2+b^2]/2]^1/2]
The correct value p=4aE where E is the elliptic integral where k=1/asqrt[a^2-b^2]

Yeah, what Mac said...

slbaumgartner

Mac is right, though there are several other approximate formulas that are better than the one he gave. Also, there are power-series that can be run to enough terms to get arbitrarily close. The point here is that even the sum of the lengths of the edges in the oval comes much closer than the strange values that SketchUp sometimes provides.i

CAUL

The best estimation of the circumference I've found is this:


  def self.circumference(major, minor)
    a = major / 2.0
    b = minor / 2.0 
    d = b / a
    
    x0 = d**0.5
    x1 = d
    x2 = d**1.5
    x3 = d**2
    x4 = d**2.5
    
    s0 = 3929 * x0 + 1639157 * x1 + 19407215 * x2 + 24302653 * x3 + 12892432 * x4
    s1 = 86251 + 1924742 * x0 + 6612384 * x1 + 7291509 * x2 + 6436977 * x3 + 3158719 * x4
    c = 4 * a + b * (s0 / s1)
    return c
  end

It's extremely accurate, unfortunately I don't know where I found it so I can't give credits.