Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Joe-SA

  1. You might have a Saved View that keeps turning off some of your classes. The best way I found to quickly set where each class shows up and where it doesn't is with the Visibilities tab of the Organization Dialog box. This is an easy one to miss. Click Visibilities in the upper right corner along with the Class tab. When you highlight a class (or multiple) you see where that class is set for all your viewports and saved views. Manipulate a bunch of classes across multiple viewports with a single click. Its the fastest way to manipulate classes being turned on or off in areas that function outside the active class settings. (viewports and saved views) Joe
  2. The Snap Loupe feature (Z-quick key) lessons the need to turn off different wall components and still get the snap point you wish to use. Wall Styles set up with wall component classes (Wall-Component-Sheathing, Wall-Component-Frame) should give you the ability to turn off the classes you wish regardless of what class the Wall itself is in. Incidentally, the default is to have the siding and sheathing in the same class...I created the sheathing class to control it independently. Joe
  3. You can add your own custom hatch to the Linear Material Board(Generic) setting. This, however, won't give you a hatch that stays oriented to changing direction of the material. I think the hatch orientation is also a problem with the 2d poly with components idea. Years ago in the days before the Linear Material tool I used to use a suite of custom walls designed for drafting details. I had over a dozen for various thickness and materials. This was (and may still be) the only way to create a linear material where the hatch changes orientation with every change of angle of the material since a custom hatch can be set to maintain its orientation to walls. It would be nice if this setting also applied to the Linear Material PIO at the same time. Joe
  4. We set the walls to begin at the subfloor, not finish floor, as to avoid finishes extending beneath the interior stud walls in detail building sections. The floor slab datum is the top of subfloor. The wall heights are set to the plate heights, not the floor to floor heights. They get their value from the Wall Height setting assigned to the Layer they are on. I set the exterior sheathing and siding components (not the framing) to extend down past the floor slab to the Plate Height (Wall Height Setting) of the floor layer below. If I need to add 2" to my floor thickness my Layer Elevation (plate height) below doesn't change, I add 2" to my Layer Elevation to all the floor layers above. The actual heights of my walls don't change at all. If I need to modify a plate height then I modify the Wall Height setting for the Layer as needed. All this happens in one dialog box. I guess one item outside of the Organization Dialog box also needing adjustment would be the height of the sheathing and siding components that overlap the floor slab. This is saved inside the Wall Style and is a set value and not a value linked to a layer height. That, however, is just a single point of control for all the exterior walls unless there is a lot of variety in the design with regard to floor thickness and plate heights. One improvement I'll throw out there is to allow us to offset the wall components to bound floor slabs similar to how we offset slab components from bound walls. In this way my components that overlap the floor slab would be set automatically by the floor thickness the wall is bound to. Joe
  5. I would have hoped that you could use this to isolate a 3d portion of the model and print it with a hidden line or rendered view with some notations. I was hoping for the inverse as well, rendering an entire structure but using the clip cube to 'scoop out' a portion of the model so you can see inside. So when I upgrade I shouldn't expect either of these features to be possible? Joe
  6. One work around for 2d plan view only is to create one viewport in your sheet layer for your roof and one for your floor plan. Stack the 2nd floor plan viewport on top of the roof plan viewport. With the floor slabs on in your floor plan it should mask any roof lines that extend into the roof plan. If you don't have floors you may need to make a mask that you stack between the viewports. For 3d I do believe you have generate a section viewport from an elevation view giving you a horizontal slice at your desired elevation. I haven't done this but there has been talk on this forum that its possible. Joe
  7. I'll admit I'm getting closer and your diagram is helpful but I'm not quite sold and I'm not sure I will be until I actually put it to practical use. To answer your question about the slab thickness....I just open the Organization Dialog Box and modify some Layer Elevation numbers accordingly. Everything adjusts as needed from the one dialog. Even in your example you still may have to do this because you might raise the height of Story 1 a couple feet while desiring to keep Subfloor 1 and Subfloor 2 in place. In this instance you are modifying Layer Elevations in much the same way are you not? Like I said, I may need to just put it to practical use. Certainly the more stories you have the more important it will be to use them. I don't think I would even question their use in buildings with 10+ stories but in simple 2-3 story residential construction (which is the bulk of our work) I'm still not sure they add much to the process. Joe
  8. Just about all of the tools I use that I desire to link to a height setting get that height from the Layer, not a Story. (walls, columns, stairs, etc) So if I change a floor to floor height by adjusting a layer height I am still seeing all those linked objects shift accordingly. So one advantage is being able to adjust the first floor plate height and see all the floors above it move up or down accordingly without having to adjust those layer z-bases. But can the walls within a story extend up past the height of the floor above and extend into the story above? If I remember correctly this was not possible yet is common in split-level homes. Joe
  9. This is good to know. Depending on the new features we will often choose to finish a job in the previous version and not convert it to the new version while starting new jobs in the new version. I have multiple releases of VW installed on my computer right now. Are you saying that you were told this will no longer be possible? Joe
  10. Admittedly I haven't explored all the advantages and disadvantages of the use of Stories. My initial investigations hit on the split-level difficulties and it appeared then that the time spent to create work arounds and put those work arounds to use outweighed their advantage. I would be very curious to hear what advantages I'm missing out on by not employing their use in my modeling and construction documents and just using the layer settings. I'm sure I will be taking another hard look at Stories as I transition my office to VW2013. Joe
  11. You are not required to use Stories in your setup at all. Just leave them blank. For this specific reason I have yet to adopt their use. Just set your Layer Z-Base and Wall Heights independently in the Organization Dialogue. Joe
  12. Something doesn't seem right about your initial setup for your section. From your model, choose 'Create Section Viewport'. Place the section viewport on your desired Sheet Layer.(not a Design Layer) It sounds like you might be creating a Design Layer Viewport on a Design Layer and then linking that to a Sheet Layer Viewport. It appears you have a DLVP inside a SLVP. The intermediate step is not needed if the desired result is a section drawing on a sheet layer. Hope this helps. Joe
  13. The biggest advantage appears to be the time savings...faster panning while in render mode, generate renderings while continuing to work, crunch building sections from the cloud (according to the Keynote), etc. Having just upgraded from 4gb to 12gb things will seem like light speed. Biggest disappointment is the lack of Roof Components. Eliminating the 'too complex' error is a nice step, however. Biggest 'almost but just missed' feature in my eyes is the Detail Viewport. Why no ability to add breaklines to the detail viewport so a single wall section viewport can be broken into enlarged stacked display segments with breaks? Instead we need to create new detail viewports each with unique tags for each joint in a single wall section. I'm guessing time will be needed developing that work around. Other specific features look promising. I've learned to withhold too much praise until they are put through their paces, however. Joe
  14. When editing a VP be sure to toggle on Display Viewport Cache at the dialog where you select Annotations. This way the VP won't get lost and overlay drafting makes more sense. I will say the biggest issue with the 3d workflow you describe is the time and memory it takes to re-generate a series of viewports. I'm looking to upgrade my RAM specifically to improve this performance. I can't re-generate 4 in a row without crashing. Right now I'm presuming (hoping) more RAM helps the problem. Also a twinkling of hope better memory management for section VP's is included in VW2013. Joe
  15. Ungrouping the Roof Object into Roof Faces is one solution. Another is to cut a polygon representing your flat portion to the clipboard, edit the Roof Object by entering it like a group, paste in the polygon, and then exit. You should have just clipped the core out of the hip roof object. Fill in the gap with a floor object as suggested. If you think you will still have the need for very shallow slopes on the 'flat' part you can model that with another Roof Object set to whatever slope you desire. There was just an extensive discussion on Roof Objects vs Roof Faces you might be interested in. http://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=173418#Post173418 Joe
  16. Jonathon, I may have miss read the initial message but I thought the desire was to not just get a default title block from one project file to another project file but to actually reference the project data contained inside the title block from one file to another file that is part of the same project. Once upon a time when our title blocks were symbols on design layers it was easy to WGR the title block layer into other files that were part of the same project. The data was controlled from a single point in one file and linked to all other files. With Sheet Borders on Sheet Layers I have not found a way to recreate a situation where the project data can be input once into a 'master' file and have that data sent out to other 'satellite' files that are part of the same project. To all title blocks in the same file, yes, but not to external files. If I over thought it and Roman's question was far more basic then, yes, your recommended setup for up getting default title blocks into new projects is correct. An extension of this, however....if you want the same default title block to be available to multiple people on the same network then locate the title block in the Defaults folder of the Library and locate the library on the server. Everyone should then have a link to this location in their local VW/Library folder. Joe
  17. Not an easy question and not a straight forward answer. For geometry I would use DLVP. My current understanding is they make WorkGroup Referencing obsolete. Does anyone have an argument for why WGR should be used over DLVP? In the file you are referencing from, are you using TitleBlocks placed with the Sheet Border object with Automated Drawing Coordination and links to the Project Data, Sheet Data, and Issue Data sets? Or are you using a TitleBlock symbol with text linked to a Record Format? Or are you using a static titleblock with no special formatting at all? If you are using the Sheet Border with Auto Drawing Coordination, etc I have not found a method yet to link this titleblock data to satellite files so the Project Data is only input once in the main file and then linked out to multiple files. We place the Sheet Border object that references the titleblock symbol directly into the sheet layer outside the viewport and re-enter the data once for each satellite file. If there is a better method out there I would like to know. If you are using one of the other methods I would suggest creating a referenced symbol in your satellite file that remains linked to the main file. Place this symbol directly onto your Sheet Layer and not inside any viewport. I haven't tried this as I use the Sheet Border method. There may be some issues with the record linked text if you have some. A DLVP which then gets included 'inside' your viewport may also work but I feel titleblocks should stay on sheet layers and out of design layers. Joe
  18. I have recently started doing more and more detailing from models but it requires some special techniques that I hope are improved with new tools in the near future. We do primarily residential so the BIM requirement is not needed. My goal is merely drawing efficiency. I find myself exploiting the tools as much as I can to get the individual components into the model. Here are a few examples: - The co-planer nature of the Extrude Along Path command allows me to wrap crowns and fascia's and gutters easily around my eaves and/or rakes. Good for details and elevations. - taking my design level roof object drawn first to represent the entire roof assembly and full overhang and pretty quickly duplicating it in place and changing thickness and heights to create a series of stacked and properly classed roof objects each representing a component of the roof assembly and each with overhangs set as needed per component. (hopefully this gets automated soon in an upgrade) - setting my sheathing and siding wall components only to extend down to overlap the floor framing and up past the truss area to the roof deck. - using class overrides in viewports to achieve different hatches and line types (for footings for instance) whether you are creating a foundation plan or elevation (dash no hatch), an overall building section (generic solid), or detail (solid line with hatch) These and many other aspects allow me to get reasonably detailed section cuts through the model. More and more as the tools improve and I learn to use the them better and develop these techniques I'm finding the need for 2d overlay to be less and less. Yes, there is a long way to go but using the Linear Material, Detail Wood Cut, and Batt Insulation tools in a quick trace is much better than starting from scratch or even tracing a model shell with no components at all. Another sorely needed advancement is a tool to take a cropped viewport showing a foundation to roof wall section and introducing breaks so you can shrink it onto the page. Right now I have no choice but to duplicate the viewport for each break and adjust the crop for each one and then move the collection of viewports in place. Makes annotations a challenge. I use one overlay viewport for all the common scale detail annotation overlay on the same page for simplicity. I am longing for a special detail viewport that allows me to set the number of horizontal and vertical divisions along with the size of the breaks between the divisions and then the unwanted gaps would get automatically zipped out of the viewport. I believe Revit has this capability. A way to allow groups of common scale detail viewports to share a common annotation layer would be another welcome improvement. My current method is somewhat tedious especially considering the section viewport regeneration time but it still seems better then other methods which include more 2d drafting and details with no connection to the changes that take place in the model. BTW - I use DLVP's to get the model into a satellite file and generate the section detail viewports from there. Joe
  19. Thanks for the link. I'm assuming in the last few months nobody has been able to get the setwallheights command into a script that functions in VW2012. I curious question...even if it did work, does this command change the heights of the end points or does it change the height of the center reference point? If I have a bunch of walls that are all flat topped but with end points set at a variety of different heights other then the height of the center reference point of each wall, some shorter some taller...a change to the center reference point is no different than changing the number in the OIP and both end points move with the height change. If that command actually reshapes the end points to a newly input height or simply re-shapes them to the already assigned center reference height...it would solve the problem. Joe
  20. In the past I have converted the numbers field to a text field so they don't add even though they are numbers.
  21. I have the 'unfit walls' script that takes the peaks out of walls. However, I need to go one step further. I've always wondered why when you reshape the ends of a wall to make them taller or shorter the reported wall height in the OIP remains unchanged. After running the 'unfit walls' script its very easy to end up with a variety of walls that appear graphically to be different heights but all report the height they were first created at...usually the original layer wall height. I thought using the OIP to modify them all back to Layer Elevation height and then back might fix it but it doesn't. There doesn't seem to be any way except graphically reshaping each corner of every wall back to my desired plate height. If you modify designs between flat or vaulted ceilings or hip vs gable roofs or heights of dormer walls or attic knee walls this can be an issue. Right now the easiest method I know of is to simply redraft the walls in place. Does anybody have a script to automate this process? Joe
  22. We do our own custom schedules so I am not familiar with the VA door schedule, however, in worksheets when editing your database headers you can drag the 'sum' icon (short for summarize I believe) into the database header of any column. Any duplicate names in that column will be listed only once. I would suspect this would work in the VA door schedule. Joe
  23. I would like to see what roof designs you are saying can't be built using Roof Objects. I do some exceedingly complicated roofs using Roof Objects. I find it difficult to believe there are some planer based roof designs that can not be built using them. There are aspects of technique and work around that I use that may not be evident in this discussion. For example, adding corners and reshaping is often dependent on the order of operation like taking away an overhang to accomplish a reshape and then bring it back. I had many frustrations in this area when I first started using them. Especially before I started breaking down my roof objects to more basic components. I recently had to model a vaulted gambrel roof and provide both interior and exterior model views. A nightmare for both tools since gambrel is a totally unsupported roof type. I ended up using stacked Roof Objects each representing a component of the roof so my interior finish could extend just to the point I needed it at the underside of roof joints while my framing stopped at the wall plate and my sheathing extended out over my crown moulding and trim. Quite complex and made me long for a single Roof Object with inherent components each with independent perimeter offsets. But considering I was able to manipulate multiple faces at a time in a single Roof Object plus the need to 'enter' every face in order to get the the polygon to reshape I feel this would have been more difficult overall with Roof Faces but perhaps easier in some ways like combining faces. I am finding it quite easy to duplicate and explode roof objects in order to gain the ability to combine roof faces where I need to define hips and valleys but I then return to the Roof Object for perimeter reshape and/or cutaways. It is quite effective and allows me to keep the other advantages of using Roof Objects I have mentioned.
  24. I guess I'm not fully understanding the point. Yes, Roof Objects are made up of Roof Faces allowing you to break up the objects to its face components (this is good when you need it) but the creation process, editing, texturing, interaction with surrounding objects and plug-ins, parametric settings, etc are very different between the two object types as we have been discussing. In my eyes, this makes for two very different tools with different abilities both put forth to accomplish the same task. Neither are perfect and both are in need of an update. My intention in first joining this thread was to simply illustrate to new users the many reasons why a Roof Object might be a better choice than a Roof Face even for a single plane roof like a shed roof. I'm sure they are now able to weigh the pros and cons and join the debate.
  25. Yes, this is what I was referring to as zero overhang. However, doesn't the position of your pivot change depending on which type of miter your roof has? My understanding is AXIS Z represents (in section) the lower outside corner of the roof at the plan drawn slope line. For a vertical miter its along the bottom of the roof thickness, for horizontal miter its along the top of the roof and for double miter it somewhere in the middle. Even if you work that out you still have to deal with the unwanted change in height of the vertical leg of the double miter when changing a pitch. I'll stick with typing in a bearing height and a bearing inset and a distance for vertical leg of the double miter and knowing all three will only change if I change them regardless of changes in pitch and thickness. I don't think that is usually the case with Roof Faces. Also I like being able to modify an overhang by typing in a new value instead of doing a reshape of a polygon. The only thing I feel I'm giving up is the automatic joining of roof faces and I'm not really giving that up because I can always duplicate and explode a couple of roof objects to faces, do a quick join to find a valley, then use that line to shape my Roof Objects while deleting the faces used to find the valley. I'm not trying to win a battle here. One of the great things about VW is the many ways to skin the cat. I'm just trying to be clear why I don't see myself going back to Roof Faces any time soon. I'm losing out on a lot of features of Roof Objects using Faces and I feel I'm missing very little by using Roof Objects.


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.

  • Create New...