Working with imported .dwg point cloud


I’m usually able to figure things out for myself, but this time I’m stumped. Just got a .dwg from the surveyor, which includes some rudimentary 3D geometry of the roofs to aid me in constructing a more accurate model of the subject property and adjacent buildings. Imported it into 2017 but was having some problems, so saved the part I needed as v2016 and opened it there, since I haven’t spent any time in 2017 yet. Same problem in 2016 though.

Numerous problems with using the file. In orbiting, some or all of the geometry disappears and reappears. It’s entirely edges, no faces, but some lines can be selected by clicking on them, others I need to click a little distance away. Try to make faces from them, and inference cues tell me I’m on a point, but when I click to start a line or rectangle, it’s not actually on the point. If I do manage to start a line along one of these lines, and connect it to a line on the opposite side, the existing line gets pulled over to meet the point that wasn’t actually on the line, though it does create a face. As imported, it had around 100 layers, but putting everything into Layer 0 didn’t change anything. There doesn’t appear to be any hidden geometry.

File was too big to upload, so hopefully this link will get you to it on dropbox.

Thanks in advance for your help!


The problem (which is a common one with imported dwg files) is that your model contents are located a very large distance from the model’s origin. You can tell because the model axes aren’t visible even if you check the View menu to make them so - they are way off screen.

The simplest way to fix it may be to select everything, activate the move tool, start to move and then let go of the mouse and type [0,0,0] + enter. That tells SketchUp to move the selected point to the absolute origin of the model.

The best way to avoid this in the future is to uncheck “preserve drawing origin” in the dwg importer options.


Brilliant, absolutely brilliant! Don’t think I would have ever thought of it. Curious that it behaves that way, almost like being in a parallel universe…which I guess I kinda was…

You’re right though, I exploded the original component when imported and got rid of all the stuff I didn’t need. Checking it now, I see the origin was some 700,000 feet away!

There was a moment of frustration, until I realized that I needed to type the brackets in your explanation, in addition to 0,0,0.

Thanks so much for your quick assistance!


You’re welcome. If you are technically inclined read on, otherwise quit here :wink:

What is happening is a clash between the zooming capabilities of the OpenGL view and the finite-precision representation of positions inside SketchUp. Due to the finite precision, there is always a minimum possible change in a value by changing the least significant bit. This is true even in a floating point representation. Multiplying by a power from the exponent just scales the physical size represented by the least significant bit. You can still use up all the bits just expressing the distance from the origin.

When the contents are vastly far from the origin, that minimum possible change may be larger than the difference between points you see on the view. So, when you click, SketchUp selects the nearest position it is able to represent. That doesn’t necessarily match what you saw in the view.

Before anyone launches off on a reply about how this really doesn’t need to be the case, please remember that I don’t work for Trimble, didn’t design SketchUp, and can’t answer for whether the designers made the same decisions you might have.


More info always better than less info! I appreciate the breadth of your response…


Ne connaissant pas cette astuce je me suis empressé de la reproduire, mais pour que cela fonctionne, il me faut taper [0;0;0] (avec un “point virgule” et non une “virgule”.
Est-ce normal?


Commas worked for me just fine. Could it be you’re using a French keyboard, and hence the difference in the key you need to use?


I think the keyboard is the explanation…


In the English speaking world and several other countries a . [period or full-stop] is used as the day-to-day decimal-separator, and then in SketchUp a , [comma] is used to separate values in the Measurements box - e.g. when inputting multiple numbers.
In much of Europe and several other countries a , [comma] is used as the day-to-day decimal separator, and then in SketchUp a ; [semi-colon] is used to separate values in the Measurements box.
SketchUp takes the set up from the locale.
Your Computer set up will also determine the use of . or , etc
In Ruby itself and within SketchUp’s internal processing the locale set up is ignored - so a . is always used as the decimal-separator and a , [comma] is used to separates items in a list, while a ; is equivalent to new-line in Ruby.

The use of a comma as a decimal point can cause issues with some XYZ CSV files, as they are themselves ‘Comma-Separated-Variables’.
While 1.2,3.4,5.6 works
1,2,3,4,5,6 won’t !
Then “” are used to ‘protect’ the numbers:


Though this was my first post on the forum, I always enjoy reading the forum, and often learning things outside of strictly SU issues. Thanks all you sages!


Effectivement j’utilise un clavier français.
Il est donc bon de savoir que si cela ne fonctionne pas avec la “virgule”, il faut essayer avec le “point virgule”.
Cette astuce qui semble fonctionner avec n’importe quel type de modèle est vraiment très intéressante, et il si je l’avais connue plus tôt je l’aurais certainement déjà utilisée une multitude de fois.
Merci d’avoir lancé le sujet.