nrkuhl

You shouldn't need any metadata for photogrammetry - all the info is based on the photos, you just need enough photos from sufficient angles (at least with the applications I have experience with)

I did some limited experimentations with photogrammetry via an entry level DSLR a year or two ago using specialized software that I convinced my school to get me a license for. It's not a particularly straightforward process, nor did it generate particularly useful geometry at that point. There's no reason at that stage I couldn't have done it with smartphone photos. Basically every camera on earth at this point has sufficient resolution and sensor size for photogrammetry at this point. The issue is (as others have said) getting it to useful geometry. Photogrammetry is TOO accurate in my experience so far for easy architectural use/and it can't distinguish between objects. And working with point clouds is somewhat difficult. I was attempting to use it for site surveying a historical site in Malta where I had limited time on site and no ability to return after an initial visit. I ended up doing the surveying I needed manually and using the photogrammetry as a reference. Fortunately that was a school project so it didn't matter when I fudged things to deal with inconsistencies. I know some archaeologists have been using photogrammetry for documenting excavated objects for a while (which was my initial introduction to it). They seemed to keep the resulting models as records that lived entirely in the specialized photogrammetry programs they used - I have no idea if/when they were extracting that data to another modeling program. I did not have a chance to probe that too much, as I was only onsite with those guys for a few days on a somewhat remote site in Peru.

Nah, BIM is "just" linking a database to your objects. More data heavy than graphical scripting, sure, but I'm not convinced it's particularly difficult from a programming standpoint in a program where every object already has a unique ID. The issue for me is in fundamental work flows: having drafted in both VW and ACAD professionally, 3D is bolted on. Working in 3D in a native program is a vastly better experience. I'll gladly grant you that command line based programs like Rhino have a steeper learning curve, but in the long run you'll produce much faster as well than in something hotkey or icon based, and the ease of setting construction planes and the vast capabilities of such a resource light program are really impressive (I've run Rhino on an ARM based Windows tablet in the past, with a totally reasonable experience). Going back to BIM and Parametric modeling though, VisualARQ (rhino's AEC parametric plugin) is already better at some things that are basic to the workflow: for instance, I can have multiple buildings with separate stories in a single file, without the level settings interfering with each other. Magical. It definitely isn't professional production ready, but it's good enough that I use it personally for my master's projects, while griping about the software that I'm paid to use on a daily basis.

I use VW at work on a Mac, and sometimes work remotely at home on my PC. The overall experience is way better on the Mac version. The UI feels more polished, and the program as a whole is much more stable. This is in spite of the fact that my work computer is somewhat underpowered for VW and my home computer is significantly more powerful. Files are totally interchangeable. I used to work in theater as a tech director, and all my lighting designer friends run VW on PCs and hate it. That said, I really dislike the Mac experience as a whole, and the hardware is overpriced and underpowered. I actually also somewhat despise VW (though I'm not sure Revit is any better, just differently dumb). I dream of a day when Rhino's BIM / parametric plugins are fully production ready.

We've had some issues with this as a result of VW crashing while people were working on shared projects. The only solution I found was to "save a copy as" from one of the working files to a regular VWX, then turn that file into a new VWXP.

Oh snap. @Andy Broomellthat's a slick setup. I think "include in drawing list" needs to be a checkbox that exists in the setup of all sheet layers, a la windows on schedules. If I setup Andy's worksheet tactic, it'll break the moment I leave my firm and no one else will know how to manage it.

We're also using a fully custom title block set up using the steps @JMR describes above. I've also never put in the time to figure out the VW built in issue and revision trackers: I remember not finding the documentation on it particularly helpful and decided it wasn't worth the effort and I just made those _P fields in our custom title blocks so they only have to be updated once.. We've also stuck with using manual sheet lists - we tend to have a lot of superceded sheets that get saved for reference, or sheets of renderings set up that we don't want showing up in our drawing index.

Will this work with structural elements? It would be great if I could quickly import my structural engineers Revit drawings in Vectorworks native structural objects. Of course, you guys will have to fix the structural member tool too...

Standard walls above the layer cut plane (as set in layer options), still show as though cut by the layer cut plane. They should be invisible, or even better, have configurable options in the wall style for how they show when above layer cut plane. Even better, a method for setting cut plane per viewport, while still having the drawing show in top/plan mode would be excellent. See this thread for further discussion:

I have a plan with several walls that do not touch the floor (i.e. there are major ceiling height changes in a certain area of the floor). I'm trying to set up a plan so that those walls do not show. Since none of the walls come to within 2' off the floor, I set the Design Layer cut plane to 2', but nothing changes in either the design layer or the sheet layer. Any suggestions as to what I'm missing? This is not the first time I've tried to use this option, and it's also not the first time it hasn't made a difference.

Did you by chance figure out how this happened, or has anyone else had a similar experience? This just happened to my boss, and between us we just lost about 90 minutes of billable time to this.

And the display of this varies by object type and view. I did just figure out that the move by points tool does let you do this if you tab all the way through the fields, you get to (working plane based) absolute measurements.

Actually, 0,0,0 should be the same through every program. But if everyone involved in a project doesn't keep their drawings in the same relation to the origin, things are going to end up off. PEBKAC and all that. Both VW and Revit seem to try to obscure origins and all the 3D modeling backend (I know VW has rulers and all that, but it's not the same), compared to actual 3D modeling programs (i.e Rhino). I've found anything with a command line much easier to manage geometric relations in, since there's always some version of "move this object to 0,0,0" available as a command. If there's a way in VW to move an object to a specified, absolute point in 3D space, I haven't found it.

This current project is the first that I've worked on with a consultant (structural in this case) using a BIM program. Nothing crashed, but in order to actually get the 3D models in the same space, I had to manually move some things. I think this is a problem created by VW rather than Revit - I have our site modeled with absolute dimensions, which results in the model being ~500' above the origin. The IFC import from Revit came in on the origin. I'm not sure what the best method of coordinating origins between programs that operate very differently is.

@killafornia, if you're hoping to get a workable model from another program into VW, the conclusion I came to was that it's not happening. If you just want to coordinate with a consultant and make sure things fit, then having them export to IFC is the right choice.

The only thing I've managed to successfully use the Structural Member tool for is as a work around for making gutters. The tool is incapable of producing a column, nevermind the ID (as discussed in the thread @rDesignreferenced above).

Did you turn off the dimension class in the viewport via the OIP>Classes ?

Just to throw in one more, I'm having this same issue trying to place a custom sized wood column with the Structural Member tool.

Oh, I was confused because it downloaded with the 2016 icon color. I meant more in the context of using a dimension line to do so. I know I could add a row to show the height just as text.

@diamond, I'm pretty sure no one else in my office even knows the purge command exists. They certainly aren't worrying about file sizes. I'm still working on getting people to switch classes instead of changing object properties, so asking them to go looking for a class to import from a template file is out of reach at the moment. Auto-classing takes some of the difficulty out of using VW for some people, then at least PIOs are in reasonable classes (most of the time). My take on the problem (in gross generalizations) is that baby boomers tend to view everything through the lens of hand drafting, and just want to switch around lineweights. Younger Millenials all seem to have learned on Revit, and so classes and layers are totally alien to them. The easiest people to teach are gen-X and older Millenials who learned AutoCAD as their first drawing program. So mid-level folks understand drawing organization, but everyone above and below has a steep learning curve if they didn't learn it from the get-go.

Also, this is OT, but @michaelk, that was a vw2016 file, right? I just opened it in 2017 without a conversion prompt or anything. New SP2 feature?

Got it, unfortunately I think it's a product of the worksheet database functionality, and unrelated to the image functionality. @michaelk that's pretty neat! Unfortunately one of the things we do with our opening schedules is show the dimension of the sill above AFF - which may preclude the use of worksheets altogether for our process, since the product is an image.

I've looked into this before, and you can't go horizontal with a database-based worksheet. I wish you could, it would actually allow us to fully automate our opening schedules. Our format for commercial projects is to do both a standard, non-graphic schedule, combined with a series of opening elevations showing each style of opening. It's my least favorite sheet to create because on larger projects I have to create and edit a couple dozen small section viewports.

That would be awesome! Putting time into learning VW scripting or Marionette has unfortunately been outside the scope of my activities at work, even though I'm sure it would be very useful.

My office subscribes to Service Select, would one of the support options be a good way to answer this? What is the right channel for asking VW questions that no one seems to be able to answer? Thanks!