Referenced DLVPs

[Assemblage]

I've got a problem best explained in the attached example files. The circles represent elements common to multiple storeys in the building. The little rectangles represent elements specific to that building storey, drawn in that level.

The 'Sections' file contains a whole model DLVP for cutting section VPs, and the 'Plans' file is layered ready for SLVP production...except the contents of the building storeys do not appear correctly in either file. What am I doing wrong?

Edited April 17, 2010 by Assemblage

[Assemblage]

I don't understand why the model/storeys appear correctly in the main model file but not in the other files.

[Assemblage]

Tried putting main model DLVPs in dedicated classes (attached). Same thing happens: main model file appears fine, in the other files all circles appear on all storeys.

Does this mean you can't use DLVPs when modelling, with multi-users??

[_c_]

Hello Assemblage,

it's just that the classes are all enabled in the "Plan" and "Section" files. You seem to think that if the classes are invisible in the original VPs then they should be invisible also in files referencing these VPs.

EACH original DLVPs in Master_Model states: show me the layer "Elements on many storeys". Then each DLVP enables/disables the particular classes.

"Use current document class visibility is disabled", so you have different class visibility sets for "Building Storey 1, 2, 3"

This doesn't happen in the files Plan and Section. So you see all you have in "Elements on many storeys". All classes enabled.

Look, you seem to have an awfully complex construct there, we use references all the time, multi-user, large projects, no problem whatsoever.

If I might give you an advise, use one file for one floor. Use the layer Z and dZ for constructing models. You instead shift the objects' Z, which actually all reside in "Building Storey 3".

That would make your life much easier.

I hope I understood your problem, I am really not intelligent enough for a construction like you do there

ciao,

orso

[Assemblage]

Many thanks for looking at this orso. I'm not looking for a 'complex construct' believe me...

A few things:

- Relieved to hear there are multi-user large project stable workflows happening out there. It's v hard to find advice; I found two diagrams: one Mike M posted, and Ellicott Heights (attached). Is yours like Ellicott Heights therefore..? How do you repeat elements across floors, and what about section viewports etc? A rough diagram would be great if you have one.

- We do actually use Z and dZ etc. I made an error with the rectangles, which should have been on each layer as I said in the text (corrected in the second 'Master Model' uploaded).. sorry about that. It didn't affect the reference problem I was showing so I didn't mention it.

- From what I understand the references I've set up should actually work, but don't. And it is something to do with the classes as you say. There's nothing on this in 'Help'; the references are not circular. I'll need to now rebuild the whole project some other way.

To the Moderators/NNA: do you consider there is enough guidance out there on these things? The NNA stance of not dictating workflow and leaving this to the user is accepted, however workgroup diagrams with pros/cons commentary on a small number of known/tested options would very useful, if not in fact necessary to professional architects entering contracts and serious deadlines who nevertheless want to start working in 3D.

[_c_]

Ciao Assemblage,

to fix your immediate problem: simply fix the class visibilities in the files where you load your DLVPs ("Plan" and "Sections"). Visible what should be visible, invisible what shouldn't.

Is no workflow problem, is just that visibilities are always related to the VP showing them. The attributes are another matter.

No, I won't make a diagram of how we work. Is too complex.

In this sense I am probably a tiny bit of a rebel, I don't think that the recommended workflow is apt to fit our needs. Which are simple needs of the banal architect. The recommended workflow has been developed with immense care. Who am I to state is wrong. I just observe that is not good for me and my environment.

I need things that Americans don't need. Such as loads of 2D details and permits going on up to 30 variants, while we are building. And we are responsible for all what's built, not the general contractor, so we draw a lot more and preciser than you need to do, you lucky ones...

In short:

MASTER FILES

All reference kinds are by "Design Layer viewport".

I need to use referenced resources. They to stay in sync. Personally I don't care much for DLVPs.

* one file for each floor

* different layers, where you put everything related to the floor.

(so for example dimensions 1:100, 1:50 each in a separate layer, and so on)

PUBLISH FILES

All references by "Layer import".

These are catch all files which display my master files. They also toggle the visibility modifying the attributes of the singular classes.

This allows me to have at the same time permits drawings (color coded scale 1:100) and construction drawings (strictly black and white, scale 1:10).

I just need to reset the attributes of the document.

These files make all but I don't work on them. They make me 3D, presentations, whatever. Just toggling the attributes.

Whenever I need a new issue, the whole set of files lands in "Archive", I upgrade the references and issue a new one.

mind, I use records (and scripts too), to achieve my needs, one could almost say that I draw using worksheets. I don't model. Only parametric.

hope it helps

orso

PS.

Before someone to state the false, I draw everything in 3D too. Just don't model it. And add up the 2D infos.

And I can't use generated sections above scale 1:100, because the cavities are not according to what my working environment expects them to be. A pity, because I am the greatest admirer of generated sections.

Edited April 18, 2010 by _c_

[Assemblage]

Hi orso

- We're in London, UK: we need to draw a lot too, all the way to 1:5 details for which we're directly responsible on site. A project we're just finishing has over 1000 drawings, all done in 2D, very many with over 30 revisions each. It's absurd: imagine a whole team pushing hundreds of 2D lines/info around the screen for months on end; and the cost, tedious cross-checking, and scope for human error that comes with that. In short, we HAVE to go 3D. And yet, finding out halfway through a new 3D workflow that we've set it up wrongly, or that VW can't do something we thought it could, could actually be worse. Hence all my questions. I'm puzzled however why the issue not more widely discussed ..?

- Interesting to hear about your parametric drawing via worksheets and scripts.

- Immediate problem: sadly, I still can't get the files working. All the circles are still appearing. All I'm trying to make appear in the 'Sections' file is the 'whole of model' you get in the Master Model file: the element classes and DLVP classes all need to be set to 'visible'. Attached is what I'm seeing: Master Model file on the left, Sections file on the right. Maybe yours works because you use layer referencing and not DLVPs?

[_c_]

Assemblage, I will send you your files "fixed" later, so you see.

Look, DLVPs are what I call "byzantine". I am a scripter, used to deal with visibilities, attributes and all their quirks since many years, but DLVPs are on my opinion one-two levels above average comprehension. So definitely above my comprehension.

Let's see if I can explain to you what is all about, in deep, it might be easier for you to understand what's happening to you.

DLVP are the same thing as the old reference style, but they hide the resources (including classes) and rename them in the background.

A huge apparatus of management then activates, in order to give you the impression that these resources aren't there. But they are there. You just don't see them.

So if you want to display certain classes on a DLVP whose content is again a DLVP and these classes are not enabled, AND these classes don't exist in your document (they do, but renamed), you just need to

Alternative A)

Enable the class visibility one by one, as you need, in each DLVP

Alternative B)

* click on the option "Use current document's class visibilites"

* import the classes which are missing in your target document by clicking on the 4th radio button with the small icon. This will make the classes sync to those of your target document.

At this point you can manage half-way easy these DLPVs and their visibility (and above all their attributes).

But actually you are back to the situation where you used old reference imports (the resouces are now imported).

And you might then just as well save yourself this pain and use straight off the design layer import system.

Mind, you can always use DLVPs, also with the old ref system, but on sheet layers you won't be able to display them (which is for me absolutely irrelevant, since I have all in desing layers).

All in all the complication of the DLVPs, their attributes, eventual overrides, and their resource management is such a monster, that I gladly renounce to it.

I might add that is seldom, very seldom, that I declare something too complicated in this application. But this is one, perhaps the only complicate thing available at plain user level. Still, is powerful, and there are circumstances where this power is the only solution, be it so cumbersome or not.

This happens when you need to deal with ACAD users and puzzle together drawings with different orientations. The new reference system masters this excellently, and ACAD recipients are happy.

Edited April 18, 2010 by _c_

[Assemblage]

I see. That was a helpful explanation, thank you orso.

The wider question to the Community Board was: can you use DLVPs to reproduce (and going forward, amend) common elements on different storeys of a building (eg a portion of perimeter wall with windows in it), rather than manually copy and pasting etc, whether you're using (i) the Ellicott Heights arrangement, in which case you're copying an pasting between files, or (ii) Mike M's arrangement where you're copying and pasting between levels in a Master Model file.

The answer seems to be: maybe, but it spawns a nasty thicket of classes which a normal user is unlikely to emerge from with his right mind intact.

[mike m oz]

If you have common elements make them symbols. That way one edit of the symbol will change the element everywhere.

[_c_]

Exactly Mike.

Assemblage,

to make the usage of symbols efficient (no copy, no lack of sync), we need to reference them from a common source. Thus the need to have the working files with the new reference system.

Even then, you don't actually really need this, you can "Export" them just as well at each edit. But it helps specially in multi-users projects.

I post here an "acquisition" for a small project where everything are symbols. The 3D that you see is constructed by references old style. This document has all attributes optimized for 3D (fills everywhere, textures...).

Just a few symbols to combine the variations of each floor. Which only rely on the terrasses.

Now if I want to see some plans, I just change the attributes of my document, and everything changes face (obviously I have templates for this and simply reload the references).

Actually to "publish" your drawings you have no other choices than use the old reference system. Because this system allows you ONE feature, whose advantages are so overwhelming, that you cannot renounce to it:

you can change attributes of a whole document simply loading by reference a prepared file and this reference has the option "Update Class Definitions" activated.

In our office we have 4 such files, which deal with the appearance. We store them in the Workgroup Folder>Defaults>Standards.

They allow you to override the appearance of a whole document on click.

Being them in Standard, they are also accessible from each file whenever the user needs to create a new class.

Each class is present on drawing using all its attributes. When I reference this file and the above mentioned option is checked, this file will override the appearance of everything.

The recommended workflow has this lack: it doesn't offer a good solution for managing the appearance. A project will need very differently appearing files according to the project phase.

A project contains hundreds of differently displaying VPs. I cannot go on changing their attributes every time I want.

It makes me furious and I also am prone to errors, without mentioning errors of my eventual colleagues working at the same project, who, in the rule, don't feel as comfortable with this application as Orso does.

orso

Edited April 19, 2010 by _c_

[Assemblage]

make them symbols

I had understood symbols were for things like a door, not a whole floor plate will numerous elements etc..are there information limits on symbol content? I'll experiment. I notice wall heights set to layer dZ cease to work, and need to be set to a specific dimension.