Tom Klaber

@Jonathan Pickup Is the answer really "Don't use that tool/setting" - ?

We use Control Point - and have taken to adding a tick at the 0'0 so that we can adjust the control points of all benchmarks at the same time. This behavior is only related to the control point method. It's frustratingly funny that this is the exact behavior that I actually want and have been asking for when it comes to the drawing labels. I want them to maintain their association with the viewport but NOT move when tweaking the position of the viewport. But here, it is truly catastrophic. This will lead to a lawsuit somewhere for sure.

All fine and good if you have a 3D model. After some painful years - we have gone back to drawing our elevations and sections in 2D. I loved the fact that VW had a tool to help coordinate the 2D process - but this bug has me completely petrified that we are going to send out a set and not notice that all the benchmarks are incorrect because somebody tweaked the sheet layout. Suddenly this is a HUGE liability.

Just noticed 2 more pages affected by this. Its really consequential. @Vectorworks - can you confirm this is acting as designed?

If you setup Benchmark Elevation markers in the annotation of a viewport - and set them to Control Point with a Y-Axis (2D MODE) - the reference point seems to be referenced to the position on the page rather than relative to the annotations. This means if you move your viewport - as one often does when setting up sheets - all the elevation benchmarks become incorrect as the the control point does not move with the viewport. The control point should bn "In" the annotations - and move along with the viewport. This is close to a bug in my opinion - as there is not a single use case I can think of that would benefit from this behavior.

We are looking at moving more schedules to online shared resources. This collaboration with contractors, clients etc. is super helpful. Right now we have to have all of our automated schedules as stand-a-lone Vectorworks worksheets, and shared schedules like finish schedules as google. It would be great if we could export and import google sheets to directly sync and overwrite the shared files.

Is the simplest would be to retire the rectangle object entirely. The rectangle tool should remain - but simply draw a 4 sided polygon.

I clearly do not want to work today... @zoomer The reason the other programs misuse the term "layer" - is because of Autocad - not because of anything innate. Layers - are analogous to layers of vellum - the place where objects are drawn. They can be stacked (or not) but can - if you wish to have a stacked relationship with each other. What do you do with classes but to classify the objects? Either at an object type or an option a or option b... ? Honestly curious to understand how else classes can be utilized. While you might have some outliers - classes do classify objects - and are analogous to your pen set - as they define the visual appearance of the objects. Your layers do not need to have a layered wall height to take advantage of their stackability. Would you really advise switching their meanings? Do you really think that makes more sense? Do not believe it.

XREFS are not quite the same as layers - but I hear you. Convention aside - I really do think that Vectorworks - despite being in the minority - is actually using the correct terminology in the grand layers/classes debate. I say we stand our ground - righteous win out. I am so baffled by this. Vectorworks has Materials. Just not sure how renaming "Renderworks Textures" to "Materials" is a step in the right direction. I never hear people say they have to go "re-material the model" - they have to go "re-texture the model." Do you take your Vectorworks models into physics engines? We use Lumion - and they - as you say - call these resources Materials. Maybe I am just used to it - but have not run into this as a sticking point. Each own.

Oh Zoomer - we have never been so opposed before. While industry standards are all fine and good - doing something just because that is the way AutoCad does it is not good enough. Autocad "Layers" is a bad name for that that is. The term "Classes" is more accurate to what they are. The fact that VW has this dual organizational system is one of the most profound advantages it has over AutoCad. Classes are classifications - layers - like a cake - can have Z relationships. You are dead wrong about wanting to follow AutoCad there - even if others have. "Textures" has always been the industry standard for a map that gets applied to an object for rendering. WWW.TEXTURES.COM - formally CGTEXTURES - is one of the best resources. If you go to Poliigon - they have "Textures, Modesl, and HDRIs" - nobody calls the image maps you apply to objects "Materials." "Materials" is more of a BIM term meant to classify objects with material-specific data and attributes. What if you wanted to change the look of the concrete in your model? You would not say that you wanted to change the material - you want to change the texture that represents the material. They are different. Vectorworks has materials too - I do not use them - but if you make a material you can assign a texture to represent that material - have no idea why you would want name both those concepts the same thing.

Right now Textures and Materials are not the same thing. A texture is a rendering term about how something looks - the idea of a material is broader and that it comes with more data. You need those concepts to be different.

I have not heard it spoken - but yes - we very much have this same curse.

Bumping this. Do not have to wait until 2025... Could be a December SP update for Chistmas!

Again - loving the new drawer style pinning mechanic. But everytime I open VW - the resource browser resets to: I then have to slide out the deferent columns to my preferred width. Would be great if it could remember the positions rather than defaulting to what looks like min, min, remainder.

Yeah I figured. Maybe I will get used to it - but as of now its still stalling me for a microsecond overtime as it looks like its telling me the OK button is not available. Maybe a yearly "accent color"! Miss the yearly accent colors...

I mostly get that - but the Mark data is not really by style - there is a mechanism to transfer the data - but if you do not have that box checked - you could have 2 walls with the same style with different marks. If there was a true by style control of the mark - you could elect to eliminate that failure point. It is easy for me to imagine that somebody in the office does not have that checked - (despite the email I will send this morning) - and replaces the walls - not realizing that the tags will not update.

Not mentioned anywhere is a great new feature of being able to dock closed tool pallets that then roll out on mouse over. I love this in principal - no more lost Resource Window. I love how it also rolls out on the CMD+R command. Great new feature... But... The animation is janky - studdering - feels and looks terrible every time. Not sure what the programing behind the scenes looks like - but if that could be a smoother action - it would go a long way to having this feel polished.

Thank you. That is helpful. Still would be great if you could chose for the Mark to be a by style attribute if desired.

I really need the Wall Mark to be controlled by style. It seems right now - if I change the wall type - the Wall Mark does not update - leaving the tag reading incorrectly. This obviously negates one of the biggest benefits of using styles is not having to manually check all the tags. Am I doing something wrong? Is there another field I should be using?

Agian - loving the new UI. There is one wierd thing on Windows where the OK button / and sometimes default YES option is grayed out and looks as if it is not clickable: I have come to realize that it is just selected - but the it is the same look as an unclickable button. I think we need a darker shade of gray - or a slightly different look for a selected button.

The confusion with Layers and Classes as it applies to communication with AutoCad will exist regardless - no desire to make the internal VW nomenclature clunkier to somehow better fit with other programs termonology. Not sure if I understand the hesitation around Textures vs Renderers Textures. Materials are a broader concept that contain lots of information including textures. To me - dropping the word Renderworks does not change anything.

Liking the UI refresh. I think we should build on this cleaner aesthetic and use the momentum to rename some things: Design Layers -> Layers Sheet Layers -> Sheets Renderworks Textures -> Textures Let's Marie Kondo this thing!

Yes! I am playing around in 2024 - the new UI feels great - but the attributes panel is little changed. There is room for great improvement here. Just the way a hatch or tile is previewed in that long skinny box with the name over it - not great: I think the suggestion of having a quick all by class button is a great idea. I think a better layout in general should be investigated - with a better preview. Maybe have a full lager square below that previews the settings.

Just opened it up for the first time. The UI feels soooo much better. Like a breath of fresh air. I am sure I will find occasion to complain soon - but visually it now feels like I am using a grown-up program.

Our internal desire - is to have the same or mostly the same classes across all of our projects / files. Every project usually gets a couple of special classes to sort something out - but the majority of it is standardized. Additionally - we have template files with the starting official office standard classes built in - so the viewport styles could be predefined and contained in your template. So ideally you would not be starting from nothing. Speculation here - but my guess would be that the style would simply try and translate as best it could at the time of being imported. If there is a class definition that does not exist - then it is simply ignored and new classes are defaulted to off. I would not imagine that if you added a class later that it would default to on - even if that style in some previous version of its life in a previous document had it on. You would simply need to redefine the style if you add classes after the style is imported. Without class support - the viewport style is not of very much use to me...