[Plugin] Dxf_In v2.2 20110517 Dxf2Skp
-
Yes, in my case, "Red_Rectangle" is missing. While I am moving ahead on this, I would like to get the opinion of those that are more experienced then myself. Bottom line is that the app. should conform to Acad, GCD/4D (the reason I wrote this plugin), and SU specifications.
Btw, Dxf_In currently doesn't do splines, ellipses, or polyface entities. Ellipsis can be added in the future, but polyface entities, and splines are outside of my comprehension of their computer math algorithms.
-
@honoluludesktop said:
Looks like you got another post in while I was writing the other.>_< The accurate image is based another application that I use to check my work. I placed the SU layer window over it in order that you can ID the layers.
but how did you get that accurate importing? i see all the lines in your SU
-
Tig, Do you think it will be a problem if I add layer "0" to the set along with layer0"? If a problem, why? Don't know if I can do it, but was about to try having both.
-
Alex, getting there. The yellow block is erroneously being replicated. Maybe tomorrow.
-
i see in the picture, that the yellow Block is placed 2-times, for some reason
pray it will work tomorrow -
also, it is an advance already, because i see the rectangle fully imported into SU.
-
Alex, This should do for now. The plugin needs to be tested for lines, circles, arcs, faces, 3dfaces, and polylines.dxf_In_v1.28.rbI will have to work on the problem group or component transformations before I add ellipses to the supported entities.
-
i read the above post
i saw "The plugin needs to be tested for lines, circles, arcs, faces, 3dfaces, and polylines." and i created a new file with everything that you said. So, here iti is:test4plugin.dxf
it is a model that has a layer for each element that you have requested.after testing it in SU, this is what it needs to be said:
- everything imported pretty well, but 3Dfaces and Blocks. (blocks i tested with other files, and got the error"bloks not suppoerted)
- other thing; i think it is a bug: everytime i open an multi-layered dxf in SU, the layer "PERGOLAS" is automatically imported, for no reason. here are the previews:
![what's with "PERGOLAS" ?](/uploads/imported_attachments/LpiM_layerstrangeness0.PNG "what's with "PERGOLAS" ?") ![here's on different file. the "PERGOLAS" still appears for some reason](/uploads/imported_attachments/JpAL_layerstrangeness2.PNG "here's on different file. the "PERGOLAS" still appears for some reason")
- the last thing: is that SU's Layer0, when is turned off, everything disappears. It should better dissapear only what's on Layer0. If a create another file with two layers on SU, and put different objects on diffenret layers, when i turn off Layer0, not everything disappears.
-
If you imported a Dxf into a existing file, there may be left over layers. Check by purging the file.
Yes, "nested blocks" are not currently supported, and I am working on the Acad entity "Insert" (which is like a transformed component instances).
What problem did you find with 3DFaces? I just discovered that the surface gets put on the correct layer, but its edges remain on layer0.
SketchUp Layers are not like Acad layers. I believe that it is a mistake to eliminate Layer0. You can control entity visibility with the imported Acad layers, but the consensus here on SketchUcation is that you should always draw on layer0. Perhaps at a later time, I can offer removing Layer0 as a help menu option.
Dxf_In is written (to the best of my in-abilities:-) to conform to Acad's Dxf specifications. Problem is, every other Cad program that writes Dxf, only does so in terms of that application's characteristics, and sometimes fails to translate perfectly. See previous discussion. Because many Dxf files are not from Acad, it's necessary to check the changes to Dxf_In don't compromise the original Acad specification. All that takes time, and I don't always succeed.
-
You have to have layer 'Layer0' in a SKP.
You have to have layer '0' in a DWG/DXF.Whist CAD uses layers to separate geometry a SKP's layers only separate the visibility and geometry connectedness remains.
In CAD, objects on layer '0' inside a Block [aka Component] are treated in a different way to those placed on other layers; those on layer '0' will displayed the properties of the layer used by the Insert [aka Instance] of that Block, rather than those of layer '0' itself.
[This is akin to SUp's use of 'materials' - if a face inside a group/componnet-instance has the 'default material' then when you 'paint' the group/instance those faces display the group/instance's material instead - although in reality they are not changed - faces with other materials are unaffected by the 'painting' of the 'container'...]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...
currentlayer=model.active_layer model.active_layer=nil defaultlayername=model.active_layer.name model.active_layer=currentlayer
This leaves the current active-layer unchanged but sets "defaultlayername
" as a reference to the default-layer's name in that SKP's locale... which is 'Layer0' in EN-US but other names in other languages.......... -
the left over is gone , so no more "pergolas"
i see that 3d faces are not being imported at all. As you could see in the picture form my erlier post , there is a layer called BF witch is a 3d model from Blender imported into DraftSight, and finally exported as a 3d-dxf. in SU doesn't come that particular object. It is a truncated piramyd, and not a single line appears in SU, neither Layer0, nor any other layer. The layer (the name of it) appears in the layer's list, but no geometry exists. (as seen in the pictures from previous post)
No, do not eliminate Layer0. I'm not saying this. I only say that when Layer0 is turned off( say i want that for seeing just for seeing what i have imported from dxf file), everything dissapears, so by turning off Layer0, my scene desissapears and so the imported geometry from dxf, even though the the geometry from dxf is actually marked as visible.
It is a very strange behaviour, i don't get why you don't understand it. Look carefully at the 2 pictures comparing the situations, into my previous post. -
TIG, i'm saying isn't it better to have this situation?
@on Layer0, everybody draws their model in SU, say a forrest of cubes.
@now i want to import a dxf, in order to have some drawings that other made, to construct some more geometry into my scene. so it is better to have all the geometry for dxf on other layers that Layer0, to not mess up the entire scene.all i say is this: the imported dxf should be on it's separate layers, and geometry that is already in SU, should remain on it's layers. Not messing around. Everybody with it's place.
i think this is the best way on keeping everything organised.
cheers! -
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]... -
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. -
create a poll and see what people say
-
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 ? -
@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:
-
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...] -
Aaah... So you will layer objects to their code #8...
-
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.
Advertisement