Number of Segments too large for given angle and radius

Pop up: ‘Number of Segments to large for given angle and radius’ is a real pain. I have to leave SU17 and revert to using SU16 to overcome issue. It seems to occur every time I want to add a radius. Any plans to put things back to how they were?
On the other hand perhaps I should be making a setting change somewhere else.

Please advise

The number of segments is limited for small radius arcs and circles to reduce the problems created by them when those curves are made 3D. See FollowMe tool issue for an example.

You can work at a larger scale and then scale down after creating the geometry.

1 Like

Thank you Dave R for responding. As the SU sage you may also care to lobby for a sw fix in SU17 which prevents problems when smaller curves are made 3D. [Is that a good idea?].
In the meantime I could either take your kind advice and up-scale or flip between SU’16 &17

1 Like

The trap for number of segments was added in an attempt to reduce the frequency of cases in which people creating small circles with many segments run into problems later. I support the idea that it is better to stop you now than to leave you with confusing problems later. Perhaps just a warning would suffice, but we all know how people ignore warnings and then blame the programmers anyway!

But this approach is really a band-aid over the fundamental cause, which is building models at a smaller size than what SketchUp was designed to handle. As Dave pointed out above, the current workaround is to model at a large size and then scale down to actual size when completed. Particularly for people who work in fractional inches, this workaround is a nuisance - but it does address the problem.

There have been many requests to give the users more control over SketchUp’s small size tolerance. Possibly because there is a known workaround, Trimble has so far not done anything with these requests.

1 Like

I guess that to make SketchUp scale-independent would require quite big changes to its fundamentals. It is a face modelling application, and the applications that are scale-independent are mostly driven by geometry (often NURBS) with the faces generated at different resolutions for display purposes only.

Anssi

Nobody but the developers at Trimble knows for sure. It seems like the threshold should just be a constant that is used by the cleanup code, as opposed to something fundamental about how Sketchup works. I suspect that reluctance to change it derives from two sources:

  • Nobody has tested what other operations are sensitive to the cleanup threshold. That is, where have developers implicitly done things that could break if the threshold was changed? What might modelers do that would provoke new problems? The regression testing to identify and fix problems could be enormous (even if it turns out nothing broke).
  • The existing threshold was chosen as a tradeoff between the smallest details and the largest models SketchUp can handle. If it was changed, there would be a new tradeoff that could cause a whole new raft of user complaints about broken models. You just know that somebody would set the threshold to 0.000001", try to model a city, and then complain about resulting modeling issues - it’s just the mirror of what we get now with small models (hmm…workaround: model very small and scale up when finished :wink:)…

Hi SL Baumgartner - thanks for joining the conversation and advising the
current thinking on this topic.

I’m at a loss as to the contention that creating small circles and radii
could be regarded as bad practice? How can this suddenly be so in the world
of SU?. I have been using SU since V 2008 and can honestly say I’ve never
experienced any confusion in this respect. I’m also a bit surprised at the
declaration that SU wasn’t designed to handle small models! This can’t be
true surely? For the sake of future world sales you may wish to reconsider
that statement.

I don’t work as an architect as you will see if you go the the warehouse
and enter ‘agv’. There, under DO you will find a few of my robot vehicles
at sizes much smaller than street buildings. There’s a westminster chime
clock there as well, drawn up with many small diameter cogs and spindles.

Be assured that I do empathise with and don’t [always], blame the sw
programmers. Including those that are inclined to branch out and dabble in
‘good ideas’.
As previously stated I’ll remain baffled for a while and revert to SU 16
which in my opinion behaves exactly as it should.

Best Regards

David

The way to look at this is as a preventative warning. In 20016, if I tried to draw an arc in a 2mm, 2mm square with 100 sides, it would (kind of) let me… but the geometry it created would be… awkward:

Yes, it lets me draw SOMETHING, but the geometry gets rounded doe to the miniscule size and the results are not pretty.

In 2017, when I try to draw the same thing, I get a message, letting me know that it will not be able to generate the geometry I am trying to draw:

So, it is not that 2017 is less capable than 2016, it is just letting you know that it is not going to draw incorrect geometry from the start.

3 Likes

Hi Anssi

I suppose you are connected, but if not here’s’ a not I just sent to
slbaumgartner:

Hi SL Baumgartner - thanks for joining the conversation and advising the
current thinking on this topic.

I’m at a loss as to the contention that creating small circles and radii
could be regarded as bad practice? How can this suddenly be so in the world
of SU?. I have been using SU since V 2008 and can honestly say I’ve never
experienced any confusion in this respect. I’m also a bit surprised at the
declaration that SU wasn’t designed to handle small models! This can’t be
true surely? For the sake of future world sales you may wish to reconsider
that statement.

I don’t work as an architect as you will see if you go the the warehouse
and enter ‘agv’. There, under DO you will find a few of my robot vehicles
at sizes much smaller than street buildings. There’s a westminster chime
clock there as well, drawn up with many small diameter cogs and spindles.

Be assured that I do empathise with and don’t [always], blame the sw
programmers. Including those that are inclined to branch out and dabble in
‘good ideas’.
As previously stated I’ll remain baffled for a while and revert to SU 16
which in my opinion behaves exactly as it should.

Best Regards

David

I assume this is aimed at Trimble, not me, as I do not work for or speak for Trimble. I am just an informed volunteer.

It’s bad practice only in the same sense as playing with firecrackers. No problem if you know and follow basic safety precautions, but an ongoing source of injuries to people who don’t. The people at Trimble were just trying to reduce the number of support questions by preventing a well-known problem.

Surprised or not, that is the truth. It was originally designed as a tool for architects, and tradeoffs were made based on that use. I think the designers (in retrospect, maybe naively) were surprised at how many other areas it has come to be used in.

1 Like

Gentlemen,

I’m going to bow to your expert knowledge in the matter - and also note
the warnings on use of firecrackers - [crackers being the operative word I
suppose]. Have a look at the attached sketch which appears to me at any
rate, to close the endpoints of a radius 0.002mm both sides from a null
point. I am very happy with that, so will be proceeding accordingly.
Perhaps our brilliant programmers, while in a spirit of goodwill-to all- ’
can at least introduce an option box to accept or discard the rather
irritating pop up advice.

That’s my lot on this topic - thank you for the responses.

David

I know David has signed off, so this reply is directed to others who may come across this discussion later.

I attempted to recreate what is shown in his image using SU 2016. I don’t know the exact sequence of steps he followed. Here’s what I did:

  • I created guide lines 2mm away from the red and green axes.
  • I drew two edges starting at the origin and 2mm long, one along red and one along green
  • I activated the arc tool, picked the intersection of the guides as center, and swung an arc from the end of one of the edges to the end of the other edge.

Below is what I got. You can see that the ends of both edges got “sucked” over to the next vertex of the arc. That is the sort of thing that happens at very small scale in SketchUp. You can’t tell from the image, but this also caused the arc to be decomposed into a series of edges.

Then I modified the previous result by deleting the two (now errant) edges. I noticed while I did so that the small edge cleanup caused the former arc to have a longer segment at each end. That is, the two short edges were replaced with a single longer one. Subsequently I could redraw the two on-axis edges to get the following, which looks just like David’s image. You can plainly see the elongated start and end edges, as you can in David’s image:

So, here is what happened: the original edges were within SketchUp’s nearby vertex tolerance of an arc vertex as the arc was generated. So SketchUp concluded they were meant to intersect and moved the edge’s end to the vertex on the arc, replacing the single edge with two in a slight kink. Then when I deleted the (errant) edges, SketchUp noticed that the prior end vertex was within tolerance of a straight line between the two adjacent former arc vertices, so it decided they were meant to be a single edge and merged them, producing the longer starting edges. I could then redraw the original on-axis edges because the vertex of the elongated former arc edge is farther away from the axis than SketchUp’s tolerance.

This kind of thing may not happen to you every time, but it is lurking out there, is very hard to detect unless you look extremely closely, and can cause downstream glitches in your model. That is why they added the trap in SU 2017.

2 Likes

I do want to point out that this is an issue of scale. You CAN create an arc across very small geometry, but you may have to scale up, first.

This arc was drawn across a 2m square:

Then scaled WAY down:

You can see that the geometry holds when you scale down.

I think the ‘error’ is a good idea but I do feel the error message should be more informative.

Meanwhile here is a simple demo of what the error is trying to avoid, how tiny faces fail when attempting to make them with short segments, and how they can easily exist when created at a larger scale, without having to scale up and back down again.

1 Like

Hello Box…

How well you get your point over with excellent graphics. I didn’t much
want to continue with this conversation preferring to 'go my own way using
SU 16 or up scale in SU17 as previously advised.
That said; I congratulate you as an obvious expert. It’s very plain to
see. So - I thank you very much for taking the time to produce the short
sequence clearly explaining the issue - and, my thanks to the other
contributors as well.

Goodbye,
David

And, why couldn’t we have a check box for “Don’t show this warning again”? Like in other Sketchup warnings?

Not a fan of the warning,
Shep

Okay, so this final response seems to be several months old. Has there been any further resolution? I have used sketchup for years but prior to now the most recent download was 8. I am currently using the trial period to see if I will stay with sketchup or move on to another CAD program. One of my main uses of sketchup is to create DXF files for my CNC router and plasma table. I like to but a small radius at intersecting lines to allow the machines to run smoothly. The radius however needs to be small so that it is not noticeable. This is seeming to be very difficult to accomplish with this new version. I understand the scaling concept but honestly it would be way to cumbersome for me to use in real life. Any other suggestions.

You might try another workflow. Instead of going through a .dxf file, go through a .stl file.
Then, as you are modeling model in Meters but use mm values. (Thus a 20mm x 20mm x 20mm part is modeled as a 20M x 20M x 20M part).

Every .stl importer I’ve heard of (admittedly, that set is small) will ask what the units are on import. Even though you’ve modeled in meters, enter millimeters as the unit when you import!

Advantages:

  1. You only have to “scale” once - by having an intentional mismatch between your SU model at the units used with your .stl import.
  2. Whatever the minimum movement of your CNC router control may be, it will be larger than the smallest radius arc you can draw IN METERS when meters are switched to millimeters - so the warning that number of arc segments is too high for the radius becomes - in essence - “Hey! Your trying to draw an arc that’s too small for the precision of your CNC machines!”

Thank you for responding, unfortunately I firmly believe (and others do as well) that it is a very bad idea to rely on resizing. One of my peers put it like this “It is rediculous for SketchUp to ask people to modify their work flow based on the softwares shortcomings.” And I feel that it could be dangerous and costly as well. Unless Trimbles frontline support team comes up with a solution by tomorrow, SketchUp will lose another customer and I have been using it since the Google beta.

You said:

You asked, I answered. Yes it’s a workaround - and yes it does involve scaling. But it doesn’t involve multiple up/down scales whenever you need to work around SketchUp’s fundamental modeling restrictions. You only have to remember to do it when you import the .stl to your toolpath generator. Having to do something only once, at a specific point in your workflow as you go from one program to another, to me, qualifies as less “cumbersome.”

And I emphasized “fundamental” for a reason. The vagaries of floating point manipulation on computers is, at the root, the cause of the problem. At some point at both the large and small ends of the spectrum, internal calculation precision limits make it impossible to make an algorithmic guess as to whether or not the user intends geometries to merge (at the smallest end). At the largest end, this is also likely part of the the cause of clipping on very large models and models located ridiculously far from the origin.

With that being said, it is my hope that SketchUp makes major changes in this area in their internal modeling engine. Now that new releases will be only for 64 bit computers, there likely is now the ability to “expand” their range of modeling sizes now that they don’t have to support 32 bit computing.

And if you’re really considering abandoning SketchUp “Unless Trimbles frontline support team comes up with a solution by tomorrow …” (emphasis added), you might as well go ahead and do it today because the changes necessary to make it happen likely demand a complete rewrite of their modeling engine. It’s not something SketchUp is going to change before the next major version release, if not two or three major versions later. It’s likely that big of a programming task!

2 Likes