[Plugin] Dxf_In v2.2 20110517 Dxf2Skp

[honoluludesktop]

Originally released on 09/24/2010 as v0.38 Alpha, this is v2.2 Beta dated 5/17/2011. Dxf_In is for use with Dxf ASCII files, and now includes support for Dxf layers. Until the SketchUp Ruby API is updated, the application is limited to locating Dxf files in a DriveLetter\Path\FileName.dxf written in Standard ASCII characters. Read help for other limitations, and error messages.

Dxf_In_v2.2.rb

Dxf_In_v1.15_french.rb

For SuPro Users: DxfIn will face closed polylines. The model in the image below normally imports into SuPro as a wireframe.

Example of Dxf imported into SU v8

Download and place plugin into the SketchUp Plugins folder ("Google SketchUp xx\Plugins" where xx is the SketchUp version number). From the SketchUp menu, select File, then Import Dxf. The options menu defaults can be changed to your preferences. If your imports are slow, and you typically do not import materials, select as "None". The default settings are satisfactory for most situations. Get Help from the options menu the fist time you use Dxf_In to see which entities are supported. The importer will convert closed polylines into faces by default or edges by selection. In the situation that a closed polyline has a hole in it, the importer will face it by default. Inspect your model, and delete those faces. Other options include selecting the Dxf model's units, locating by its origin, by the model, or with the mouse pointer. The final option selects the method of inserting materials on the model's faces. The default material setting is is by Acad's color numbers. By name is by Sketchup's materials, and by model is the current model's materials.

When a error message provides the option to Cancel, where possible, the application will skip the problem, and continue the translation without displaying the error message.

The application is slow, and has minimum error trapping for processing the dxf file. Unsupported geometric entities include text, dimensions, polyface mesh, and nested blocks. If you require any unsupported entities, explode them into their basic parts before creating your dxf.

[charly2008]

Hi honoluludesktop,

I wanted to try it once but I can't find it in the Plugins menu!

Charly

[honoluludesktop]

Hi Charly, It's in the lower part of the File menu. Let me know if you have any problems.

[charly2008]

OK, there it is present. It works but not as it should be!

I imported an example dxf, below you can see the result in the first image. The second shows the imported dxf in Sketchup pro 7.

Charly

[honoluludesktop]

Ouch, looks like my block references, arcs, and circles need work. Thanks for the dxf file, that will help me correct it. Btw, what version of Autocad did you use to make the Dxf?

[charly2008]

I have downloaded the DXF-file from the Internet.

[honoluludesktop]

The basic arcs, have been corrected, but the Dxf contains entities currently unsupported by "Dxf Import". Until these are added, along with support for "nested block(s)", only the most basic geometry, will be imported. If necessary, the unsupported entities can be exploded into supported entities prior to being imported into SU.

I have been unable to test "basic block(s)" except in the simplest cases. If I can get a Dxf with "BLOCK" and their related "INSERT" entities (not INSERT(s) inside a BLOCK) to test, I will then be able to check them. I need someone to post a Dxf with a pair of BLOCK(s) made in Acad as illustrated below.

temp01.jpg

[Bep]

Hi Honoluludektop,

I'm sorry that i cant help you with a real acad dxf ,but would'nt a dxf created with the free doublecad http://www.doublecad.com/LinkClick.aspx ... 8&mid=3384
do the same.

Thanks for your effort ,and i wish you succes ,

Bep

[honoluludesktop]

I am not fluent in that app, and failed to take a component into it as a block, and back as a group/component with the original entities preserved. But if you build the model in DoubleCad, and save as a Dxf, I can give it a try. By inspecting the DXF, it is possible to see if the entities are preserved. Thanks.

[honoluludesktop]

Alpha v 0.45 includes support for Blocks2Groups. Charley, while still missing lwpolylines and ellipse, arcs are resolved, and blocks accomodated in the current release, (I hope:-). Bep, translators are not equal. One app. may elect to export circles as connected edges, in other situations, SU may have, or not have a high level entity that a Cad app supports, so....Sigh!!!!, several situations need to be tested for.

temp10.jpg

Acad has more entities then I thought possible. In the process of supporting blocks, I discovered polyface meshes. The following is one of 6 variations in this category. In this release blocks2groups is addressed. I would still like to get a Acad created Dxf of a cube, and drum represented as faces.

temp11.jpg

temp12.jpg

Anyway, if "NO" to convert polyline to faces is selected, the above is created. It is a way of representing a 3d object with polylines, taking the least amount of space in Dxf.

In most cases, selecting OK, to a error message, allows you to proceed. In some cases, this is taking too much time, and needs to be accommodated

[honoluludesktop]

Beta release v0.50 includes LWPolylines, group names, and some fixes. The following image is the bathtub dxf previously provided.

temp13.jpg

[SurfingAlien]

thank you very much!
I will try it asap and let you know if it works fine with my CAD programs (I'm still with SU 7.1 BTW)

cheers,
Alessandro

[honoluludesktop]

Except for polyface mesh, Dxf_in v1.0 imports the basic geometric entities recognized by SU.

temp15.jpg

[honoluludesktop]

Sigh...As soon as you think you got it, there is something to change, hence v1.1. Functionally no different, but with better error messages. Unless I find a bug, or figure how to add a polyface mesh, this should be it:-) Attached are some test with old.dxf models.

temp17.jpg

Temp90.jpg

The model's groups are based on common materials, textures, or colors. This makes it is easy to update the SU model's textures of any Cad based revision. The groups/blocks are sent both ways so that the production drawings are easily revised based on changes to the model.

[DavidBoulder]

Looks great! I ran it through a test with some DXF's created by EnergyPlus (as part of an energy simulation run).

What I noticed is that using your plugin the DXF came in 12x smaller. In the Pro I have units set to feet vs. inches, which works with these DXF's. Easy enough for the user to fix but could be nice option to add down the road. One other thing I noticed is that on your DXF import a few faces were reversed from how there were with the pro importer. The pro importer was not set to "orient faces consistently" but maybe it was doing it anyway, and the source file really does have some reversed faces.

Other features that would be nice, but aren't critical, are to support the layer and color applied to a face.

dxf_In screenshot.png

[honoluludesktop]

David, Thanks. Can you provide a sample dxf (smaller the easier for me) with layer and texture? Perhaps I should provide a options menu.

[DavidBoulder]

David, Thanks. Can you provide a sample dxf (smaller the easier for me) with layer and texture? Perhaps I should provide a options menu.

Sure, here is a 50k file from the example above. Now this was made from EnergyPlus, so it may not be the best test case since it wasn't generated by AutoCad. I'm not sure if a similar file from Autocad would like the same or not.

This file has layers and color (not image textures)

(hmm, can I not upload DXF file?)

[honoluludesktop]

Just change the file.extension name to .txt, or right click, sent to .zip first. Thanks

Addenda: See post by Gai below.

[Jim]

you can download lot's of dxf files from here (my google site.) The .zip contains an un-attributed compilation of shared .dxf files designed as 2D cnc routing patterns. (17MB)

I'm wondering, do you know how to handle the bulge data when it appears in the lwpolylines? It's something I'd like to add to my importer, too.

[Gaieus]

I made dxf (and dwg) an attachable file extension

[honoluludesktop]

Jim, Thanks, I will take a look at your files. Is lwpolyline something that is required by a lot of modern applications? I found the following, but bulge remains unimplemented with my importer:

"The bulge is the tangent of 1/4 of the included angle for the arc between the selected vertex and the next vertex in the polyline's vertex list. A negative bulge value indicates that the arc goes clockwise from the selected vertex to the next vertex. A bulge of 0 indicates a straight segment, and a bulge of 1 is a semicircle."

DXF is on the other side of the moon when compared with SUs faces, and edges. I initially made Dxf_In work for my own Cad application, then added features as others have requested. Initially, by self imposed discipline, all of my cad models were built with 3d faces, and blocks. My Cad2Dxf2Su requirements were simple. But times change, and while my code is fairly well organized to implement new entities, it needs work on the overall DXF structure. Something I ignored since I was only interested in geometry.

Gai, Great. Perhaps, like a lot of others, I only learned how to "send to zip" once I needed to do it.

[DavidBoulder]

Here is the attachment. Thanks for the tips. I left the file at work, so couldn't send last night. Sounds like we can do dxf's now.

[Jim]

Looking at the Blender dxf importer (written in Python) and found these dxf test files in the Downloads section:

http://wiki.blender.org/index.php/Exten ... ort/DXF-3D

[honoluludesktop]

V1.2 provides the option to select input units, and location (thanks to_tt). Not being familiar with metric conversion, I did not check their accuracy.

temp18.jpg

Btw: In regards to lwpolylines, when I wrote this translator, I found that the dxf example I used contained occasional differences in the actual number of vertices's, and the number provided by the dxf. So, I ended up writing a procedure that did not depend on the stated number. I am not sure if this is a misunderstanding on my part or a bug in the program that created the dxf.

[Jim]

Btw: In regards to lwpolylines, when I wrote this translator, I found that the dxf example I used contained occasional differences in the actual number of vertices's, and the number provided by the dxf. So, I ended up writing a procedure that did not depend on the stated number. I am not sure if this is a misunderstanding on my part or a bug in the program that created the dxf.

I can't find the reference now, but I understood it to say something similar to "polylines that can be converted to lwpolylines, are converted into lwpolylines in order to save space."

I have a routine to handle the bulge data for regular polylines, but the lwpolylines are different enough that I haven't been able to decipher them consistently.

I found a dwg/dxf converter for Windows that may be of interest. It converts between dwg and dxf, but also from dxf to dxf and you can choose several versions of the file format. So maybe it will be useful for converting tricky dxf files into older formats which your importer is more tolerant of.

The converter is here, under the name ODA Teigha File Converter.

http://www.opendesign.com/guestfiles

[honoluludesktop]

Hi Jim, Thanks, I have used that open source translator from time to time, especially with a cad.dxf that needed to be accessed by older programs. It has a difficult interface requiring two folders, one for the file and the other for the export. As I recall (perhaps erroneously) it did not allow you to select specific files for translation, and processed the entire folder.

When Dxf_In detects a lwpolyline, it process it as a SU "continuous edge" by assuming z=0.0. I am not sure if that's what's intended for that entity type, but have successfully translated the examples I had access to at that time.

There were other anomalies I noticed in comparing Dxf_In to SU Pro imports. The windows in the energy model above, imported with SU Pro, are faces in the same plane as the wall (surface) they are on. Hence the problem displaying its color. For some reason, Dxf_In corrects this by drawing the window as a faced hole in the wall. However, Dxf_In draws some of the energy models faces, back side out, where SU Pro draws them properly. I speculated that the cause of this maybe in part, the order that the faces are drawn. Dxf_In, processes the Cad.dxf in the order the entities are listed. Perhaps SU Pro pre-processes the entities before drawing them. Btw, I hadn't realized that polylines have "bulge". Although I haven't encounter any that did, I guess I need to look at that entity attribute. Is my post above regarding bulge calculation correct to your understanding? Also puzzling to me were the entities in some dxf files that by the manner of their identification in the file, are not drawn. If file size is a consideration, I wondered why these were included in the dxf file.

[honoluludesktop]

Jim, I am using Dxf Reference, ACAD 2010 and am not able to identify bulge data within dxf polyline.

Temp89.jpg

The group code for bulge in lwpolyline "42", is absent in the 2010 reference for polyline unless it is part of "70" and some other group code. I don't look forward to figuring out how to including it in Dxf_In.

Incidentally, Dxf_In doesn't check for version number, and will attempt to process any File.Dxf, even one that is manually, incorrectly edited, and rejected by Import SU Pro. It has succeed for the implemented entities, except when the group code is written out of order. I noticed that import SU Pro V7 refused to translate a 2010 Dxf file.

[Jim]

Jim, I am using Dxf Reference, ACAD 2010 and am not able to identify bulge data within dxf polyline.

It's the POLYLINE's VERTEX that may or may not have a bulge attribute. POLYLINE's are implemented as a sequence of VERTEX's, ending with a SEQEND code. LWPOLYLINE's can have multiple vertex and bulge data but these are stored in the object itself as multiple 10, 20, and 42 codes.

Incidentally, Dxf_In doesn't check for version number, and will attempt to process any File.Dxf, even one that is manually, incorrectly edited, and rejected by Import SU Pro. It has succeed for the implemented entities, except when the group code is written out of order. I noticed that import SU Pro V7 refused to translate a 2010 Dxf file.

I am in the process of separating out the dxf reader part of my importer to be more generally useful. It reads a dxf and converts it into a Ruby data structure of Arrays and Hashes. This will allow access to the sections and entities much easier.

Header variables:
dxf = DxfReader.load("c:\drawing.dxf")
acad_version = dxf['HEADER']['$ACADVER']

Iterating ENTITIES:
dxf['ENTITIES'].each do |entitiy|
process_entity(entity)
end

Viewing a specific, or entities by type:
all_lwpolylines = dxf['ENTITIES'].select{|e| e[0] == 'LWPOLYLINE'}

In addition, you can "pretty print" the dxf allowing for easier analysis, such as this image of the representation of a LWPOLYLINE as a Ruby data structure.

739.png

You can see the lwpolyline has 8 vertices (code 90), but only 4 of those bulge data (code 42). I know how to create an arc from 2 verts and a bulge, but I don't know how to apply that formula to this particular lwpolyline.

But with the DxfReader, you can pick out and try to create this one particular entity for debugging:

lwpoly = dxf['ENTITIES'].select{|entity| entity[5]=="477"}.first
x_values = lwpoly[10]
y_values = lwpoly[20]
bulge_data = lwpoly[42]
nverts = lwpoly[90]
for i in 0..nverts-1
pt = Geom::Point3d.new(x_values[i], y_values[i])
entities.add_cpoint(pt)
end
(etc.)

I will try to clean-up and post the reader this week.

[honoluludesktop]

V1.5 adds layer names, and materials to faces. In addition, the initial user interface is now organized as a single options menu.

When selecting DXF_In materials on, unless the material exists in SU, the resulting face is black. I currently have not thought of a practical way to handle that situation.

Jim, I have been reading up on lwpolyline, and polyline entities. Thanks for your post.

[honoluludesktop]

Jim, I think I get it about bulge in polyline as "a sequence of vertexes". The dxf reader sounds like a great tool. Just an idea, but perhaps in addition to displaying the group code, you could provide a short meaning of it (probably too much work).

In the process of material importing, I tried to convert Acad's basic colors to the ones recognized by SU. Wow, too much work for me, and there were to many approximate correlations. Then I thought of setting the RGB values in SU, but that wouldn't cover materials, so I decided to leave it in the hands of the user to make sure that the same material existed on both sides. Because I do not use ACad, I can't test the validity of that assumption, and will have to depend on feedback. Now I see this discussion, and will leave the matter to experts.

I read that lwpolyline was implemented by ACad in version 14. So unlike my original speculation, it is not an old form of polyline, rather a newer one then polyline. To my understanding, It is a 2d, variable width, entity that supports curves between pairs of vertex. One application is as "arrow heads" at the ends of dimension line. I have yet to read an explanation why this entity was created. Perhaps because, it helps reduce the size of the drawing database, especially with those that are primarily used in "production drawings".