nrkuhl

Member
  • Content count

    108
  • Joined

  • Last visited

Community Reputation

8 Neutral

About nrkuhl

  • Rank
    Journeyman

Personal Information

  • Occupation
    Architectural Designer
  1. This sounds like something I've run into before with linework that I copied from an imported dwg and turned into blocks for details. However, I don't remember actually doing anything to fix it and it might have just been fixed by a subsequent update. What version are you on?
  2. There are a few tutorials on this kicking around the web. It's a process, as you have to make a symbol and then insert it and then fight with roof related dialogues. In my office we just make a hole in the roof and then draw everything else as an annotation (i.e. a simple outline for the frame in the roof plan, full details, or often nothing (in the case of sections at smaller scales). The last time I really looked into it, there wasn't enough control to make it worth while, so it's better just to manually draft the thing.
  3. Yeah, I've found the supposedly associative objects work intermittently at best (dimensions seem somewhat randomly associative.)
  4. One of the reasons that I've held off on updating our office is that it sounds like titleblocks work so differently in 2018 that I'm going to spend half a day fixing ours.
  5. If you place them on a design layer they will update - they just won't look right in all (any) views. That's why I'm currently using the mixed workflow I described earlier.
  6. I believe we've had this problem post-SP3 update.
  7. It would be really great if objects or components of plugin objects could be set to change their display settings based on the scale of a viewport. For instance, on my general plans, I don't need to see shim gaps for doors and windows. But, on plan details, it would be useful to see the shim gaps. Similarly, I don't want shim gaps on my 1/2" scale elevations, but I do want to see them on my 3"=1' details. This could also be applied to wall components: at 1/16" scale, I don't need to see wall components, they just end up lumping together into a weird heavy line. If I'm really ambitious, I want to have this as a live feature in linked to zoom, and also controls the available snaps: If I'm at 200% zoom, then please, show me all wall components and let me snap to each of them individually. If I'm at 20% zoom, show me walls as a solid piece, where I only snap to exterior or interior vertexes / endpoints.
  8. Yeah, I've been setting one reference elevation in the design layer that sits on my first finished floor. I then manually draw the markers I want in elevation viewports, and set their control points to land on my reference marker. It's not great. I haven't messed with using them in design layers extensively, so there might be a way to get them to work, but they'd only show properly when your view is to the same view you set them in or the mirrored elevation.
  9. As folks have pointed out, the elevation benchmark is the tool that sort of does this. It seems to get weird graphically when used directly in design layers (I was just messing with it yesterday). It definitely doesn't work the way you think it should if you've used the equivalent Revit tool.
  10. @DOVyou have to draw them in manually in your annotation layer.
  11. You shouldn't need any metadata for photogrammetry - all the info is based on the photos, you just need enough photos from sufficient angles (at least with the applications I have experience with)
  12. I did some limited experimentations with photogrammetry via an entry level DSLR a year or two ago using specialized software that I convinced my school to get me a license for. It's not a particularly straightforward process, nor did it generate particularly useful geometry at that point. There's no reason at that stage I couldn't have done it with smartphone photos. Basically every camera on earth at this point has sufficient resolution and sensor size for photogrammetry at this point. The issue is (as others have said) getting it to useful geometry. Photogrammetry is TOO accurate in my experience so far for easy architectural use/and it can't distinguish between objects. And working with point clouds is somewhat difficult. I was attempting to use it for site surveying a historical site in Malta where I had limited time on site and no ability to return after an initial visit. I ended up doing the surveying I needed manually and using the photogrammetry as a reference. Fortunately that was a school project so it didn't matter when I fudged things to deal with inconsistencies. I know some archaeologists have been using photogrammetry for documenting excavated objects for a while (which was my initial introduction to it). They seemed to keep the resulting models as records that lived entirely in the specialized photogrammetry programs they used - I have no idea if/when they were extracting that data to another modeling program. I did not have a chance to probe that too much, as I was only onsite with those guys for a few days on a somewhat remote site in Peru.
  13. Nah, BIM is "just" linking a database to your objects. More data heavy than graphical scripting, sure, but I'm not convinced it's particularly difficult from a programming standpoint in a program where every object already has a unique ID. The issue for me is in fundamental work flows: having drafted in both VW and ACAD professionally, 3D is bolted on. Working in 3D in a native program is a vastly better experience. I'll gladly grant you that command line based programs like Rhino have a steeper learning curve, but in the long run you'll produce much faster as well than in something hotkey or icon based, and the ease of setting construction planes and the vast capabilities of such a resource light program are really impressive (I've run Rhino on an ARM based Windows tablet in the past, with a totally reasonable experience). Going back to BIM and Parametric modeling though, VisualARQ (rhino's AEC parametric plugin) is already better at some things that are basic to the workflow: for instance, I can have multiple buildings with separate stories in a single file, without the level settings interfering with each other. Magical. It definitely isn't professional production ready, but it's good enough that I use it personally for my master's projects, while griping about the software that I'm paid to use on a daily basis.
  14. I use VW at work on a Mac, and sometimes work remotely at home on my PC. The overall experience is way better on the Mac version. The UI feels more polished, and the program as a whole is much more stable. This is in spite of the fact that my work computer is somewhat underpowered for VW and my home computer is significantly more powerful. Files are totally interchangeable. I used to work in theater as a tech director, and all my lighting designer friends run VW on PCs and hate it. That said, I really dislike the Mac experience as a whole, and the hardware is overpriced and underpowered. I actually also somewhat despise VW (though I'm not sure Revit is any better, just differently dumb). I dream of a day when Rhino's BIM / parametric plugins are fully production ready.
  15. We've had some issues with this as a result of VW crashing while people were working on shared projects. The only solution I found was to "save a copy as" from one of the working files to a regular VWX, then turn that file into a new VWXP.