[Plugin] Dxf_In v2.2 20110517 Dxf2Skp

TIG

honoluludesktop
What I'm saying is you seem to be putting Lines on a 'Line' layer, Arcs on an 'Arcs' layer etc - i.e. you are layering them by their 'kind' and ignoring what they might have had set in the DXF file itself.
Each object in a DXF has its own CAD layer under its code #8 [OR if not then it's taken as being on CAD layer '0'].
You are breaking the connectedness of objects by RE-layering then by 'kind' - e.g. a simple CAD Door made from a Line and an Arc would probably have both of these things on a CAD layer called 'DOOR', or if they are placed within a BLOCK then they might be on CAD layer '0', with the Block's INSERTs then placed on layers like 'DOOR', [or even 'DOOR-0001', 'DOOR-0002' etc to separate them by 'story'].
You loose all of the DXF's 'intelligence' by doing it your way. You can no longer select or switch on/off 'Doors' in the SKP, as their parts that should be on layer 'DOOR' are now all over the place depending on the kind of geometry they are... You may as well put everything on SKP Layer0 [i.e. don't bother giving things layers at all].
I see little logic in layering the imported geometry by 'kind' - I believe that it should always use the DXF code #8 string as the thing's layer-name [suitably trapped for '0' >>> 'Layer0' or the locale's equivalent name...]

TIG

Aaah... So you will layer objects to their code #8...

honoluludesktop

Tig, I don't understand "kind", if its a array, and @entity_layer is the Acad layer name, then the procedure is:

def hdt_put_ent_layer(entity_array)
  entity_array.each do |e|
    e.layer=@entity_layer
  end
end

If its a single entity the code is:

entity.layer=@entity_layer

Thanks for the lesson, I will spend some time on it, as well as your .rb.

Alex, As I said before, the 3D model in your "test4plugin.dxf" consist of a entity that is not supported by Dxf_In. The model is not creates with Acad 3DFaces. They may be 3D, and faces, but not Acad 3DFaces as follows: A Acad 3DFace is a coplaner entity with three or four vertexes. Your application creates them as a unsupported "polyface mesh". Dxf_In outputs the model as a "polyline". Attached image follows. I could eliminate the incorrect output, but I thought it would be helpfull to some users. For now, if you want the 3d model to import with Dxf_In, you can try to "explode" the model within your Cad application into more basic elements before creating the Dxf.

I am currently working on cleaning up v1.28 layers, will move on to Acad Inserts, then ellipse.

honoluludesktop

Tig, Aha, understood. In this situation, the Dxf examples posted were supplied by Alex. Of course, you are right, the organization of layers should conform to some means to make work easier. He was helping me check that the imported entities were being assigned in SU to their original Dxf layers.

honoluludesktop

I thought that was what I was doing, but I will recheck my code, thanks.

honoluludesktop

@tig said:

.......To properly reflect the CAD data imported into a SKP all geometry should keep its CAD layers, and also all Inserts should keep their CAD layers.

Anything on CAD layer '0' should be given the SKP layer 'Layer0' - or more precisely the 'default-layer', because the default-layer has different names in different locales; to find that simply have some code that does this...

Tig, What I have done, is the result of the SU Api methods. I must admit I have never spent much time trying to understand SU's layers.

Alex, Did you purge? Attached is my screen print of your file. Unfortunately, your 3d model may be built with a unsupported entity. I will continue to check. You could try exploding it into lines prior to creating your Dxf.

In the VPort section, your file has a Name "3dfaces", but contains no Acad 3DFaces. Can you describe the problem you have with 3DFaces?

honoluludesktop

Dxf_In v2.0 Beta is posted here. It cleans up some of the code, and adds Dxf layers to the supported entities. Hereafter, support for Dxf_In will be modest at best.

arkitekt02

I apologize if this has been discussed previously in the thread (I didn't see any mention of it). Is the DXF import plug-in compatible with a MAC operating system?

honoluludesktop

Within the limits of the supported entities (see help), Dxf_In has run on a Mac. The only place where there may be a problem, is in the way the application saves user preferences. However, no one has mentioned that to be a problem.

Corb

Hi,

first of all thank you very much for the hard work in making this precious plugin.
I was reluctanct to install SU8 because it lacks DWG/DXF import.

As I found your plugin I immediately downloaded SU8 and gave it a try.
I exported from Autocad 2011 a bunch of simple rectangles in dxf of several versions:
R12, 2000,2004,2007,2010.(BTW, up to which version the DXF is supported by your plug-in?)

I tried to import them into SU8(free) via the File/import DXF command in SU8 but none of them was imported.
Scale was correctly set, so I wonder what am I doing wrong.

I attach 2 dxf files (2000 and 2010) in case you have the time and patience to give them a look.
Any help from you or others who are following this thread will be greatly appreciated.

Again, many thanks for your work.
Cheers,

Win XP Pro x64 Edition
version 2003 Service Pack 2
Intel Core 2 Duo CPU
E7500@2.93GHz
3.93 GB Ram

DXF v2000

DXF v2010

RadoAller

Hi,
First things first...I'd like to thank you for sharing this with us...
For me everything worked well uptill when I imported my dxf file and got the notice:
<Error> or Empty file.
I tried putting diff. types of models and none of them seemed to work.
If you have any idea about the possible solution please come back to me asap.
Thanks again,

honoluludesktop

RadoAller, There are some Dxf entities that Dxf_In doesn't support. Check the Dxf_In Options menu, help options, for help. Also make sure that the Dxf file is an ASCII, not binary file. If you post your file here (the Dxf, and if you have one, the image of the model being imported), I can look at it to see what the problem may be.

honoluludesktop

Hi Cob, Attached are my imports of your files, 2000 below, and 2010 above. I moved them around to make this image, but did you zoom all after the import?
Within limits of Dxf_In's list of supported entities (see Dxf_In Options menu, help options for help), I have successfully translated files from v10 to v2010, and the current additions to the plugin used Acad's Dxf reference for v2012.

Did you get any error messages?

Corb

Hi,

first of all thanks for your kind and speedy reply.
I retried today but didn't succeed in importing anything.

Yes, I did zoom all but nothing showed up.

Ruby Console message reads:

"Error: #<Errno::ENOENT: No such file or directory - C:\Documents and Settings\corbella\デスクトップ\test_v2000.dxf>
C:/Program Files (x86)/Google/Google SketchUp 8/Plugins/dxf_In_v2.0.rb:228:in initialize' C:/Program Files (x86)/Google/Google SketchUp 8/Plugins/dxf_In_v2.0.rb:228:in open'
C:/Program Files (x86)/Google/Google SketchUp 8/Plugins/dxf_In_v2.0.rb:228:in atelier_main_proc' C:/Program Files (x86)/Google/Google SketchUp 8/Plugins/dxf_In_v2.0.rb:921 C:/Program Files (x86)/Google/Google SketchUp 8/Plugins/dxf_In_v2.0.rb:228:in call'
C:/Program Files (x86)/Google/Google SketchUp 8/Plugins/dxf_In_v2.0.rb:228"

The strange thing is that it does not show me the shapes even when I import them with "pointer" for origin placement.
It looks like it ignores the import command.

I am using your v.2.0 version, dropped in the plugin folder.
Am I missing any other file?

Bye from Japan

honoluludesktop

Corb, Dxf_In v2.0 is the current plugin. I see that you have a Kanji (or is it Katakana) directory in the path. I also see from the error message that the plugin failed at line 228, when the program first uses the file name to open itself. I am guessing that the problem is the plugin editor can not write the program to use the Japanese writing. Just guessing, but try accessing a Dxf file from a Drive\Path\FileName.dxf written only in English. If that is the problem, I will ask for help from others to fix it.

Corb

Yep!

The problem is caused by the katakana characters in the filepath.

I imported the v2010 dxf from an external drive with an english filepath and it showed up just fine !

Glad that there is a workaround for the moment.
Hope that someone can solve the issue, sooner or later. Language free would be good as SU is quite used her in Japan too.

Many thanks for your help !

honoluludesktop

Corb, Apparently, the SketchUp API is based on Ruby 1.8, which is incapable of working with Japanese characters. You will have to place your Dxf files in a location that only contains standard ASCII characters.

Corb

Thank you.

Ok.
Maybe it`s SU8 that works in a different way then, because SU7 could import DXF from my Japanese computer even if the filepath had kana characters.

If solving this is impractical I will use SU7 for importing and then open the SKP file with SU8 to work on it.

Best !

honoluludesktop

Hi Corb, SUv7's "Import Dxf" is hard coded, and doesn't depend on a Ruby Plugin. Until SketchUp incorporates a higher version of Ruby, plugins will be subject to the current restrictions. It's good that you have a alternate solution. SketchUp's "import dxf" will import more entities then Dxf_In, however it may not work with Acad v2010, and higher dxf files.

Corb

I see.
Again, thanks really a lot for the great and friendly support to your plugin !
My best to you and Hawaii (I`d love to go there sooner or later).