Jump to content
Developer Wiki and Function Reference Links ×

Can a script change viewport class/layer visibilities?


Recommended Posts

1 hour ago, Jesse Cogswell said:

@SamIWas ,

@line-weight mentioned in the original post that they have been using the eyedropper tool to do this, but it becomes very tedious if you have a large number of viewports spread across multiple sheet layers, the tool I wrote and posted above allows you to do it all in one go, and has the ability to force the viewports to run an update as well.

 

Sigh...that's what happens when I don't finish reading the entire post and move on to the responses....🤔

 

Link to comment

Yes, this script is great and is saving me a lot of time and tedium on one particular project where I have a large number of viewports with quite complicated class setups.

 

The eyedropper tool can be slow, not just because you have to go around each viewport manually, but because of the slowness with which Vectorworks opens up and draws sheet layers with large numbers of viewports (something that might have improved somewhat in later versions, but at least in VW2018 which I'm still using, switching between such sheet layers is incredibly lethargic and tedious).

 

Being able to tick the box that re-renders all the viewports you've just updated also saves quite a lot of time (although, if I had one further suggestion to @Jesse Cogswell it would be that this box should be un-ticked rather than ticked by default, as it's quite easy to unintentionally set VW off on a redraw when you didn't meant to).

Link to comment

@line-weight , ask and you shall receive.  The script will now save the choice from the Attributes to Copy drop-down as well as the Update Viewports checkbox to a resource file and will recall those settings the next time you run the command.  This is set globally, so these settings will be recalled regardless of which drawing you have open.  Update Viewports will be unchecked by default the first time you run the tool.

Copy Viewport Settings.vsm

  • Like 2
Link to comment
  • 1 year later...
14 hours ago, Jesse Cogswell said:

Updated plug-in attached.  Let me know if this creates any bugs or issues that I might have missed in my (admittedly rather quick) testing.

Copy Viewport Settings.vsm 15.7 kB · 4 downloads

 

Thanks very much! Seems to work fine. Really appreciate you doing this.

 

Not expecting anyone to write this for me, but here is another thing that would be really useful to automate:

>Activate saved view A

>Create viewport named "A" on sheet layer X

>Activate saved view B

>Create viewport named "B" on sheet layer X

>Activate saved view C

>Create viewport named "C" on sheet layer X

etc etc

 

Would that be complicated to do, in principle?

Link to comment

Not hard in principle but probably a tricky implementation.  Saved Views are basically already just a script that changes visibility and views. So you can change to View A, but there is no way to test and see what view you are in. If you make the user choose from a dialog of Saved Views you should be able to grab the names you need to create the viewports.

 

Any reason you want to do it serially? Could you not have the user choose all the Saved Views they want and then generate all the viewports at once?

 

Link to comment

@line-weight I've run some tests this morning and think I have a handle of this and am working on a script for you.  It will launch a dialog showing all Saved Views, allowing you to select them, choose a Sheet Layer, and set things like Viewport Name, Drawing Number, and Drawing Title before cycling through the selected views and creating Viewports.

 

As @Pat Stanford mentioned, Saved Views are a little tricky, so at the moment it will be creating viewports strictly based on the class and layer visibilities of the Saved Views, not the screen view itself.  It IS theoretically possible to pull the screen view and use that to create a crop, but it is a fair bit trickier.

  • Like 1
Link to comment

Yes please don't put loads of time into this unless there is some enjoyment in it for you @Jesse Cogswell! It is something that would be really handy for me in managing a particular project, and would save me some tedium but it's also a process that I can do manually without it being a big deal.

 

@Pat Stanford no need for it to happen serially - choosing from a list and generating at once would be fine.

 

To explain the purpose of this, it's really just a way of applying (very large) bunches of class visibilities that are saved as saved views, and applying these to already existing viewports. As I work on the model, a gradually add elements that get assigned to different classes and each of these classes is then made visible in one or more of my saved views. So the saved view setups can gradually evolve as I work on things, and I use them all the time to flip between different states of the model, but I also have viewports set up to produce renderworks images which are the final output of the process. Each of these viewports has a class visibility setup that matches one of those saved views, but there is no way of having them update themselves in parallel automatically. So, periodically, I have to update each of those viewports.

 

At the moment the process to do this is to view the model in an arbitrary view, activate each of the relevant saved views, and for each of them create a viewport on a "master viewports" layer. It doesn't matter what these viewports look like, all that matters is that each of them contains the right combination of class visibilities to match each of my standard saved views.

 

Then when I have all those master viewports generated, I use the script that @Jesse Cogswell kindly already provided, to copy the class visibilities from each of those master viewports, to a bunch of the final output viewports. Sometimes I am wanting to copy each master viewport to three 'final' viewports, and in other scenarios I want to copy them to ten or twenty. The script I already have makes this process hugely less tedious than it was previously (I had to go round with the eyedropper tool, and VW responds very sluggishly when you use it to copy class visibilities).

 

So this other script would be about the generation of the master viewports each time I want to update them. It would streamline the current process of

-go to design layer

-activate saved view

-wait for model to update

-choose "create viewport"

-deal with the settings dialogue (including typing in a name for the viewport)

-wait for VW to produce the saved view on the sheet layer

-navigate back to the design layer view

-activate the next saved view ... and so on, eight or ten times over, each time I want to do this.

  • Like 2
Link to comment

@line-weight All right, give this a shot.  When you select a saved view, press the button at the bottom to set things like where the viewport should live, what its name should be, etc.  If you select the saved view without setting the options, it will default to the top sheet layer.  It will also do an error check on the viewport name, but if you leave it blank it will do the standard "Viewport-X" scheme that VW does automatically.  Also, pressing the button with the saved view selected will automatically put a check in the Selected column.

 

This only looks at class and layer visibilities, and will rope in stuff set to "Ignore" if you're not careful (it loads the Saved View, pulls the current layer and class visibilities, then builds the viewport and applies them, if the class or layer is set to ignore in the saved view but is visible at the time you run this command, it will end up in the viewport).

 

It also pulls the scale of the active layer to apply to the viewport, so it works best if you have the saved view Active Layer set to something other than "Don't Save", since then if you run the command while a sheet layer is active, your viewport will be at 1:1 scale, which probably isn't ideal.

 

The plug-in was written in VW2019 but tested in both VW2021 and VW2022, so let me know if something doesn't work right for you.

 

 

Saved Views to Viewports.vsm

Edited by Jesse Cogswell
Plug-in file updated
Link to comment
8 hours ago, Jesse Cogswell said:

@line-weight All right, give this a shot.  When you select a saved view, press the button at the bottom to set things like where the viewport should live, what its name should be, etc.  If you select the saved view without setting the options, it will default to the top sheet layer.  It will also do an error check on the viewport name, but if you leave it blank it will do the standard "Viewport-X" scheme that VW does automatically.  Also, pressing the button with the saved view selected will automatically put a check in the Selected column.

 

This only looks at class and layer visibilities, and will rope in stuff set to "Ignore" if you're not careful (it loads the Saved View, pulls the current layer and class visibilities, then builds the viewport and applies them, if the class or layer is set to ignore in the saved view but is visible at the time you run this command, it will end up in the viewport).

 

It also pulls the scale of the active layer to apply to the viewport, so it works best if you have the saved view Active Layer set to something other than "Don't Save", since then if you run the command while a sheet layer is active, your viewport will be at 1:1 scale, which probably isn't ideal.

 

The plug-in was written in VW2019 but tested in both VW2021 and VW2022, so let me know if something doesn't work right for you.

Saved Views to Viewports.vsm 13.54 kB · 2 downloads

 

Thanks!

 

I'm not managing to get it to work on the drawing that I want to use it on. It just doesn't seem to produce any viewports. Tell it to produce the vports on a certain sheet layer, but the layer is just empty. I've tried turning on all classes, etc, and doing "select all" in case the viewports are tiny or away from the origin. I can also use your other script to see if the viewports exist anywhere but this confirms they don't, because they don't appear in that dialogue box.

 

However, I've tested it on a new very simple file, and it works there.

 

I've also tested it on one of my other "real" projects, and it seems to work there too.

 

So I am trying to think if there is anything special/unusual about the file where it isn't working. The only real difference I can think of is that it's quite a lot larger and more complex. I'll try and do a bit more detective work later today to see if I can work out what's happening. let me know if you have any suggestions for things to check.

Link to comment

@line-weight I only tested the script on a handful of files, none of them terribly large.  I'll try to get some time tonight to test it on a much larger file and nail down the issue.  In the meantime, could you PM me a list of the Layer names and Saved View names?  There might be a naming conflict somewhere preventing the viewports from being created.

 

Also, which VW version are you currently using?

Link to comment
13 minutes ago, Jesse Cogswell said:

@line-weight I only tested the script on a handful of files, none of them terribly large.  I'll try to get some time tonight to test it on a much larger file and nail down the issue.  In the meantime, could you PM me a list of the Layer names and Saved View names?  There might be a naming conflict somewhere preventing the viewports from being created.

 

Also, which VW version are you currently using?

 

I'm using VW2021 at the moment. I'll PM you that list in a second. Thanks.

Link to comment
  • 3 weeks later...

@line-weight Sorry this took longer than expected, I was swamped with work and only got a chance to look at this in fits and starts.  I wasn't able to replicate your bug using the layer names and saved view names you provided, and nothing in the code initially looked like it would cause the issue you were describing.  When I was working on the Split Worksheet script, I came across a bug with the SubString Vectorscript function function where the documentation lists the delimiter argument to be a full string, but in reality it only uses the first character of the string.  Starting in VW2020, the Sheet Layer Pulldown Menu dialog component would display the full sheet layer information, both Sheet Number as well as Sheet Title (as in Sht-1 [Sheet Title]).  This is very helpful except that when you pull the data from the pulldown, it gives you the full string even though VW needs just the Sheet Number to get the proper name of the Sheet Layer.  So I have all of my scripts using Sheet Layer Pulldown Menus do a version check, and if greater than 24 (VW2019), it used a SubString function with the delimiter set to ' [' to separate out the Sheet Number.  In reality, it was only seeing the space in the string, but because I never put spaces in my Sheet Numbers, I never noticed that the delimiter wasn't pulling the correct information.

 

My guess is that in that particular drawing of yours, you have a space in the Sheet Number of the target Sheet Layer.  So my script was getting the incomplete name of the Sheet Layer, so it wouldn't build the viewports.  I have rewritten the script with a manual substring function that uses the Pos function alongside Copy to properly use the ' [' delimiter.  Now it should properly create the viewports.

 

I also added a couple of quality of life improvements.  When you press the Set Viewport Options button (now called Viewport Settings), the dialog will populate with the information from the list browser.  So if you need to make an adjustment to a Viewport Setting, you now won't have to retype in the information.  I added a button to that dialog box at your request called "Generate Name from Saved View Name" that will populate the Viewport Name field using the Saved View name.  It can't be an exact match, so it will add the suffix " VP-#" with the number consisting of the next open number starting at 1.

 

Anyhow, give this a shot and let me know if it still doesn't work or breaks in some other way.

 

Saved Views to Viewports.vsm

Edited by Jesse Cogswell
Updated plug-in. Added functionality for multiple selection and Viewport scale.
  • Like 2
Link to comment

@Jesse Cogswell Once again thanks for this!

 

Firstly, you were quite right that the sheet number of my target sheet layer had a space in it (actually a couple). When I changed this to eliminate the spaces, your previous version of the script worked fine in VW2021.

 

Having tested that, I replaced it with the updated version of the script. And this now works even if my sheet layer number has spaces in it.

 

At this point the script already does more than I had anticipated I would get so please don't interpret any of the following as demands for further improvements!

 

However, if you are interested in some further comments -

 

- "generate name from saved view name" works perfectly and is very handy - thanks.

 

- where you talk about the dialogue populating with information from the list browser, do you mean that it populates with any settings that I've already chosen during that instance of me using the command/script? So, I set some things for one of the saved views, go and choose some settings for another, and then if I go back to the first saved view, I can press "viewport settings" an everything I've chosen a minute previously will still be there? If so - then it seems to be working as intended. Or do you mean, if I use and execute the command/script, and it creates my requested viewports, and then at some point later I go to use the command/script again, the settings will be remembered from last time around? That doesn't happen, but it would be pretty handy if it did. I can see that it might get complicated though because if I hadn't deleted the previously generated set of viewports, then VW would not like be trying to create some new ones with the same names.

 

- when in the main dialogue, I can't bulk select a bunch of saved views, and then apply the same settings to them all, is that correct? Again, it would be handy if that were possible, because I could select a group of 10 saved views, click "viewport settings", set the target sheet layer and choose "generate name from saved view name" and it would put all of the 10 viewports on the same layer with automatically generated names. It would save me going through each one and choosing the same settings for each (which as it happens is what I'd be doing most of the time for my application).

 

- a question, and this is not really important, because when I create these viewports they are really only containers for the class & layer visibility settings which means that I don't actually ever have to look at or manipulate them directly, but I notice that what is created for each is at 1:1 scale, top/plan view, wireframe, showing the full extents of the model. Because I am working with a big model, this creates a bunch of viewports that have a lot of geometry in them and trying to do anything like move them around on the sheet layer is very sluggish. Like I say, I think this doesn't really matter, because I don't need to move them around, but I wonder if it has any consequences for file size? Up to now I have been doing this process manually, and I usually generate the viewports set up as an openGL perspective view. Because I'll have done it with a viewpoint that doesn't see the whole model, the resulting viewport doesn't contain lots of geometry and is much more lightweight. Alternatively, I'll look at a blank sheet layer, activate my saved view (which will not create any visible result) and then do "create viewport" and this will give me a viewport that does "contain" all my class/layer settings, but it will just be a red square with an X across it, ie. it doesn't actually contain any geometry and is consequently lightweight. I was wondering why the script generates something different... ie I still get that red square with X, but it's in the middle of a load of wireframe geometry.

 

That final question I'm largely asking out of curiosity; please ignore it if it's a stupid or boring one.

 

Again thanks for taking the time to do all this.

Link to comment

@line-weight I'm glad to hear that the script is working largely as intended.  I'll address each comment laid out above.

  • Regarding the settings dialog populating, it populates now directly from the list browser.  In the previous version, it would open with empty fields, so you would need to enter in all of the information a second time.  So, when you are absent-minded (like me during testing) and forget to select the correct sheet layer, you would have to enter the data again.  The tricky thing about populating the list browser from a previous operation is that there isn't really a great way to save what that operation is.  I could have it search the drawing for viewports with names following the "auto-generation" template and populate the list browser that way.
  • The main dialog list browser is intentially locked off so you can only select one saved view at a time.  I did this to prevent viewports from having the same name, since that would be populated with the Viewport Settings dialog.  In a future version, I'll make it so that it will allow you to select multiple items, but the Viewport Name field will be disabled if more than one is selected.  I'll do some testing to see if I can find a clever way to add in auto numbering for drawing number and allow for the automatic name generation to work with multiple items selected.
  • The scale is pulled from whatever the active layer is when you run the tool.  It's out of laziness on my part, I don't want to take the time to code in a scale pulldown menu from scratch (there isn't a prebuilt one in Vectorscript).  I could just have a Scale field that would be the direct scaling factor (48 for 1/4"=1'-0", or 50 for 1:50) that could populate from the active design layer.  I'll add that to the revision list.  I almost always have my design layers set to 1/4"=1'-0", since that's the most common printing scale for me, so it usually suits my needs to pull from the active layer.
  • The bit with the red square when creating a viewport with the command when the target sheet layer is also the currently active sheet layer is due to me forgetting to put a ResetObject procedure at the end of my CreateViewports function.  It's been fixed now and will be in the next revision.  For now, either make sure you have a different active layer when you run the command, or if you do, just do something that forces the viewport to reset, such as changing the scale or editing the viewport annotations.  You might have to scroll to zoom to get the screen to redraw, but it will clear out the red X.

I have two fairly large drawings that i need to get done by the end of today, but I should have a bit of time to make the changes early this week.  I'll re-enable the ability to select multiple items, add an auto-increment on drawing numbers that share sheet layers, add a scale field to the Viewport Settings dialog, and have already fixed the red X when generating viewports with the target sheet layer active.  I'll let you know when the revisions are finished.

 

 

  • Like 1
Link to comment

Regarding the settings dialogue populating ... I think I understand what you are saying. For my purposes, once I've set that a certain saved view should be used to set the class/layer visibilities of a certain viewport, then I'm likely to want the same thing to happen next time, and next time I ran the command, it would be because I'd updated the saved view and just want to update the viewports to match. In effect of course I'm asking for something additional here, which is to copy visibilities from a saved view to an existing viewport rather than using them to make a new one, which is what this script is actually designed for.

 

Regarding the bulk select, again I understand why you chose to disable this, but if it could be made to work with the auto generated viewport names that would be great and for me it would make the above issue partly redundant, because it would make it fairly trivial to generate a large number of viewports in one go. Again for me, I don't really care about the "drawing number" or "drawing name" fields and would be perfectly happy if they were just left blank as the result of a bulk operation.

 

The scale actually doesn't matter very much to me because I'm only using the viewports as repositories for visibility settings. There might of course be others with different use cases. Having it reflect the active layer when you run the tool seems fine to me.

 

Similarly the "red square" issue is not in practice a problem for me but thanks for the tip how to reset it.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...