Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by ericjhberg

  1. I have been talking with VW staff on this issue over JIRA, but essentially have traced it down to a bug. There is actually different functionality on this issue in Windows vs. MacOS. On Windows, starting in VW 2022, the Make All Attributes by Class option will add an endpoint style to ALL objects and the only way to remove it is by manually removing the endpoint style...defeating the Make All Attributes by Class benefit. On MacOS, this does not occur and the functionality of previous versions remains in tact where Make All Attributes by Class DOES NOT affect the endpoint style of objects, but endpoints can be added to objects manually. Obviously, the differentiating functionality across versions of the program means that this is an issue, and I only see two ways of resolving it. Match the current Mac behavior (which was the typical behavior pre-2022) and make it so that endpoint styles do NOT respond to Make All Attributes by Class settings. OR (preferable)...just add a None option to the Class settings for endpoint styles...allowing for users to specify certain classes that my want endpoint styles to be by class, while others more typically can be set to none. If you choose this route, behaviors on both platforms should match though.
  2. Pacific Coast Land Design, Inc. (PCLD) is seeking a motivated and skilled landscape design professional to join our award-winning firm. The studio, located in beautiful downtown Ventura, specializes in regional projects throughout Ventura County, Santa Barbara County, and Northern Los Angeles County. With an emphasis on public space, PCLD is proud to have contributed to the development of a broad range of community serving projects in our region. As we head into our 40th year, this is an exciting opportunity to join the creative and dynamic staff of our growing firm. PCLD offers opportunities to engage in every aspect of the practice. From design detailing and 3d rendering to project management, community engagement, grant writing, and even business development; we encourage everyone to take part, and be a part of our collective effort to provide our clients and the communities we serve with premier service. A well-positioned candidate will be a self-motivated and collaborative team player, with strong written and verbal communication skills and well-developed design and technical acumen. We are a fully intergrated Vectorworks office, leveraging the platform's BIM and 3D modeling capabilities for everything from concept development through construction documentation. For more information about the job posting and to apply, visit https://www.pc-ld.com/careers EDUCATION REQUIREMENTS A professional degree in landscape architecture or related field of study from an accredited university. Must be legally eligible to work in the U.S.A.
  3. Thanks @Pat Stanford. You're right, I just checked this out in SP3 and it appears to be "fixed"...meaning it at least reverted back to prior functionality where markers were not activated as a part of Make All Attributes By Class. While I think this functionality is fine and matches the way we have used the program forever...I didn't have an issue with the idea that maybe markers could/should be activated for certain specific classes through Make All Attributes By Class...only if that were the case, then None should also be an option in the Class Settings. Anyway, as long as it stays this way, I guess I'm still fine with it. Thanks again.
  4. I just wanted to repost this to see if any progress has been made on adding a None option to the line endpoint style inside the class options dialog. It would really solve the problem and allow us to continue our use of Make All Attributes By Class effectively.
  5. And I thought of a 4th functionality I would love to see in a grade object... 4. the ability to create a curved line grade object. Currently you can do this with a Site Modifier used as a sloping contour, but it won't link to anything...oh wait...and a 5th 5. Grade objects should be able to link with site modifiers as part of their network. This would create an amazing suite of interchangable site modeling tools.
  6. I do...the problem is this involves a new Dimension Style...and I need to apply it to hundreds of stock design details that are already mapped to Document Unit standards. I'm hoping to avoid that effort. Additionally, this shouldn't be the reason independent unit control in Site Modifers, Site Models, and Grade Objects can't/shouldn't be realized.
  7. Thanks @jeff prince for chiming in. I completely agree, but we since we eventually have all our details and human scale elements in the same file, we definitely need to be able to dimension things architecturally from the get go...and I don't like my ADA compliance details reading 2.8333 feet (34") or my horizontal width dimenions reading 5.00 (would prefer 5'-0"). If only we were collectively brave enough to go metric...life would be so much simpler.
  8. Since the ability to link grade objects became available, the Grade Tool has really become a workhorse for parameter based Site Model/DTM workflows. That said, it would be great if more functionality could be added to it/improved Make most of the Settings... available for editing directly from the OIP...particularly the General settings and ability to toggle between Elevation, Downward Grade %, Upward Grade %, Downward Ratio (rise/run), Upward Ration (rise/run), and Elevation Change. Right now, you have to enter the extra dialog box anytime you need to reset a parameter for a grade object (that is for Downward Grade %, Upward Grade %, Downward Ratio (rise/run), Upward Ration (rise/run), and Elevation Change) Provide the ability to LOCK certain parameters once set. For example, after I set an object to use the Downward Grade at 2%, I want the ability to lock that parameter. Usually these are parameters that are set to compliance minimums, maximums, or best practices, and I never want them to change. This functionality could become extra useful when connecting multiple Grade Objects, essentially allowing subtle changes at precise locations to ripple through a network and change throughout. Obviously, this could case "breaks" in the parameters when everything is locked and the end result is that a locked parameter at the other end of the network can no longer be kept, but this is not too dissimilar from the mins/max settings in the Stair Tool. My biggest gripe with the grade tool (and other tools in the Site Model suite) are that the units cannot be controlled independently of the Document Units in the same way that Stake Objects function. This is a no brainer. Landscape Architecture in the US, with some exceptions, revolves around architectural scales for horizontal layout and engineering scales for vertical (i.e. feet and inches for horizontal, decimal feet for vertical). The Stake Tool already does this perfectly, just please extend that functionality to Site Models, Site Modifiers, and the Grade Tool...we've been waiting forever and there are no shortage of Wishlist Requests for this. @Vlado @Eric Gilbey, PLA @Tony Kostreski @Bryan G.
  9. I posted something similar in troubleshooting...
  10. We are finally transitioning to VW2022 and noticed that the line endpoint style (i.e. arrow, dot, etc.) is always visible on objects that are set to Make All Attributes by Class. It appears that this is intentional since in previous versions, the ability to have endpoints visible under when setting objects to use the class settings wasn't possible and had to be controlled on individual elements. That said, it doesn't appear that there is anywhere to set a class style to have NONE as an option for the endpoint style? You can individually set objects to have no endpoint, but this defeats the purpose of the Make All Attributes By Class. It seems that VW solved one problem by creating another...and the solution is to add the ability to have a endpoint style be set to None in the class settings. Am I missing something?
  11. @Piotr Karczewski...completely agree! The irrigation tools were rolled out in 2017 and there have been 0 updates since. It's been largely forgotten and needs some serious attention if it hopes to remain a relevant and productive portion of the VW toolset.
  12. I love the functionality of Data Tags, they have completely changed our documentation workflow and data tracking, for the better. That said, I wish there were a few functionality upgrades. I'll post them in separate posts, so for this one...how data tags work on sheet layers in recognizing objects. It is clear that when adding a data tag in Viewport Annotations that it is designed to find the geometric center of the object, which may be fine for small or relatively "square" objects. Where this gets challenging is for objects that often span multiple viewports or asymmetric objects. For example, if you applied a Data Tag to the letter 'C', the Data Tag would be positioned in the void of the letter, not on the edges. The best practical example I have is a trail project where a long, linear trail is broken into several (10-20) different viewports with matchlines. To adequately identify the trail object (a single, closed polygon), the Data Tag tool will only find the object in the viewport that contains the geometric center point...not every viewport where the object is visible. To combat this, you have to break the object into a separate polygons per viewport. This is less than ideal becuase you have to break up geometry that should be simple, which enters opportunity for error in multiple ways. Even then, if multiple competing long, linear objects exist in one viewport, Data Tags defer to stacking order in the Design Layers to select which object to apply a tag to...making application of Data Tags almost impossible. You can use the Select Eligible Objects Mode to place all the Data Tags, but then positioning the leaders/arrows to accurately point to the correct object becomes an exhausting effort. Instead, Data Tags should be designed to recognize the edges and/or the fill of objects, not the geometric center point.
  13. I wish there was a way (maybe there is?) to format a calculation to return the area in common between two intersecting objects. I know that it is possible to calculate this area after performing an Intersect Surface command, but that workflow doesn't support iterative design very well. If the objects move, the area intersection changes, and you have to redo the entire workflow. This would be an amazing calculation for things like Tree Shade calculations, often required by permitting jurisdictions (and now integrated into the CalGreen Building Code). The calculation is essentially an intersection of the Graphic Tree diameter with areas of paving divided by the entire area of the paved surfaces. If the trees move around or you need to add/subtract, there is no way to easily re-perform this calculation without a bunch of duplication and destructive actions.
  14. I actually don’t know. Another consultant/contractor provided it for one of our projects and I didn’t get to ask.
  15. Maybe I missed the point, but the exhibit I shared is a way of visualizing the depths of cut/fill, not specific to contours. This is a functionality I wish VW could perform, but currently cannot. if you’re looking for a way to show both contours and cut/fill, then yes, duplicating the site model or using a site model snapshot is the only way.
  16. @jpccrodriguesUnfortunately no. I just posted this as an example of what we would love to produce if Vectorworks had the capability.
  17. I'm not sure that this is with contours, but rather as a gradient of more cut, to more fill. Something similar to the attached rough site plan where deeper reds = more cut and deeper blues = more fill. Ingore the green overlay.
  18. Ugh...this request has been made over and over again for not only the grade tool, but the site model and site modifiers as well. Unfortunately, no fix in sight. @Jess_J, the font size is changable by the general font size control under the Text dropdown.
  19. And yes, while this is a great place to store your visibility settings, we have learned that applying the settings will NOT inherently create any missing classes pre-defined in your settings that are not currently in the active file. Instead, those classes have to be created or imported from a template file either before or after applying the saved settings to the Site Model. I wish they automatically stored the classes and imported them with saved settings once the saved setting is applied. And also...to be clear, there are two settings to save within the Site Model object...there are the 'Site Model - Settings available from the main Site Model Settings dialog box and the Graphic Properties...Settings available from the Graphic Properties sub-dialog box. We don't manage saved settings through the first Site Model Settings because those settings apply similar Maximum, Minimum, Datum, Contour Interval, Contour Multiplier, etc. settings to all site models, despite the fact that those parameters change widely across different projects. Rather, we use the Graphic Properties sub-dialog box Saved Settings to control visibilities of site models based on specific class assignments/visibilities, but we have to remember to import specific classes from our template files before applying the saved settings to get the desired result. Another question/idea. Is there a location to store these saved settings in a Workgroup library for office wide sharing? I haven't found this location yet, and rely on manually saving the same settings on each machine in our office for universal collaboration, but a workgroup library location would be awesome. Lastly, regarding Contours, contour labeling as a whole needs to get much better. Contour labels should be allowed to be set independent of document units. That way I can set my contour labels to be in Feet with 0 decimal places, and read appropriately while staying in Feet and Inches for my document units, which is typical for the work we do. Without this, my contours ready 406'-0", which is just plain terrible. This functionality is already available with Stake Objects...just use it for Site Models (and Site Modifiers, Grade Objects, any other site modeling tool). Contour label positions automatically set by the site model are often in terrible locations with way too many instances. To make things worse, if you go through the process of updating the site model...even once...the manually set contour label locations revert to their original, terrible locations. Pointless. It is easier, but potentially error prone, to just manually place text contour labels on a finished site model than to use them from the plug-in. Fix this!
  20. That's too bad. Thanks for the info @Antonio Landsberger
  21. Honestly, whichever is easier to develop and use. That said, I feel like all of the Site Model visualizations are currently only accessible via the Site Model graphics, so that seems like the most logical.
  22. This post was from over 2 years ago with no answer, and I'm still curious. Any ideas?
  23. It would be awesome if you could generate a 2-dimensional visualization of a Site Model's cut/fill, but instead of just static Cut = Red and Fill = Blue...you could assign a gradient for each that could color the site model based on cut severity or fill severity. For example a White to Red gradient for cut that the greater the value of cut, the deeper the shade of red. Additionally a White to Blue for fill that the greater the value of fill, the deeper the shade of blue. This would be an extremely useful way to visualize site models. @Tony Kostreski @Eric Gilbey, PLA @Vlado @bgoff
  • Create New...