Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by line-weight

  1. The way this works is really confusing and in a similar situation I have ended up with duplicate site models, each on their own layer and each with their own variant of the site modifiers. When I make any changes to the unmodified site model, I have to then copy&paste it into each of these various layers, a bit annoying but can be done relatively quickly. It means I can also copy and paste site modifiers between versions if convenient. Then I can control which version is shown in any SLVP just by making visible the relevant layer.
  2. It works for me - whatever files I put in the relevant place in the library, appear under favourites in the RM.
  3. Hm ... you could also make some sort of monster symbol that contained a whole load of classes and use this as the vehicle for bringing them into new files.
  4. This is a good point and I will start using this method a bit i think. I was going to say there are some scenarios where I might still do the copy & paste method... for example where I want to import a wall style and all the classes of its components. Because a C&P of a wall object from the old file would bring all of that over. But actually .... I guess importing the wall style "properly" via resource browser would also bring in the necessary classes (I think?).
  5. In practice what I often end up doing instead of using template files properly is... - Go to previous file that has the class(es) I want to 'import' to the file I'm working on - draw a line(s) in the relevant class(es) - copy & paste into the other file - immediately delete the actual objects themselves (the objects go but the classes stay) - save file important semi related things to get your head around as a beginner: 1. an imported object brings its class but not its layer with it 2. duplicating a class doesn't duplicate any geometry assigned to it, but duplicating a layer duplicates all the geometry on it.
  6. So I have taken one of the wall objects from Tom W's file and pasted it into a new empty file. I've duplicated it, and also drawn a simple extrude. I've placed all of these objects close to 0,0,0 to rule that out as a contributing factor. The test I am doing is selecting various points on the extrude to set the flyover origin. First I try this with the wall objects "behind" me. Selection on the extrude is not instantaneous; it's a little bit laggy, but not extreme. Then I change the viewpoint so that the wall objects are behind the extrude and try doing the same thing. You can see that the lagginess now increases substantially and I can induce some beachballs. Note that in the final bit of the video, I am getting some substantial lag on preselecting the wall objects, although this seems to come and go in phases. (As an aside, I don't seem to get an orange selection box on the extrude object - why's that??) This behaviour really reminds me a lot of the problems with the push-pull tool not selecting faces, that I've been complaining about for several years now. Similarly, it seems worst when there are any complex objects in the background of the viewpoint. It's a problem that I've already identified as continuing to exist in VW2022. I've not managed to prompt any feedback on whether this problem is being addressed. Screen Recording 2021-11-23 at 09.53.31.mov
  7. For what it's worth... I've been doing some testing of something else in VW2022 and rendering a viewport does not do the same thing of hogging memory that happens in VW2021 - the memory appears to get used while the render is happening, but then it gets released again when it's completed. It looks like this in activity monitor:
  8. When I looked at @Tom W.'s model I didn't see the extreme lagginess in preselection that is visible in the videos above, but I did see it navigating with the Flyover Tool in Interactive Origin Mode (not doing anything directly related to wall objects). This became very laggy, to the point of being unusable. And this wasn't the case when I looked at the same model in VW2021.
  9. Have you made sure that they are not elements that involve containers, where the class of the container is different to the objects inside it? For example, a group, where the has one class but the objects inside it are in class "AN-general". (Including groups inside groups)
  10. On a more positive note ... this kind of comment/feedback is enormously welcome. When something is broken or buggy in a new version of VW, this is annoying and disappointing, and certainly leads to some resentment about having just paid quite a large amount of money for something that hasn't been properly tested ... but all of this can be pretty much forgiven if we get some kind of info along the lines of "we know this is a problem and we hope to have improved/fixed it by XXX". That's because, if it's some kind of issue that's critical to your workflow, then it's quite a big deal to know whether anyone's actually taking it seriously, and also when there might be a solution. Rather than the black hole of silence. There's an issue with VW2022 that I found almost immediately on first try of it, which because of the way I work, makes it sufficiently unusable for me that there's no way I'd switch to it from VW2021. But, there was a comment (again from @Matt Panzer I think) that basically let me know it was recognised, and that it would hopefully be solved by SP2. The result of that is that I can just set VW2022 aside until SP2 appears at which point, hopefully, it might be usable for me, or at least "on balance not worse than VW2021". This is pretty helpful in my planning for things like when I attempt a switchover, whether I start setting up new projects in anticipation of things that will be possible in VW2022, and so on. In contrast there are several longstanding issues where something was half-acknowledged say 5 years ago, maybe even some bug was submitted, and all there is, is a wall of silence. Even having paid for VW2022, it would be better to hear "yeah we probably won't fix that until VW2023" than just to have it left hanging with no resolution and no indication that it's being worked on. In certain cases, knowing something probably just will never get fixed, would let me know that in fact instead of waiting for VW to sort it, I would be better off changing my workflow and just not trying to use that thing (a decision I end up making anyway, quite often).
  11. This kind of relies on the time to resolution being of roughly the same order of magnitude as a human lifespan.
  12. I have an M1 mac but haven't dared to move any projects to 2022 yet (apart from anything else, on first viewing there were obvious issues with shaded view and I'm not going to start using it until those are sorted). But if anyone wanted to post a file with some actions that reliably produce sluggish behaviour I would be happy to test it out on my M1 and report back.
  13. I opened the file in VW2021 and looked at the "Forest Cabin" sheet. It looked as you want it. But when I updated it (without changing anything) it came out like this
  14. Yes, although I often find that the "show other objects" mode doesn't show enough to snap to what you want, when the scene is congested, or at least it makes it very awkward.
  15. I find that similar "face selection" problems exist with some other tools but the push pull tool is the one where it is by far the most disruptive. It defeats the purpose of that tool which is supposed to make it easy to rapidly manipulate 3d geometry. Maybe add a comment to that other thread to make clear this is a problem that doesn't just affect me!
  16. Hi @Nicholas Beloso . I think I recognise what you are experiencing here and it is a fundamental problem with Vectorworks that I have been complaining about for several years now, but it does not seem to be taken seriously by VW. Essentially the push-pull tool often fails to select a surface when it should. See below for a thread on this topic. Because there seems to be no urgency at VW to fix this, it looks like it's just an annoyance that we have to live with for now, even thpough it is very disruptive to a fluent workflow. Here are my tips for encouraging VW to find the face you want: - sometimes selecting the object containing the face before activating the push-pull tool helps - Sometimes selecting the object and sending it to front (cmd-F) helps - otherwise, try changing your viewpoint (several times). usually, eventually you will find that there is a certain direction of view where it will work from. I think it helps if there is not complicated geometry immediately behind the object - try using the "select back face" option (hold down option key) and view the object from the other side - if all else fails, my solution is to temporarily put the object in a group by itself, double click to enter the group and hide other geometry, and then the push-pull operation will succeed. Then exit and ungroup. This method is of course inconvenient when you want to snap to some other object. If your experience matches what I describe above, please complain to VW and your distributor, and so on. Add a vote to my thread below. This problem is one of the things that frustrates me most about VW on a daily basis. As you can see, I have been complaining about this for at least 5 years now.
  17. I'm using VW2021 at the moment. I'll PM you that list in a second. Thanks.
  18. 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.
  19. 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.
  20. I'm seeing it on Big Sur / M1 / VW2021. And there are reports further up the thread seeing it on Intel Macs. So I don't think it's as straightforward as that. I seem to be OK doing multiple viewports up to a certain number, and then problems above that number. So maybe everyone will find a different threshold depending on all sorts of variables including hardware, software, and drawing size.
  21. yes this is my habit too. It looks a bit like this is related to the vectorworks version rather than the type of mac hardware though. Either way I would agree it might be a reason to hesitate from upgrading if you are still on VW2018.
  22. Eurghh... as I suspected, no longer being able to reliably render multiple viewports in one go presents me with some headaches. There is something peculiar about the way VW does renders, that means that rendering the exact same viewport with the exact same settings, doesn't always produce a pixel-perfect identical result. One use case for me involves multiple views of the same scene, each with identical viewpoint, but with some changes to the model geometry in each. I need to be able to extract these images into a photo editing application where I can lay them exactly on top of each other. It all needs to line up at a pixel level. But infuriatingly, unless you render all these versions in one go, VW is liable to output a bunch of images all with slightly different pixel dimensions. So, updating all the viewports in one go is the only way I have of achieving this. And if VW can't update multiple viewports without crashing......
  23. Thanks, that's very good of you! It seems to work; the only thing is that it acted on all viewports rather than just the selected one like a previous iteration of your script (which I have) did. However, I could see that I just needed to change the line near the end to ForEachObject(RenameVP,(((T=VIEWPORT) & (SEL=TRUE)))); and now it works on selected viewports only. I notice it takes quite a long time to run (about 15-20 seconds) even if I just have one viewport selected ... is that what you would expect? Is it because it has to check every viewport in the document to see if it's selected, something like that?
  24. Did you make a troubleshooting thread in the forum, or just file as a bug? And was this recently, or some time ago? I guess you have not had any response as to whether it's something we might see fixed?
  • Create New...