Cad to Sketchup Issue - Please help

haynesc

my problem :

rickgraham

my problem :

Sorry, I'm still not following. Your villa1, villa2, etc. need to be imprted into Sketchup one by one in order to show. Unless I'm not understanding. Here is a sample drawing imported into SketchUp.

In the CAD world, all of these would be xrefed into a master sheet. In SU, they are imported and are separated by their layers names, and are also components so you can drill through them and still keep their individuality if you wish.

Rick

xrefed stuff into SU.png

bocomofo

Could you not save a copy of your CAD file and bind the xrefs to it? That way when you import it to sketchup everything will be in the correct place, and your villas will be blocks.

A solution perhaps?

haynesc

@bocomofo said:

Could you not save a copy of your CAD file and bind the xrefs to it? That way when you import it to sketchup everything will be in the correct place, and your villas will be blocks.

A solution perhaps?

Yeah Thanks ... this seams like the only way ...

rickgraham

@haynesc said:

@bocomofo said:

Could you not save a copy of your CAD file and bind the xrefs to it? That way when you import it to sketchup everything will be in the correct place, and your villas will be blocks.

A solution perhaps?

Yeah Thanks ... this seams like the only way ...

Yeah, that's one way... $:\$

Rick

Chris Fullmer

Why not just open each separate dwg into SU?

haynesc

@chris fullmer said:

Why not just open each separate dwg into SU?

its not as simple as that though ... has the 'xrefs' i am using are acting as villa typology blocks within a landscape plan ...

i cannot open these xref blocks as they have no defined global position, they are just inserted into the landscape/masterplan plan and then copied/rotated/mirrored/aligned to fit the road layout ...

masterplan.dwg, > villaA.dwg (xref) (26 instances), > villaB.dwg (xref) (34 instances) ... etc

when i open the masterplan.dwg in su, the villas are not inserted as they are xrefs and sketchup doesnt understand them i suppose ...

chris h

TIG

@haynesc said:

thanks but this hasnt really answered my question ...
i have a masterplan.dwg drawing with xrefs: villa1.dwg, villa2.dwg, villa3.dwg, etc inside, which have been copied into their respective locations, therefore the villas are xrefs with x. no. of instances per typology
... i dont want to convert these to blocks within cad ... how can i bring them into sketchup??
seams impossible

You cannot import xrefs via a dwg.
However, if you just copy the original dwg and bind-in all of these xrefs then they become blocks within the dwg itself.
Now you can slim-down, purge and tidy the copied dwg before it is imported into SUp... [always a good ideas anyway]...
I don't see the problem here - you can't import something that's "not there" - an xref is 'an eXternal REFerence' ?
If you want to import the individual villas' dwgs then you can do so.... BUT you'll have to manually place/rotate them etc to suit - but this could be done over the top of a 'bound' dwg import which is later deleted/purged from SUp ???

haynesc

I understand the issues now ... i will be binding my references before import, thanks for the help...

Chris Fullmer

Oh interesting. The way you are using your x-refs is how most people would use a block (at least the places I've worked). If you have an object and you want to use it repetitously ina model, insert it as a block. THen when you update one block, you update all others. THat way SU will import your block as a component and you will have 24 instances of a single component.

I do not know if there is a quick way to convert all instances of an xref into a single block in CAD. That might help solve the issue.

Chris

TIG

@chris fullmer said:

Oh interesting. The way you are using your x-refs is how most people would use a block (at least the places I've worked). If you have an object and you want to use it repetitously ina model, insert it as a block. THen when you update one block, you update all others. THat way SU will import your block as a component and you will have 24 instances of a single component.
I do not know if there is a quick way to convert all instances of an xref into a single block in CAD. That might help solve the issue.
Chris

An xref in CAD is just a special form of block that refers to an external dwg file - so it's not 'really there' in the CAD file... if that external xref dwg file changes you are told, and you can reload it into the CAD file: the latest xref version is always used when the CAD file first opens.
At any time you can 'bind' an xref into the CAD dwg and it then becomes an ordinary block inside the dwg file - at that point changing the original xref dwg has no effect on the one that was 'bound'.
You can make a block inside a CAD file and then 'wblock' it out as a separate dwg you could xref back into the file if desired...
In a way, in SUp an imported component skp is part way between the two. You can reload it as needed but it's always 'in' the model - whereas a CAD xref is wholly external until it's bound...

haynesc

@chris fullmer said:

Oh interesting. The way you are using your x-refs is how most people would use a block (at least the places I've worked). If you have an object and you want to use it repetitously ina model, insert it as a block. THen when you update one block, you update all others. THat way SU will import your block as a component and you will have 24 instances of a single component.

I do not know if there is a quick way to convert all instances of an xref into a single block in CAD. That might help solve the issue.

Chris

The reason for using the xrefs as blocks, is due to the large scale collaboration of multiple designers working on a large scale masterplan in this case. The 'xref block' shall we call them work because an architect can redesign the villa, save his/her drawing and the urban designers who are all working on their respective piece of the giant puzzle, all get a new villa design updated in their chunk of the masterplan, eliminating block duplication / discrepancies ...

file structure:

[masterplan].dwg

xref Road Network.dwg
xref Context.dwg
xref Landscape.dwg

xref [district area nameA].dwg

xref VillaA.dwg
xref VillaB.dwg
xref VillaC.dwg

xref [district area nameB].dwg

xref VillaA.dwg
xref VillaB.dwg
xref VillaC.dwg

xref [district area nameC].dwg

xref VillaA.dwg
xref VillaB.dwg
xref VillaC.dwg

level one attachment

level two attachement

does that make sence ?

chris h

TIG

I know xrefs all too well - I use them all the time in CAD...
Of course there's also my SUP XrefMananger.rb that lets you import SKP, DWG and DXF in a similar way and keep track of them being updated and then reload, bind etc - it's a bit long in the tooth now and needs and makeover but it works...

rickgraham

Yes or no - when you xref a drawing they have a common insertion point. In this case 0,0 unless you have it changed to something else - the answer is YES

Yes or no - When you IMPORT a drawing into SketchUp and and in the import OPTIONS, they are set to PRESERVE DRAWING ORIGIN it will overlay perfectly - the answer is YES

THERFORE - my post earlier that spelled this method out would work. There would be no extra work needed on the CAD end to bind xrefs and all that.

sigh I better leave this thread for my own sake.

Rick

haynesc

@rickgraham said:

Yes or no - when you xref a drawing they have a common insertion point. In this case 0,0 unless you have it changed to something else - the answer is YES

Yes or no - When you IMPORT a drawing into SketchUp and and in the import OPTIONS, they are set to PRESERVE DRAWING ORIGIN it will overlay perfectly - the answer is YES

THERFORE - my post earlier that spelled this method out would work. There would be no extra work needed on the CAD end to bind xrefs and all that.

sigh I better leave this thread for my own sake.

Rick

lol ... the answer for the first one is no ... i have many xrefs and many locations therefore it wouldnt work ...

rickgraham

@haynesc said:

lol ... the answer for the first one is no ... i have many xrefs and many locations therefore it wouldnt work ...

Hmmm, I have been taught from day one in AutoCAD (back in 1987) that all xrefs should share the same origin for ease of organizing and collaborating drawings. Ever since that I have been faithfully teaching, writing, and doing that methodology without anyone objecting, per se.

That is why I am surprised at this. No reflection on you at all.

Rick

Chris Fullmer

@ Rick - It is because his xrefs are being used more like blocks. Bring in one bldg footprint, then move it to one of its 20 locations. Then rotate it to fit the orientation of that site. So each bldg has a different insertion point and rotation.

I definitely see why you're doing it that way, and it makes complete sense. It does make the SU import a bit tricky though. Possibly a plugin could be devised? If only there was someone on the forum who knew Ruby AND Lisp....hehehehehe.

Chris

j.k, no real pressure intended TIG.

TIG

Xrefs in CAD are just 'blocks' that refer to an external dwg file.
You can insert them - move, copy, rotate, scale, mirror etc as needed - just like blocks - it's a very common usage. Individual house-types can be drawn orthogonally with a common origin at 0,0,0 making swapping them easy - you can insert them as blocks OR xrefs [remember that you can always bind the xrefs into ordinary blocks later - if there are later changes you can always re-insert the block to update the earlier (now 'frozen') version]

The other way is to use xrefs as 'models' and have a separate set of sheet dwgs that have these model.dwgs inserted as xrefs into the sheets' model-space, with layers on/off as needed, and little or no 'raw' stuff in the sheet's model-space itself otherwise. You'd always insert your xrefs at 0,0,0 and lock their layer etc, never copy/move them etc - this is important when you have a single building inserted onto a site plan - you have the building's grid-dwg set to the correct location orientation [using the site-dwg as a temporary xref overlay] and you then use a UCS to set it square to the screen when editing it later. The desired building dwg's [e.g. grid/wall/etc] are reinserted as xrefs into the site at 0,0,0 so to line up appropriately - taking any world-coordinates etc will return true in the site or building dwgs. Any sub-xrefs for the building are all inserted at 0,0,0: so for example the ceiling-dwg xref lines up over the grid-dwg and the wall.dwg etc etc...

Note also that xrefs can be 'overlaid' or 'attached' - overlay is only visible in the 'parent' dwg that has it inserted - inserting that into another dwg will NOT show the overlaid xrefs; however an attached xref is 'nested' and will be brought in by the parent when that is inserted !
This can lead to confusion OR useful results...
If I am working on a plan.dwg and you are looking at the elevation.dwg you can xref-overlay the plan.dwg into your elevations to help align elements; I can also overlay your elevation.dwg into my plan.dwg so I can see the changes you make in real time whenever I reload that xref... This is fine as long as they are overlays - if they were attached then all hell breaks loose - your imported elevations show my plan in my plan and my imported plan shows the elevations in your elevations. Such nested xrefs make binding impossible as you cannot bind something into itself ! If a user 'unloads' such an xref it is not show but still there and messes up any attempts to bind xrefs - ***see 'archiving' paragraph below.

Mixing the methods and attaching nested xrefs can be useful too - for example you have a hotel project, there are dwgs for a base grids, base wall plans etc overlaid as xrefs in appropriate sheet.dwgs, you have a bathroom layout as a separate dwg inserted into every room as an attached xref in the wall dwgs - that way it'll come over into other dwgs using the walls - appropriately layered stuff can easily e used to hide or change the nature of the displayed elements. For example - for a ceiling plan you want to xref in the walls etc, so the WALL- layers are 'on' but the WINDow layers are'off' etc, except for the dotted LINTel layer used with the windows which is left 'on', but changed to look solid/heavy like the walls - that way the wall is continuous around the ceiling... hanging the walls/windows in one dwg will change them in the ceiling plans too - avoiding the need to manually coordinate your drawing sheets...

Since xrefs are dynamic and update whenever a dwg containing one is [re]opened it is important that you have an agreed 'archiving' procedure to 'freeze' a dwg at a set point - e.g. when it is issued to others or passes over to SUp for example - this seems missing here. This 'archiving' process needs to copy the dwg to an 'archive' folder [renamed with a revision suffix added etc], then you'd bind in all xrefs***, then purge and audit the dwg etc etc before finally saving it [perhaps in an earlier revision to suit some recipients] - you might also make dwf and pdf version at this point. In the past I have made tools in AutoLisp to automatically do all of this...
Simply saving a copy of the dwg with a revision code is useless - when you are on rev-B but want to look [or worse reissue] rev-A, when you open it it'll update with all of the current xrefs - xrefs must be frozen by binding them into the archived versions.

This turned into a CAD xref guide - seems some users need it IF they are to import stuff the SUp later ?

rickgraham

@chris fullmer said:

@ Rick - It is because his xrefs are being used more like blocks. Bring in one bldg footprint, then move it to one of its 20 locations. Then rotate it to fit the orientation of that site. So each bldg has a different insertion point and rotation.

I definitely see why you're doing it that way, and it makes complete sense. It does make the SU import a bit tricky though. Possibly a plugin could be devised? If only there was someone on the forum who knew Ruby AND Lisp....hehehehehe.

Chris

j.k, no real pressure intended TIG.

Hi Chris,

The keyword that got me stuck was XREF. Instantly my mind goes into the 'insert a 0,0' mode. If the OP would have said BLOCK, then this whole thing would have been settled or I wouldn't have chimed in - which might have been for the better.

Rick

rickgraham

@tig said:

... and TIG said ALOT of good things here.

That was pretty good TIG. It pretty much nails it on the head.

Rick