Jump to content

line-weight

Member
  • Posts

    3,707
  • Joined

  • Last visited

Posts posted by line-weight

  1. VW simply isn't able to draw things like rooms in roofspaces properly in top/plan, especially when you want to show construction buildup even at a basic level of detail. For example in the drawing in the video there is an external finish and insulation shown in the dwarf walls that separate the eaves spaces from the room.

     

    Best in my view to draw them as horizontal sections, and just use solid modelling (or possibly stacked wall objects) for things like this. More flexible and probably no more cumbersome/time consuming to draw and edit.

  2. I've got two roof faces which meet each other at a vertical join. If I look at them in 3d, I can see that the 'inner' faces are aligned at the join, but the 'outer' faces aren't. This is because the two roof faces are at different pitches.

    660601286_ScreenShot2020-06-26at16_40_47.thumb.jpg.761b8b0b3fd48e94297e3d1931ab23af.jpg

     

    (Am I correct to understand that the reason they are aligned on the inner face is because this is where I have set the "datum" for the components on each?)

     

    But when I look at this in top-plan view, they are drawn as if they are overlapping. Why is this?

     

    1519075699_ScreenShot2020-06-26at16_32_05.thumb.jpg.d1b54448d567a6d9c09cbe39f0d82f00.jpg

     

    You can see that I have placed a few 3d locii to check that the "join" face is vertical. You can see them in the top-plan view. I've attached the VWX file.

     

     

    roofsvw.vwx

  3. 2 hours ago, FBernardo said:

     

    Do you want me to create a video showing how i usually do it? i think it's a lot easier to show than to explain in words! 

     

    But you are right the Roof "dormer" way VW uses is quite a gibberish in comparison with other tools that are quite easy to use and with all the mojo of easy to use philosophy!

     

    What kind of issues have you found with the Textures by class and using in the components? I use it this way and it seems so much easier and quick also works wonderfully!

     

     

    I think I mostly understood about how you draw them - thanks - so there is no need to make a video, although it might still be interesting to see.

     

    With the classes (actually it may not be related to textures as such) - the specific thing I noticed was:

    1. Viewing in OpenGL with "use textures" and "use colours".

    2. I assign a "material" class to each component, and each class has its own "fill colour".

    3. I then edited one of these classes, to change it's "fill colour".

    4. Then, viewing in OpenGL something strange was happening, the relevant component would sometimes appear with its "old" colour and sometimes with its "new" one. It would change when I shifted the view around.

    5. Changing the render setting for the roof face object from 'by component' to 'by object' and then back to 'by component' seemed to fix it.

  4. 43 minutes ago, FBernardo said:

    The way i've found to be easier to me is drawing the dormer from the walls and cut the roof where the walls are sitting and then add a normal window and a roof on top of those walls and join both roofs. Later i'll edit the walls as to how they're going to be in construction, so the bottom of the wall is going to be on the bottom of the main roof.

     

    Yes, having tried the dormer tool out a bit more now, I've decided it's not all that much use, except maybe if you want to show something indicative at an early stage.

    - as far as I can see, you can't go back and edit the window easily, because although it exists as a symbol, it's no longer a plug in object so you can't make adjustments to it in the same way that you would to a normal window-in wall

    - it seems that the only way you can adjust its location in plan is through typing numbers into the dialogue box in a trial-and-error kind of fashion, which isn't even updated live, so you have to keep closing and opening the dialogue to see if you have got it right yet

    - the controls themselves seem rather confusing, with various options to offset and so on, but little information about where the reference points actually are, how they relate to what points on the symbol, and so on.

     

    Even roofs/roof faces themselves (which I've not used a lot until now, but they do seem useful to an extent) are a typical VW jumble of confusing, inconsistent and anti-intuitive commands. And something weird seems to go on with textures and classing by component and so on.

     

     

  5. 13 hours ago, Robert Darden said:

    I created a dormer by dragging in the window into the roof in isometric view.

    However, I want to modify the window, but can't - the program only allows editing of a skylight.

    Please advise, thanks!

    When you get into the edit dialogue for the dormer/skylight, in the top right you can choose between dormer and skylight. It's not well worded - "edit dormer" implies it's a function to edit an existing dormer whereas really it should say "create dormer".

     

    364359033_ScreenShot2020-06-25at08_56_20.thumb.jpg.893a762e9890eb8a08a4f15a7f93c685.jpg

  6. I just tried creating a dormer window for the first time. I've not tried using this before.

     

    I ran into exactly the same problem as @domer1322 above. I followed all the instructions, including the create a symbol bit, which isn't properly explained in the user guides, and activated the symbol, and tried to insert it into a roof face. Nothing.

     

    I remembered this thread. So, reading it, yes, you have to *drag* the symbol from the resource browser. As identified above. But not stated in the VW documentation.

     

    Thank you @domer1322.

     

    It's absolutely dreadful, this. How to annoy and frustrate your users, for no apparent reason. It should win some kind of award for terrible design.

  7. Another thing that is a bit of an art ... and especially when you work in 3d.

     

    You measure the ground floor and the upper floor, and drawing each one individually all works fine.

     

    Then you overlay them and it doesn't. In 2d you could to some extent pretend it wasn't happening. Maybe you would bodge things around so that at east the staircase makes sense. If the proposed work didn't involve connecting the two levels in new places... it didn't matter too much that the chimneybreast on one level was 100mm away from the one below.

     

    Can't really get away with that in 3d. It'll show on the elevations at least. So you have to do a bit of "rounding", and decide which dimensions are the important ones, which might be the ones relating to bits you know there is going to be work done to. The alternative is to draw the walls as they actually are... not vertical. Which VW doesn't really like.

     

    I assume that point clouds don't make this any easier.

     

     

    • Like 1
  8. On 6/20/2020 at 1:31 AM, jeff prince said:

    @line-weight thank, glad you found it interesting!  My wife’s eyes kind of glaze over when I triumphantly present my latest work 🙂, so I post this stuff here for your enjoyment.  I also kind of hope the folks at Vectorworks are paying attention to this workflow.  It’s huge, usually with LIDAR, in aerial survey, environmental analysis, large scale construction monitoring, and infrastructure planning.  It’s gaining a foothold in design as well.  I used to hire a plane to do this kind of work, now I can do it with a machine that fits in my backpack.

     

    I agree with your comments on detail and accuracy, it’s certainly not survey quality work.  Part of interpretation and tracing revolves around knowing the construction type.  If you have something that is block modular, rectilinear, and built by a reasonably skilled crew... you can get within 1/2” in most cases 🙂. Having the knowledge about how things are built goes a long ways in quickly recreating things without measuring.  Architecture can usually benefit from a ground based scan and be highly accurate when required.  I do this mostly as a professional challenge for myself and to save time with data acquisition.  It’s pretty nice to be able to review the entire site visit from oblique aerial photography.  There is all kinds of stuff you miss when walking around a large site.  Plus, the wide aerial vantage point reveals patterns in the landscape that are difficult to perceive from the ground or on Google Earth.

     

    That handrail on the stepped wall at the end was pretty fun.  It was built off the drone footage and a walk thru video.  I measured it today just for comparison and to develop a construction detail should I decide to mimic it elsewhere.  The only bust was on the rebar pickets ( I faked it with a texture), height of the lower rail (Off by 1/2”), and connection details (couldn’t see).  I got the slope of the steps (block modular) and steel framing (Assumed standard profiles) correct.  20 years ago I would have struggled with all that because I didn’t have the needed experience.  Now it just flows during modeling.

     

    The drone I used on this was a 1st generation Mavic Pro.  I used to have an Inspire as well, but the lower flight time was problematic.  While the mavic camera is not as nice as the Inspire, it is more than adequate when configured correctly.  I probably have about $2000 into it with all the accessories (batteries, props, memory cards, camera filters, ipad holder, glare hood for the ipad, etc).  I fly it with my iPad for these kinds of jobs, so that’s an expense that should be factored in.   Doing it on a phone is okay for motorcycle videos, but on not on this kind of work.  I like to see the photos it is taken on the iPad so I can see if I got the focus and other settings correct.  That’s very difficult to do on the phone.  If you shoot 300+ photos of a site and find out they are out of focus when you get back to the studio, it’s heart breaking and makes digital mapping less accurate.  I unusually shoot two sets of the same photos, but with slightly different settings, as cheap insurance.  That’s where having lots of batteries and memory cards is a benefit.  Oh, I almost forgot the software for reconstruction, that can get pricey depending on what you use.  I bought the drone to take photos and video of my adventures and already had an iPad Pro for other purposes.  Only later did I develop a method for using it for my work due to a lack of aerial photography in the country I was in and having a lot of time for R&D with my employer.  If I didn’t have all the gear already and an interest in figuring this out, I would just hire one of the many companies out there to collect the data for me.  Drone based aerial photography is a cutthroat business in the western US.  There are a lot of hobbyist shooting real estate, they should generally be avoided because they usually can’t actually produce maps or engineering data.  If you find a skilled map maker who is reasonably priced, keep their number handy.

     

    hope it helps,

    Jeff

     

    There is certainly an element of art to surveying, and you become better/quicker at it the better you understand how the building type you are looking at is put together. You also get to know which are the really critical dimensions, and which are the ones where it really doesn't matter if you're a little bit out.

     

    Where I do most of my work, the block module is often a hand-made and hand-laid brick, but on soft ground with virtually no foundations so one of the things you learn is not to assume horizontal lines are horizontal! That said, you can often get pretty close by counting brick courses for heights.

     

    I'm keeping an eye on this drone surveying, to see if it's something that will become easy/affordable enough for me to start using in place of X hours measuring up manually. There is an engineer I have worked with who uses it a bit ... however some of his efforts have been frustrated by limitations on where and how high you are allowed to fly in densely built up urban areas.

     

    In fact what I'd most welcome becoming automated is the surveying of internal details... measuring up multiple rooms with similar but not identical arrangements, trying to get diagonals with furniture in the way, all that can be pretty tedious. Would be nice just to put a device in the middle and get a point cloud - but before starting to try doing things that way I'd want to be confident that VW can actually deal with it, and it feels a bit like we are not quite there yet.

    • Like 3
  9. @Boh Do either of the worksheets work OK when you want to include a drawing in an issue which hasn't had a revision since the last issue?

     

    For example, in "third issue B3" from your screenshots above, if issue 3 had included "elevations proposed" but issued again as revision B (rather than a new revision C)?

  10. 5 hours ago, Nikolay Zhelyazkov said:

     

     

     

    - Any feedback on what is expected from the worksheet reports is welcome and considered. 🙂

     

    Your proactive approach is appreciated.

    I am still on VW2018 but as soon as I move up to the latest version I will have another go at using this and be sure to bring some feedback here.

    • Like 1
  11. Looks a bit like the problems I was experiencing, that caused me to lose confidence in the reliability of this.

     

    It's a shame because it's at a "nearly works" stage. VW needs to provide some worksheets that have been subject to intensive testing, because the majority of users are never going to put this much effort into developing one for themselves.

  12. Thanks for posting that - really interesting to see your process.

     

    Especially your method of "tracing" the house in 3d.

     

    I don't think it would produce anything detailed enough for those of us on the architecture side who would want to do work involving the building - I would want something accurate within say 50mm - but it would certainly be useful for site context, neighbouring buildings, etc. And no doubt, technology will progress.

     

    How much did your drone cost?

    • Like 1
  13. Thanks for the replies @Luka Stefanovic.

     

    I'm particularly interested in the U value calculations for windows, because this is something that is actually often very difficult to get out of window suppliers, so frequently I am trying to make a judgement on the best arrangement without proper information. So it could be a useful design tool for me - of course, assuming that I have confidence that the calculations it is doing are realistic. I'll take a close look at it some time.

     

    I'll also try having a look at that webinar.

  14. 16 hours ago, architectmark said:

    Hi @line-weight

     

    Luka may help more on this but below are a few comments,/answers

     

    *The workflow is up to you, the seminar goes through what I think is ideal but feel free to improvise

     

    * Q1 Multiple mullions (muntins) are poorer thermally - the less the better

     

    * Q2 Average out the volume in the block

     

    Q3 - unsure 

     

    I wouldn't use this for Building Regulation submission - SAP only for this

     

    Mark

     

     

    Thanks for your reply.

     

    On Q1 - yes, I understand that multiple mullions are poorer - my question was whether Energos' calculation for the window takes this into account - in other words will it give me a worse U value for a window with multiple mullions than it will for one of the same overall size with fewer mullions.

  15. Thanks @Mark Stephens for posting that; I've just watched the video.

     

    This is the first time I've got around to sitting down and understanding at a basic level what it does and how it works.

     

    I can see an immediate problem in applying it to most things I design, which is that if I understand correctly it's reliant on using objects created by the slab, wall, roof and door window tools. But my real world experience of vectorworks is that most of these tools are no use for anything but early design stages. I might start out using the door/window tool but as things progress many of these get swapped out for custom modelled elements that are a closer match to the thing I actually want. Even walls, perhaps most of my building model will use wall objects but often there are bits that are made up of solid-modelled elements because they can't be generated by the wall tool. I hardly ever use the roof tool; it's way too limited to create what I want. I do use roof faces a bit, and it looks like Energos can recognise these.

     

    So my first question... either for @Luka Stefanovic or @Mark Stephens or anyone else: is it a feasible workflow, to have my "real model" exist somewhat independently of my "energos model"? By this I mean that perhaps the energos model sits on its own layer, and I can copy-and paste things into it from the real model, but where I have a custom-modelled window in my real model, I place a "near-enough" equivalent, produced from the window tool, into the energos model. And where I have some kind of complicated roof geometry I make a near-enough simplified version out of roof faces to exist in the energos model. For example.

     

    Some more specific questions:

    1) I was interested in the bit about it being able to do u-value estimates for windows, based on me telling it the glass spec, frame type, etc. Does this take into account the number of framing members and their sizing or does it just provide a generic U-value for a window with overall size of X width and Y height? In other words, where the glazing U value is better than the framing U value, will I get a better result from a window that it just one perimeter frame and a big frame of glass, compared to a similar sized window which is subdivided into multiple casements and which has a different frame:glazing ratio?

     

    2)If I have a "space" which has a non horizontal ceiling, and/or a stepped floor level, can it cope with that, or do I have to give it an extruded form with approximately the same volume as the real space?

     

    3)In the example in the video, where the roof is a pitched one with hipped ends... does it assume the insulation layer is at a flat, horizontal ceiling plane around eaves level or does it assume it follows the pitch of the roof - ie with  a "warm" loft space? Or can this be defined in settings?

     

    Aside from these questions I'd echo the concern in some previous comments about the extent to which its output shows its workings - this is important if they are to be used to support building control submissions (UK perspective here) but I'd also feel more confident in them if I could see how they are arrived at, to satisfy myself that it wasn't making any wrong assumptions that I did not realise about.

  16. 8 minutes ago, herbieherb said:

    I'd rather hear what the Vectorworks employees have to say about the issue before I invest a lot of time to work around it in the script.

     

    I'd be interested to see what they say too; I don't know if this should be filed as a bug.

  17. 2 hours ago, herbieherb said:

    This is really weird. But I can reproduce it here. It's not the script. It already gets the different sized images from Vectorworks. So I can reproduce that too. The exact same viewport with the exact same content rendered and then converted into an image almost always results in a slightly different image size. Tested with ~4960x3510 pixels I have variations of ±1 pixel in Y-direction and even ±9 pixels in X-direction.

    That's interesting, so you are getting it even if the content hasn't changed? I had assumed that it was connected to me changing something in the geometry that the viewport is looking at.

     

    It's a bit of a problem if you are exporting the images to somewhere else, with the intention that the renders can be updated, and then older versions in the target document simply replaced with the new ones on the assumption that they will be the same pixel size.

     

    I may have to test whether the same thing happens if images are exported in other ways.

  18. I'd be interested to hear how you get on using it "for real".

     

    If it seems reliable I'd reconsider trying to use it.

     

    As it happens, independently of this title block thing, I've decided just to start calling the first version of any drawing "revision A", because it seems to reduce the potential for confusion in general. If I ask someone "do you have a copy of drawing 209" then the answer might be "yes" whether they have 209 (unrevised) or 209 revision A. If I ask them whether they have a copy of drawing 209 revision A, then it's unambiguous.

  19. @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?

    • Like 1
  20. 29 minutes ago, Boh said:

     

    @lineweight what is your workaround on this?

     

    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)

     

     

     

     

×
×
  • Create New...