Jump to content

ericjhberg

Member
  • Posts

    581
  • Joined

  • Last visited

Posts posted by ericjhberg

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

    • Like 4
  2. 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.

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

    • Like 1
  4. 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

    • Like 4
  5. 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.

    Screenshot_1.jpg

    • Like 2
  6. @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.

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

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

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

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

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

  12. 1 hour ago, Tony Kostreski said:

    but in the meantime, I would suggest placing the north arrow directly in the annotations part of a viewport making sure to check "Use Heliodon".

     

    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.

×
×
  • Create New...