Jump to content

ericjhberg

Member
  • Content Count

    537
  • Joined

  • Last visited

Community Reputation

357 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,282 profile views
  1. 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.
  2. 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?
  3. 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.
  4. @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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Ugh...I hate to say it, but this is a huge problem with the =IMAGE function within VW worksheets. The function actually takes a raster image of the symbol that is most commonly a vector based symbol and the resulting image is incapable of capturing lineweight. For us it is Plant symbols (Trees) with thick outlines. The plant schedule, regardless of the DPI does a horrible job of translating those symbols into the legend legibly. We actually have resorted to a workaround of double-stacking two identical worksheets on top of each other. It kinda works to darken the images, but is a far cry from how it SHOULD work.
  10. @Tony Kostreski...I am seeing this in 2020 SP5. Haven't tried it in my testing of 2021 yet. Could be particular to a specific file? I don't even have a Heliodon in the file I am working in and when I go to rotate the North Arrow...nothing. Does it have to do with Georeferencing? Screen Recording 2020-11-23 - VW North Arrow.mov
  11. This doesn't work. No matter which settings are enabled, it is impossible to rotate the north arrow within the viewport annotations layer. The only way to make it work is to actually "Explode" (covert to group) the north arrow, or create a dumb 2d symbol, which is a REALLY, REALLY bad workflow considering the intent of the north arrow tool. We actually ONLY put north arrows within viewports in case we do have multiple viewports on the same sheet with different north arrow orientations (not often and try to avoid, but occasionally). We never put north arrows in the titleblock.
  12. I am also running into this problem. For some reason VW doesn't realize that it is standard practice to rotate viewports... They don't allow the north arrow to rotate with the viewport or be smart enough to understand that the viewport is rotated. I don't mind a smart north arrow that realizes georeferencing, but it should also be smart enough to understand the concepts of rotated viewports. This is DUMB! @Tony Kostreski....I'm tagging you on this one...figure it out.
  13. @bgoff I am fluctuating between 2020 and 2021. It may be fixed in the newest SPs, but I haven't tested it again. When I said changes to the design, I meant something like if the Input/Design pressure changed, and thus pipe's resized or the output pressure changes. The corresponding data visualization doesn't change to show any changes in pipe size or output pressure...I just stayed the same as when the data visualization was first applied.

 

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