Christiaan

I have 128 GB RAM in my iMac and it's just enough. Occasionally I'll run out if I'm editing multiple large VW files and rendering viewports.

Hi Madeleine. It's not currently a feature of the native window object unfortunately. Please upvote these two requests: https://forum.vectorworks.net/index.php?/topic/49479-window-sill-improvements/ https://forum.vectorworks.net/index.php?/topic/64381-window-and-door-tool-maturity/ In the mean time the way I work around this limitation is to use a symbol. I've attached an example of one we use. You need to insert this symbol before inserting the window, so that the window sits on top of the sill in Top Plan view. If your window is already inserted just pull it out, insert the sill symbol and then re-insert your window. It's made up of simple extrudes. Adjust these to suit your wall thickness and window position. Then you can duplicate the symbol and adjust as required to make sills for every width you need. aluminium_window_sill_v2019.vwx aluminium_window_sill_v2020.vwx aluminium_window_sill_v2021.vwx aluminium_window_sill_2022.vwx

To me the smartest thing about VW buying OzCAD (and, say, CameraMatch), is the smart people that come with them.

Farkas' idea above is the best idea then.

I just updated my Monterey beta to 12.0 Beta (21A5552a) yesterday and it's still a problem.

When I used WinDoor I loved it because it did everything I needed a window/door object to do and it did it really well and reliably. But I actually find the native window object interface a little more intuitive, especially for example the Custom Sash Options. So I would love to see it brought up to feature parity with WinDoor; I just don't want that to take years.

What's the end result look like that you want to achieve?

Yeah, we don't experience this anymore because we almost exclusively use the layer import method. With Project Sharing we don't find ourselves using the design layer viewport method. We use Sheet Layer Section Viewports for our elevation drawings and we're placing the tags in the Annotation layer of these, which at first is fine in a WGR file, but when you update the reference the Data Tags no longer know what object they were tagged to and go blank. The new Data Tag is superior in many ways and there are quite a few problems associated with the legacy window id and 3D model elevations: They get hidden behind other objects (e.g. columns); and you can't adjust their position individually They become difficult or impossible to read if the window is not at right angles to the elevation (e.g. a triangular bay windows, or part of the building that is not at right angles) They're rastered images rather than crisp font You can see them edge-on at the flanks of an elevation and have to use elaborate Classes to be able to control visibility (the more complex the building shape the more elaborate the Class scheme becomes) That's only how big it is if we keep everything in one file. In practice we divide up into multiple files—generally drawing groups (floor plans, sections, etc), using Layer Import WGRing. And anything that's incompatible with WGRing (e.g. window tags in elevation) we keep the associated sheets in the model file (which increases the size of the model file and interrupts the logical grouping of sheets into drawing groups). Yes, I'm easy either way—maybe leaning toward a single file because it's less to manage—but in practice we're forced to split the files up. How do you mean rebuild it? We make use of shaded/openGL elevations these days, even for some construction drawings. And we use renderworks elevations for planning conditions for instance. These would normally be in a separate WGR file but we had an issue with the foliage tool (as mentioned above) so we keep them in the model file too. So these contribute quite a bit to the size of the files. Our model file was about 600 MB, but with all elevations (including for planning conditions) it now weighs in at 1.5 GB. Our floor plans file weighs in at 440 MB.

Sure, but consider the problems I've identified. These are not in that category: Data Tags don't work in WGR files, so we can't tag windows in elevation views of the model. Adjustments can be made to gridlines in the Annotations layer of viewports in WGR files, but those adjustments are wiped out when updating the WGR. Bugs that have no workarounds, e.g. the foliage tool showing denser foliage in a WGR file compared to the original model file. And it's now my understanding that because of the way WGR works (i.e. deleting and replacing data) we can't expect these issues to be fixed with the current technology (at least not to 1 and 2). So perhaps Matt is right, the solution to my problem is to deal with the speed problems with large files. That may happen quicker than overhauling WGRing. A project I'm working on at the moment weighs in at 2GB if we keep everything in one file (I was working on one last year that would probably be 4GB). But file size is not the problem (in fact it's more space efficient to keep everything in one file); the problem is navigation through layers slows and working with the nav palette and organisation window slows down significantly.

All the specific problems with WGRing that I've identified above are strictly WGRing problems; they don't have anything to do with PS.

Yes, I noticed this yesterday too.

I don't know to what extent but it's worth bearing in mind that this forum is not necessarily representative of Vectorworks' market. How many Japanese people are on here for instance?

Another reason for modernised WGRing: I invariably find bugs that make something look different in the WGR file than in the original model file. If that bug gets fixed, then next time I find something else. One example I've come across this week is the foliage tool. I have a particular hedge type that looks way denser in the WGR file than in the original model, which forces me to move my viewports back to the original model file.

I think it shows, too, because advances in stability and other areas means that we're now seeing WGRing as one of our main bottlenecks. The ability to copy and paste viewports has also made us more willing to split files up and use WGRing because it's now a trivial task to reverse that decision and merge them again if we need to. But things that make it easier to switch to WGRing end up highlighting the limitations of using WGRing.

Another reason for modernised WGRing: any adjustments to gridline bubbles are wiped out any time the reference is updated.