Jump to content

ericjhberg

Member
  • Content Count

    543
  • Joined

  • Last visited

Community Reputation

377 Spectacular

7 Followers

About ericjhberg

  • Rank
    500 Club

Personal Information

  • Occupation
    Landscape Architect
  • Homepage
    http://www.pc-ld.com/
  • Location
    United States

Recent Profile Visitors

2,397 profile views
  1. 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!
  2. That's too bad. Thanks for the info @Antonio Landsberger
  3. 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.
  4. This post was from over 2 years ago with no answer, and I'm still curious. Any ideas?
  5. 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
  6. Thanks @Pat Stanford! pSet_StairCommon does store data regarding the Stair object, but width is unfortunately not one of them and I am really looking for a global location to universally change stair widths at one time. The pSet doesn't appear to have that capability, unless I am missing something.
  7. Ugh...that was what I was afraid of @Pat Stanford. Any other ways you can think of to report/control this information? Marionette? Custom Script?
  8. Is it possible to pull in/edit stair General Geometry (i.e. Tread Depth(G), Riser Height(R), Num of Risers, Stair Width, Walk Line Length) into a worksheet? If not, why? I noticed that Total Rise can be queried and edited, but not other geometries. I have a project where I need to edit 50 stair objects to ALL be the same, albeit different than originally drafted, dimension. It would be so awesome if this was available in a worksheet, with the ability to change them all from 4'-3" to 4'-0". Otherwise, the only way to change these all is to go through them individually and change the width because they all have different total rises, and riser heights.
  9. @TDimov...I would like to piggy back on this thread and ask if it is possible to build a Data Tag that pulls in some of the OIP data from Wall objects, like Height and Top Offset? I cannot seem to find the data point to add to my data tag and it doesn't appear possible using your step-by-step above.
  10. Nope. All levels are at 0. I find it strange that symbols work find with the send to surface, but Plants do not? I have had a troubling history with the send to surface command. Sometimes it won't work for one object, but will for another right next to it. Usually, I have found that the more complex the site model, the more "holes" present where send to surface or even Stake objects won't accurately read the surface. This is not one of those models. Everything else works fine.
  11. Plants are on a different layer, out of necessity. No site modifiers, simple site model built from 3D geometry. Symbols sent to surface register correct Z-values. Plant objects do not and in 3D, their 3D representations all appear at Z=0 no matter if they are sent to surface or not. Luckily, we are not rendering in VW anymore, and using Lumion instead. I was just trying to get proxy nodes in place for a quick Lumion replacement with the correct Z values. That said, I did learn that I can just send them as proxies in Lumion at Z=0, raise them all en-masse above the Lumion version of the Site Model, and then conform them to the surface. Works like a charm with no bugs...unlike VW. Thanks @Jonathan Pickup for your assistance.
  12. It would be awesome if Vectorworks was able to easily export and coordinate proxy nodes for easy/quick replacement in Lumion. This functionality appears extremely simple with the other programs supported by Lumion, but I will tell you it is almost impossible in Vectorworks. With this functionality, we could save countless hours placing objects between the two softwares. Perhaps there is a workflow I am missing though, so I am happy to hear others experiences and hopefully success stories.
  13. I'm having difficulty sending plant objects to the Site Model elevation using the Send to Surface command. Meanwhile, simple symbols send to surface in replacement of the Plant Objects without problems. I'm in VW2020 and it's been awhile since I've tried this command with plant objects...long enough to question if Plant Objects lost this functionality in VW2020 going forward? Thanks.

 

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