ericjhberg

As a landscape architect we consistently find ourselves floating between the worlds of architecture and civil engineering...it's one of the benefits of the profession, and sometimes even a headache. With that in mind, we constantly have the need to convey units in both Feet & Inches (architectural) for details and sit dimensions and Decimal Feet (engineering) for anything having to do with survey or elevations. Unfortunately VW doesn't make this very easy. Currently the only real tool we use that allows us to specify the type of units to use is the Stake Tool, which works perfectly. With this tool, it is possible to leave the Document Units in Feet & Inches while showing elevations in Decimal Feet (or visa versa if ever needed). Dimensions should be similar...so should Grade Objects, Site Model Labels, etc...really anything that returns a dimension, the user should have the option of setting the units to be displayed and to be able to do so en masse when needed to change. Take Site Models for example. Currently the contour labels on a Site Model (which have more problems than just units...see other posts regarding this issue) will display only the units that match the Document Settings. Even if you change the document settings to Feet and Inches, the contour labels will show with the number of decimal places specified in the Document Units, so a 50' contour on a site model will ready either 50'-0" or 50.00 and neither one of these is desired, appropriate or standard. The only way to achieve some of the desired results is to constantly switch the Document Units back and forth, which I'm not entirely sure is a good idea for rounding and tolerance reasons?

When doing a large irrigation system (I'm working on several with over 70 stations), the connection time is incredibly cumbersome and slow. The file I am currently working on takes up to 15 seconds to make one connection. Additionally, we have already turned off the Auto Calculation Update feature, so that is just processing time. Some simple math to show you how cumbersome this actually is... 830 outlets of just one type (over 2000 total in the project) = 830 connections 830 connections at 15 seconds each = 12,450 seconds = 207.5 minutes = approximately 3.5 hours of drafting to make the connections. When compared to our traditional methods, we could do this drafting in approximately 1 hour or less. So for 2.5 extra hours, what do I get? Some data attached to the pipe network? That would be great, except half the time there is at least 1 error for every 20 outlets, which has to be found, diagnosed, and corrected, adding at least another hour to the mix. I get that we are supposed to be moving into the "smarter, not harder" category, but this is only coming at it from the "smarter" perspective while making it a whole lot harder to meet your targets. Expand your horizons Landmark and start thinking bigger than a single, lot residential project. We need BIG applications here that scale easily!

The Grade Object tool in Landmark has long been a frustration of mine. It is a very powerful tool, but when used in actual applications it is SUPER SLOW and cumbersome. I hope the grading tools and workflows get a hard look for both functionality and usability because many are just clunky and not applicable in a professional setting.

It would be incredible if Hardscapes and Landscape Areas could be managed by Styles, similar to walls, roofs, slabs, titleblocks, etc. With this functionality, these would be saved as resources similar to Wall Styles, Roof Styles, Slab Styles, etc. and then could be edited in one location to make changes throughout the document. Currently the functionality of Save Hardscape... or Save Landscape Area... does create a resource manager resource, but that has no effect/connection to the instances located in the drawing. Furthermore, it really can't even be edited in the resource manager. Right now, the only way to enact large changes to multiple similar hardscapes is to make the changes to one and then use the match properties to apply it to all others. There are several reasons why this isn't ideal, Very Slow - Matching properties to hundreds of hardscapes or landscape areas can take forever to complete Inaccurate - The match properties workflow is a manual selection workflow and is only as precise as the users selection abilities/criteria It's time to rethink the way the Landmark tools fit within the greater movements of VW tools, I feel like they are out in their own little world and really should be brought into the fold.

Thanks Kevin...unfortunately our work arounds had already rendered this fix difficult to gauge, but I will try to keep it in my head for the next time...which hopefully never comes. I have to say that I was perplexed by this one...haven't ever seen it before.

We have had a nightmare scenario where in a push toward a deadline we noticed that ALL of the fonts and their formatting changed throughout several documents and their associated references. I have never seen anything like this before in our workflow and we have been using for a long time. Thoughts?

With the new irrigation tools we are still trying to figure out a workflow that streamlines connections on a large job. Unfortunately it is much harder to layout a clean diagrammatic irrigation plan using the new tools since after pipes are created, offsetting lines is no longer an option. Additionally, the process to connect several emitters to lines can is very cumbersome when using the pipe tool and we often experience issues where items become "disconnected" from the network despite the fact that they appear to be connected...blue drop down arrow is present and asks Detach from Pipe Network, despite the fact that the emitter isn't connected to begin with. Perhaps there is a way to create an Auto-Connect command that could be run on selected emitters. This command could automatically draw in connecting lateral pipes to a chosen branch lateral already drawn? Or correct connection error problems by joining to the nearest drafted pipe? Anything to save the headache of troubleshooting connections when your calcs tell you that 5 emitters out of 1000 are not connected properly.

YES, YES, YES THUMBS UP X1000. Better document coordination!

Agreed. I think the visual usability within the irrigation tools could be improved upon. Another idea of similar nature...Auto-color toggle that automatically assigns different colors to different stations' components (i.e. pipe, emitters, dripline, valves, etc.)

Technically it already does. That said, it is almost impossible to discover and/or edit once you have made it part of a hardscape object. To get at the current functionality for this capability, you have to right-click on a hardscape object and choose Edit Slab Note that what you see next will be a Roof Face object, you can edit the Roof Face Style to include the component section you are looking for (i.e. subgrade, sub-base, setting course, paving, etc.) I was told that in order to make hardscape objects pitch, the software developers hijacked the Roof Face object. This allows the functionality of creating sloped hardscape objects. Instead of creating a new Hardscape Style object however, they just left it as a Roof Face Style which is very confusing. You can then edit the Roof Style used in that hardscape object and it will change universally You can match properties and the Roof Style/Slab will also match You can Save Hardscape and then apply that to other hardscapes to match properties including the Roof Style You CANNOT control the Roof Style through the Hardscape Settings Dialog Box...they must be controlled through the Right-Click option. Exit Slab Edit and you will see that your hardscape object object reflecting the entire section To me, the sole fact that Hardscape Component sections end up as Roof Styles is reason enough to not trust this functionality. I get the reason why this feature was used, but you are asking a lot of designers to intuitively know that in order to edit a hardscape's component sections, you should edit the corresponding Roof Style...that is deeply embedded in the object properties...is asking too much. Bring this functionality forward and make it more a part of the Hardscape Settings, make the component structure part of a Hardscape Style, and now we're off to the races.

Or perhaps better yet...make the hardscape object actually work more like the slab object? Currently the slab portion of the hardscape (ability to map a slab style and components) is present in the hardscape tool, but it is buried so deep and lacks the ability to be controlled in one location that it is virtually useless.

You are correct. VW does not offer the ability to do a photometric calculation like you are looking for, though it has been a long requested feature update. I'm hoping they'll get there soon. In the meantime, depending on your crunch and ability to learn a new software, DIALux is a free software that offers this capability. It is a little cumbersome to learn at first, but not too difficult and does offer the abilities you are looking for. https://www.dial.de/en/dialux-desktop/download/ Hope this helps.

So...thanks for chiming in. Generally I try to use the bug submit, but in this case I was having difficulty replicating the issue in an easily uploadable file. And since this has to do with references across several files, it was even more cumbersome and time consuming to try and submit the bug. That said...I called Tech Support which was very helpful. They actually solved the problem...not a bug after all. It turns out that this issue is caused by Viewport Crops of Viewport References. If a referenced viewport has a crop and is then rotated, the rotation will likely move the linework outside of the corresponding crop object and no longer be visible...at least that is what I was told. That said, what is strange is that only some of the linework dissappears...generally the complex types. Regardless, the lesson learned here is don't crop viewport references, especially if you intend to rotate them in a sheet layer viewport somewhere. Thanks again for chiming in, and my apologies for the demands. I do generally feel that submitting bugs should be an easier process since users don't always have the extra time it takes to go through the vetting process. As it turns out, this may not have been an appropriate problem for a bug submission anyway, so walking that line is a little tricky too.

After installing SP4, this is STILL A BUG! This needs to be fixed ASAP because important information has just started disappearing on many of our projects! FIX THIS ASAP!

When trying to represent an image (Planting Schedule) using the =IMAGE function, it seems that the cell formatting options of Layer Scale and Custom Scale seem to not be working properly. When selected, regardless of the scale chosen, the images miniaturize and become almost invisible. Additionally, the Auto Size setting acts differently depending on what option was previously selected...sometimes scaling symbols proportionally, sometimes not...but never responding to the relative plant definition settings for different plant objects. I don't remember this being an issue in previous versions or if this is just another NEW to 2018 bug, but I am pretty certain we haven't had this problem before. Finally, IMO the whole =IMAGE function within worksheets needs to be completely rethought to yield much better results. I have made several postings to this effect on the forum before and I'm not going to re-link them here...but this should be a prioritize FIX of an existing feature.

It is too bad that the floor has been moved past. There are very few simple hybrid objects that function as beautifully as floors for quick 3d mock ups of concepts. Obviously slabs are a better final product, but floors have been tremendously helpful to our team for quick planar work, especially when assigned to a Key Command.

I haven't tried Twinmotion yet, but it is on my radar too. From what I can tell they are very similar. The biggest differences I am considering Twinmotion over Lumion for are: Twinmotion is available on MacOS Twinmotion supports BIM Motion and VR path rendering while Lumion only supports point based 3d panoramas/VR. There are several YouTube comparison up now to view as well...

We have been using Lumion now for a couple of years to great effect. With every new release and update Lumion adds interoperability with SketchUp, Revit, and most recently ArchiCAD. I keep waiting for Vectorworks to be next, but not yet unfortunately. I'll keep hounding and asking for it though. Just a quick overview of what is possible with Lumion and VWX integration...

Any improvements to the road tools that actually support real world road grading applications would be tremendously useful!

It would be awesome if you had the ability to right-click on a worksheet, placed anywhere in a drawing and have the option to create a duplicate instance of that worksheet in the resource manager/replace the selected worksheet with said duplicate. This is a workflow that would be extremely helpful when creating duplicate sheets with different worksheet variations, each designed to total different quantities/data present on that sheet alone. Instead, when duplicated such a sheet/worksheet, the original worksheet and criteria are still present and require a cumbersome resource manager duplication and replacement workflow.

Thanks @rDesign for the credit on the original post! Obviously I strongly agree with this request. The need is clear when we have files and data sets that are exponentially increasing with each project.

I hesitate to support any option that requires additional input first, i.e. dragging a line to orient the hatch. This is essentially the way the software works now with the Attribute Mapping tool. Instead, I imagine a checkbox functionality that would do its best to determine an auto-orientation based on either longest edge or some other factor. From there, if tweaking is still needed, the attribute mapping tool could be further used to manually set orientations.

It would be great if there were a way to quickly align hatches to objects. As landscape architects, we are constantly using hatches to represent paving patterns where directionality is key. It is very cumbersome to manually control the alignment of hatches using the Attribute Mapping Tool. Instead, it would be amazing if there were a way to align hatches to the longest edge or some other auto-align feature, similar to the auto-align features present with mapping rendering textures. Often they are one and the same, so it would be even better if aligning one (either texture or hatch) would align the other.

Thanks @JMR for confirming. I would like to submit an official bug request on this, but haven't yet had the time to put together the materials. My larger question on this is HOW? We never encountered this issue prior to v2018, but now it is rampant. How to bugs like this appear on features that were working smoothly before?

The reason for this is WORLD based hatches. These hatches are intended to scale as the layer/viewport scale changes, which is actually what you want for accurate paver hatches. Are you overlaying an object with the hatch over the top of the worksheet? If so, then place the worksheet and objects within the Viewport Annotations. The worksheet will not scale since it is a page based object, while the hatch objects will display the hatch at the same scale as the drawing.