Jump to content

line-weight

Member
  • Posts

    2,176
  • Joined

  • Last visited

Everything posted by line-weight

  1. Ok, thanks. I don't understand why this can't be set by style and/or in the OIP box, but in any case I think it needs to be made clearer on the VW help page, because it says this: You have to read the green text very carefully to understand that you need to go to the "plug-in options" dialogue, and not to the "Wall closure" button on the OIP to get things to work: Because that's where most people will expect to find settings that apply to a particular object. I bet that 90% of Vectorworks users who want to try this out will spend quite some time fiddling with wall closure settings in the Wall and Window object OIPs, find that they have no effect, and give up or assume something isn't working.
  2. @Julian Carr thanks very much for that video - I would not have managed to get anything working without it. A critical point is that you have to turn on wall closure for the individual window instance, and you have to do it via "plug in object options". As far as I can see, this is not explained in the most obviously relevant help page: https://app-help.vectorworks.net/2022/eng/VW2022_Guide/Walls/Wall_closure_settings.htm Doesn't this need to be made clear in here? I don't really understand why I change this setting in this separate dialogue box, rather than the OIP for the window instance, which would seem more intuitive. Also, do I have to go round every single window and change this "use wall closure" setting? I can't choose it per window style, for example?
  3. I see big problems with this in VW2022 too. It might be helpful if you could report this on this thread to increase the chance of something being done about it: Changing the "crease angle" improves things a bit but it doesn't make the problem go away. It seems to be worse in more complex models. And is present in perspective but not orthogonal views.
  4. Is it on a single line path or a polyline? When you have a single line, you can set a different elevation for each end. When you have a polyline, it has to be level. So if you want it to follow a non-straight line on sloping ground, you have to make each section individually and manually adjust the elevations of the ends of each to match its neighbours.
  5. I agree it's not really good enough that you have to add detail in 2D linework (which has to be manually updated at every revision), in a "BIM" workflow. Have a look at the approach explained at the end of this thread I still want to look at this more closely to understand how it works but in principle there might be a way of using this type of method to get your overhead lines.
  6. Ah, ok, that's good news!
  7. Hm, here is my test on what is a fairly complex file (some quite complex geometry rendered as a glassy material). Left - renderworks (my custom settings) - render time 4:32 Middle - redshift (default 'exterior final' settings) - render time 16:44 Right - redshift (settings adjusted so that ambient light is on, and 16 rather than 4 bounces, which matches more closely my custom renderworks, and some adjustments to light intensity) - render time 24:25 An enlarged portion of each version: Of course I would have to fiddle with the settings in redshift more, to get something closer to what I want. I can see that perhaps it is picking up some complex internal reflections more than renderworks does... but it is at a high time penalty, with the redshift renders taking 4x and 6x as long as the RW one.
  8. There are two major (for me) issues that mean I can't use 2022 as it stands. Firstly this one makes my primary mode of interaction (openGL/shaded view, perspective, draw edges) unusable thanks to wildly flickering artefacts. Secondly this one means that I lose important visual cues in shaded mode that my workflow relies on. It's been recognised as a bug so hopefully will get fixed. Then all the other changes that could have been good seem to be compromised: - redshift is there but appears to offer no advantage over renderworks at all - twinmotion direct link is nice but bugs in the datasmith import process that have been present since it was introduced, are still not fixed - wall component wrapping is very welcome, as is Windoor...however, as far as I understand, we can't use them together, so it's not possible to realise the benefits of both. So I don't feel too positive about VW2022 right now. Maybe future SPs will change things. Perhaps if it weren't for some of the above problems, I'd have spent a bit more time using VW2022 and enjoyed some of the general improvements mentioned. Perhaps some annoying general bugs have disappeared. However, I've just successfully replicated problems with the push-pull tool that have existed since at least 2017 and have supposedly been logged as bugs. This is one of those general-use bugs that doesn't make VW impossible to use, just frustrating. There are others which I've not tested yet but my guess is that many of them still won't have been fixed.
  9. I can also replicate this problem (posted in 2017) in VW2022. So, again, not fixed.
  10. Having just tested this, it seems not to be fixed in VW2022 as I can replicate it exactly.
  11. I have not tried to do much 'real' drawing in 2022 yet - but I was quickly able to reproduce the above by: 1. Draw rectangle 2. Extrude rectangle 3. Rotate extrude by arbitrary amount 4. Enter extrude edit mode 5. Try and draw arc One thing that I have noticed happening in 2d (but on sheet layers) is that if I scale a viewport by x,y% it scales to the new size but appears at a new location on the sheet, offset from the old position.
  12. @Jesse Cogswell how do you find render times compare? I had got the impression Redshift would let us produce renderings that weren't quite as good as full renderworks, but could be done much more quickly. This is what it says on the promo page But my limited testing so far indicates that Redshift takes much longer.
  13. Having had no response to this I thought I'd try things out. I think that some things may have been improved but within a few minutes of testing, I find: - VW glass material is imported as opaque. - I can override that with one of TM's glass materials, and that works fine... - until I try making some edits in the VW file, click the update button, the TM scene updates with the geometry changes but the glass material reverts back to the wrong, opaque version. NB the edits I made were nothing to do with the glass object, they were edits to other objects in the model. So, still not practically useful for me. Ho hum.
  14. Well, i often grumble that we are asked to submit bugs when all the info is laid out already in a thread like this. Nonetheless I thought I'd try submitting a bug for this issue - partly to see if it actually caused anything more to happen than when I report something on the forum here. I just spent 15 minutes of my own time doing this, preparing and uploading a sample file, filling out all the fields in the form, describing how to replicate step by step, and so on. Then I press submit, and the form deletes everything I've just written, giving me an error message relating to the number of digits in the serial number I entered. So that was a waste of my time and I'm not going to type everything out again. Maybe if any Vectorworks staff are reading this thread they could acknowledge the issue.
  15. Thanks for the confirmation. It does seem it's specific to walls. I've just tried with a slab object, for example, and it behaves as expected.
  16. I'm also trying to figure out whether Redshift is any use to me. First experiments aren't promising - I have compared render times and results on some viewports in already existing files. The "renderworks" settings I'm using are custom ones that I have tweaked over time to get the results I want, but they are effectively "final" quality ones. These are essentially exterior renderings: Rendering A - quite a lot of glassy/reflective/transparent material - time to render: Renderworks custom final quality: 1:51 Redshift "exterior fast": 2:41 Redshift "exterior final": at 5:00 it was still going and appeared only to be halfway through. Rendering B - pretty basic materials without reflections, transparency etc: Renderworks custom final quality: 0:15 Redshift "exterior fast": 0:20 Redshift "exterior final": 2:15 So the Redshift renderings seem to take significantly longer than the regular Renderworks ones. The images they produce are notably inferior to the RW ones. The comparison may not be entirely fair because of course, I could probably improve the quality of the Redshift ones by fiddling around with settings for a while. But I don't see why I'd bother doing that if they are even slower than RW to render. I may be missing something.
  17. Ok - as in your Renderworks Textures? So you choose what texture each wall component has by class, and render the wall "by component". This works for me, if I have the wall components set to classes which have textures. However, the problem is when the class has no texture. So, say I have a class called "red fill class". Under its "graphic attributes" I set its "fill" like this: But then under its "textures" I assign no texture, like this: In previous versions of Vectorworks, this would result in the wall component in OpenGL view being shown in the "fill" colour. In VW2022 this seems to result in the component just being shown as white*. In other words, if I want to control the appearance of a class-controlled wall component in "shaded" view, then I have to assign a texture to it, rather than just a fill colour. *in fact, further experiments show that it will not always default to white, but to some other fill colour that I previously assigned to that component when I gave it a "fill" attribute directly, and not controlled by class.
  18. When you say "materials" do you mean, attributes of classes that you set up as "material" classes... or do you mean, the newer vectorworks-defined "Materials"?
  19. Can anyone comment on this - am I missing something obvious? Because if this is intended behaviour in VW2022 I have to change the whole way I set up and use my classes.
  20. The behaviour I am used to in VW is that if I: make classes with a fill colour: Assign these classes to wall components: make sure that the "fill" of those wall components is set to "class style" Make sure the wall object is set to render "by component" And make sure that in the OpenGL options I tick "use colours" Then, my wall should look like this is OpenGL view: Doing all this in VW2022 produces a different result though - my wall just looks like this: I've created the two extrudes to show that assigning them to the relevant classes has the expected outcome- they are displayed with their red and green fills. But the wall isn't. Is this intended behaviour, an error on my part, or a bug?
  21. I can reproduce the issue in that test file by arraying the object, and the problem patterning still appears with the crease angle set at 90 or even 150 degrees. Screen Recording 2021-09-18 at 10.32.26.mov Test File_arrayed.vwx
  22. Is there any possibility of making the Windoor plugin available in VW2021, at least for those of us who have paid for VW2022 (eg via service select) but might choose not to start using it for real until it has been proven reliable?
  23. I agree this would be useful. But don't forget that for frequently-used layer/class visibility switches, you can use saved views, and once set up, achieve the change with a single double-click on the saved views list.
×
×
  • Create New...