Cad to Sketchup Issue - Please help

TIG

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

haynesc

If a plugin was able to import a .dwg in sketchup with all its xrefs, overlays or attachments ... thats exactly what im praying for ...

otherwise i will bind the masterplan.dwg xrefs into one file, hopefully the size wont be too big ... then i can start modelling...

question: ... for example if:

'Masterplan.dwg' has inside xrefs:

'South Beach.dwg' & 'North Quarter.dwg' & 'East Peninsula.dwg' and so on... and each one of these districts have 'villaA.dwg', 'villaB.dwg', 'townhouseA.dwg' xrefed into those as attachments ...

when i bind the masterplan.dwg, will sketchup convert all 'villaA.dwg' instances into a component ... 'villaA' ... or will it only do it per district ... 'villaA_1', 'villaA_2' ...

This topic is a good one to discuss in my opinion and certainily a feature / plugin request ...

Thanks

Chris Haynes

TIG

You cannot import xrefs.
They must be bound in OR imported individually.
How do you save versions of this scheme ?
You must bind xrefs otherwise the dwg will always update and you have no frozen version ??
Surely you have a bound dwg anyway for your records ???
It's easy to bind them into a copy of the dwg 'master' and import that - ALSO remember to purge, audit and tidy up the CAD dwg, before the import to minimize its size - SUp doesn't need hatching, text, dims etc - you can easily use the CAD filter options to select and delete these - then re-purge etc...

To import xrefs from a dwg into SUp you need to read the dwg code and have the xrefs in the correct folder relationships etc - probably all too complicated.

haynesc

@tig said:

You cannot import xrefs.
They must be bound in OR imported individually.
How do you save versions of this scheme ?
You must bind xrefs otherwise the dwg will always update and you have no frozen version ??
Surely you have a bound dwg anyway for your records ???
It's easy to bind them into a copy of the dwg 'master' and import that - ALSO remember to purge, audit and tidy up the CAD dwg, before the import to minimize its size - SUp doesn't need hatching, text, dims etc - you can easily use the CAD filter options to select and delete these - then re-purge etc...

To import xrefs from a dwg into SUp you need to read the dwg code and have the xrefs in the correct folder relationships etc - probably all too complicated.

tig,

we bind a frozen drawing when we issue to client ... but apart from that no we dont bind drawings. we create revA, revB of the seperate districts, but the master drawing is always the same file as it has nothing inside it but xrefs ... you unload all the xrefs and the drawing is empty ...

chris

TIG

I understand that - it is the usual process - and as you say, you have the 'frozen' copy for the 'client' issue - so why not make one for SUp import ?
On import it will bring all of the xrefs in as blocks > components.
If you want to bring in the original xrefed dwg too then you can either try an 'swap' if with the 'bound' component version or place the original version over it and rotated etc using it as a guide then erase the bound one - that way you'd have the separate dwg villas as components and the site as it was [after you erase all the bound versions once the reinsertion is done and the model has been purged]

bytor

TIG,

Great explenation of x-refs in CAD. External References are one of the most powerfull features of all of the different AutoCAD flavors. Multi-discipline teams / offices could never survive without them. That being said - I have never seen a topic and concept that so confuses a typical CAD user more than x-refs, and their proper use. This 2 pages is a a good reminder of why I am so damn glad we migrated to Revit this past year!

Dean