Jump to content
Sign in to follow this  
Pete (STZ)

2d vs 3d elevations and line weights

Recommended Posts

The dialogue box asks, "do you want the selected object(s) to use the graphic attributes of the new class?" I said NO to all, keeping the heavy lines for the floor plan.

By doing this, the attributes won't be by class, meaning that the class overrides you do in viewports won't be doen to your walls.

Look at it this way:

* Create a wall class.

* Set the wall class attributes to something you want your walls to look like in plan view.

* Check the box "use at creation".

* Put your walls in this class, and make sure they take over the attributes of the class. (look at the attributes palette, there should be arrows on them)

* If you now have viewports of plan view, your walls will look as you want in those.

* In the elevation view, override the class to something else.

* You'll see your walls changing.

I think you need to slow down a bit and try to solve things bit by bit. Creating a workflow in VW for getting the results you want isn't that easy. You need to try some stuff to see what's best for you.

Share this post


Link to post

Thanx DW for giving the run-down to Ken...

But I think that he is missing 1 major step at the VP level...

Class overrides mean that you 'Edit' that particular class to the desired attributes in the particular VP itself.

So going back to your first example... with your 'House' and 'Garage' classes for walls, ensure that the heavy lines you have on your walls in plan are using the CLASS ATTRIBUTES (i.e. the little arrow thingy for the different attributes in the 'Attributes Palette'). So your plans look the way you want them to.

In the Elevation VP, click the 'Classes' button in the OIP, and scroll down to the 2 classes (House & Garage). You can use the Cmd button to select them both at the same time if you wish both sets of walls to show the same line weight in elevations. Click on the 'Edit' button, and put in your desired line thickness, click 'OK' twice and you should see the difference.

The main thing is that the attributes are SET BY CLASS in order for you to have that level of control.

Yes, wall components are very handy if you use them right, but not necessary for what you want.

I only recommend line weight scaling (Advanced Properties), if you wish to adjust the Line thicknesses of EVERYTHING in that particular VP.

In your example though, if you wanted to control visibilities of House and Garage, i would have placed these in different Layers, and kept 1 class for the walls. Again, this all depends on what you want to achieve.

If it still doesn't work, send a file (exported to 2011), and I'll sort it out!

Share this post


Link to post

I see what you're saying. Editing the class inside a VP is unique and does NOT affect global settings ? although the edit window looks hauntingly similar.

But this actually means I cannot use the same Class definitions for simple on/off visibility in the same VP because the "House" and "Garage" classes I already have assigned to many other objects, some of which require different line weights from that of walls.

I might as well create new classes solely for the purpose, like VPL1, VPL2, VPL3, VPL4? maybe up to VPL7 because my elevations require as many as seven different line weights. More classes to manage... you have to keep track of this from VP to VP to VP.

And all this requires assigning *SOME* kind of distinct class to each and every visible object. The default None class becomes lacking. You just can't draw simple objects and leave them in the None class.

It's a decent work around though... just for walls' line weights.

Share this post


Link to post
I see what you're saying. Editing the class inside a VP is unique and does NOT affect global settings ? although the edit window looks hauntingly similar.

But this actually means I cannot use the same Class definitions for simple on/off visibility in the same VP because the "House" and "Garage" classes I already have assigned to many other objects, some of which require different line weights from that of walls.

I might as well create new classes solely for the purpose, like VPL1, VPL2, VPL3, VPL4? maybe up to VPL7 because my elevations require as many as seven different line weights. More classes to manage... you have to keep track of this from VP to VP to VP.

And all this requires assigning *SOME* kind of distinct class to each and every visible object. The default None class becomes lacking. You just can't draw simple objects and leave them in the None class.

It's a decent work around though... just for walls' line weights.

When you give your classes descriptive names and group object to what they are, you'll have manageble classes. Just investigate what you want to accomplish and see what kind and how many classes you need for that purpose. Like you say, you'll have a pair of classes for your walls, the rest will follow.

Share this post


Link to post

Don't you guys have the lineweight overide option in the eyedropper tool???

Works on 2D and 3D lines.

:grin: :grin:

Edited by Kizza

Share this post


Link to post

As a slight turn in this conversation: once classes have had over rides for line weights etc, is there an easy way to have hatches on these walls in elevation views? No matter what I try, I can't seem to get hatches to work in anything but top/plan view

Share this post


Link to post

Nup - only as a viewport annotation 'overlay'.

You can also 'extract a planar object' under the extract command - however it is not linked to the wall so you have to manually adjust the hatch. The only way to do it if you want your hatches in your perspectives...

Share this post


Link to post

Or you can use textures that represent hatches. I know it's not the same, but it's doable.

Edited by DWorks

Share this post


Link to post

But if you extract a planar object and then render it hatched in a hidden line section viewport, does the hatch show up? I can't get it to show up in my section viewport (although it does fine in an isometric viewport!)

Share this post


Link to post
Works on 2D and 3D lines.

It's not the lines that are the problem it's the PIOs......

PIO's should always set their objects by class for total control!

You'll have more classes, but also more control.

Share this post


Link to post

Agree on the classes for PIO components generally, but long term we need less abstraction for the Architect version of VW - we need Building Materials which have real world properties such as appearance, performance, density etc that are consistent in 2D/3D

Share this post


Link to post
Agree on the classes for PIO components generally, but long term we need less abstraction for the Architect version of VW - we need Building Materials which have real world properties such as appearance, performance, density etc that are consistent in 2D/3D

Precisely. ?If I?d asked customers what they wanted, they would have said ?a faster horse'" ?Henry Ford (attributed, unsourced, probably didn't actually say it)

In other words, get our feedback on what we need; what we like, what we don't like, what makes our lives easier or harder, what we wish for and what we're trying to get done. But NV needs to come up with the solution. Solutions that look at the big picture and actually solve the problem rather than simply trying to improve tools that are fundamentally not up to the task. Improving the existing tools based on our isolated feedback in this instance isn't a solution to the problem, it's a stopgap. The solution involves less abstraction.

Share this post


Link to post

Some wrinkles in this class overrides discussion some might be missing that I don't think have been mentioned....

When you define your Wall Style you must set your wall attribute lines within the style to be controlled by the class you draw your wall in. If the original Wall Style is not set this way the class overrides will never work.

In addition, I found an oddity with this. 3 tiered class names do not always respond to class overrides yet 1 and 2 tiered class names do. I was setting up classes where I could model my foundation and footings using Wall Styles. By default they show up the way you typically see them in plan. However, in elevation I want to override the foundation walls to be dashed while in section I want to override the dashed footings to be solid and filled with concrete. I struggled with this until I dropped my class names down to 2 tiers...then all worked well.

In the end I have the following classes:

Wall-Exterior, Wall-Interior, Wall-Footing, Wall-Foundation, in addition to all the Wall-Component-____ classes.

One other comment on general information organization....I've never been an advocate of using classes for items like 'House' and 'Garage' to control visibility. Those items are much better organized on different layers. Classes are best used to control attributes of building components. Its a rare occasion when I use classes for visibility. One example, I always have a TEXT layer paired with every floor plan layer. REAL objects go on the plan layer while SHEET objects go on the TEXT layer.

I tried adding furring to concrete walls as a component and turning it off for my foundation plan but the concrete components that remained would not display properly. I had to abandon it. I was trying to simplify the insertion of basement windows through both furring and concrete but for now its still a two stage process for me. Insert the window into the furring wall with an extended sill and cut a separate hole in the separate concrete wall.

Share this post


Link to post

In addition, I found an oddity with this. 3 tiered class names do not always respond to class overrides yet 1 and 2 tiered class names do. I was setting up classes where I could model my foundation and footings using Wall Styles. By default they show up the way you typically see them in plan. However, in elevation I want to override the foundation walls to be dashed while in section I want to override the dashed footings to be solid and filled with concrete. I struggled with this until I dropped my class names down to 2 tiers...then all worked well.

The problem is not because they are 3 tiered. It's because the names are too long. I had to change a bunch of my classes to get their names shorter, still 3 tiered, because of this. I hate using abbriviations, but in this case I have no choice. I first found this out, and bugsubmitted it, when using referenced design layer viewports to other documents. Classes with too long class names will not show up in the class list, although the objects do show, but you can't change the visibility or attributes.

Share this post


Link to post

The problem is not because they are 3 tiered. It's because the names are too long . . . Classes with too long class names will not show up in the class list, although the objects do show, but you can't change the visibility or attributes.

So how long is too long?

Thanks.

Monadnoc

Share this post


Link to post

So how long is too long?

I did not test it exactly, but the following class was one of the problem makers:

3 Secundaire bovenbouw - 2 Binnenschrijnwerk - Materiaal VA (1)

That's 63 characters.

I then changed it to the following to avoid the problem:

3 Sec. bovenbouw - 2 Binnenschrijnwerk - Materiaal VA (1)

That's 57 characters.

It really is a bug, because we can declare classes with longer names, but they give problems like these.

Share this post


Link to post

I don't know if it has changed, but class names used to have a limit on their length. I think it was 23 characters, but I am not sure.

You could put in a longer name, but only the first 23 characters would be used to identify the class internally.

I wonder if that could be part of the problem.

Share this post


Link to post
I don't know if it has changed, but class names used to have a limit on their length. I think it was 23 characters, but I am not sure.

You could put in a longer name, but only the first 23 characters would be used to identify the class internally.

I wonder if that could be part of the problem.

Didn't know that, but I don't think this is the case anymore. I have a lot of classes that begin with the first two groups of my example.

Share this post


Link to post
Agree on the classes for PIO components generally, but long term we need less abstraction for the Architect version of VW - we need Building Materials which have real world properties such as appearance, performance, density etc that are consistent in 2D/3D

Here, here. I'll have to second that thought!

I have a current thread in "general" section (Help with VW vs ACAD)in which I'm weighing the cost of upgrading from VWA/RW 2008 to 2012 and I specifically ask if in the 4 versions I've missed my list my pet peeves has been addressed.

Among them:

--applying hatches to 3d objects (why? textures are not the same (my drwgs still get plotted in B&W) and its way, way too cumbersome to fake in the annotation VP)

--polygon by lasso within VPs (why? so I can quickly, although tediously get elevation line wts to look right, ie profiling. yep that's oldschool, but its what makes my drwgs look better than an engineer's working in ACAD)

--visual control of live sections.

--Better door and window control (mainly to simply have them look right in plan view, elevation, and section)

and... the big kicker-- can I finally use VW as a 2d/3d tool rather than have this convoluted workflow to address one workaround after another!!!

BTW I use the classes to control visuals control extensively and rely heavily on Class overrides in VP's. Sounds like this workaround, er, I mean, workflow is still an accepted methodology.

One tip is create one good elevation with overrides in place, foreground/backgrnd render options selected, then duplicate and reset view for each add'l elev needed (still req's a lot of "touching up" IMHO).

I'm sure a lot of you have used Sketch-Up. How can such a basic program define line wts by edge so easily and effectively, while we continue slogging through the workarounds.

Share this post


Link to post

BTW I use the classes to control visuals control extensively and rely heavily on Class overrides in VP's. Sounds like this workaround, er, I mean, workflow is still an accepted methodology.

I find classes always getting in the way. You will need to seriously consider other software if you want more efficient functionality in this area.

Share this post


Link to post

[quote=Mark McCay-MoranOne tip is create one good elevation with overrides in place, foreground/backgrnd render options selected, then duplicate and reset view for each add'l elev needed (still req's a lot of "touching up" IMHO).

You can use the eyedropper to copy the overrides from one viewport to another.

And you can use the organisation dialog to set visibilities in multiple viewports at once.

Share this post


Link to post

Thanks for the info. I don't see a logical reason and/or pattern on why 57 works and 63 doesn't, but it's one more tool to fall back on when troubleshooting the 10,000 bugs of VW.

Thanks.

Monadnoc

So how long is too long?

I did not test it exactly, but the following class was one of the problem makers:

3 Secundaire bovenbouw - 2 Binnenschrijnwerk - Materiaal VA (1)

That's 63 characters.

I then changed it to the following to avoid the problem:

3 Sec. bovenbouw - 2 Binnenschrijnwerk - Materiaal VA (1)

That's 57 characters.

It really is a bug, because we can declare classes with longer names, but they give problems like these.

Share this post


Link to post
I'm sure a lot of you have used Sketch-Up. How can such a basic program define line wts by edge so easily and effectively, while we continue slogging through the workarounds.

Well the simple answer is because it is a simple program whereas VWs is a very complex program. Though this shouldn't be an excuse for not having better control over sections and elevations, which are an essential part of an architecture workflow.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×