Jump to content

ericjhberg

Member
  • Posts

    562
  • Joined

  • Last visited

Everything posted by ericjhberg

  1. @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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. @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
  8. 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.
  9. 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.
  10. @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.
  11. Just an FYI, depending on version, there is also a data visualization bug associated with Irrigation Objects that may, or may not, be solved yet. I have submitted the bug in Beta testing and still haven't determined if it's fixed. Essentially the bug is that once a data visualization is set up, say for pipe size or for output pressure, the data visualization appears correctly upon first setup, but as soon as the design changes, the visualization doesn't dynamically update or change with the changes in parameters. The only workaround I have found was to save the data visualization, remove it from the current drawing, and then re-apply it from the saved visualization library.
  12. There should be an option to Lock In Place for Site Model objects, similar to Referenced Viewports. I can't tell you how many times I'm panning around my site model and accidentally grab it and move it...sometimes without noticing. Of course, you can Lock a Site Model, but that doesn't allow you to perform updates to it either.
  13. Yes, This functionality should be extended across ALL of the Site Modeling tools/objects, including Site Models, Grade Objects, and Site Modifiers, in addition to the current capabilities of Stake Objects.
  14. This tool should also have the ability to essentially extrude custom curb profiles along, allowing for monolithic curb and gutter and other configurations. The tool should also be hybrid in nature, allowing for 2D visibility settings and 3D visibility settings.
  15. @jeff prince This is exactly what we're looking for, even if I did hijack the post...apologies. Thanks.
  16. @Pat Stanford I think this could work okay, but I'm not sure if it works as a long-term repository of the WUCOLS data. The WUCOLS data is static, per plant, for each region. It just makes more sense to me if this could be added to the Plant Database for long-term storage of that particular data. We could do the additional record strategy if we're storing the Plants, pre-created, in a Library file (which we do already), but it seems secondary to the Plant Database.
  17. @bob cleaver I would like a way to add/reassign/classify custom fields in the Plant Database for each of the 6 different WUCOLS regions. An example would be Quercus agrifolia WUCOLS Region 1 - North-Central Coastal = LOW WUCOLS Region 2 - Central Valley = LOW WUCOLS Region 3- South Coastal = LOW WUCOLS Region 4 - South Inland = LOW WUCOLS Region 5 - High and Intermediate Desert = INAPPROPRIATE WUCOLS Region 6 - Low Desert = MODERATE With this data entered in the plant database, theoretically you could then set up a worksheet to just query the correct WUCOLS Region field and all the plants in the project would then display their WUCOLS rating for that region. Our current workflow is similar to yours where we use COMMENT to adjust the WUCOLS given the current project's location. But if we then use that same plant in another project/region, we have to change the WUCOLS information to suit the project for each plant. The suggested workflow would simply be changing the field query to the correct region, all plants would update. For WUCOLS research, this type of database customization would also be extremely effective for searching for compliant plants in the database/VW as well, generating a "potential" list depending on WUCOLS and other criteria.
  18. Agreed. Additionally, in WUCOLS a plant can have up to 6 different WUCOLS classifications depending on the designated climate zone, so ideally I would like to be able to reproduce all 6 designations in 6 different fields and then just have a worksheet query the one specific to the given project. We currently work across 3-4 of the different climate zones within WUCOLS, but also want to store ready-to-use plants. Without this, we are constantly changing the WUCOLS information for every project depending on the climate zone.
  19. Please, please bring back the changing colors. We now operate across (3) versions of the software depending on the project...and with 2021 release, they are ALL black. It is TERRIBLE.
  20. @Tony Kostreski...There should be a way, within the plant database, to Add Custom Fields. Since this is controlled through FileMaker, it may be possible, but I have no clue how to do it. This would be extremely useful in mapping local customizable features (i.e. WUCOLS data) here in California or wherever.
  21. We ran across an error in the Irrigation Catalog for one specific, albeit very commonly used, irrigation component. Under Outlets, Sprays, Rainbird, R-VAN Series Nozzles, the R-VAN24-360 nozzle does not have the correct Performance data tied to it. Instead of the radius ranging from 19 ft - 24 ft based on varying pressure input (see Screenshot 2 attached), the Vectorworks catalog only displays a range from 16 ft - 18 ft (see Screenshot 1 attached). This is an important fix because this is a common standard manufacturer product within the shipped VW library and cannot be easily edited by users. By not allowing for the full radius, this is disincentivizing this particular, solid performing product. I am completely capable of creating an alternative custom outlet type to correct the issue, but this shouldn't be confused for a permanent fix to this error.
×
×
  • Create New...