Jump to content

line-weight

Member
  • Content Count

    1,019
  • Joined

  • Last visited

Everything posted by line-weight

  1. Shortcut doesn't work for me - however the 'update selected viewports' command in the View menu does. I'd assumed not possible if you have other object types selected (because the 'update' button doesn't appear in the OIP if you do a select-all which picks up non viewport objects)
  2. This thread is in "wishes granted / issues resolved" but I can't see any way of doing what the wish is for - update all vports on a sheet. Or is this possible in 2019?
  3. line-weight

    OpenGL Low quality

    The way I see it there are two things going on here... One is that using OpenGL to produce those particular drawings is kind of using a sledgehammer to crack a nut because really they ought to be output as vector rather than raster graphics - essentially it is linework with areas of flat colour (ok, except for the wood texture). As vector drawings the file size would be measured in kb not mb. The other is that even when it's appropriate to output as raster graphics - VW produces absolutely enormous file sizes, way bigger than necessary, with very little control over the amount of compression applied. There have been a few threads on this, and there are some ways to reduce the output size a bit but they are either not fully effective or very fiddly. In most cases (in my opinion at least) a file size of 18mb is just not acceptable for a single sheet drawing. It would be impolite to email a file that big, and indeed many email servers would reject it. If you are trying to send a 10 sheet or 100 sheet drawing set... it's even worse. VW needs to (a) sort out its vector-based 3d output so we don't need to fall back on openGL and (2) sort out its PDF output controls and compression levels.
  4. line-weight

    Colours bleached out in OpenGL view

    Ah! Yes, you are right. I never adjust that setting. Don't know how it managed to somehow change itself. Anyway, problem solved. Thanks
  5. line-weight

    Colours bleached out in OpenGL view

    I have a file where, if I view the model in OpenGL view, the colours appear bleached out. The image on the right shows what it *should* look like, on the left is how it frequently appears. Any ideas what is causing this? It looks like something that might be caused by lights: I do have several heliodons in the model but they are on their own layer and I've double checked that this layer is turned off. I've also tried deleting the heliodons altogether but this has no effect. Closing the file/Vectorworks and reopening has no consistent effect.
  6. line-weight

    Can't edit 2d component of symbols.

    (VW2018) When I try and edit the 2d component of a symbol, I am taken to the 2d geometry, but then can't edit it. I can select an object so that it appears as selected in the OIP, but it doesn't have any selection handles on it so it's not possible to manipulate it. I can make changes to it from within the OIP but not directly using the cursor. This happens in an existing file, including when I make a new symbol. It doesn't seem to happen if I open a completely new file, and make a symbol in that. Any ideas what might be happening here?
  7. line-weight

    Can't edit 2d component of symbols.

    Any comments on this?
  8. line-weight

    OpenGL Low quality

    ...and then brace yourself for some enormous file sizes when exported to PDF (even at 300dpi)
  9. ***edit: Originally this thread was titled 'My wish: VW2018 to have no new features. Please.' Shortly after the release of VW2018 it was changed to: 'My wish: VW2019 to have no new features. Please.' It is now changed to: 'My wish: VW2020 to have no new features. Please.' *** Instead, all resources should be put into making already-existing features work properly. Doors, windows, stairs, structural members. I'm sure everyone can add their own things to this list. Anything else in the "known issues" list. Wishlist items that relate to existing features and which obviously are important to many users. I don't actually care what new features are offered in VW2018. I won't really be interested in paying for them because I won't really trust that they'll work in practice, even in the SP2 and beyond versions. Much more valuable to me would be the ability to reliably use the tools that are supposedly there already, but which I don't use because either a bug or a crucial dysfunctionality means they aren't useful in real practice. One of the best "features" of 2017 was the revamped resource browser. Something everyone has to use all the time but which was horrible to use. I actively avoided going near it and it discouraged me from trying all sorts of things. It's not now completely perfect but it's loads better and it changes the way I use VW. It wasn't a flashy new toy but its real world benefit is much higher than, say, the Structural Member tool which still doesn't seem to be usable. I think this is a serious issue with VW. Please vote this up if you agree. I am worried that we'll get left behind as the rest of the world transitions into proper BIM, not because they've got fancier features but because they have software that works properly and reliably in its core functions - something VW does in 2D but not in the context of BIM/3D.
  10. line-weight

    Traditional window schedules

    I'd say that generally once you get to the point of making window schedules, you're quite likely well beyond the level of detail that you can fudge with the hopeless VW window tool.
  11. line-weight

    moving a project from 2018-2019

    You have my full sympathy. I have stayed on 2018 because it looks like there are still too many issues with 2019. I've judged that moving would cause me more hassle than sticking with 2018 even though it still has loads of problems that we have been told will now never be fixed. It is at least the devil I know. If 2019 seems to be better 6 months hence, then maybe I'll reconsider but I suspect I might just sit it out until 2020 appears. I'm staying well away from updating to Mojave at the moment because it seems just to add to the problems. Is it an option to roll back from Mojave to whatever you were on before? I too have recently given a lot of thought to changing programme. For now, I am just hoping that VW can manage to get things back on track soon and give us something stable because moving programme is a whole other level of pain and disruption.
  12. line-weight

    moving a project from 2018-2019

    As I understand it there will be no more SPs for 2018.
  13. Especially as we're not even allowed to buy the add-on for extra, outside of Au/NZ! Why???
  14. line-weight

    Structural Member and Elevations

    Is the structural member tool *still* not working even in 2019?
  15. Yet another thing wrong in VW2018 that I guess will never be fixed now. This has been confusing me for some time now: I have a render set up with ambient occlusion as I want it (size and strength adjusted), it seems fine and then at some later point it seems to have changed. I have now realised that the 'size' is applied differently, depending on how far you are zoomed out when you update the viewport. The two screenshots are of the same viewport, no settings changed, but updated each whilst viewed at a different zoom level. What a mess.
  16. line-weight

    Best Way to Manage classes?

    I have 3(ish) types of class. "2d-...." classes which are mostly used for annotations and any 2d draughting and set up with the lineweights, line types etc that I like. "materials-..." classes which are used for 3d elements. These are set up with the attributes for each 'material' I use in the model, and these are what determine the colour of those elements in openGL views, the texture in render views, and the hatch type in sections. So anything that's made of concrete is in the "materials-concrete" class "objects-..." classes which determine the type of object - whether it's a window, or structural frame, external wall, furniture and so on. These are mostly used to control visibility whilst editing, or in viewports. For example I can set the model only to show the main structural elements, or not to show loose furniture, etc. In my system, everything is in a material class *and* an object class. At the lowest level, it's assigned to a material class. Then it will be in, say, a group which is assigned to an object class. So, lets say I custom-model a window, there will be a bunch of elements that are assigned to different materials classes - aluminium, timber, glass, and so on, and these will be in a group that is assigned to the "objects-windows" class. Occasionally I need to make an object and put it in a group by itself to achieve this but I find it helpful for editing purposes to have things in groups anyway. For things like walls, there's no need to use a group; the components are by material class and the wall object itself is in my "objects-walls' class. In addition to the above I sometimes have "visibility" classes. For example to show a window in closed or open position, there will be a symbol, duplicated with one copy in "visibility-windows-open" in one orientation and one in "visibility-windows-closed" in a different orientation. Then those classes can be switched on and off as desired. Then there will be a few "junk DNA" classes that are put there by VW; often I'm not sure exactly what they do and leave them alone if they don't seem to cause any issues. I prefix my own classes with an asterix so they all appear at the top of the classes list.
  17. line-weight

    Section viewport: inconsistent behaviour

    Sure. Thanks, and I appreciate that. For the record there's also this one: And this one (labelled as resolved, but it's not resolved in 2018): I agree that one or two of these, on their own, can be considered 'minor'. The cumulative effect of them all, though, isn't. And that's before I even get started on what happens in design layer section viewports, which are borderline unusable.
  18. See the attached file. (VW2018) There is a solid block, and three zero-height rectangular extrusions. Each of those three extrusions is identical. They have a red dotted linetype. The section viewport is set up to use objects' own attributes for the cut plane. The three extrudes are rendered differently in the section viewport. One with a black elevation line in the background, the others without. Why? Is this another bug? So far I've lost about 5 hours today trying to sort out this and an associated problem. VWsect.vwx
  19. line-weight

    Section viewport: inconsistent behaviour

    That's certainly good to hear for the future, but it would be even more evident if multiple SVP bugs were not allowed to remain in the final release of VW2018.
  20. line-weight

    Section / Elevation Settings

    Have to agree with this. It makes all the difference.
  21. line-weight

    Section / Elevation Settings

    At risk of going off topic...why did you switch from Revit?
  22. I can't work out what's going on here. The attached file has a wall object, and three 'grid plane' objects (these are groups containing 3d polygons). The wall should be positioned with its outer face aligned with the vertical grid plane, and its top and bottom aligned with the horizontal grid planes. When viewed in wireframe, all seems to be ok. But in section it seems to be misaligned by 1mm in each direction...why? (You can use the saved views in the file to see this) VWalignment.vwx
  23. line-weight

    Section viewport: inconsistent behaviour

    Since moving into 3d properly, section viewports have become central and crucial to my workflow*. The various issues with them cause me quite a few headaches. They are one of those things which it's really important work well and are rock solid. Because if you build your model perfectly and then a section VP messes up when it renders it, it's impossible to correct those errors manually. It means time consuming and frustrating workarounds in the way the model is built. *At present I use them for all 2d views of the model. That means not just sections but all elevations and floorplans too.
  24. line-weight

    Why is object appearing in wrong position in section VP?

    Thanks for taking the time to look at this. I see what you mean; the zoom level affects the displacement. That is weird. NB that it's not just a 'screen display' thing - the error is reproduced if you export as PDF. This kind of thing makes me feel a bit nervous because I thought I could trust dimensions added in the annotations layer to be accurate - but in this case it's possible to snap a dimension to one of the planar objects and to one of the non-planar objects, which are in fact in the exact same location in the model, but in the annotation layer it will produce a dimension between them. By the way, is this connected to the thing where planar and non-planar objects are often not aligned when working in OpenGL view?
  25. line-weight

    Section viewport: inconsistent behaviour

    Yes, that's exactly what I assumed it's doing: drawing the geometry beyond. And you're right that there are situations where you do want to see the geometry beyond. But what is frustrating is the inconsistent behaviour. Why does it only happen with one instance of the object? I got this to work previously by using a 2d polygon with some of the edges turned 'off' so that there were no edges to see, and that was fine until I realised that the section viewports were drawing them in the wrong place, which is covered in another thread I posted earlier today.

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×