Jump to content

line-weight

Member
  • Posts

    3,708
  • Joined

  • Last visited

Everything posted by line-weight

  1. @herbieherb I am continuing to use this scriptand it's very useful. Thank you. There's something strange I have noticed. I expect this is something in Vectorworks, not a problem with your script, but I wonder if it makes any sense to you. I will export a render viewport, and I'll get a PNG image with a certain size, let's say 2000px wide and 1000px high. I then do some kind of edit of the geometry that the viewport is looking at, and re-render it. And then I export it using the script again. And this time I will get a viewport that is 2000px wide and 1019px high (or similar). It'll be a slightly different size, and from what I can make out, the crop is the same, the image is just squashed or stretched very slightly. Surely this shouldn't happen - the viewport should produce the same pixel dimension image each time, no?
  2. I'm afraid it was to give up, and continue doing my issue sheets manually. Not because of that specific problem, just the whole thing felt too buggy and complicated, and I didn't trust it with something as important as keeping track of what has been issued to who and when. I'm still using VW2018, so maybe things are better in 2019 or 2020? (I think I can guess the answer though)
  3. I've not worked with point clouds yet. Recently soeone asked me if Vectorworks could handle point clouds. I said I wasn't completely sure but I thought it was supposed to be able to handle them now. But, seeing as it's Vectorworks, it would probably turn out it couldn't actually do much useful with them in practice.
  4. After extensive fiddling around, I realised it's the refraction setting in the glass transparency shader that affects this. Turning it down to only slightly over 1 has gotten me a little closer to what I want.
  5. Trying that doesn't seem to make much difference - you may have misunderstood what I'm trying to reduce, which is the dark grey/black you can see along the 'edges' and facets of some the glassy elements. Here I have highlighted a couple of examples:
  6. In a further unwelcome twist to this story ... it would appear that for some reason, re-rendering a viewport, without changing the crop or anything else about it, is liable to result in a new image that is just a few pixels different in size from the previous one. So, any workflow that relies on being able to replace the old render, with the new one, in exactly the same position, gets broken.
  7. I've just had one of those mornings where I've basically been doing unpaid testing for vectorworks, because that's the only way I am going to get semi-predictable results using the heliodon tool. My conclusions at the moment: 1) Just don't even think about touching any settings in the visualisation pallete when dealing with viewports. The over-rides here, for switching lights on and off, just seem completely unreliable. 2) Instead from now on I'm going to control which heliodons are on and off by class and by class only (as @Matt Overton suggests above). 3) So the heliodons are "always on" where they are sitting on whatever design layer they live on (I have a dedicated "lighting" layer). Each has its own class, and it's that class that gets turned on or off per viewport. 4) There's another bug which I don't know if it's been noted before: if you change a heliodon's class in the OIP, it doesn't actually change its class. Look in the visualisation palette, against that particular heliodon, and you'll see in the "class" column that it is still in its previous class. This caused me much confusion until I realised this, because I'd put the heliodon in the class I want, turn that class on in the viewport where I want it, but the heliodon would not be active. So, if you want to change a heliodon's class, it seems you have to activate the class, then create a new heliodon with all the same settings. One of the biggest problems I have with heliodons is that I change the sun brightness, but it doesn't take effect, or causes unpredictable results, usually being brighter than expected. I now wonder if what has actually been happening is that there are actually duplicate heliodons active, even though the vis palette says there are not. Anyway, I'm now implementing a strict "by class only policy" and will see if this helps at all.
  8. There are so many bugs with the Heliodon tool, it's hard to know which one is causing a problem at any one time.
  9. Does anyone else have this problem all the time? It seems that if you change the "sun brightness" setting of a heliodon, whether that actually takes effect is highly unreliable. I can do a rendering with it set at 100%, then change it to 50%, redo the rendering, and sometimes I'll see a difference and sometimes I won't. I can't work out a consistent way of getting around it: making a new heliodon and changing the setting on that? Duplicating the heliodon and then changing the setting? Closing and opening the file? Quitting and reopening Vectorworks? Is there something somewhere I might be missing?
  10. Yes. At the moment I'm doing something slightly complicated that involves exporting a large number of renders that need to be an exact pixel size for a website. All I need is to be able to right click on the viewport and extract what I know VW can produce (because it produces it if you do cmd-K on the veiwport). I can't really use the exact-size sheet method you describe because the number of viewports, and I want them on the same sheet so that I can transfer class settings and other stuff easily. Doing a copy-to-clipboard nearly works but it adds a white border, and something weird happens to the resolution which is then a big faff to sort out in an image editor. I did some experiments to see if there was a sheet resolution that would produce output from the marquee tool that was the same pixel dimensions as VW had actually rendered. It turns out it would have to be something like 92.26dpi, and the sheet settings only accept whole numbers. If I try with 92 or 93 dpi, the marquee tool gives me an image that is just a few pixels larger or smaller than the actual rendering, so it must resample it somehow and this must result in a loss of image quality. The saviour is the great script produced by @herbieherb which can be found here. That gives me something reliable and predictable (and also allows me to batch export a bunch of images, already named correctly if I give the viewports names). Unfortunately it doesn't export anything on an annotation layer though. So it looks like my workflow is going to have to be -Export from VW using that script -Open in an image editing programme, and do all my annotations on layers in there -Export from there to produce the final output The whole step of messing around in an image editor could be avoided if VW could just provide a very simple command, which we know would be technically possible to implement, and which was requested at least five years ago.
  11. It's 1,000,000,000 mm3 = 1 m3!
  12. Just dropping by, FIVE YEARS LATER to note that this bug is still not fixed, in VW2018 or 2019. I don't have 2020 yet. Don't know if anyone can confirm whether it's still an issue there? I'll put my money on it not being fixed.
  13. Thanks. It's already set to zero on that texture (the top one of my images), though.
  14. Thanks! Yes, I have tried playing with these settings a bit, but without full understanding of what they each do. I was hoping someone might be able to point me to the specific things that will affect what I'm trying to change ... otherwise it is quite a long and tedious process of trial and error.
  15. Here are some test renderings for quite a complicated model. You can see that there is a bunch of stuff that I am rendering as if it's glass - the idea being that the parts that I've highlighted in a kind of beige colour are visible through it. In the top image, I've used the "glass frosted 01 RT" default texture. It sort of looks how I want it, but I'd like to reduce the very dark portions that mostly appear along edges, but also on some angled faces. What's the setting that I should be fiddling with to reduce this? Are they reflections? If so, I can't work out what they are reflecting, because I've got a pure white background. The bottom image is the same model but using "plastic transparent polythene RT" instead. This has no dark edges, and makes the highlighted elements more visible, but I don't like the look of it so much - it doesn't really look like a real material. So I guess I'm aiming for something that is in between these two materials. Any tips?
  16. It's scientific notation (E notation) https://www.calculatorsoup.com/calculators/math/scientific-notation-converter.php 7.59e+006 means 7.59 x 10^6 (10 to the power of 6 which means 10 with 6 zeros after it) So, 7.59 x 10,000,000 = 7,590,000mm3 Then you can use a converter to change it to cubic meters or whatever unit you need. eg https://www.digitaldutch.com/unitconverter/volume Somewhere in vectorworks there is a setting that will make you give these volumes in, say cubic metres rather than cubic millimetres, if that's more useful to you. I think.
  17. A quick test suggests that it does pick up light overrides if the "render properties" box is ticked. That's potentially handy - although, could also be problematic where I want to copy render settings between viewports without changing the lighting setup. In that case, I guess I could use your class based system for switching lights - but then I'd have problems where I want to copy class visibilities but leave the lighting alone. A typical use case for me is when I do sunlight studies - I'll have maybe an option A and an option B design, and for each one I'll have a few viewports showing sunlight at different times of day/year, which I do by having multiple Heliodons, each for a different time, and each viewport will have one of these switched on.
  18. That's me not looking carefully enough! Does that copy lighting settings too (ie which lights are switched on or off)?
  19. I've a feeling I've seen this as a wishlist item at some point ... but it would be useful if the eyedropper tool could copy render and lighting settings between viewports too.
  20. Ah! I never noticed it had these settings! This will make quite a few things easier. Thanks.
  21. Is there any way to copy class visibilities only from one viewport to the other?
  22. I've realised there's a problem: a saved view can have the "don't change" option for class visibilities, whereas a viewport can't. This means that the method described above doesn't work for any saved views where I have some classes set as "don't change" - that setting gets over-written.
  23. I've had a thought though, maybe this can be a multi step process: 1) Edit viewport>display using viewport visibilities 2) Save that as a temporary saved view.... but save the class visibilities only. 3) Go to the saved view that I want to change (with layers and other stuff set up) 4) Then go to the temporary saved view, which will switch the classes but leave everything else alone 5) Then save that on top of the old saved view, effectively changing it to the new class visibilities setup. A bit tedious but less tedious than manually changing lots of class visibilities. Not sure if something similar can work in the opposite direction.
×
×
  • Create New...