line-weight

I'm currently working on a project at early design stage. Trying out different versions, jumping between working on stuff in openGL and a sheet layer that I have a load of renderworks viewports set up on. I can make some changes to the design, and then see how it looks in any of the preset viewport viewpoints I want, just by updating the viewport. It allows me to look at two versions of the same design, from exactly the same view, alongside each other (I can just duplicate viewports and adjust layer/class visibility as necessary). I can also quickly see the same view with accurate sunlighting at different times of day/year, again by duplicating viewports. I've only fiddled a bit with TM but I don't see that there would be an easy way of duplicating this kind of workflow/method. For every small change to the model I'd have to re-import into TM. And I assume that for each version of my model, I'd have to export that as a different file to TM? For example, if I have two versions of a design for part of the ground floor of a multi-storey building, in VW have duplicate ground floor layers, version A and version B and so on, with the appropriate ground floor layers turned on or off in my RW viewports. I think to see this in TM I'd have to export two copies of the whole model, one for each version. Is that right? I assume TM lets you save preset viewpoints where you can also save the time of day and so on? And then you can export these as image files? There's something very convenient about being able to have a sheet layer with a bunch of RW viewports that you can look at all at the same time, move around the page and so on. Would be interested to hear if anyone has worked out a similar type of workflow using TM.

Certainly +1 from me. This thread is highly relevant: https://forum.vectorworks.net/index.php?/topic/55522-smoothing-nurbs-curves/ In particular, for anyone looking for work-arounds to the problems caused by this faceting, have a look at the last post on that thread; @axhake has done a lot of work in working up a method that may be very useful for various situations. I would say there are two concerns and I don't know enough to say to what extent they are interlinked. - one is mainly about the visual consequences of this faceting (ie, the rendered geometry looks rubbish but we suspect the underlying maths is sound) - one is about how sound the underlying maths is, when you do things like splitting off a portion of something like a NURBs curve and rely on that portion following *exactly* the same path as the one you have derived it from. And there are going to be problems even if the underlying maths is preserved perfectly, if the two curves are rendered with their facets in different positions. These things are mentioned on that other thread.

Thanks - its a kind of spare-time project that is modelling as-built context as well as reconstructing previously existing historical versions. It proceeds in fits and starts and is gradually becoming more refined. It's been good practice for me in improving my 3d modelling skills... if I'd known from the outset how tricky it would be to get some victorian era brick viaducts right in VW I might not have started...

This would start to get very complicated if your foundations stepped or sloped in levels, either along their length or in profile. I tend not to use DTMs at construction drawings stage for this reason, often preferring to use a mesh type surface to represent the ground surface and then do all the backfilling manually in section viewport annotations. The DTM would become a lot more useful if it could at least automatically subtract from itself wherever it intersected with a solid (that would cover any building that didn't have internal space below ground level - for those that do, the DTM would have to become more intelligent but it would be a start).

VW2021 SP3. I have found that if I make a clip cube sectional view in OpenGL, in a sheet layer viewport, and then I go back in to edit the clip cube extents, that when I return to the sheet layer, the clip cube extents have been changed but there is a major graphical glitch which appears to make the whole model in wireframe plan view flash in and out of view. This makes things unusable and I have to close and reopen the file to solve it. I *think* this only happens when I also have a "floating view pane" open. This is not the first problem I have noted appearing when I have a floating view pane open; having one open seems to cause multiple issues, some of which I have reported in the past. Screen Recording 2021-03-29 at 17.55.12.mov

More rooflight problems. I have my own custom modelled rooflight symbol and it's inserted into a roof face. Same one as described above in fact. I'm finding that I'm unable to snap to any of the symbol geometry ; that is, the rooflight in its inserted position. I can't get the working plane to find any of its faces and I can't seem to snap to any part of it in any form. Dunno if others can replicate this problem or whether it's specific to this file/instance. I'm going to have to convert it all into 'dumb' objects I think. The roof face will be a generic solid and the rooflight a symbol manually moved/rotated to position in a manually cut hole. Otherwise it's impossible to work with it in any useful way.

I wonder if that's how it is supposed to work though.

Thanks. So it includes non-structural elements of walls etc. And I'd not really paid attention/noticed that option in the OIP of extrudes etc - very useful to know.

I like also to tick the "merge structural objects with the same fill" as it often helps get rid of unwanted 'junction' lines between wall sections etc. I've never been entirely clear what count as "structural objects" for this feature; all I know is that ticking it usually gives me something closer to what I want.

Well, I never knew you could create a detail viewport by this method! I would normally do what @Tom W. describes - duplicate the viewport, rescale and crop. And also agree, you should be able to pull more detail into the wall buildups by adjusting the 'advanced section properties'.

It's a bit of a joke that when you look at the VW promo website it has stuff like this: and meanwhile in the real world here we are wondering why we can't even have a proper rooflight tool. Not to mention a working regular window tool.

It's completely infuriating, right? Multiply that half a day by hundreds or thousands of confused users, and compare it with the time it would take just to write up the relevant help section properly. Another example of this is NURBS curves:

Does this thread help you? I've complained several times about the lack of clear documentation on how EAP is actually "expected" to work but it seems to fall on deaf ears.

VW just need to pay @Matt Panzer lots of overtime to re-write the entire door and window tools.

Still a bit of a mystery to me, what exactly was submitted as VB-145786, and what was deemed to be working as designed!

That is good to hear. Although I've not explored Twinmotion very much, my impression is that Renderworks is still capable of producing the better quality renderings, given enough effort. Twinmotion has a bit of the computer-game look to it. The biggest thing missing from renderworks is the ability to use it to easily make walkthrough animations. The walkthrough animation tool in VW is slightly better than it used to be, but frankly still pretty hopeless. It would be great to see that improved.

I note, by the way, that this thread has the second largest number of upvotes in the "known issues" section of the feedback forum. That suggests it's not an obscure problem that only I am bothered by.

Ok - thanks for the explanation. I'm not sure I understand what "resolved as working as designed" means - does that mean that it was decided it wasn't a bug after all? I just tried downloading the file that I attached to the very first post in this thread. I can replicate exactly what I report in that post - face selection from certain viewpoints becomes unreliable and provokes freezes and spinning beachballs. This is three releases of Vectorworks later, in VW2021 SP3 and on a brand new mac. To me this seems to suggest that nothing has been done about trying to fix these issues in all this time. Not intended as a criticism of you @Matt Panzer and I appreciate your feedback on this - but this kind of thing is why I now so often feel like submitting bugs is just a waste of my time.

Sorry - I meant TB3, rather than TB4. I'm not expecting anything special from the USB A ports - what's slightly disappointing is just that plugging the 20Gbps capable USB3-variant directly into one of the TB3/USB4 ports only gives me 10Gbps.

Does that mean a TB4 dock, plugged into the TB port, and then the SSD plugged into the dock? And that should take advantage of the full disk speed?

Back to the M1 itself...I've now got an external SSD to supplement the meagre 256GB internal one that I opted for. Trying to figure out all of the USB variants that now exist is a bit of a nightmare. The disk I have advertises itself as USB3.2 gen2x2 compatible with a speed up to 2000MB/s which is not far short of the 20Gb/s that UBB3.2 2x2 is supposed to be capable of. The M1 mini says its two rear thunderbolt ports are "TB3 / USB4" and I assumed that USB4 (which allows up to 40Gb/s) would not be a limiting factor on that USB3 speed... however it turns out that it is - it restricts it to the USB3.2 Gen2 speed of 10Gb/s. It seems that if you want >10Gb/s then you need a TB3 or USB4 disk or enclosure. Anyway, I have measured around 900Gb/s on the disk which is probably plenty fast enough for anything that I need; just a bit annoying that the USB protocol has now become as far as I can see a complete mess which makes it very difficult to figure out what is actually going to work with what.

I note that a Vectorworks SP3.1 update has also appeared.

What would be useful to know, is whether any future is projected for Renderworks - or will it be gradually abandoned, with the expectation that users move to using external, additional-cost things like Twinmotion instead? This knowledge would affect two things: (a) my level of disgruntlement with VW (b) the amount of time I invest in learning how to use Twinmotion at this stage

3dconnexion have now released a new beta version of their Big Sur beta https://3dconnexion.com/uk/support/faq/beta-driver-for-macos-11-big-sur/ They say it's now written natively for M1. I've not dared to download it yet...in case it messes things up again. Would be interested to know if anyone else has found it to work.

Thank you for this. Back in September 2017 (as can be seen on the first page of this thread) JimW reported a bug for what I think is essentially the same, or a related problem. That was recorded as VB-145786. Is there any record of what happened to that, in the intervening 3.5 years?