Jump to content

ericjhberg

Member
  • Posts

    562
  • Joined

  • Last visited

Everything posted by ericjhberg

  1. We use Vectorworks heavily for graphic layouts as a way of reducing our software license costs (Adobe InDesign, Illustrator). It works great for the most part, but a few, seemingly simple additions could make it even better. 1. In text blocks, Vectorworks is very clunky in dealing with paragraph styles, tabs, and automatic numbering/bulleting. I see even the forum board has the ability to auto-bullet. We often avoid using the general notes or keynote legend tool because of its clunkiness, and instead use simple text blocks; however when creating numbered lists or indented paragraphs, there aren't any ways to format without creating manual tabs that break up the paragraph. 2. For more complex graphic packages, or even sheet specifications, the ability to link text boxes (similar to Adobe InDesign) so that text can spill over from one text box into another continuously as one text string. This frees up the formatting of text into one continuous process, rather than editing one box, then the next, and the next...repeatedly as notes or other text change. InDesign also has the ability to reference in text from Word or other word processing applications; therefore utilizing word processors more complex spell-check and grammar check functions. 3. Text block columns. Similar to above, the ability to split a text box into multiple columns, with continuous text spanning.
  2. I notice that in V2016 there is now the ability to create Detail-Callout Markers that link to detail viewports, so that if that viewport moves to a different Sheet Layer or its callout number changes, the marker responds accordingly. Great! I can also see a tremendous need to provide a text string (hyperlink?) that does something similar, linking to a viewport or sheet layer. This way, when a sheet is added or removed from a set, matchline callouts, notes references or other embeded sheet references could respond automatically. It would allow the most flexibility as a text string hyperlink (similar to a standard interactive PDF link). Bonus: Prior to 2016 and Project Sharing, the only way we have been able to provide a multi-user environment for a project is by creating separate project files (i.e. hardscape, planting, irrigation, details, etc.) and referencing them together with viewport references. Since we are not completely sold on Project Sharing yet due to a couple of reasons ( see other wishlist thread ) we have not yet made this transition. A way to make similar cross-references across different project files (similar to publish script?) would free up our workflow options tremendously.
  3. We are facing a couple of issues with implementation of Project Sharing. As landscape architects, with previous versions we would create separate files for each different plan set (i.e. hardscape, demolition, irrigation, planting, etc.) and reference them together with referenced viewports. This allowed multi-user to work on the same project at the same time, but just on different aspects. With Project Sharing, I can see the benefit to having everything together in one project file and checking out design layers/sheet layers for other users to work on; however, the issues we are facing are as follows: 1. Because of our use of multiple design layers to separate information, the list of design layers in one combined project file will become too cumbersome, often hundreds long. It would be great if there were a way to create 'folders' for design layers or a hierarchical system similar to that used in classes. This would streamline the document organization into information sets (i.e. Hardscape-, Demolition-, Irrigation-, Planting-, etc.). We would still need to maintain proper inter-mixed stacking orders though. I could also see the same being very useful for sheet layers, essentially creating sheet layer folders for varying plan sets. 2. File size. Some of these files, when combined into one Project File will be enormous. Considering our varying workstation situation, I can forsee dramatic problems with file loading, crashes, and update times. This is a general issue Vectorworks needs to address in order to compete in the growing data-rich, 3d, BIM world. We have top of the line workstations that still struggle with the complexity of some of these large project files.
  4. Just a thought regarding the clip cube. I am fairly green to the clip cube so some of these suggestions may be possible, but I just haven't been able to figure it out yet. 1. Provide the ability to turn a clip cube into a 3D View, not just a section viewport. This could support the ability to create cool Section Perspectives that showcase a cut line while projecting the background in either an isometric or perspective view. When you try to create a 3d viewport from a clip cube view, the clip cube disappears and the entire model is present. 2. Solid modeling of the cut plane. When using the clip cube, it appears that its intersection with an object always shows the bounds of the objects as lines with the centers as voids. Rather, a way to use the class attribute fill or texture to close the shape and show a solid fill for the clipped objects. 3. A slightly more complex clip cube shape. This counters the idea of calling it a clip 'cube' but imagine a 2-plane cut-away 'L' clip cube line where details in 2 planes could be exposed and then communicated via comment #1.
  5. In addition, some other considerations for future hardscape tool and operability. 1. The ability to select multiple hardscape objects and still be able to edit the Hardscape Settings... 2. If including a border for the hardscape object, make the border color respond to By Class setting rather than a manual picked color that doesn't respond to a change in the class attributes for the border class. 3. Scoring lines for curved paths. The ability to provide scoring lines for pathway hardscape objects that are perpendicular to the centerline at a given interval.
  6. We were hoping that in V2016, Landmark would add components to the hardscape plug-in objects, similar to those of walls and now roofs in architect. It would be great, when placing a hardscape, to include in one object, the entire profile of a hardscape installation assignable by class. This would include, as part of the "slab" thickness, the base materials, any fabrics/geotextiles, drainage, etc. With the new site modifier features of hardscape objects in v2016, site models would respond to the total thickness of a hardscape installation and therefore provide more accurate excavation numbers as a result of base thicknesses. Schedules could then calculate quantities of base materials without having a derivative or hardscape areas. This could also then be used to create simple, self-correcting details for variable hardscape installations. I could image a similar engine backing other Landmark plug-in objects such as landscape walls, roads, etc.
  7. Jim, We are currently holding off on the switch from 2015 to 2016 precisely because of this issue. I have been testing it for our office and it crashes far too often to be viable for now. Is there a fix coming?
  8. Gentlemen, I am not familiar with this script. Is there a place I could access it? Download? We are just planning on using the __KeynoteNumber as a sort column and won't be editing it either. We have noticed that editing the 'Callout'.'Text' field that it does break the reference to the database, but for our use, we don't mind. Thanks again for all the help!
  9. Works yet again!! I have no idea how you know all of this or where to even begin looking, but it works perfectly. You are blowing our workflow wide open with this help. Thanks so much from all of us here!
  10. Thank you so much Michael! That is a huge time saver for us. Any ideas on how to query the Keynote number if you are placing the callout as a keynote? You may remember, we met in Philadelphia this year at the Vectorworks Conference. I am a landscape architect down in Ventura, CA. I hope to make it up to a user group meeting sometime. Anyway, thanks again!
  11. I've noticed the ability to query multiple fields of a callout into a the database header of a worksheet. One feature that seems to be absent though is a weigh to query the callout's text or, if placed as a keynote, the number/letter associated with it. This would be an extremely helpful tool in constructing quick, easy to edit schedules/legends.
  12. Thanks Alan. I have the different prefixes for sheet vs. project information correct I think (S_ vs P_). I also have the box checked under project information to carry that to all sheets; however the problem occurs between referenced titleblock symbols in other drawings for the same project. When I update project based information (i.e. client name, address, project name, date, etc.) in the mother file, and update the reference in the other files, the project based information does not change accordingly. Any ideas if there other check boxes?
  13. As a part of my workflow, I create several different files within a given project (i.e. planting, irrigation, hardscape, etc.). For the longest time I placed titleblocks as 2D symbols with linked text to custom records. I could reference these symbols in between project files and it would allow me to keep project specific information (i.e. project title, date, etc.) editing to one location, the mother file. I could customize each sheet with sheet specific information by modifying the records on each sheet. I only recently became aware of the Titleblock feature as part of the Sheet Border tool and its inherent properties. I particularly like the link between the Sheet Number and Sheet Title of the titlebar and the Navigation Sheet Number and Sheet Title. This feature alone can reduce redundant mistakes by multiples. However, after some trial and error, I am noticing that although I can still reference the titleblock symbols in between drawings, the sheet border tool no longer references changes to the titleblock symbol in the mother file without performing some sort of update on each sheet’s titleblock. Also, I noticed that project information, when changed in the mother file, does not update in the referenced files. My question, is there a best practice for referencing titleblock symbols as part of a Sheet Border that allows for changes in the titleblock and project information to only occur in one location, the mother file?
×
×
  • Create New...