line-weight

Member
  • Content count

    502
  • Joined

  • Last visited

Community Reputation

92 Excellent

About line-weight

  • Rank
    500 Club

Personal Information

  • Location
    London, UK
  1. Thanks for your reply. While there might technically be a logic to the "default" folder I don't think it's meaningful or useful to the user. I'm guessing that some of your arrangements with manufacturers involve them hoping that the inclusion of their products mean that people might be led to specify them, and they don't therefore want them to get lost amongst other stuff, or become non-identifiable as their product. But surely it's also in their interests that people can find them easily? I would have thought the identifiability could be dealt with using a suitable file name. Once I've imported, say, an Arroway texture into a drawing, I have no memory or interest in which folder volume I took it from. Maybe it's worth a discussion with manufacturers to see if they can see that it might be their interest to have their products easily discoverable within a logical file structure. Alternatively perhaps there could be a high level subdivision into "generic" and "proprietary" textures. If manufacturers insist on their own folder structures, then they can be allowed to exist in the "proprietary" section and users can look in there if they can be bothered picking through endless files. Meanwhile if I just want to find something quickly I can do so easily in a clean and orderly "generic" section. Going back to the "defaults" folder - looking in there just now, there are quite a few things which don't seem to be of any use to a user browsing for resources. For example, there is a folder called "plug-in components" which contains two files (eg "blank default") which look like things that are used by some tool or other but which are of no interest to me when browsing for importable resources. I don't think this kind of stuff should be cluttering up the folder structure. There should be a folder at high level that is named such that the user understands it contains stuff they don't generally need to look at. I've attached a screenshot of the "vectorworks libraries" section folder list, with the "defaults" folder open. This is the point a user needs to get to to find where renderworks textures are (it's obvious that they are not going to be in any of the "objects..." folders). The list is longer than will fit on my screen. I think anyone can see some groups of items that could be put together within a sub-folder (all the objects stuff to start with). Doing this, and clearing the clutter that doesn't even need to be normally accessible, would make the list much more manageable. I think a good principle would be, that once I've got down to the resource file level, the expanded tree of folders containing it should be compact enough that it can fit within the height of a screen.
  2. While the recent improvements to the resource browser are welcome, I still find the process of finding something like a renderworks texture very tedious. For example, say I want to find a timber texture. Firstly, ignoring any libraries I might have created myself, just to see what resource files are available, I have to go seperately into two high level folders and then dig down two levels in each. a) Subscription libraries > defaults > renderworks textures b) Vectorworks libraries > defaults > renderworks textures (And why is there a folder called "default" on the same level as a number of "objects" folders? Why isn't that first level of folders sorted by general type of resource, like "objects", "renderworks", etc?) Then when I do get to one of those "renderworks textures" folders I am confronted with a long list of files, which are only really usefully sorted in as much as their names happen to work out alphabetically. So if I want to look for wood textures, effectively I have to look through the whole list, because there might be a suitable texture in "wood_..." or "flooring_wood_..." or "misc_materials" or "misc_arroway_textures" or "_default textures" or who knows where else - there might be some folder called "timber_..." or "oak_..." for all I know. The files should be organised in a way such that if I don't know exactly what I'm after, but want to see what is available, it's easy to find everything in a broad category. eg: Libraries > renderworks > textures > wood > hardwood or something like that. And then, not a long list of files with unhelpful names like "wood_arroway_textures_vol02f" but a minimum number of files with names that describe what's in each of them. So if I am looking for an oak texture I don't have to look through all of volumes 01a to 99z. I'm guessing some might say this is what the search function is for. But the search function relies on the file or texture having been named with the right word that I happen to think of. This is not of much help if I want to look for, say, a light-coloured hardwood texture. Searching for "light coloured hardwood" isn't going to get me anywhere. But if I can go down into a logical file structure, then I can be sure that I can do a fairly exhaustive search of the options without having to look through virtually every folder on there, which is what it feels like at the moment. I find the file structure for renderworks textures such a mess, and so tedious to look through, that I sort of dread going in there, and will often use a texture that I've found previously and used in another drawing, instead, even if it's not really quite what I want. Surely this is not how VW wants people to be using the resources made available.
  3. Yup, stair, doors, windows - potentially the 3 most useful of any of the parametric tools for architecture - the ones which if they worked well, could really save a lot of time and tedium, yet they are all fairly awful and don't seem to have been improved in any significant way over the past several releases.
  4. Something that has become apparent to me, after using multiview for a bit. Although some visibility options can be chosen on a per-pane basis, the "show other objects while in edit modes" can't. It would be useful if it could. (What would be *really* useful is if I could be editing within a group, say, and have pane (1) show just the objects in that group, for clarity, and pane (2) show the same but with objects outside the group also visible, and for it to be possible to grab something in pane (1) and then flip to pane (2), with that same thing still grabbed, to let me snap it to some object outside of the group. I'm imagining that pane (1) might be an openGL perspective view and pane (2) a wireframe orthogonal view. But I realise quite a few other things would need to happen to make this possible)
  5. Something that has become apparent to me: Although some visibility options can be chosen on a per-pane basis, the "show other objects while in edit modes" can't. It would be useful if it could.
  6. I think you've misunderstood the problem we are talking about here. I don't want to ungroup the autohybrid. I want to paste-in-place something that was previously outside the autohybrid, into the autohybrid.
  7. I've abandoned using auto-hybrids for this reason.
  8. Thanks.
  9. I can tell you what I'm using it for right now which has highlighted the issue for me. I have some custom made wardrobes all drawn in 3d. They are made up of a mixture of simple extrudes for the shelving etc plus some mechanical components (eg. hinged/lifting clothes rails) for which I've imported models from elsewhere. The models for those components are complex, and they cause me problems with the push pull tool which I've raised in another thread. So I have a class that I can use to switch those components on and off to allow me to edit the other parts with the p-p tool. As it's a large amount of built-in stuff I have it grouped into sections, again for ease of editing. So I am quite often "within" a group editing it, and want to show/hide those complex components without exiting and re-entering. Additionally, I use visibility classes to show certain components in closed/open or lowered/raised positions etc. Useful to be able to flip between those, again without having to exit any groups I'm working in.
  10. I use saved views as an easy way to switch visibility classes on and off. This I do by setting up the saved view to not restore viewpoint, layers, zoom etc - just to adjust class visiblity. This generally works fine. However, when I am 'inside" a group (ie. I have double clicked it to edit it) and I try to use one of these saved views to switch off some classes, I am thrown out of the group and have to re-enter it to carry on editing. Is this intended behaviour? I find it a bit annoying. To demonstrate, see attached file. There are two objects, one in class 1 and one in class 2. The two objects are grouped together. I have two saved views, one to hide class 2 and one to show it. You can see it works fine outside of the group. But if you enter the group to edit it, and select one or other of these saved views, you are exited from it. Same happens in 2017 or 2018. svexample.vwx
  11. Scenario 1: Have to say I'm not sure I'd realised that the selection in one pane can be different to the selection in another. Sometimes it seems like it is (when I'm inside the same group in both panes??) and sometimes it's not, as I realise from fiddling around just now. Makes my head hurt a bit to try and figure it all out but so far it seems to work in practice so will trust you guys to have thought it through. But surely if I'm modifying some parameters in the OIP, my cursor is going to be over the OIP, rather than any pane? Or do you mean that in moving from the pane I'm working on (say Pane A), to the OIP, I might pass over another pane (say pane B) and activate it? In that case surely the logic would be Click on pane A, cursor moves from Pane A to Pane B, click on pane B: Pane B becomes active Click on pane A, cursor moves from Pane A to Pane B (no click on on pane B) then OIP: Pane A reactivates as soon as cursor reaches OIP Scenario 2: I think I disagree here: my expectation, intuitively at least, is that if I do something with the 3d mouse, it'll act on whichever pane is under the cursor. That's what I'd expect for any tool too - if I'm going to do some operation my attention will always be where the cursor is. If I've gone to a tool palette I'll come back to the pane before doing anything (I think?) but even if for some reason I've left the cursor on the tool palette, can't the logic I've described above apply?
  12. That can't explain my example with a file that contains two rectangular extrudes and nothing else! Unless it is affected by other larger files I have open at the same time. I wonder if I too should try a clean install.
  13. The problems with the SWP tool seem similar to problems with the push pull tool; both tools having problems highlighting faces consistently.
  14. I'm finding that I can't get the "set working plane" tool to find faces that are within symbols. I don't think this was a problem in 2017. Attached is a screen recording. I've simply got two extrudes but one is within a symbol. You can see that while the SWP tool finds faces on the "normal" extrude without any problem, behaviour on the one within the symbol is erratic. It seems to be able to find faces when I hover near the bottom, but further up it sometimes does and sometimes doesn't. And it can't find the top face at all. (NB this is whilst outside of the symbol. If I double click to go into and edit the 3d symbol, then it works fine) symbolwp.mov