What is this bug that prevents projections?

#1

MORE SKETCHUP FUN WITH HEXAGONS.skp (356.2 KB)

I am trying to create a shape with a curved wall but featuring a honeycomb infill (this is for eventual 3D printing). I generate one hexagon (as a 6 sided ‘circle’) then copy it out to give the matrix seen in the left region of the model. This will ‘loft up’ nicely, but any attempt to add lines (which are in the same plane) results in the dog’s breakfast shown. This happens EVERY time and is totally random.

How can this bug be fixed?

#2

I am working on something a little similar myself.

I don’t think it’s an issue, but you could scale up 100x to be sure you aren’t getting the small faces issue.

It also looks like the model was created using 2 different styles?

#3

I am a little confused about what you are trying to do or what the problem you are seeing, but you may be running into an issue with the size of your model. SketchUp cannot create sub millimeter geometry. You may try temporarily scaling up my 100, creating your geometry, then scale back dow for output.

#4

Thanks to both of you!

It seems, as you say, that the solution is to scale the model up. Saying that, you still have to ‘throw’ a load of connecting lines across the surface to ensure that each and every hexagon is ‘tied down’ in order that it doesn’t ‘misbehave’?

Odd we should have to do this, though?..MORE SKETCHUP FUN WITH HEXAGONS.skp (527.1 KB)

#5

If you’re trying to model the “infill” within the boundaries of a 3d printed solid, it usually doesn’t need to be modeled in SketchUp. When you get to the point of using the “slicer” app to change your .stl file into gcode for your printer, all slicer programs let you define your infill at that point.

1 Like
#6

No idea what you mean by

Good modelling practice does not require this.

Why do you think this is necessary?

1 Like
#7

‘Good modelling practice’ is no panacea when the program can’t ‘cope’ with attaching one shape to another at very point of contact. This despite the fact that, as previously alluded, the two are on the same plane! My original drawing clearly demonstrates this failing.

#8

That’s a really good point! I don’t suppose this ‘infill’ facility allows you to specify number; size & wall thickness of hexagons too, does it?

#9

It varies a bit between slicer apps, the better ones (IMHO) lets you set infill % and pattern. If you specify a hexagon pattern, changing the % infill will usually result in a change to the hexagon size. I haven’t seen one where you can directly control the thickness of the hexagon walls.

1 Like
#10

The issues you are seeing are most likely due to the small scale of your model. The accuracy of SketchUp is 1/1000", which is the same as other popular 3D apps such as AutoCAD.

Have you tried scaling up your model as has been suggested to eliminate this issue?

Also, please update your profile to indicate the version of SketchUp you are using and your hardware to eliminate other possible issues.

1 Like
#11

Thanks, increasing the size does seem to have helped. Best of all, it now appears that STL will do the hexagonal infil for me anyway.:heart_eyes:

#12

You’re a star! I think I’m pretty well sussed now.
Thanks

#13

I do applaud your efforts to try to solve the small face issue - the solution is not well known in SketchUp training documentation.

#14

AutoCAD would likely dispute this …

http://blogs.autodesk.com/autocad/working-large-coordinates-in-autocad/
… which says …

AutoCAD stores geometric data in a standard IEEE 64-bit binary format that’s allocated like this:

  • 1 bit for the sign, positive or negative.
  • 11 bits for the exponent, the powers of 10 included in the value. The 11-bit exponent provides maximum and minimum real values for shifting the decimal point more than 300 places to the left or to the right. No problem there.
  • 52 bits for the mantissa, which is sometimes called the significand, fraction, or coefficient. This provides the decimal places of precision available from all computations and stored values.

Converting from 52 bits in binary to decimal gives you 15-17 decimal places as a theoretical maximum.

I’m also not sure that AutoCAD "thinks’ internally in inches. Ie, it’s calculations are probably in “units” and the user sets the display measurement units.

1 Like
#15

Regarding “accuracy” of 1/1000 inch, I would dispute that for SketchUp as well - it mis-characterises the actual issue in SketchUp. SketchUp stores endpoints as high-precision floating-point values; an individual endpoint can be located with extremely high precision. What SketchUp cannot do (sadly) is create multiple endpoints that are fairly close to each other, on the order of 1/000 of an inch gap or less.

#16

Hmm. So, to the lay-person: the ‘issue’ I’ve identified is, for once, not of MY making?

#17

Definitely not of your making.

#18

I was referring to documentation on the SketchUp website re the 1000th of an inch and AutoCAD being the same.

We could do with further clarification from SketchUp.

#19

Autocad thinks internally in numbers with no predetermined connection to real world units. The user decides what unit the numbers represent, from ångströms to light years. Changing units requires scaling the model up or down.

1 Like
#20

Lordy. I read this stuff and rejoice on two fronts:
A. That I live in a ‘digital cave’
B. That STL do more honeycombing for folk than Crunchie Bar.

Oh, better make it three: that I’ll be long gone worm food before the A.I posse take the whole gig over!!!:rofl::joy::wink: