Jump to content

Joe-SA

Member
  • Content Count

    218
  • Joined

  • Last visited

Posts posted by Joe-SA


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


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


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


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


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


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


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


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


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


  10. Customization within the door leaf is possible. Choose custom from the Leaf tab of the Door Settings menu. Make your own custom leaf symbol and reference it here.

    We use this to create custom carriage overhead garage doors. The 3d leaf symbol will reshape to the opening size so small changes in width or height does not require a new symbol unless you are specific about your proportions.

    Also used this feature to make dutch doors. Your mailbox door would be a good application.

    Joe


  11. Not an answer to your question but some perspective.

    I've been working in VW since 1996. Stories are a feature that was added just last year. Often it takes quite a few updates of VW for new features to get 'up to snuff' you might say. I looked at Stories in the last upgrade and frankly I saw more hassles then they were worth. Granted my look wasn't an exhaustive study. I currently do fully 2d/3d hybrid plan/modeling without using Stories at all. I simply manage my 3d Z-heights with my layer elevations and wall heights.

    Others who have flushed out the use of Stories will likely give you pointers on their use and likely work arounds for the short comings I'm assuming the feature has. In my current understanding I view them as Layer Groupings if that helps.

    I just wanted to let you know you can use VW very effectively without using them at all.

    Joe


  12. Just tried Pat's script. It wouldn't run from a menu command PIO but run as expected from a Vectorscript in the Resource Browser.

    Read Pat's disclaimers. After running the script the OIP was grayed out when highlighting a title block but ran the Issue Manager once and input set 'A' and the file was reset to just the A set and the second run defaulted to 'B'.

    Very cool.

    Thanks Pat.

    Joe


  13. Just went to the Resource sharing - Vectorscript section of the forum and set it to display ALL DATES.

    Lo and behold...Pat Stanford posted a script that does what you are asking back in 2009.

    Haven't tried it but it may be just what you need.

    Joe


  14. Rick,

    My script was written for the purpose of changing existing data sets. Not purging the file of the data sets so when you enter the Issue Manager it thinks its the first time.

    The Issue Data Record Format doesn't show in the OIP until you run the Issue Manager. The weird part, however, is if you select a titleblock and run the Edit Issue Data and then click OK without making any changes...the Issue Date Record is no longer visible in the OIP. But it then comes back with the same info the next time you run the Issue Manager.

    I'd have to do a lot more research in order to re-write the script for your purpose. Not sure I know enough to do it considering the odd behavior which I would suspect is designed and not a bug to limit tampering.

    One work around might be to edit individual sheets until you have only one instance of each letter. Then use my script to input spaces into each letter in order to achieve a clean text free title block. Then with each new issue date use my script to assign new info to each of your existing data sets.

    Not what you are looking for, I know, but the best I got right now.

    Joe


  15. I would suggest giving up on the Stair Tool and moving to the Custom Stair tool. This is another case where the new and improved tool doesn't yet do everything the old reliable tool does even though the new tool has been out a few versions already.

    For us the Stair Tool from introduction has been a non-starter despite all the features for treads, railings, etc. it contains.

    When first introduced it couldn't do both an upper plan and lower plan display like the Custom Stair tool. You had to 2d draft your upper stair plan. Without that it was worthless to us. It also didn't have the ability to link its height to layer heights. I think it may have added these features in later updates but then didn't have an offset for either the lower or the upper heights like the Custom Stair Tool. I think it was another version before that was added. Still in this version you can't do an angled platform with this tool.

    The Custom Stair tool isn't perfect but I get far closer to what I need for construction document production by modeling the stairs I need for plans and sections. If I ever needed a detailed stair for an interior 3d view I might consider the Stair tool but it would be only for the 3d view. Not for construction drawings.

    A simple improvement that would give me a lot of what I need in the Custom Stair tool is the ability to connect two straight runs of stairs and not only set them to independent widths (which we can do) but to offset their center line from each other. This would allow me to transition from an open tread to a narrower closed flight when one or the other railing dies into a wall. For this I either have to create a tread out of a platform or literally stack two Custom Stair PIO's with upper and lower height offsets as needed.

    What we really need is ALL of the abilities of the old tool reflected in the new tool BEFORE the new tool gets introduced. One step forward and one step back is not progress.

    Joe


  16. I'm sorry, but I think this movie is a ridiculous solution. No offense to Alicia who I have emailed many times and found very helpful. Not sure of the date on the movie but I approached an alternate technique with her directly last year.

    A better solution that doesn't involve ungrouping the PIO into its individual parts is to simply turn off the countertop that is created by the base cabinet. Then place the separate CounterTop PIO over top of the base cabinet. The CounterTop PIO includes controls for creating a hole for a sink either square or oval. Place your sink in the hole. There you have your solution while maintaining full control of your PIO for future edits of door panel, hardware, texture, etc. This solution has been around for long, long time.

    The issues I had last year with this solution was that the back splash display in 2d was different between the countertop PIO and the countertop made by the adjacent Base Cabinet PIOs. They were controlled differently and displayed differently from each other. 2d and 3d back splash creation and view were linked in one and not the other. 2D Patch lines were needed in plan just to get a common look.

    The other issues was the obvious question....if we can make sink holes as part of the CounterTop PIO then why isn't the hole function included as part of the sink front base cabinet? The code already exists. Can't they be combined? I don't think these cabinet PIOs have been modified in many, many updates. They've been the same for about the past 10 years or so.

    Haven't looked into this in some time. Seems like an easy fix. Hopefully one of the Service Packs improved it.

    Joe


  17. The SP4 update loads new default content files for the Walls-Slabs file, the Architectural Schedules file, and all the template files. Tech support is unable or unwilling to give me any information on why these files were over written.

    My concern is that I want my custom content to perform well and reflect any bug fixes that may have taken place to the content of these files. In comparing the content of the SP3 file and the SP4 file there is no readily apparent difference to the walls-slab file.

    Does anybody know what I'll be missing out on if I just continue to use my SP3 default content files?

    Joe


  18. One caution here. Use of the Sweep command will cause facets of the curve to show up in your hidden line views. Extrude Along Path automatically turns your 2d polygon path to a NURBs curve which results in a clean hidden line view of the curved elements.

    You won't see this difference with renderworks textures.

    I run into this when I create detail profiles in the cap and base of my exterior columns. I start with the Column PIO, make it into a symbol, and then wrap the block base and head with the rest of the detail profile made from EAP's.

    I would suggest you use a symbol with a 2d elements on the 2D side of the symbol and then a 3d side made up of separate square and round EAP objects.

    Joe


  19. Last year I wrote a script to get me past a similar issue I was having with the Issue Manager. Inevitably, shortly after sending date and description to 20 title blocks of a project the issue date would change or a typo would be noticed. The only way to fix each of these sheets was to edit each sheet individually. The Issue Manager is not capable in its current state of manipulating a set of sheets a second time even though it assigns common letter or number value to each sheet set.

    My script allows you to input the designation of one of these sets and then input revised date and description data...(or just spaces) It then searches all your title blocks for dates and descriptions that fall under that set designation and updates them accordingly.

    You could use this to modify each of your existing entries instead of deleting the previous ones and adding new. The script could likely be modified to do what you are asking all in one click.

    I posted this to the Vectorscript section of this board but I'm not sure if it is there anymore. This seemed like such a easily corrected deficiency that I half expected this feature to be added in an upcoming service pack. In a much more elegant fashion then I can do, I'm sure.

    Here is my script. I created a menu command plug-in out of it and keep it right next to the Issue Manager.

    Joe

    (Start of script)

    Procedure ReviseTitleBlockIssueData;

    {

    This procedure searches all instances of the 'Issue Data' record created by the Issue Manager

    and takes a user input previously issued set letter and revises the associated date and note to a user input values.

    }

    Var

    Request1, Request2, Request3, Default1, Default2, Default3, IssueLetter, RevDate, RevNote, FName, DName, NName, FValue, FinalCheck : String;

    Record : Handle;

    NoOfFields, X : LongInt;

    Answer : Boolean;

    PROCEDURE ReviseData(ObjHdl : HANDLE);

    BEGIN

    X:=1;

    REPEAT

    FName:= Concat('Number-', X);

    DName:= Concat('Date-', X);

    Nname:= Concat('Note-', X);

    FValue:= GetRField(ObjHdl, 'Issue Data', FName);

    IF (FValue = IssueLetter) THEN BEGIN

    SetRField(ObjHdl, 'Issue Data', DName, RevDate);

    SetRField(ObjHdl, 'Issue Data', NName, RevNote);

    END;

    X:=X+1;

    UNTIL(X>50);

    ResetObject(ObjHdl);

    END;

    BEGIN

    BEGIN

    Request1:=('What is the letter of the Issue Set you wish to revise?');

    Default1:='A';

    IssueLetter:= StrDialog(Request1, Default1);

    END;

    BEGIN

    Request2:=('What is the revised date you wish this issue set to display?');

    Default2:='mm/dd/yy';

    RevDate:= StrDialog(Request2, Default2);

    END;

    BEGIN

    Request3:=('What is the revised note you wish this issue set to display?');

    Default3:='Issue Note';

    RevNote:= StrDialog(Request3, Default3);

    END;

    BEGIN

    FinalCheck:= Concat('Are you sure you want to change issue set ', IssueLetter, ' to the new date ', RevDate, ' and the new note - ', RevNote, ' ?');

    Answer := YNDialog(FinalCheck);

    IF Answer THEN BEGIN

    ForEachObject(ReviseData, (R IN ['Issue Data']));

    END;

    END;

    END;

    RUN ( ReviseTitleBlockIssueData );

    (End of Script)


  20. I'm not surprised. It took me a while to work out the bugs of the system.

    You have a few different ways to define the lines of a wall. One is the exterior lines of the wall itself (the container) and the other is in the definitions of the components themselves. The component lines will overlap the 'container' lines on the wall edge. The 'container' lines are controlled in the 'Edit Wall Attributes' tab while the 'component' lines are controlled when editing each component.

    Your components should end up in a component class while your wall should end up in a 'container' class. I HAVE been able to use line and fill settings of the container class to manipulate lines as I described. I have not been able to do the same with component classes.

    Under Edit Attributes inside the Wall Type definition, be sure to assign attributes by class and also be sure to assign a default class under the Insertion Options tab. Under the component, be sure the component that is adjacent to the wall edge has a zero line overlapping the wall edge.

    Now things should work as I described. From the Class tab of the organization dialog box you should be able to manipulate the line attributes of the wall objects.

    This method falls apart when dealing with multi-component walls because you are only able to manipulate the perimeter edges of the walls but for footings and foundations it seems to work once you have reset your wall type definitions.

    Joe

 

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