line-weight

Haven't really got time to test fully right now, but the button mappings seem to at least mostly work. I barely use them in practice though.

I have 3dxware 10.7.0 and a space mouse pro, and haven't updated to latest driver for fear of breaking something. I only ever use helicopter mode, so it doesn't really affect me, but looking just now, it seems that I can't change to another mode (it used to be that one of the buttons would switch modes).

It's a useful new feature but doesn't actually help in this particular case, where the OP wants to be able to select a bunch of vertices and move them only - rather than stretching the whole object.

In that specific case, do as per previous suggestions and edit the 2d shape(s) that the extrude is made from. To make things easier to edit retrospectively it's worth keeping this in mind. So in this case, it might be better to add/compose the rectangles together into one polygon *before* extruding (rather than adding the solids together after extruding). NB that if desired, you can further streamline this by selecting all the rectangles, then doing the extrude command. This will extrude them into one solid, but double clicking it will get you straight back to the group of individual rectangles (which may or may not be more convenient for editing, than a single 2d polygon).

This raises the question of why they have to be drawn as separate objects, instead of grade limits being an integral part of any tool that needs them.

Then in "elevate" there is some kind of interpolation from those straight edges to the site surface some distance away? So I guess it needs a grade limits to define how far away that is?

I struggle to picture what this actually means (I think the only way I'd understand would be doing some trial & error experiments). It really ought to be explained with illustrations in the help documentation. Creating these kinds of level pads with vertical edges is going to be one of the main things any architecture user wants to do, if they start using the site model tool, I think. But as these multiple threads demonstrate, it's very confusing working out how to do what you'd think would be a very simple operation.

Who knows! The help section seems to be silent on this, and I don't understand the prompts you get when hovering over the options when using the tool. It all needs to be explained much better than it is.

According to this post by @Henry Finch (written 20th Nov 2021 so must apply to vw2022 or earlier) a grade limits object shouldn't be needed: Have you tried following these steps exactly? That's what eventually worked for me. What was tripping me up was updating the site model too early in the process. It's important to do the "send to surface" bit before updating the site model in any way.

All of this was recently discussed on another thread: https://forum.vectorworks.net/index.php?/topic/85946-site-modifier-pad-with-retaining-edge-hot-to-get-a-clean-line-sinking-down/ Read that carefully - there are step by step instructions. The pad tools are not intuitive. Also, as per that thread, the pad modifier behaves differently depending on whether you are applying it to the "existing" or "proposed" version of the site model. This makes everything even more confusing than it already is.

Thanks for this, I have installed one of these and tried messing with it a bit. I don't see it visibly doing much to the amount of memory VW is using. I don't fully understand how all the memory stuff works but I think that part of what's happening is that VW is putting stuff in swap files which I assume are on my HD not in the RAM. My mac (M1 mini) has 16GB of RAM and I start to get problems when VW2025 is listed as using around 20GB in Activity monitor. Obviously not all of that 20GB is in the 16GB RAM. What I observe is this: I open a large file on a certain sheet layer. VW starts using about 5GB of memory (again, according to Activity Monitor). It sits like that as long as I stay looking at that sheet layer. But if I then go to another sheet layer, with a lot of highly detailed viewports on it, the memory shoots up to around 20GB and I start getting problems. If I then go back to the first sheet layer, it stays at 20GB - it doesn't revert to the 5GB that it needed first time. To me this suggests that it has used some memory to show me that other sheet but has not released it, now that I don't need to look at that sheet. At this point if I try pressing "recycle memory" on the app you link to above, nothing happens to that 20GB registered against VW. The only way I can get it to clear is to close the file and re-open.

I am now starting to have memory problems in VW2025 (with files that were fine in VW2023). It's the same issue as before - VW seems to gradually eat up more and more memory through a session, and doesn't release any of it unless I quit and restart.

I have now!

Yeah, I worked that out this afternoon actually, partly because I was having a lot of problems trying to import DVs from one file to another, and found that putting them in the user folder is another way of getting them between files. But the question remains, why can't we just manage them via the resource browser like everything else?

Ah - thank you. That did it. Looks like I am going to have to go through a number of wall objects in my original file (where I extracted the example from) and do this for each one individually. But at least I can sort it.

See attached VW file. I have a data vis that is supposed to apply a texture to objects that match my criteria. It is applying the texture to these two wall objects, but it seems to be doing so at a different scale on one face of one of them. As far as I can see there is no difference in the two objects that explains this. Am I doing something wrong or is VW? DV text override.vwx

Is there some good reason that DVs can't exist as "resources"? They seem to fit the criteria, as they can be exported and imported between files. I find the "Manage Data Visualisations" dialogue/system annoying and confusing. Firstly it's really awkward to get to it, especially if I'm on a sheet layer. I either have to go to a design layer or select a viewport and then hunt for the tiny DV dropdown. Secondly, the import process is different from the import process for resources, because I have to go and find the relevant file in the computer's file structure even if that file is already open in Vectorworks. This kind of thing drives me nuts. I spend the time learning how resources & the resource browser works, then I am presented with something almost the same but I have to learn yet another not-quite-the-same process to do a very simple task. This stuff adds so much friction to everything. And it's part of the reason I don't use data vis more than I do.

I've become completely baffled in very similar scenarios in the past. And have only managed to fix by making the heliodons anew. This seems to confirm that I'm not imagining it, there's something up with them and I always treat them with caution. Have also had problems where things like brightness settings get all messed up.

I find heliodons to be generally a bit buggy. For example, potentially they don't like being duplicated, renamed or having their class changed. For one of your problem viewports, try creating a new Heliodon, already in the class you want it to be in, and see if that makes any difference.

The more I try and use Viewport Styles, the more I am convinced that we need something like this to make them fully useful.

The answer on this is that, yes, behaviour is different in proposed vs existing "phases" of site models. It is not considered a bug and so will remain like this for now but consistent behaviour will be considered as an enhancement.

Yes I see. I also never use the "bearing height". It's something to do with how roofs meet walls? It would perhaps be interesting to know most people actually use roof face objects and also how they approach the setting-out of roof heights when it comes to construction drawings.

The datum is effectively a plane within the roof buildup. Say I have my datum set at bottom of joists but I want to change it to top of joists. The joists are 150mm deep, so I just want VW to offset that plane by 150mm but keep the roof object in the same place. The reason I might want to do that is top keep the top-of-joists on the same plane and then increase or decrease the joist depth. With something similar to what you can do with walls, I'd just ask for the old version of the roof face to be replaced with the new one such that the tops of the joists stay in the same place. That operation could be done without changing the datum within the roof object of course but it would be useful if I could then also move the datum within the object, because maybe I've decided that from now onwards that's where it's most useful to have the point of reference. This is true yes - the diagrams look similar but they are showing different things. It might be helpful if they didn't look so similar.

Ok, thanks. That's basically what I have done. It would be good if roof face styles could be replaced/edited with the same level of control as is possible for walls. Looks like the same applies to slabs.

I want to redefine where the datum is within a roof face, but I want the roof face to remain exactly where it is. So, previously the datum was on the bottom surface of the ceiling, but I want it to be in between two internal layers. The dialogue above initially looks a bit like the one you get when you replace or edit a wall style, which gives you a lot of options of what component to align in the old wall, with what component in the new wall. But actually it doesn't give you any of those options. When I click OK, the red line will stay in the same place in the model, and then the roof face will shift relative to it. So my ceiling will drop. Am I right to think, there's not a way to do what I want? I want to redefine the red datum line from where it is in the left hand diagram, to where it is in the right hand one. But I want my ceiling to stay exactly where it is.