Art V

I don't think this has something to do with the tool being parametric but more with how the tool was designed with regard to functionality. Some additional "intelligence" for connected objects would be nice, not just for parametric tools but for all objects. That being said, e.g. Visio has those smart connector lines that move along with the linked object and sometimes it works like a charm and sometimes it creates a big mess from all the "intelligence" and resulting jumping around of segments so it really comes down to implementation and what you are doing/creating whether it works well or not.

You may want to check the read/write rights of your plug-ins folder or the plug-in. Maybe VW cannot access the plug-in because of a change in user rights. Did you check if the plug-in is still in the folder? If yes the above may be the issue, if not you may need to reinstall VW or run the latest service pack to get it back.

Oh, and to answer your question on what to tell them... ask them what units and scale (in those units) their drawing is using. That is probably the best way to sort this out. Units and scale are independent, it only matters if you select the wrong unit upon import at a certain scale that may give you a 1:71 scale in another unit. Given that, I can't think of a unit combination right away that would give this ratio based on just units so it is either a rare combination of scale in a certain unit that gives 1:71 in millimetres or it is perhaps what I wrote above.

Making a bit of a guess here... The 1:71 scale is interesting and I'll give some train of thought that may be of some help in case it does apply. Paper size in the A-format range has a square root of 2 ratio (i.e. factor 1.4xxx). The inverse of this is 0.707xxxx i.e. approx. 0.71 If scaled by a factor of 100 you get 71 It could be that the drawing has been scaled in model space to fit a paper size that is one size different than the size for which it has been drawn at a certain scale. E.g. if drawn 1:100 at A1 it would be approx. 1:71 at A0 after scaling it up to fit A0 output size. I don't know if this is the case, and it would be bad workflow to scale a drawing like this for paper output size but I have seen stranger things over the past 20+ years.

There is another option. Depending on how the contours were generated (i.e. what kind of source you used) you may want to consider using a GIS program to generate the contours (e.g. QGIS or Global Mapper or another GIS program, QGIS is free). Then you can import the contours into Vectorworks through shape files.

As I mentioned in another thread, the best solution for me so far is to make sure that all origins are aligned with the internal origin in each file, this way I don't have to check if all user origins are aligned and it is easier to correct any shifts as the internal origin does not change once the document has been created.

Over here there seems to be a shift from Microstation to AutoCAD Civil at the city/town level, but I also notice a shift from AutoCAD Civil back to Microstation for civil engineering disciplines at companies if other Autodesk products are not required. I'll be happy with just using VW if some AutoCAD/Microstation interoperability issues get solved. IFC might change this in the future, even though Vectorworks is mostly certified for IFC in building/architecture I know that Autodesk is trying to introduce BIM practices for e.g. their Infrastructure suites/AutoCAD Civil of course through Revit (ugh). I for one would like Landmark to become more IFC aware for civil purposes too instead of just Architecture. Theoretically that should be possible. BIM/IFC is mostly for information exchange and as such it will (hopefully) promote more platform independence in the future with regard to CAD software which may be a good thing for Vectorworks in the long run.

This is my experience too from the few times I ran into this issue. Which is why I make sure that all files have their origins, page and coordinate system aligned with the internal origin of the file. Especially after a dwg import an user origin shift can happen and I always re-align it to the internal origin. This seems to solve 99.9% of my shift issues with referenced files. (The 0.1% is for those occasions where it does not solve the issue but I have not yet encountered)

One thing that may help is to convert more complex geometry into generic solids. This can reduce the file size quite a bit and also improve rendering speed. That being said, this would only be a feasible option if you do not have to update the model/objects any further, otherwise you could try this out on a copy of your file so that you still have the original for updating. As Jim already mentioned, file size does not always correlate with rendering speed. You may also want to check your render settings, especially since things changed from VW2015 to VW2016 and seemingly small changes can sometimes have an enormous effect on rendering speed/time.

Jim, while you are taking this up with software engineering, could you please also have them take a look at how the edges of curved surfaces are shown in 3D wireframe views. E.g. when trying to align with the edge of an extruded circle it often happens that the edge of the extrusion is "beyond" the edge of the surface lines shown. It would be nice if in any view it would show the outmost boundary line (i.e. line up with the edge of the circle in this case). This becomes an issue when two surfaces are against each other and one appears to be extending outside the edge of the other object whereas that is actually not the case case. I always have to check if things are correct or not, so it would be a timesaver if the display in wireframe could be improved.

I'm trying to export a 3D model with just under 4,500 objects to SAT and STEP. At first it would fail with memory issues and after stripping out al non-essential stuff and 2D items as texts etc. the file size went down from approx. 550 MB to 200 MB and it would still become unresponsive during export for an hour, so I force closed VW assuming it had crashed/frozen. It finally worked after splitting the model up in multiple layers and then export each layer into SAT, however... it still took approx. two hours to get this done and I ended up with 2 GB of files. The client would still prefer a single file with the entire model, so I'll try to let VW run the SAT export from a single layer overnight and hope for the best. Though it does make me wonder about exporting to a STEP file, if SAT export is this bit of a hassle. It seems to me that with only VW and the system and antivirus and other regular things running that 16GB of memory should be sufficient to create a 2GB output file, regardless of the VW file being 200 MB or 550MB. Is there some size limit where export as a single model/file becomes a problem and I need to start splitting up into multiple layers or is it just a matter of having enough memory and time available? If it is a matter of system memory, is there a general rule of thumb for how much GB of system memory would be advised for an certain complexity within VW? (Yes, the sky is the limit but I'd rather not load the system with additional e.g 32 GB or more RAM if that is not going be be used anyway by VW in this case)

Is this an issue with (older) Mac TTF fonts only or can this happen on Windows as well? It's been a long time since I had a Mac but that the time Mac and Windows TTF fonts were different, unlike OpenType TTF fonts. That being said, I've had occasions in the past where rotated text was rasterized in PDF and non-rotated text was not thought it seems it is no longer happening since v2015.

I was quite happy when layer plane got introduced, mostly because I also use 2D plans as background for reference to surrounding areas when creating 3D models without having to turn everything 2D into 3D polylines etc. first to make it look right in 3D perspective view if one wants to show the 2D plan in perspective view as well. But I agree that the automatic plane switching that happens at times is frustrating for creating hybrid 2D/3D symbols. Regarding all 2D objects in AutoCAD actually being 3D is not entirely correct. In AutoCAD it is possible to draw 2D lines in 3D space and it will look like 3D but when you import the dwg file into Vectorworks (or other programs that can differentiate between 2D/3D objects) it will still be recognized as a 2D object, even though we can tell Vectorworks to import it as 3D.

Jim, Thanks for the reply, I'll add a wish list request for more control over colour of the point cloud after import. On another forum it was suggested to break up the point cloud files into multiple parts of 35 million points maximum and then import each part in order to get the full number of points. I had considered that too as a possibility but it would depend a bit on how the lidar scan was done and put into the file as it could be possible to end up with a point cloud that only covers the extreme ends on both sides and nothing inbetween after splitting the original point cloud file in multiple parts. Given a distance of several hundred meters between the two ends, how much of an impact would such a point cloud object have on Vectorworks' performance?

Exporting into 3ds format generates meshes, often triangulated, which is e.g. quite similar to AutoCAD 3D exports. You may want to try some other export format than Blender can use (SAT will generate triangulated meshes as well and I assume STEP may do this too but I'll find that out over the weekend). You could try DAE (Collada) or OBJ instead as export format.

It is a somewhat common problem, as I've had this happen too over the years. Regarding line weight, in AutoCAD (and comparable dwg software) it is possible to give polylines any thickness you want, from 10mm to more than 1000mm (or even 1000 km if you desire). The maximum line weight in Vectorworks is a little more than 6 if I am correct, so the 6.48 would match that. This is something you can't really fix other than update the dwg file in a dwg program before importing. Regarding the markers... this is a matter of setting the correct import scale and units in case of annotative dimensions etc., if possible try to set it to the scale it would be on the layout viewport of the dwg file, that way you should get normal sizes. After that you can adjust the scale to your working scale. Also check if you have set the correct units. It is possible for dwg files to be unitless, i.e. no unit is set. In the past this was nice because you could draw at 1:1000 by pretending you were drawing in meters by simply setting it out in millimeters taken off the paper concepts that were supposed to be 1:1000. So it may be possible that your import detects millimeters while it should actually be meters.

When I look at the toilets it really looks like a converted PDF or messy dwg file, they're not continuous polylines but a series of small non-continuous polylines, this is typical for a converted PDF from a DWG file or a PDF converted to DWG. Which is why I was mentioning it. Did you receive the file from someone or did you create it yourself? If you received the file then you may have been informed incorrectly.

I'm having similar issues at times with some drawings recently when I use "ctrl-z" to undo, it is as if a keyboard key is "stuck" and it repeats the command several times in a fraction of a second. Now I am typing this, it does make me wonder about something. Are you using a mechanical keyboard with fast rollover? (though I do seem to have the issue with a non-mechanical keyboard as well)

Another thing that may sometimes help is to save the file (without closing it), after that you can resume normal operation. It is as if memory is not reliable at times and a save resets whatever is causing the behaviour.

It looks like a PDF converted to either DWG and then imported into Vectorworks or a messy DWG file imported into Vectorworks. (giveaway is the "Simplex Bold font" which is an AutoCAD (or compatible) shx font. The result of such a conversion is that you often end up with lots of polyline fragments with lots of vertices etc., possibly even 3D polylines if you have bad luck. Did you do a count of how many objects you have in the drawing? The whole combination can slow down vectorworks quite a bit if it has to render a ton of small 3D polylines in 3D section viewports.

Last week I got (somewhat unexpectedly) into point clouds and am running into some issues/questions. I've imported two point clouds into a single Vectorworks drawing, one of 57+ million points and one of 188+ million points. The import went ok, file size is a bit over 800 megabytes. The point cloud files were .xyz files containing only coordinates and nothing else. Currently only the point clouds are in the drawing. However, Vectorworks limits the display of point cloud objects to 35 million points, even though it is said to import all points of the point cloud. How does VW sample the 35 million points from the complete set? Even though it seems to look representative of the full cloud there will obviously be some gaps in the representation and it makes me wonder if I may be missing crucial things if e.g. on 35 million of 188 million (approx. 20%) of the data set is used. To differentiate between the two (overlapping) point clouds I've set up classes, one with red pen and fill and one with green pen and fill, and assigned one class to one point cloud object and the other to the other point cloud object. When in top/plan view the assigned class colour shows properly, when in OpenGL it all renders as black/grey. Is this a bug or is it something that can be solved somehow and if yes, how? Or does the sheer number of points interfere with the display in 3D? The other question, for those having used large point clouds in Vectorworks, is what are your experiences with large point clouds, any particular issues to keep in mind, workarounds/solutions?

If you are on Windows you could try using R-Studio from R-TT Software http://www.r-studio.com/ It may recover information from formatted drives as well, depending on how the drive was formatted. I had to use it once on a failed drive and it gave better results than Recuva and other software I tried before finding R-Studio.

Deleting your Prefs file may solve it, but you may lose some customizations if you have any and will have to set your preferences again.

Are some colours still manually assigned (i.e. not "by class") to objects and/or symbols? If yes then you will not be able to purge that colour. Especially with imported dwg symbols this can be a pain at times.

Jim, OpenType fonts can be TTF or OTF, the former being TrueType coded and the later PostScript coded. Based on the link you provided above it seems OTF OpenType fonts are still(?) not properly supported like TTF OpenType fonts? If so, are there plans to improve the OTF OpenType fonts support in the foreseeable future?