line-weight
-
Posts
3,754 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by line-weight
-
-
So has it been confirmed that perpetual licenses, beyond VW2023, can officially be sold secondhand?
There will of course be a finite & ever diminishing number of these out there.
-
24 minutes ago, Matt Overton said:
It would be great if we had a hot project list that looked to see what folders the recent files were in, then kept the most recent folders and even allowed us to pin folders.
Although it might need to look up the chain a level or 2 to get meaningful names; otherwise, in our case, it would just hot list 10 folders named "CAD".
Yes, pinning folders or files could certainly be useful.
-
1
-
-
This is in VW2023.
I've not had this issue before but last time I used a keynote legend was probably a couple of VW versions ago.
The index numbers aren't aligned properly with the text descriptions. Most obvious with no. 9 here. Does anyone know what might be causing this?
-
I've not used "dual view" dimensions before but I can reproduce what @skipper sees.
Trailer text does not show up when dual view = secondary only, unless you untick "show dim value".
-
2
-
-
If you want to be able to easily edit/adjust the object after you've created it, I would avoid using a loft (because if you want to change it, you have to start again. You can save the source curves on a hidden layer/class to make this a bit easier, but I find this a rather fiddly approach).
I would first have a go using the methods @E|FA suggests above.
-
It's a Huion (now a few years old) that I have. As per my post above I don't use it as much as I thought I would. I'm not able to compare directly with a Wacom unfortunately.
-
10 minutes ago, shorter said:
Getting warmer... 😉
Ok, so then we have a vertical cut plane effectively rotated 90 degrees so that it is laying as a horizontal plane, right?
What I don't get is how you would then meaningfully relate the 0,0 for this plane to a 0,0 in the 3d model.
It's straightforward for a top/plan (or horizontal section) viewport to have its X and Y zero points superimposed on the model's X and Y zero points, because nothing has been rotated, and the Z values become irrelevant.
It's different for a vertical section though. Its cut plane might intersect with the X axis, or the Y axis, or both. What lines up with what, or determines where it is placed?
-
33 minutes ago, cberg said:
Yes. I did. Bug submit is always a bit of a black hole.
That's my experience too. Therefore I no longer waste my time doing it.
-
1
-
-
2 minutes ago, cberg said:
@Tom W. Nobody at VW has given me an official Bug number for this issue. I am not sure whether it is being worked on, or even if it is considered a bug.
Did you go through the formal bug submit process, yourself?
-
I am still trying to understand the workflow/method.
If you create a vertical section viewport on a design layer you get a kind of 3d object, right? Rather than a 2d thing, like you do on a sheet layer.
And the cut plane, which is what you want to trace from, therefore exists on a vertical plane. So how do you trace from it in (or use it as an underlay for) 2d linework? Where is the 2d linework drawn?
Or do you use "display flattened"?
-
5 minutes ago, shorter said:
Our models respect standard UK LOD definitions. They are never detailed enough to generate detail (because they are max. LOD3 or LOD4, and modelled to deliver 1:50 GAs only) and in any case I have never seen a detail extracted from a model that I would have been proud to have drawn in 2D myself (other than those derived from a model built in rhino and sectioned in vectorworks, but even then it was max. 1:20).
So all our details are drawn in 2D, just as they are in other BIM authoring tools, using the model as the coordinating 'general arrangement' underlay.
So is your method that you generate section viewports from the model, lay them out flat on a design layer, then have another design layer (only containing 2d linework) that you kind of trace them through to? And then that 2d stuff gets viewported to a sheet layer?
I think I would try and use grid lines & elevation benchmarks as my checks that things had not moved.
-
Like @Pat Stanford says, you don't have to commit to any particular "scale". Let's call it "zoom preview" instead (I think it shoud be renamed to something like that).
You could start out with a "zoom preview" scale of 1:100 and at a later point change it to 1:50 or 1:10. And back again, as many times as you like - it won't have any effect* on the drawing geometry and it won't have any effect on what anything looks like in sheet layer viewports. You can just choose whatever's convenient for whatever you are working on at the time.
In fact, the more you draw in 3d, the less relevant it becomes. These days I draw almost entirely in 3d so I am hardly ever drawing a 2d line directly (except in viewport annotations). Therefore things like previewing line thickness is not really a concern. I actually tend to have all my design layers set at a 1:1 "zoom preview" but this is to do with navigation in 3d. I use a 3dconnexion device and it means I have finer control over the motion. This is a bit of an obscure requirement though. I do have an issue when I want to edit things in a design layer in top/plan view, because then hatches become very dense, for example.
*having said this, I'm not sure why you got the error message you posted above, about "parametric constraints" becoming invalid. You say it's when you changed the scale to 1:1000. Was that when you tried to change the scale/"zoom preview" of a single design layer?
-
1 hour ago, shorter said:
Where do you draw details?
Are your details coordinated with your model or anyone's model in modelspace? Would you be able to issue a DWG of a detail and know that it is coordinated with your consultants model... Would you be able to reference your detail back to your model or plan or section to inform the model/plan/section?
Hint... If you draw detail in the sheet layer viewport, you cannot answer yes to any of the above.
My details are extracted directly from the model, so usually they are sheet layer section viewports that directly display model geometry, with some additional info added in the annotation space. I'm aware this method may not work for others.
I'm just curious how your approach works; I don't understand why a section viewport needs to be on a design layer and in a particular location. Isn't it the section-elevation line, the one that determines where the section is taken, that's the thing that needs to be in a specific location?
-
7 hours ago, Senthil Prabu said:
Generally, it is identifying those self-intersection cases (see below image), but this case it is missed, it is a bug. We will look into that, if possible, please create a bug.
Thanks for your reply. If it's a bug, then I think you should find someone within VW to register it.
-
Agreed.
In particular it would be good to have a way of texturing materials with some kind of directional grain in an intelligent "3D" way.
Like you I'd be interested to know how other softwares deal with this.
-
3
-
-
"cylinder" map pretty much manages it although not with great image quality (have increased the radius of those fillet edges for clarity).
-
3
-
-
@Senthil Prabu these "self-intersections" in source polygons quite often cause things to fail in VW. It's quite easy to introduce them without realising, and it can be quite hard to find them.
It would be good if - when this causes a failure - we could get an error message that tells us that this is the problem. Because in many cases, the operation just fails, or we get some kind of generic message, and this does not help troubleshooting.
-
If I do no overrides, plane mapping, and then rotate 90 degrees I get this.
The top face is wrong of course, but would not matter if hidden by a thin layer laminate as a separate object.
-
3
-
-
You could also choose to model it as per reality, with a plywood core and then a thin laminate layer on top. Then give each object the appropriate texture.
-
2
-
-
Ok, the main thing to understand is that when you change a design layer "scale" in vectorworks you aren't really changing the scale of anything, it's just changing how it is presented to you - how it is "previewed" if you like. This is confusing and I've long argued that the terminology should be changed, to stop confusing people.
When you change the "scale" of a layer in VW nothing at all happens to the geometry itself. If you've decided that 1 drawing unit = 1mm then that doesn't change.
If you import something externally you just need to make sure that the drawing units match. So, if in your file 1 drawing unit = 1mm then you make sure that you import geometry such that in the imported geometry, 1mm = 1 vectorworks drawing unit. Depending on where it's coming from you might need to rescale it during the import process to achieve this, but once it's in VW you don't need to change it again.
You can set different "scales" for different design layers in VW. So if you have a 10mm x 10mm rectangle on one layer, with layer scale = 1:1 and you have a 10mm x 10mm rectangle on another layer with layer scale = 1:10, and you have both layers visible at the same time, one rectangle will appear 10x larger than the other. But it's not. Change both layers to the same scale and the two rectangles will be the same size.
-
On 1/5/2024 at 5:48 PM, shorter said:
Would anyone find it useful to have a button to lock the position of section viewports when placed on a design layer?
Why don't section viewports have the same X, Y and Z values that normal viewports have on design layers?
It is impossible to know if one has moved, which is critical if you want to ensure your details are coordinated with the model.
What do you use section viewports for, on design layers? What are they placed relative to, and why?
-
I agree with everything that benson shaw says.
I think that trying to measure on the drawing to predict where the ends of the bent sheet material will end up, when attached, is destined for failure. If I wanted joints to be in specific locations, I would choose those positions such that the predicted edges of a bent sheet oversail them a bit, and work on the assumption that the sheets will be trimmed back on site.
The issues you touch upon, of faceted curves and accuracy of snapping to them, these are a bit of a problem in vectorworks in certain situations. What is and isn't a problem is a bit complicated. But I'd say that in general terms, as soon as you start doing complex curves especially things like NURBs curves in Vectorworks, then in practical terms expect to lose a bit of precision. If you are preparing drawings for some kind of high precision manufacture then VW may not really be the right tool. However... the reality of building construction is that nothing is actually that precise, and you can get away with "near enough". But it does need some careful thought in how you prepare the drawings, and some sensible allowance for tolerances.
-
- Popular Post
- Popular Post
18 hours ago, Katarina Ollikainen said:@line-weight, The fence tool has been available for beta testers since last summer, which would be user testing. The feature has been out for general use since the 2024 release in September - this is the first comment I've received about this design aspect, and we're looking at it.
I'm grateful for anyone with constructive criticism and comments - that's how we improve. In this case, I agree that the feature could be more user-friendly - it’s also an area where I’ve other ideas I would like to see implemented (based on another tool I’m working on right now).
Sometimes, things are discovered after prolonged use; sometimes, a eureka moment hits you right before release. The latter can be the most frustrating for our team - it's far too late to change it, but you already have something even better in mind. For the fence, my biggest regret was to include scaling of 3D symbols.
There will always be room for improvement, but there will also always be someone who does not like what we create. This doesn't mean we shouldn’t always try to produce the very best. We have a team of brilliant engineers making our ideas come to life - they put so much effort and energy into our product, and (IMHO) they create some fabulous, innovative features.
The 'people at the top' take UI and UX seriously, and we are constantly working on keeping the tool approach consistent across the Vectorworks application. The TechPub team (who create the Help file) is invaluable in this - they look at every feature from a unique viewpoint as they service all industries and look at each and every dialog while writing instructions for how to use them.
The process of developing a new feature is really an effort by all levels and teams. This is what makes it so much fun to do.
Also, we now have a product planner specialising in UI/UX, @Stephan Moenninghoff. Last year, he did an enormous job with the workspace redesign, but even there, we have the same situation - some love it, and some are less enthusiastic. Some find it making their life much more straightforward, while others think we have made some wrong decisions. And I'm sure Stephan already has a list of things he would like to tweak.
All this doesn't mean everything is perfect, and I can only reiterate our gratitude to all of you who gives us constructive feedback.
I know it's easy for me to be an armchair critic, but whatever the current system is for ensuring good UI design, it doesn't work.
If someone like me, a lay person, can spot UI inconsistencies everywhere then VW are not allocating sufficient resources. There needs to be some kind of tyrannical pedant (or perhaps a team of them) who looks carefully at every aspect of anything that is introduced (well, and everything that's already there too).
The thing that's been raised in this thread, this should not have slipped through the net. Of course if you give someone a button that says "flip" they are going to expect that pushing the button will make the gate flip. Because (correct me if I'm wrong) that's what happens everywhere else in VW: if you press a button then the thing the button does happens instantly. If there's a dropdown with options, or somewhere to type a numerical value, then we know that usually this means the changes will take effect when the dialogue closes. That's fine, because it's what we expect. You close the dialogue by pressing OK. When you press OK it closes the dialogue and commits the changes. Again, pressing the button is what makes something happen.
@Tom W. above has already suggested a better way of doing this, with radio buttons. I'd suggest something like that too. But it shouldn't need users to point this out. This is a very basic issue of consistency and expected behaviour. This absolutely should have been picked up before release.
I do recognise that there are certain things where the best way to do something is debatable, and you have to choose one way or the other and some users will disagree with the choice. But this example, it's not one of those. I don't see why anyone would want to have a button that doesn't do anything until later, which gives you no preview of what's going to happen later, and gives you no record of how many times you've pressed it. There are no possible advantages of this. It simply is bad UI design, and a professional software package shouldn't be getting released with stuff like this.
Again, I don't want to come across as criticising the people who develop & code the tool. I'm criticising the system VW has (or doesn't have) in place for thoroughly checking things for UI issues. That checking needs to be done by someone who has not had any involvement in the development of the tool itself, so that they can come to it in the same way a user might come to it.
-
8
-
These yuk responses, which of course must be disheartening for the VW employees who put so much hard work into developing these complex tools, could be avoided if the company were to take user testing and interface design seriously, but it's very clear that the people at the top don't. The proof of the pudding is in the eating.
-
1
-
Text Selection
in Architecture
Posted
I intermittently have this kind of problem editing text, and have done for several versions of Vectorworks. It's one of those things where it is hard to pin down what causes it to start happening. Does closing/reopening the file, or restarting vectorworks clear the problem (even temporarily)?