@thomthom said:

If you draw a Circle - Entity Info says Circle, 24 segments.
Draw a line between two vertices of that circle and you get two arcs with 12 segmetns each.
Erase the edge between them and SketchUp merges the two arcs into a single Arc with 24 segments. Now here's the little extra head scratcher - save, close and reopen the file. Select the curve and notice that Entity Info once again says Circle. o_O

I'm not seeing that. I still get an arc of 24 segments...exactly as when closed.
However, if I get to the stage of creating an arc of 24 segments and then copy either the face or the edge (or both) I get a new circle of 24 segments that is recognised as such. Seemingly the simple act of copying recreates a circle entity.

Yes, I definitely think that copying the original is probably the easiest way to go. I think that's how TIG's script works also.
On the problem of interior offsets, I long ago gave up using the Offset Tool or even Follow Me (most of the time). The shape below was constructed by positioning a scaled copy of the outside shape then using Curviloft and tweaking the individual contours to give a rounded profile rather than the straight truncated pyramid. A workaround, I admit...but a heck of a lot quicker than using SU's standard tools, then having to clear up all the mess.
(Yes, I know there's Rounded Corners in 3D, but it's not always appropriate...and it too can give some nasty intersections)

But as I said in an early post, there is a fundamental mismatch between the way SU draws arcs and circles and the way it draws offsets. It can only sensibly draw offsets perpendicularly edge to edge; but it calculates arcs and circles point to point or centre to point. If the Arc Tool could be persuaded to construct arcs with the measuremnt being made from a segment mid-point instead of an end point, then the problems associated with offset largely disappear...as in the diagram. Those are real offsets, not doctored concentric circles.
It does, however require that an arc begins and ends with a half-segment.

Yes Jeff, Joe's machine is getting pretty long in the tooth now. Joe, are you still using a CRT monitor, or have you got a flatscreen yet?
I'm very sceptical (British spelling) that it would take to kindly to being asked to handle 10 pics in a lossless format that were each over 6000 pixels wide, which is why I suggested 300 ppi. If it's good enough for book covers and glossy magazines, it's probably ok for CDs.

But Thomas, that doesn't alter the basic problem of the arc not actually being and arc but a series of segments. Saying that SU knows the radius is pretty meaningless when you get different measurements for such a radius depending on whether you are measuring from the centre to a point or to an edge.
SU has no option but to offer offsets from the edges, not the points. Think of the confusion that would arise if you were to offset 1m from a rectilinear shape...only to find that the resulting 'path' was only 1m wide as measured by the diagonal from the corner.

Surely it would make much more sense to be demanding this kind of 2D operability within Layout, not the modeller? LO deals in true bezier curves; and would therefore offer true, accurate offsets... the results of which could be carried into SU. In fact you could not only have a decent Offset tool in layout, but a decent, parametric Contour tool also...one in which you could specify how many offsets you wanted, at what distance; and whether they were to be exterior or interior to the original curve.
All this could be then worked up in 3D in SU (with the necessary faceting compromise) while still remaining gemetrically accurate in Layout.
If they could figure some way of further increasing the communication between LO and SU so that LO acted as a geometrically accurate proxy for SU, even better.

I'm not saying that the Arc and Offset tools don't need more work in SU...they do...lots of it...especially when interior offsets (of rounded corners, for instance) turn themselves inside-out instead of just shrinking sensibly. However, that very feature requires SU to second-guess what your intentions are...and therefore become necessarily more complex. It is only in a very rare and specific instance that such interior offsets would be geometrically accurate and remain concentric. So actually demanding that such offsets do not turn themselves inside-out is asking SU to be geometrically inaccurate...exactly the opposite of what is being demanded in this thread. Things get complicated.

Hi Joe,
Jpg is a lossy format. That is, if you mess about with it...especially resizing it...it will start to lose definition and get blurry, especially the fine lines and text. It's okay for digital photographs, when you tend not to notice these things, but not good for line drawings.
Personally, I'd think about using Tif format. Tiffs can be very large compared to jpgs when in full colour, but a simple black and white or greyscale is usually much smaller It is also the standard image format for the publishing industry because it is lossless...lines and text will stay sharp. Png files are lossless too.
If you're bringing them into Corel, I'd also consider not bothering to resize them beforehand. just bring them in full size (if your PC can stand it). Just import them one on top of the other, then select and resize them all in one go before arranging them on the sheet.
Whatever size page you are contemplating, if you have to resize them, I'd work on the basis of having images of 300 dpi (dots per inch) for best quality. Therefore, whether you are having them on an 11" page or two across a 2ft sheet, either way they are going to be the best part of a foot wide and therefore would need to be approaching 3600 pixels. Maybe you could consider exporting at 3000-3500 pixels wide and not bothering to resize at all.

@desertraven said:

@alan fraser said:

Chill out guys. I'm not defending the behavior, merely explaining the logic behind it. As TIG says, the Offset Tool works accurately in it's own way. ......

I don't want to miss pointing out that I am, for my part, talking about SU "PRO";
Pro as in Professional. So I'm up for a fight and I will un cover more of SU's so called shortenings, at least that way I can say I did something instead of letting it just slip.
Anyone here who is serious about doing professional work here should join in to the fight for fixing SU.

There is also the promise of an easy to use easy to learn application, and until certain shortcomings are eventually fixed or at least recognized by the developers, this promise is not being met.

Before you start insinuating that I'm some kind of complacent, unprofessional dabbler, maybe I ought to point out that I've been beta testing this software for the best part of a decade...and that quite a number of basic taken-for-granted functions that are now part of the core program are there at my urging.
There are solutions to these kind of issues, as TIG points out...either by using plugins or a little common sense. personally, I'd rather go that route than have the program overly-complicated by attempting to second-guess what your intentions are.
You might regard that arc as a true arc with a centre, but as far as SU is concerned it's just a curved polyline...and it offsets it accordingly....and accurately in that context.
If you want it offset in the context of being a segment of a circle of known radius, then might I suggest you actually draw a circle of known radius and offset that...then delete what you don't need...or use TIG's script.
Either way, if you intend fighting for a better SU at my expence I'll fight right back.

Chill out guys. I'm not defending the behaviour, merely explaining the logic behind it. As TIG says, the Offset Tool works accurately in it's own way. However, as far as I can see, that way isn't much use to most people most of the time...me included.
It seems that most of the problems arise from having the Arc and Circle tools being defined by distance to end points, while the offset Tool does exactly the opposite and works on the principle of offsetting the perpendicular distance from the edges between those end points.

TBH I can't really see how the Offset Tool can work any differently...especially when you consider offsetting rectilinear shapes. I guess what I'm trying to say is that the the fault doesn't necessarily lie with the offset Tool itself...more how SU handles arcs and elipses. If it was more aware of the true nature of any given curve, then perhaps we wouldn't see the problems we do when offsetting them.

For example, it would be useful to have the option of drawing arcs and circles defined by a radius from the centre to mid-facet...measuring the same way that the Offset Tool does. If an arc is drawn in this way, then Jeff's example of drawing such an arc of radius 10 units and offsetting by 1 unit yields a completely accurate offset. The radius of the offset is 11, not 11 1/16 or something equally weird.

TIG is perfectly correct (of course) The offset Tool works as an Offset Tool, not a Scale tool. In Olav's posted image above, you will find that the internal and external offsets are produced accurately; and the ends of those offsets are perfectly aligned with a perpendicular being drawn from the end points of the original arc.
Unfortunately, the consequence of the original arc not being a true curve, but a series of straight edges, results in these new end points not being aligned with the centre of the original arc.

Think of it this way; if the original arc had been a full semicircle, then the ends of the two offsets would be expected to be lined up with the ends of the original. In other words, all 3 arcs sharing the same baseline. However, because the curve is segmented, the only way this is going to happen is if the two end segments of the original arc are exactly parallel. You simply won't get this using the Arc Tool. You'd need to draw a full circle then rotate it so the the bisector ran through the mid point of two opposite and parallel edges....or use TIG's plugin.

It's effectively the same problem that is encountered when Follow Me is used along a curved path...the end faces may not be aligned exactly the way you would expect them to be on a true curve. It would be nice if both tools offered the plain vanilla and true-curve options.

What the guy probably means is that there are too many line segments on the curves after bringing your ai file into SketchUp. SU can't deal with bezier curves, so it will reproduce all those curves as a series of straight lines. If this is done by straight exporting the default settings will probably result in 10,000s of tiny line segments along those curves.

To be honest, if the cutter can deal with beziers, you are probably better avoiding SU altogether and finding some other way of achieving a dwg file that is acceptable.
If you have to go through SU, then what you'll need to do is edit the curves in Illustrator. You'll need to add tons more anchor points to the curves and then turn the curves into straight lines before export.

Obviously there is a trade-off between the number of anchor points and the resulting smoothness of the curve (which is no longer a curve but a series of straight line segments), but it shouldn't be too difficult to add enough extra anchor points to produce what seems to still be a real curve...yet still have far fewer lines than your current method of exporting to SU...perhaps an order of magnitude fewer.

Did somebody lose a cat?

Disabling AdBlock for SCF may not be enough. I also have the Ghostery plugin for Firefox (it allows control of tracking cookies) I found that had to be disabled too. There may be others as well.

Now why didn't I think of that?....especially as I did exactly that myself only yesterday.

I've never come across this in more than 10 years. AFAIK SketchUp measures everything internally in inches, regardless of the units being used. A component that imports too big does so because it is too big.

As Dave says, this is almost certainly a question of component definition. For instance, if you create a chair 10x normal size then select and make it a component, the component definition will be 10x normal size...even if that component in the model space is then selected and shrunk down to normal size. All you have done is reduced that componet instance to normal size...not the definition. To change that, you need to enter component edit mode and shrink the actual geometry inside the component itself.

You need to do this before you start peppering your model with multiple instances that have already been 'instance-scaled'...otherwise those already-scaled instances will shrink even further.

Staging camp.

I was going to say that the site might be down again for a few hours while the hosting company reconfigures the sparkly new back-up servers...but it looks like they may have already started.

Amazing! If you zoom right in to the head of the glacier...the flatter bit that is showing beyond the V-shaped notch, you can see a whole queue of tiny people making their way up to the summit.
I think the coloured dots are the literally hundreds...if not thousands of tents that are pitched in the area in between the navigation controls and the lower part of the glacier when you first open the image...looks like Woodstock at high altitude.

It was perfectly ok until a short while ago, Glenn. I've been uploading more stuff today. I'll find out what's going on when the guys in SoCal wake up. It may be just some temporary maintainance going on.

Thanks for the offer, Mike...very good of you. Unfortunately the only thing to do is for us modellers to go through the saved models on our own hard drives and (in my case) try to remember where on earth I squirreled everything away...which isn't always where I expect it to be.
We've upgraded our RAID level to make sure this never happens again. It's quite unbelieveable that the backup drive went down too.

Haha! What can I say? I've been a little busy lately...always nice to be missed though.
Looks like I'm going to be even busier for the next week or so, as I've got to manually reload several hundred models. Jeez! this is gonna be a boring start to the New Year.