[Plugin] Dxf_In v2.2 20110517 Dxf2Skp

TIG

The entire imported DXF should be inside its own group placed on Layer0 and named after the DXF file name. If you want to the move it onto a new layer 'XXX' it's easy...
All of the imported bits should maintain their 'nesting', and layering and naming - except that CAD layer '0' becomes SKP 'Layer0' [or whatever it's called in your locale]...

alexdobras

sorry TIG, but i do not agree with you.
to have EVERYTHING on different layers that SU's is better for keeping everything organised. I am sorry you cannot understand that.

alexdobras

create a poll and see what people say

TIG

Honoluludesktop
You get the layer name list from the DXF file and make those 'by name' [swapping CAD layer '0' for SKP layer 'Layer0' or whatever it's called in that locale] - the layers are listed under the LAYER headings - code #2=namestring and #62=colorcode [see my ImportDXFtext.rb def get_layers() lines #453 to #505] you only need code #2 for the namestrings - the layer's color will be randomized in the SKP - you CAN give your objects materials based on layer 'color' as my text is BUT it's complex - see lookup tables etc in my .rb... If a CAD object has no #8 code then it is given CAD layer '0'
Then within the the objects that you import you get each object's layer from its code #8 - see my .rb line #176.. def get_texts() which finds all TEXT entries and looks down to find the line after code #8 for the layer name [line#203..].
My code assembles lists of many things to process later... but you can extract the basic data as needed by you. So you might now have found a LINE on layer 'DOOR' and an ARC on layer 'DOOR' - that's where they should end up in the SKP if they are loose geometry. If these are inside a BLOCK in the DXF them the chances are that they will be on layer '0' [i.e ~='Layer0'] , and the the INSERT of that BLOCK will be on layer 'DOOR' - again you need to make a componnet definition based on the BLOCK's contents respecting the layering, and have instances of that definition placed to match the INSERTs, with each one on a layer matching that INSERT's layer...
I haven't read your code in detail... at the moment it seems to layer objects by their 'kind' rather than their DXF original layer ?

alexdobras

@honoluludesktop said:

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

i see that you almost got the 3dmodel, but there are missing 2 lines of it. With 1_28 version of you plugin i don't get nothing when importing. So you did somehow to almost import it.

here is what it should be:
red lines are the lines that are missing, crossed with green is the line that shouldn't be there.

this is in DraftSight CAD

this is what you see in draftsight in 3D view

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.