Matt Overton

If the Mac Version used System provided Tabs (instead of the horrible 3rd Party library) then they would work like this. Just Saying.

Duet display would be perfect if the touches were separate to the mouse. Trying to use it for extra screen while on the laptop over summer. This is the most frustrating aspect of it if you use as it touch screen you have to track the cursor back to the main work area. Which is mostly because OS X doesn't understand multi-touch. Still, shows great potential.

Does anyone use Vectorworks Remote? I ask because I thought it would be very useful when using Vectorworks on a smaller screen device like a laptop. Yet It really doesn't seem to allow me to free up much space at all. It seems worse on a larger screen device like an iPad as much of the screen space is just underused. It would be great if we could design the interface ourselves using docked palettes (eg the attached) then push that to the device that is remote. I can do similar with Duet Display how every the way MacOS treats the second display with touches means your cursor keeps being pulled over to the touch screen. So its more a second screen than a touch screen extension to the app. P.S. Also given many of us run multiple versions of Vectorworks at the same time It would be helpful the Remote Installer Disk Image had the version number in the name.

Also check out this thread for previous discussions. https://forum.vectorworks.net/index.php?/topic/44892-demo-plans-and-new-walls

Is there any real need for the distinction to remain between the two and couldn't we just have layers that are functional enough to be both? Certainly, in all the offices I've worked in we adopt this shorthand of layers meaning design layers and sheets being sheet layers. I do recall at least one the VW trainers in the Sydney area always taught the shorthand. So I'm not going to disagree with changing it in the programme for clarity.

These diagrams are perspectives looking straight up from the point of interest so in theory you should be able to set up a camera with the right settings to match. That said havent tried it in Vectorworks since minicad and it didn't work then.

Pre-miniCAD Vectorworks I see.

Holiday card and a teaser for one of our fun projects for next year.

Something like an Image Prop but for text would be very useful in this regards. Not just rooms or windows but wall tags comes to mind. Oh yes another great Tutorial document. Is there a collection of these somewhere?

It would be handy if the Navigation palette allowed us to sort layers by Z height as well as the current options of Name and Number. It would keep the stacking clearer and cleaner. Similarly and even more valuable in the views ports if we could set the layer stacking order to always be by Z height (name and number auto stack would also be handy). That way as we add layers as the complexity of the project demands these layers will fall in to the mostly the right stacking order without user interaction.

There isn't one of our current project this wouldn't be useful for. I don't see this as being any more or less complicated than current day to day and a lot less complicated when our world is complex*. It should be a lot clearer and more direct. Certainly this would much better for dividing simple models of neighbours building up to avoid cluttering the working layers. We could always pitch along side this much needed improvements to other features to help everyone even if they don't use this. Storey styles comes to mind as a way of capturing storey levels better than default does now and would be easier to update to boot. I'm sure there are others this is just the first to come to mind. I personally don't see this requiring a new tab as I think it would be better as one tab but use the hierarchical display within the storey tab. So you can see visually how it comes together. Layers could be assigned to a Storey in the same way they now if they haven't been directly created by this tab directly. *Seriously 24 storey building every floor shorten by 50mm to get a 25th storey in so much fun getting all that right again. Although this was pre-BIM and pre-storeys so the modelling was all about shadows and presentation no elevations or sections.

Why make another interface to show something visually when the majority of the programme is an interface for visual information? Also given this information we need tell others in a visual way why not just let us draw it how we need it and get the computer to work out what it needs from that? Instead of now when we draw it how we want it translate to computer code check computer has shown it right in dialogue interface then go about showing it relevant locations. All the while waiting for changes to mean we have to translate that change (and the next change) and make sure it's co-ordinated across multiple locations and formats. After all the promise of Vectorworks over its competitors was that it would understand us and the language of drawing better to help us get the results we want faster.

The only annoying thing (just to make those missing out feel better) the options for which approach are all the way inside the setting dialogue box on a tab. So you can't group select door and change them all at once. It would be nicer if you could control from object info. Still Dynamic Blocks / Symbols would still be very very useful for many many things.

Doesn't the sheet boarder still use a symbol for it's basic geometry? So couldn't you do the same thing when you are ready to sign add image of the signed stamp to a file specific version of the Titleblock symbol. That way all working projects use the most up to date symbol, signed of projects will be archived with the right Title block embedded in the file. That is how we do it with VAA titleblocks but there is also Stamp Field in those title blocks that can be used for progress stamps.

Must be physic this same frustration has been cropping up more and more although my thinking was more on the lines why can't the Key command just pick the right tool for the job instead of me thinking about. Yes I've been working with slabs and wondering why clip command works if I want to cut 2d out of component but tells me it doesn't work if I use the same key command. I mean all these tools have a system that checks if the context is right why can't a whole bunch of similar commends be on the same key command that finds the right command for me. If if this checking takes milliseconds still faster than me reacting to dialogue box dismissing it then thinking about where command is moving mouse to find the right menu item, after all so many new commands have been shafted with pizza box commands and not used enough to develop twitch. This to me solves the legacy issue as well as the new feature and the old features could be on the same command but the context checking could preference the new in new files. Would also free up a lot of easy key commands for more common uses.

Which means if they fixed the default behavour on one misses out if on rare occasions they really do want that corner. Although can't for the life of me think why you'd want just that one corner and not want all the others as well.

Sorry I meant within the profile space of the extrude. If you have multiple classes in the profile they get converted to a single class 3D object. If the final extrude maintained the the classes of the defining objects we could do interesting things without writing PIO to basically extrude multiple geometries along the same path. Like:- -LED strip lights - we could have an Aluminium carrier in one class and the diffuser in another with a glow texture assigned. -Gutters - basic profile for large scale elevations and sections, detailed linework and polygon intensive geometry for closer views. -have a simple basic cornice for general work then add a more detailed version that is only turned on for presentation and detail views.

Would it be silly to suggest profile could be class driven? I.e. have a low detail and high detail profiles on the same path as a single object. Also options for end caps or mitres, and insertions of symbols along path would be handy. Still will take any improvement.

How are you generating the point cloud? wondering if you have tried a tool like visualSFM to make a cloud from photos or drone video. We we do a lot of infill work with "interested" neighbours so my xmas project is to try if I can't streamline site context using point clouds.

Based on existence Project North could the standard Views menu add. -North Plan (like rotated plan but always set the angle of project north) -North, South, East and West Elevations - NE,NW,..... Isometrics. On Geo-referencing it would be great if there was a map view using one of the common services to pick the location.

In traditional drafting each sheet we always knew what was the content that sheet was responsible for generating what was there purely for context/reference. Yes the onus was on the staff to keep the reference up to date and is something that the computer has been very good at streamlining. Still for all the benefit It allows it strikes me almost everyday that CAD/BIM has never managed to nail an organization structure as simple, effective and teachable as of manual drafting and that causes a fair bit of busy-work we do for the system not for the project/client. Although Saved Views does this so they to are more effective in this regards but create two things that must be managed. I think many roadblocks and visibility control issues could go away if Vectorworks and Viewports understood this same concept and had different grades of layers in the viewport. To me this would look like :- - Viewports have a distinction between active "content" and secondary "context" layers. Personally and for our office system I'd only want one active but I can see how people would want more. - Double clicking a Viewport to navigate to design space would favour active layers, maybe making context layers grey in appearance. - If there is only one active layer this navigation could happen without user input. - If say you're in "return to Viewport" mode command-arrows could jump between active layers not all layers. - In project sharing if no one else has command of the layer the system could check out the active layer(s) on my behalf without user input. understanding this couldn't happen now as the system would check-out far to much and cause more hassle than it solves. - For viewports with crops or view limitations the system would further refine that to only checking out the visible objects. All these would streamline workflow by giving the system the information it needs to get us working faster and fluidly. Yet wouldn't stop us jumping out of this context to fix part of the project another drawing is responsible for but this shift would be a clear choice on the user. Further it would hopefully allow:- - Class Visibility that could be controlled to be only visible for content layers or generally visible as they are now. Allowing for dimensions and notes to be done in context without complex class structures. - for crops to be applied to just the context layers. Which combined with above would do away with annotation space which has allows felt divorced from the project.

I was modeling in a box gutter then turning it in to a auto hybrid the other day and while it was an improvement it also felt like it could be so much better along the line of this discussion. I think 60% of my frustration with BIMish workflows is I have to model thinks from a plan perspective to get the section view I want that could indeed by more easily defined in section to get the plan/3d we want. The next 20% is defining things in model and not being able to get any representation out of that modeling at all but that is for another discussion. So basically yes a sketch / primitive hybrid object so we can draw the drafted representation on any plane we deem most important then push/pull out to length or better still along a path and the Auto Hybrid system takes care of other planes and 3D would be a very welcome improvement.

Backwards how? Mostly just curious as I've yet to come across a school of thought on Issues that VAA hasn't covered. At times I think it gives too many options and should only do it the right way.

Maybe this requires so many lines as it is because VW isn't as Object-Oriented as the sales pitch for version 8 made it out to be. Not to mention most of the scripting we are talking about happens in miniPascal, Vectorscript and now Python in scripting environments that have poor UI support. Rough stab in the dark I'd say at least half those lines are UI, made half again boiler plate code structure doing very little but routing information a round the code and doing math for things that should obvious. So I can write tools for myself it a couple hours that would take a month to make them good enough to deploy in the office and a year for general public release. I mean the Easiest way to start a script was always draw the generic line work convert it vectorscript then go in to the generated code line by line tuning numbers in to parameters then writing lines of math to stitch that back in working code. Then wrapping that in lines and line of boiler plate. As you say this adds up to 10,000 lines of code and years of work to translate a dozen lines of pseudo code in to a working plug-in. What is worse is that there are no divisions in the code so everytime the script runs it has to transverse everyone of those 10,000 lines to find the 10 affected by the user change. So we end up with tools like curtain wall that are so complex that the runloop extends out and make all 3d editing tools useless as fire off countless runloops as you edit in some vain attempt to keep the preview updated. Again, I am not trying to be negative, but the reality is Vectorworks Scripting tools are not well suited to the style of automation the programme generates demand for.

Right - Brilliant. Now needs to go off and make symbols of standard timber sizes for the library. Wait does this mean you loss the additional Rafter settings and the like? Yes yes it does. :-(