ericjhberg

@rowbear97 & @mjm Thank's for asking. We're fine here in Ventura. The SoCal fires this year so far have been about 30 miles south of us and moved further south...not like last year's Thomas Fire, which swept right through Ventura. We've been lucky...so far! Regarding FLOORS...I completely disagree with your assessment @rowbear97. Floor are actually extremely useful in quick studies and 2D/3D integration. You are correct that we cannot use them as site modifiers; however, flat planed hardscapes with directional slopes are very uncommon in the grading world anyway. They are often complex with varied pitches which requires you to break up your hardscapes into little chunks for each pitch...oh yeah...and they can't technically touch either...not very practical if you ask me. I'd rather use actual site modifiers to do my grading than hardscapes with site modifiers. Take offs are always by area anyway, which can be done with floors, 2d linework, hardscape alike. With the addition of slab settings and profiles to hardscapes I am more compelled to give it a go, but the other functionalities are so lacking that we are caught in the middle. As for the data tags...we still will have to add a custom record field to hardscapes/floors/2d anyway to get the data tag to work as intended. Hardscape objects do not contain the necessary fields to adequately describe the object without adding an additional record to it, so what does it matter that it is a hardscape to begin with. Additionally, they have not figured out Hardscape Styles yet. You can save a slab style that is applied to a hardscape object and modify the slab style in one location, but you cannot save a Hardscape Style that when modified, makes universal changes throughout the design. Right now, the best you can do is use the match properties tool (eyedropper), which is often inaccurate, slow and can cause crashes. All of this is in combination to the 3 problems I expressed above. My experience with the hardscape tool is that it is just powerful enough to trick you into using it, but after you do, you quickly will find instances where it doesn't work or causes problems. It is not a completely thought out tool to handle all applications and unfortunately the Floor isn't either...it's just easier to use, manipulate, and go back and forth with. Until they completely rethink hardscapes and how they work, I'm not convinced.

That is what I was afraid of and I am bummed that they are phasing this tool out. As I have mentioned on here before regarding the Floor, very few objects in VW operate as simply, yet effectively as floors. They are the perfect HYBRID OBJECT for quick flat slab/hardscape modeling, mainly because they dramatically outperform hardscapes and slab objects. Just some of the benefits of floors over the others. Simple Hybrid Objects - Working in Plan and 3D separates them from extrudes and other solid geometries. 1:1 Object to Plug-in Relationship - After creating a Floor from an object it is very easy to go back to the original polyline/polygon. This is great for problem solving/simplifying bad drafting or complex linework because a simple ungroup command will yield the unmodified single original object. When doing this with floors or hardscapes, they will yield at least 3 different redundant objects, making cleanup a nightmare. Texture Orientation - The floor responds simply to the directional editing of textures in the OIP, allowing for multiple directional variations of one texture on several objects. Hardscapes STILL don't have this functionality and slabs are difficult as well. THIS IS A BIG REASON WHY FLOORS ARE JUST BETTER! Either keep floors around or improve the other objects.

Unfortunately the saved views route wont get you very far right now if you are trying to update viewports. There is now way of linking a viewport to a saved view's layer and class visibility settings, which is a bummer.

I was wondering if there is a Create Floor from Objects type of node in Marionette, or if not, could one be easily created? Not an expert here, but looking for a way to streamline the process of using this very simple geometry en masse. Thanks in advance for your help.

I was experiencing the same problem and found the solution/bug... If you have any CROP objects in your viewport references...delete them. It seems to work now, but definitely not desirable considering the complexity and necessity to crop viewport references on occasion.

I have been lobbying for a "Viewport Style" option that would allow us to control the visibilities of our classes/layers in ONE location that may be applied to several viewports. This way, when you add options, classes, layers, etc. you can update the STYLE and all of the viewports that use that style would update also. It's very similar to saved views currently, but would be applied to viewports and I think it would be the easiest and most effective way to control visibilities throughout large documents without having to match styles or visit each sheet individually during the process.

Looks amazing @twk. I'm hopefully going to dive in to Lumion 9 this week!

Thanks @LanceF. Great news. I had some great conversations at the Design Summit about this issue (and some other) and really do stand behind our methodology. Ultimately, as long as we have the functionality to visually isolate and work on separate irrigation stations individually, how we get there is trivial.

Thanks @CipesDesign. I agree with the concept/theory, except the Irrigation Suite is heavily reliant on Auto-Classing, which in actuality is a good thing. It helps keep all of the information separate (i.e. valves, pipe-mainline, pipe-lateral, emitters, drip zones, etc.). In order to do this, you would have to manually disable the auto-classing functionality. Additionally I would add that this shouldn't be the solution. Doing this would be like asking an architect to control the visibility of different floors in a building by class instead of by layer/story. In order to do so, they would have classes like (Wall-Exterior-Floor 1, Wall-Exterior-Floor 2, etc.). That is why we have design layers...to avoid this redundancy. With a heavy use irrigation example that has 50 stations, I would need 50 different classes for valves, lateral, emitters, drip zones, etc.). Then, to visually isolate a station, you would have to find a way to control the visibilities of at least 7 different classes x 50... LandFX (an AutoCAD plugin) has a coded way of isolating stations. Since AutoCAD doesn't have the second organizational level that VW has (layers vs layers), they have developed a tool that detects components downstream of a valve and can isolate those visually from the rest during design. Either something like this or some sort of in between is ideal. Prior to VW2019, I wasn't a huge fan of our separate design layer approach either because 65 design layers in a file was a cumbersome process to navigate, but with layer filtering in 2019 (thank you!) it isn't as bad and almost seems fun. Another bonus I have discovered with our methodology is that the extra design layers do help us with viewport visibilities on complex regulatory submittals. Sometimes half of the job gets submitted to one agency and the other half to a different agency, even though it is one irrigation system. Having different stations in different design layers allows me to easily turn off layers that don't apply to one or the other. I will echo over and over again at the risk of sounding like a broken record...rather than making it work for small applications...make it work for big applications that can be scaled down to meet smaller needs. Our experience has been that scaling up is way more cumbersome and time consuming than scaling down.

Hey @LanceF. I'm sorry we won't be able to catch up at the VW Summit this year, @Eric Gilbey, RLA ASLA mentioned you wouldn't be making the trip. Bummer. You'll be missed. So...apologies in advance for the tone here. It isn't great, but my frustration level right now is high. Not a personal thing. If this is true, the problem here is that the way it was designed only caters to a very specific workflow...and a workflow that is NOT explicitly obvious when using the tools and/or that Vectorworks doesn't back up with any How To or Best Practices guidelines. To this day, I have never seen a document, released by Vectorworks, that tells users how to use the irrigation tools...the way they were designed. When you say: Do you mean that the Mainline and all of the connected components in a system should be on the same design layer? All stations/valves/laterals/heads connected to the network on 1 Design Layer? If so...well this is another reason I get frustrated at VW and Landmark. This workflow is really only suitable for single-family residential practice where the irrigation systems are relatively simple. I would say in the 1-12 station range. We do work that often marries 6 to 10 different points of connection/mainlines, each occasionally with more than 50 stations. I have done systems that have as many as 65 stations on one controller/mainline. The idea of putting all of those stations on one design layer makes me nauseous...so many crossing lines with no way of visually isolating stations. I'm going cross-eyed just imagining it. On a much broader note, my struggle has been that if VW wants to be competitive in the landscape architecture arena, the tools have to graduate beyond the single family residential scale. It seams that so many of them work just fine on a small project, but instantly create headaches and slowdowns when applied to large projects. We are making it work, but it is often a struggle and honestly, not a week goes by anymore when I don't second guess the whole venture. We have a business to run and it's hard when you feel completely out control with the workflows you are forced to use....RANT over, apologies but I had to get that off my chest somewhere so that it doesn't run into my presentation at the summit. I have several sample files I am preparing to share. The problem is that they are all often in excess of 1GB each, making the transfer/storage problematic. The attached video is a small example of the workflow we employ, this is one I am putting together for my presentation Monday about the irrigation tools. Again, apologies for the tone here. Nothing personal, just some pent up frustration. Not an excuse, just an explanation. Thanks for the response. MAWA Areas Video.mp4

I haven't played with Twinmotion yet, but I want to. We have been using Lumion for almost a year now, to GREAT effect. It is an incredible piece of software, despite it's clunky and different interface. The features of Twinmotion, mentioned above, that are different in Lumion that appeal to me are: Regarding textures... This is actually not true. You can use and add dimension to textures imported from VW. We use COLLADA files to interchange which inherently preserves the textures from VW. We can then choose to overwrite them with Lumion textures if they are better, or add some qualities (i.e. bump, weathering, reflectivity, etc.) to the VW texture in Lumion. We have actually found that the only way to map directional textures with different directionality between different elements is by getting them right in VW and then importing to Lumion. For example wood grain, posts/columns have a vertical wood grain, while horizontal slats have horizontal wood grain. Using Lumion textures, you can only map one direction per texture, but in VW you can manipulate the direction of textures per object. Insert here, a chance to show off a little...

An additional note to this BUG is that we have found that we cannot really copy and paste-in-place irrigation networks either. Components will lose connection status. Not as big of a deal, only so far as you can switch their design layer without losing connection.

Our workflow for irrigation in VW has ALWAYS been to separate each station into a unique design layer. This allows for greater control, visibility, and conflict detection. Since the creation of the irrigation tools, this workflow has been compromised. Irrigation components, mainly valves, will magically change design layers when connected to different features. Nothing in VW should ever change design layers unless by User Error or by choice. Additionally, when moving valves and other components between design layers, the will actually lose their connection status. I understand that irrigation networks are a unique feature in VW and the fact that they can connect through different design layers in the first place is a revelation, but that shouldn't compromise our ability to control it. The following is a simple screenshare showing the issue. FIX THIS!

If you still have the opportunity to work with the civil engineering you can request their Civil 3D surface in a couple of different formats that will help you with your model. Ask them to export their Surface as a TIN, all by itself - This is essentially the civil 3D "site model" that you can explode and use directly as your site model Ask them to export their "breaklines" or "feature lines" as 3D polys in CAD (.dwg). Import them into VW as 3D polys and use them to building your site model. Some cleanup may be necessary, but this is essentially just trading the guts of their surface model with the guts of VW's site models. Finally, have them export the Surface as 3D contours, giving you that last bit of information to help you. Ultimately this doesn't take them much time and dramatically streamlines yours. That said, I do wish VW had better interoperability with Civil 3D and could read all of the CoGo objects that are used in Civil3D's grading exercise.

Hi @Vladislav Stanev. I'll try to get you something today or tomorrow. It's gonna be BIG!

I couldn't agree more with the sentiment of this post and some of the frustrations. Every tool VW develops is powerful at its base, but when you put them to use in actual real-life scenarios, they often fail to meet basic productivity standards. This is something that every professional on this forum should be pushing VW to get better at it. Ultimately we all want VW to thrive and beat its competitors, but that only happens if we can ALL thrive using their software. Just one of many other similar occurrences/workflows:

We’ve only experienced it going between two different Windows machines.

We have had this happen, where suddenly the program doesn't recognize our selected font and then uses a Font Mapping to change the appearance of everything to Arial (the default font selection in mapping). This is only a problem because Arial has different spacing and will respace several of our very finely controlled annotations and text boxes. Is there a way to en-masse change the fonts in a particular file? Not necessarily size or font style, just font? This sounds dangerous, but indeed may be more time efficient that going and finding all of the remapped fonts that are incorrect when this problem occurs. If VW would get their text game even a little better, problems like this wouldn't be as prevalent. I've added wishlist items for better text handling for years now, but the program is still only slightly better than MS-DOS mode for handling text.

We have tried on a couple of projects, rather large in scope, and have had moderate success. That said, we have decided to avoid it going forward because the errors we did experience, which were mostly confined to edited resources not updating, are scary enough and sometimes not noticeable until much later when it is too late to fix.

If you make any changes to the document, do they save?

Yep, this is a frustrating one for sure and has been voiced now for long enough to have made the fix. It is also a pretty well established graphic standard in the landscape architecture world and the "improvements" should always be gauged against these standards to make sure users can actually use the tools in their workflow. Regressing functionality shouldn't happen with "improvements"...otherwise, what is the point of having improved tools you can't even use without a complicated workaround.

We are used to handing off grading plans to civil engineers and haven't had to experience these problems first hand until very recently. Yes, this is a very frustrating regression with no fix yet. Hopefully the new release will have features like this fixed?

I've got over 60 different SketchUp models I need to import and due to resource conflicts, I have learned that it is best to import them all into one file, all at once. That said, the SketchUp import only processes one file at a time, needing the user to accept each import manually. It's at the pace of about one import every 2 minutes or so. I was wondering if there was a way to script this import process so that Vectorworks would just use and import the same settings for all the files, without the need to have a user accept each import every 2 minutes for 2 hours of time? Any help or suggestions are welcome, thanks.

Yep...all for the sake of 'smart' tools. At the base level I understand the promise of BIM and its potential to change the way we design and draft. I often compare it to the old saying "work smarter, not harder". This all falls apart though when you spend 4x as much time making things 'smart' as you would using traditional methods, especially when that 4x doesn't pay off in the long run with reduced time on revisions or enhanced collaboration. I sometimes feel that VW misses this point and just creates tools and features for the sake of having tools and features, without asking the question of how this gets used. Furthermore...how specific tools get used seems to be framed around very specific types of applications, applications that users don't necessary know about before diving in. I feel that the irrigation tools and many of the site tools were designed to accommodate the residential, single-family market and then when large-scale landscape architects try to use them for massive projects, they fail or these efficiency problems creep in. Marketing continues to push the tools to a broader audience, whether or not they were ever intended or designed to facilitate the variety of scales being pitched. You and I have had these conversations before and you know where I stand. If VW and Landmark specifically is gearing to be the preferential tool used by the landscape architecture profession, then they need to get outside the small box they have created for themselves.

Wow @rowbear97, you were a busy one on here this morning! Regardless of how you make the grade object, it still takes way too long to edit some of the functionality of one, once it's created. The tool is actually very useful for annotating slopes on a site model, if it didn't take so long to create using the toolbar tool. What I have found though is that once you create one, you can just copy it and move around copies to a much quicker effect than drafting one from scratch each time which takes more than 30 seconds each to get from first click to application. My thinking is that if Vectorworks is going to create tools for our use, then they should be useful and practical tools, not only from a functional standpoint, but also from a practical application perspective. 30 seconds is far too long to expect anyone to wait to draft a grade object when we may have hundreds to do. This problem doesn't stop with grade objects too...take irrigation tools, they often take 15-20 seconds per command, adding hours to a drafting process.