[Batch Image Import & Texture Creation From An Image]

Here's a little background, so you know where I'm coming from. I do Toy Fair & Trade Show design for Mattel, and our presentations are very graphic heavy. This request may not be useful to most, but it would be huge for us. I'm not aware of any other VW users that implement individual graphic elements the way that we do (complex, non-repeating shapes, character standees, logos, etc. on a substrate, rather than the typical repeating textures and patterns like brick, grass, metal, glass, etc.). Image props do not work for this purpose, nor do images aligned to a layer plane. Cut-out, extruded objects with precisely mapped textures are the solution. A couple years ago when I was tasked with transforming our operation from 2D drafting into a full 3D world, I had to literally invent the process we use to create these graphics, as I was unable to find any techniques online that satisfied this particular need. It's completely within VW's capabilities to do this, but mass producing these graphics in a quick and efficient way, without crashing VW (as texture mapping often does), while in the context of a fast-paced, high pressure organization was the trick. As such, I am always looking for ways to make this process even more efficient.

 

So, here's request number one: We would LOVE the ability to batch import images. Importing dozens of graphics one image at a time is crazy tedious. And to follow that up, how about right-clicking on an image to find an option to create a texture from the graphic. Right-click the graphic, select 'Texture from Image', and the 'Edit Texture' dialog appears with the image already applied under the color shader, and the name filled in with the images name. Some sort of appendix would need to be added to the name so that it is unique; we use _T (underscore T for texture). Tweak the settings and adjust the size and it's ready to go.

 

Just to pile on, and I may be getting a little too wishful here, but some very basic image editing would be great too. Crop, rotate & stretch/transform would be great. I know we can kind-of do this, but not really in a useful way. I'm talking about altering pixels, not cutting and transforming using drafting tools. In no way do I expect VW to become an image editing tool, but those few basics would mean I wouldn't have to go to Photoshop for the super simple stuff.

[RM "No Items to View"]

This is a good idea. And while we're at it, I would love to see the resource sorting categories drop-down available from the contextual right-click menu, up there next to 'View As' & 'Sort By'. I'm in favor less mouse movement and fewer clicks in general.

 

On a somewhat related note, when I'm creating a new resource from the contextual menu while sorting by the images category (for example), I would like to see all resource types available for creation rather than just images (that is, always display 'New Resource in…' rather than getting specific with 'New Image in…' [or whatever category I'm sorting by]). Again, less mouse movement and fewer clicks is the mantra. It's for this reason that I generally shy away from sorting by category, and opt for using the search bar from 'All Resources' instead. I'm an organization freak, and appreciate the additional tools, but organization should facilitate workflow, not hinder it as this does for me.

 

I'll stop now since this is turning into a separate topic of it's own. 😎

[2 Point Perspecitive]

Yes! I hadn't actually thought about it until I read this, but I can think of many situations where I could use some good ol' 2PP.

[Title Block double click function]

Whether it's a bug or an inconsistency or whatever, it's a running theme with VW. With VW, I expect an upgrade to bring with it a bunch of broken functionality for things that worked fine before. It's the only major software I use where I assume that a release will not be stable until the 3rd or 4th update. I like where they're going with Title Block generally, but there is a ton of room for improvement. And it's mostly simple, obvious things that should never have been overlooked, like direct text entry into fields. Thanks for making it take ten clicks to do what used to take two Vectorworks. Very frustrating. Anyway…

 

1 hour ago, JimW said:

I was able to set this behavior to Opens Settings Dialog, then confirm that Edit took me directly to the Settings and didnt offer a choice, then Tools > Options > Vectorworks Preferences > Session > Reset Saved Settings with both boxes checked brought back the choice for me.

 

Yeah, we considered that (I was solving this problem for a workmate), but that would be along the lines of trashing the SavedSettingsUser.xml file completely, and we wanted to preserve all the other custom settings and just reset that one behavior. Interesting that that worked for you though, Jim, and not us. It was the first thing we tried, as I expected it to work as before. Still, I never mind digging around in the code a little to solve a problem. It brings one a little closer to Understanding. At the same time, I wish it would just work as it should.

[Title Block double click function]

Right clicking the Title Block Border and selecting Edit from there does not open the dialog in 2018. It goes to whatever setting you have chosen, same as if you were to double click the border. You could trash HD/Users/[user name]/Library/Application Support/Vectorworks/20xx/Setings/SavedSettingsUser.xml (or the Windows equivalent) if you want to start from scratch, but if you to get more surgical you can open SavedSettingsUser.xml with a text editor and search for <TitleBlockBorderDB>. Between the <EditDialog> tags is the command to set that preference. The option are (exact entry required, of course) DisplaysThisDialog, OpensSettingsDialog or EditsTBLayout. Examples:

 

  <TitleBlockBorderDB>
    <EditDialog>DisplaysThisDialog</EditDialog>
  </TitleBlockBorderDB>

 

  <TitleBlockBorderDB>
    <EditDialog>OpensSettingsDialog</EditDialog>
  </TitleBlockBorderDB>

 

  <TitleBlockBorderDB>
    <EditDialog>EditsTBLayout</EditDialog>
  </TitleBlockBorderDB>

 

The results should be self-explanatory as it is fairly plain English. Make your adjustments with VW closed, save your changes to the XML file, and open VW. You should be satisfied.

[Vectorworks 2018 Hogs Application Memory]

To be clear for P Retondo, my issue is not with RAM, but with virtual memory. I have 16 GB RAM and the monitor never shows it using much more than 12 GB with all processes going.

[Vectorworks 2018 Hogs Application Memory]

I work for Mattel, who will not allow us to send files to others, though I may be able to send the system profiles. I'll ask, but usually the answer is a knee-jerk no. I know that makes troubleshooting hard, and I've run into this roadblock before with my organization, but unfortunately that's the way it is. Hopefully this post will help others with the same problem, and I'll try to provide as much info as I can.

 

I do have an update though. The rendering issue is still as described above for my Mac Pro running macOS Sierra, however the MacBook Pro now running High Sierra is behaving differently since updating the OS yesterday morning. Before yesterday it had been running regular Sierra, and exhibiting the same symptoms as the Mac Pro. Yesterday I decided to tax it as much as I could, and the result was interesting. The gauges I'm monitoring are in the Memory tab of the Activity Monitor; the numbers in the row associated with Vectorworks 2018 and the Memory Pressure graph at the bottom of the window. With the described problem, as rendering proceeds, the numerical amount of memory accumulates and the Memory Pressure graph fills up, going from green, to yellow, then to red which is when it pauses and gives up. At first the MacBook seemed to be on it's way to maxing out like the Mac Pro, but when the pressure started to hit red it suddenly released and dropped back to green where it continued to render as it should. The numerical memory value rose to about 40 GB and hovered around that spot for the remainder of rendering. The Mac Pro w/ Sierra never plateaus, only climbs. I've never paid any attention to this before, so I don't know if this is typical, but so far so good. I'm doing another test now and will update if this changes, but I've just recreated the situation I described above except that this time it has plateaued around 23 GB and the gauge is steadily green, so even better.

 

So, it appears (and I'm cautiously optimistic) that this is a macOS Sierra working with VW 2018 problem, and updating to macOS High Sierra fixed it. I'm the only one in the office still running regular Sierra, so I have no way to cross check, except with myself before I updated the laptop. I cannot update my 2010 Mac Pro to High Sierra, so I may finally have the legitimate excuse I need to force IT to upgrade my machine as they usually only respond to mission critical needs for hardware upgrades. I'm curious to hear if anyone else is having problems with VW 2018/macOS Sierra.

 

Seth

[Vectorworks 2018 Hogs Application Memory]

I'm running interchangeably between two systems:

 

Mac Pro (Mid 2010) w/ 16 GB RAM running macOS Sierra &

MacBook Pro (Retina, 15-inch, Mid 2014) w/ 16 GB RAM running macOS High Sierra

 

I have this same issue running Vectorworks 2018 SP2 on both machines.

 

When rendering (doing anything really, but rendering is the main culprit) I eventually reach a point where the application pauses and I get a message stating that "Your system has run out of application memory". This refers to virtual memory, not RAM. The only remedy is to quit and restart VW. I've been monitoring application memory usage in Activity Monitor while rendering, and sure enough, VW is consuming memory and never letting go. It climbs with each render until it gets around 35 GB and then it pauses and I get the message. My understanding is that an application uses this virtual memory while it is running a process and is supposed to release it when done. VW apparently is never releasing, which I think is referred to as a virtual memory leak. I upgraded the laptop from Sierra to High Sierra this morning to see if that would solve the issue, but it persists. Anyone else experiencing this problem? While I'v learned to monitor the situation and work around it, it's very frustrating and needs a solve ASAP.

 

Seth

[Title Block Record Format seems to be Hidden]

That did the trick! Thanks.

[Title Block Record Format seems to be Hidden]

Working on a Mac Pro 2010 running MacOS Sierra, Vectorworks 2016 SP6

 

I've created a custom title block which includes all the automated bells & whistles I need: Sheet numbers, sheet titles, revisions, etc. I keep it, along with a few alternate versions, in a workgroup folder for our department under Libraries/Defaults/Sheet Border - Title Blocks so that it is accessible as a default from the sheet border tool preferences. Everything works fine except one thing that is occasionally an issue: When I place a border using the sheet border tool, it appears in the document and functions as it should, but the record format does not import with it. When I place other default sheet borders that come with VW the record format comes with it, and I'm pretty sure that at some point in the past the record format was importing with mine as well. In most cases it's not a big deal since it all works, but occasionally I want to alter the record format for a specific reason in a specific project and I cannot because it is not visible in the resources browser. I understand that there is a hidden record format for revisions that can be toggled visible/hidden using a script. I am wondering if my format is for some reason imposing as hidden. Has anyone else experienced this, or something similar? Is there a setting change or script that could solve this?

 

Thanks,

 

Seth

[Project Sharing Crashing When Committing, Refreshing and Releasing]

Under File>Save A Copy As… you must change the file type at the bottom of the dialog box that appears.

[Trouble with annotating hidden line viewports]

When you enter the annotations layer of the section viewport do you have 'display viewport cache' checked? It must be in order to keep the render and not revert to wireframe.

[Worksheet not seeing Records in Reference Viewport objects]

I'm working with VW 2016 SP4 and experiencing the same problem. I'm incredibly bummed as it makes me have to redo my binder structure in a less than ideal way. I see this was originally posted back in 2012, with a promise for Tech Support to fix, so Vectorworks must not be taking this one seriously.

[Changing title block fields requires all Sheet Layers to be Checked Out]

Unfortunately it makes no difference whether I'm editing sheet, project or general info. Upon clicking OK after making a change a dialog pops up stating that all of the sheet layers must be checked out. I actually do not need to check out any layers at all to edit the Sheet Border symbol, but it's the linked data that needs editing, not the symbol. This is somehow related to the file containing the sheet border as I have another file using the exact same sheet border and it does not have this issue, except when editing project wide fields, like you mentioned. I wonder if there is a setting somewhere that I'm missing.

Also noteworthy that this is specifically isolated to editing data, not objects on the sheet layer, like worksheets. Even a title block can be copied and pasted to another sheet layer without issue, but as soon as I try to edit data, all sheet layers must be checked out. I wonder if this has something to do record itself.

[Changing title block fields requires all Sheet Layers to be Checked Out]

Thanks Jim.

[Changing title block fields requires all Sheet Layers to be Checked Out]

Using VW 2016 SP3 on a Mac Pro (Mid 2010) running Yosemite 10.10.5

I am project sharing with a colleague. We are experiencing an issue where neither of us can change the info in our individually checked-out title blocks without having ALL of the the Sheet Layers checked out. If one of us has any Sheet Layers checked out at all, the other has to wait for them to be released to make changes, even to title blocks not checked-out by the other user. This was not happening before the SP3 update. We've been using this same custom title block for a couple years now, and I have recently made a few formatting changes to it and modified the record, but I didn't make any changes that I haven't made many times before. I can't imagine that would cause this kind of issue, but maybe I'm missing something.

Anyone else experiencing this?

[Project Sharing Crashing When Committing, Refreshing and Releasing]

Quick update:

I've been project sharing with another drafter on my latest project and so far so good. I've even had a crash during the commit process, reopened the file, recommitted and no problems. It just picked up from where it left off. I'll report if I encounter problems, but it looks like SP3 may have been the fix.

I am noticing one other (fairly minor) issue now regarding sheet borders, but that's for another discussion that I will post soon.

[Project Sharing Crashing When Committing, Refreshing and Releasing]

AFP is superior for an all Mac environment, and I would use it if I could, but SMB just works for us while AFP doesn't, so that's what I'm going with. This may be an issue specific to our setup, so be careful making any changes to your system based on my report. Our IT team isn't really on top of things, so I make it work any way I can.

I keep my working files on my local machines and encourage others to do so also. While it's not strictly necessary, it does seem to provide a slight performance enhancement. SMB vs AFP did not seem to be a factor in this case. The other major reason for keeping the working file local is that I can work offline from home. In this case I do all my work offline and only connect through a VPN to sync to the project file. Working in online mode introduces tons of slow downs, but offline is no problem at all.

[Sheet Border Customization]

Double-check all of your text format settings. The revision notes in my custom title block wrap and align just like I intend. I have the text format of :rNote set to 'wrap text' and I specify my width, along with my desired line height spacing. All those specifics are up to you. The only thing that really bugs me is that, using the custom note method instead of VWs revision block, Vert. Align must be set to bottom in order for the newest entries to appear on top. This causes the entries to start at the bottom of my box and propagate upward. Not a huge deal, but mildly annoying.

[Project Sharing Crashing When Committing, Refreshing and Releasing]

Since the SP3 update I have been using Project Sharing to share with myself. That is, I have a Working File on a MacBook Pro that I use to work from home, and another on a Mac Pro that I use at the office. These both sync to the Project File on our server, which I connect to using the SMB protocol. Our IT department tells me we should be using AFP for our Macs, but that doesn't work and SMB always does. This is a small scale test before I try again with the whole department across Mac and Windows platforms in the fall.

What I can report so far is that everything seems to be working 'fine'. I put fine in quotes because what I really mean is that VW is operating in the manner that I've come to expect, which is far from totally stable, but usually good enough, and in some ways quite nice. Project Sharing has caused no problems, and I've even had the files crash in the middle of a commit process, re-opened the file, and completed the commit with no problems or data loss. Prior to SP3 that would have been a disaster. So this is a positive report. More to come when we expand to other platforms.

As a side note, I have noticed that, in general, VW does not like to be connected to a server while working, no matter how fast the network (though, the faster the network, the better). Working from the office is much more stable than at home because of the super-fast network, but simply being connected to a server causes slow-downs that don't happen at all while working offline. This is VERY noticeable using a VPN via my residential connection. It is protocol (though not a rule) in the office to maintain a connection to the server at all times. I think that many VW instabilities that I assumed were due to quirky programming may actually be because of this (though that's a programming issue in its own right). I'm going to try disconnecting from the server and working mainly in offline mode for a while, connecting only to sync, and see how that feels.

[Project Sharing Crashing When Committing, Refreshing and Releasing]

This thread has exploded a bit since my initial post and I'm just catching up. Since then I have been in touch with Tech Support, sending crash reports and trouble shooting. We agree that the issue may be related to autosaving. Last report was that the issue was sent to the engineering team to be worked on for the next service pack. I'll report back when I hear more.

[Worksheet Row Numbering]

I have created a worksheet as a sheet index for a binder. It is a database worksheet drawing upon information in the sheet border and does everything I need except give me row numbers. I would like for the first column of each row to display its number within the sequence of rows. Seems like a simple thing, but I can't find a function for that. Anyone have any ideas?

[Project Sharing Crashing When Committing, Refreshing and Releasing]

Thanks TimG for letting me know that I'm not alone out here. Your issue sounds just like ours. I also disabled auto save for the project file and that did not solve the problem.

I'll be talking to tech support very soon.

[Project Sharing Crashing When Committing, Refreshing and Releasing]

I am running Mac OS 10.10.5 on Mac Pro 2 x 2.4 GHz Quad-Core Intel Xeon. I administer a group that uses VW2016 on both Mac and Windows platforms. We work from a server using Project Sharing. The project file is kept on the server. I store my project file on my local machine, but others store theirs on the server. The issues described below do not seem to care where the project file is stored, nor which OS is being used. We all experience the same issues.

I've been experiencing occasional crashes when committing or refreshing, seemingly at random times. Upon reopening VW after the crash I find that layers that were checked out before crash are now still checked out, but VW thinks they're checked out by another user, even though they're checked out by me. It seems to forget who I am and won't let go of the layer without a fight. When trying to commit the changes made before the crash, I get errors stating that there are conflicts with the other user (me) and asks if I would like to keep my changes or the other me's changes. No matter which option I chose, I get to the end of the process and the program crashes. The same happens when trying to refresh, save and commit, or close and release. If I force release the layers through the Project Sharing menu, I do not get a crash. Using this method I sometimes lose the last set of changes (as if the changes were committed before the crash occurred and VW just doesn't realize it), sometimes not (as if the crash happened before the commitment).

Fortunately, normal saves of the working file work fine, so the habit I have gotten into in lieu of a fix from VW is to save a copy of my project file as a regular VW document for a safety (so I can copy in any lost changes if necessary), then experiment with various possible solutions. I have yet to find one except to force release layers and hope that the changes have committed. After this, things seem fine until it happens again a day or two later. Another way is to create a new project file from my working file, but this only works if other users have committed all their changes and my file is refreshed before creating the new project file. I also commit as often as possible, being aware of any other users committing at the same time, which causes problems too.

Also, after all the above occurs, I find one or more .vwxp files of the project file, so it seems like this may somehow be related to the autosave function of the project file. I've disabled this function for a while to see if this helps.

Clearly, this is not an acceptable way to work. Does anyone have any insight into this? Will VW be addressing this is the next Service Pack?

[Referencing records from different files in a worksheet]

Thanks, but that doesn't answer my question.

I'm willing to setup an external database with additional software if necessary, but all that seems like overkill for my needs.

What I want to do is pull field data from a record format into a worksheet, just like I would normally do inside a file, but access it from an another VW file, akin to referencing a style sheet from and html file. I'm aware that worksheets cannot be referenced. I'm actually trying to reference a record format, which also seems like it can't be done, but I'm wondering if anyone might know how.

Vectorworks will reference objects and keep them updated, but for some reason it can't do the same for data.