Jump to content

Joe-SA

Member
  • Posts

    232
  • Joined

  • Last visited

Posts posted by Joe-SA

  1. 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

  2. What if you change your slab total thickness?

    Using stories is just more flexible because you can have more levels to choose from for each object, and you can draw objects on layers and have their height/level be linked to the level of another layer.

    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

  3. If they change, then you'll miss the ability to just change the level type height and see all changing accordingly.

    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.

    My understanding is with a split level or mezzanine, the only hard part would be to base those design layers (which would include floors, ceilings, wall heights, etc.) as an offset elevation height of a Story (as in the adjacent lower floor level). Once this inconvenience is done, then it would be easier to work with.

    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

  4. Nicholas,

    In the seminar they told me that I could not maintain my installation of 2012 if I installed 2013. I am on a mac as well.

    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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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.

  18. 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.

  19. 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.

  20. The AXIS Z setting of Roof Faces was always confusing. Never could you set the proper Z height at the initial creation. Always had to make the roof and then set it in place from the elevation or create some other workaround. Changes in thickness or fascia height on a double miter always meant tweaks to the height. Change in pitch also resulted in a fascia height change unless you had a zero overhang. The Bearing Height, Bearing Inset, and Eave Height settings in the Roof Object make the results predictable and easily edited...from a vertical height standpoint anyway.

    Early on the extend wall to roof command didn't work with Roof Faces but only Roof Objects. Perhaps that one has been overcome. It was one of the deciding factors, along with the items previously mentioned, that led me to use Roof Objects exclusively.

    I will admit that getting the right shape can be a chore and the limited ability to just extend a surface in any direction is also limiting but once I caught on to breaking down the roof into assembled Roof Objects with cut out perimeters and openings I found their advantages far outweighed continuing with Roof Faces. I haven't modeled a roof with the face tool in a couple years.

    I don't think Roof Face technology changed between the miniCAD days in the mid to late 90's until they added the ability to join them together a few years ago. And I think that was the only improvement that has been done in all that time. I was surprised. I thought NNA had abandoned development of Roof Faces in favor of the Roof Object years earlier. Whichever tool you choose to use I think we can all agree there is a lot of work yet to be done. Mainly, consolidating the best of both tools into one tool and adding Roof Components. Similar to Stairs...providing two separate tools to achieve the same task but each with independent abilities and pitfalls is not good practice.

  21. I was where you were at one point. The Roof Object was introduced I think in VW 9. It took until VW 12.5 until I adopted it. (for the record I updated from 12.5 all the way to VW2011.)

    The trick is to not try to construct your entire roof out of a single Roof Object but out of a collection of Roof Objects with holes cut where needed...as in the shed dormer roof example above. Cross gables can be made with a single Roof Object reshaped with an extended ridge line to meet the main Roof Object.

    With polygons of any shape able to be used to cut any Roof Object down to your desired shape I have found in recent years that I can make a roof design of any complexity.

    I have to ask, how do you texture the vertical surfaces of your Roof Faces? Its often not an issue for us because we'll wrap trim or a crown around the roof line but for simple flat fascias they are usually exposed. To clarify..I'm not talking about the built in fascia creating option. We never use those either.

    One other limitation is that Roof Faces do not interact with symbols for the insertion of skylights or the dormer maker as the Roof Object does. We seldom have need for these but its nice when you need them.

  22. Roof Faces and Roof Objects are not the same. I seem to have ranted on this in the past. My main issue with Roof Faces is how texture is applied. The top texture merely wraps to the sides of the Roof Face object. This is not the case with Roof Objects were the sides are controlled independently from the top. This makes texturing a lot easier...or in some cases possible when otherwise it would not be.

    I hope someday there is an easier way but for now to make the same thing with a Roof object you have to draw the rectangle and use the Create Roof Object to create a hipped roof with the overhangs on all sides. Then you have to change the side and top edges to Rakes and adjust the overhangs independently. Overhang would be zero for the top. Set the slope from the leading edge.

    Roof Faces have the ability to join to one another but since we are forced to choose, I've chosen to forgo that feature and build all my roof components with objects and not faces for consistency in modeling and texturing. It would be great if Roof Faces became single plane Roof Objects with all the advantages of both. I suspect that is coming someday along with a major Roof Tool overhaul that adds Roof Components. Lets hope they get it right the first time when it happens.

    One note, unless modified by SP4, Roof Face textures assigned by class are controlled by the 'other' tab while Roof Object textures are controlled by the 'roof' tab. Another reason for my desire for consistency.

  23. Your default Dimension style includes a preset for Text Style.

    If you create a Text Style specific for your dimension string and set your Dimension style to that Text Style you should get the desired text in your dimensions regardless of the active text settings.

    As a side note, Text Styles for general notes is something I have not adopted because as soon as you change the justification to something other then what is defined in your Text Style you end up with an unstyled text instance. Text Styles need to be improved so you can choose which text attributes you want them to control and which you want to ignore. Until that happens this application for default dimension strings may be the only use I have for them.

    Joe

×
×
  • Create New...