Jump to content

mgries

Member
  • Posts

    135
  • Joined

  • Last visited

Posts posted by mgries

  1. On 4/8/2019 at 3:28 PM, zoomer said:

    It is an anomaly that when your Symbol content sits all on Class none,

    when you insert the Symbol, all its content will switch to the Attributes

    of the Class the Symbol was inserted on.

     

    While if the Symbol content has any other Class assigned than none,

    it will behave like any Symbol in VW an keep its own Classes Attributes.

    OMG...Is THAT what's going on?! Thank you for clearing this up for me! I had learned that setting class to "none" inside a symbol allows the overall symbol class to control display. But often this does not work. Now I know why...

     

    Honestly, this really needs to be fixed! It is far too often the case to have some text inside a symbol set to a separate "...IDEN" class, so the text can be turned on or off separate from the linework. This shouldn't get in the way of using the "'none' class gets overwritten by symbol class attributes" rule. 

     

    Matt

  2. I'm getting a new problem related to Space Tool upgrade.

    I'm using the old version space labels in which I've created some sub-classes for the text. This allows me to independently turn on/off extra data about the space (such as the Area, Room Dimensions, or Occupant Load). In the screenshot I've attached, for example, only the top 2 lines of text are on the none class. The last 3 lines of text are on unique IDEN-DAT1,2,...etc. classes. After updating to SP3, all of the space label text is permanently displaying regardless of on/off visibility of these sub-classes. Is this supposed to work this way now? This had been a very simple and consistent way for me to control label info.

    Please help! This has wrecked my drawings!

    thanks,

    Matt

    1485703316_ScreenShot2019-03-27at10_49_14AM.thumb.png.d3f3198039f3fe8c0444e3710c321937.png

  3. I'm getting a new problem related to Space Tool upgrade.

    I'm using the old version space labels in which I've created some sub-classes for the text. This allows me to independently turn on/off extra data about the space (such as the Area, Room Dimensions, or Occupant Load). In the screenshot I've attached, for example, only the top 2 lines of text are on the none class. The last 3 lines of text are on unique IDEN-DAT1,2,...etc. classes. After updating to SP3, all of the space label text is permanently displaying regardless of on/off visibility of these sub-classes. Is this supposed to work this way now? This had been a very simple and consistent way for me to control label info.

    Please help! This has wrecked my drawings!

    thanks,

    Matt

    1485703316_ScreenShot2019-03-27at10_49_14AM.thumb.png.d3f3198039f3fe8c0444e3710c321937.png

  4. Is it a known issue that hidden line sketch mode (I'm using Section viewports in this case), produces seriously unstable results? I've run into a few different ways it fails to draw the expected result:

    1. The most common issue is that it displays everything in the view, but sketch mode does not appear to be activated.
    2. In some cases, the line work initially displays in sketch mode, but then after drawing annotation in the viewport, sketch gets deactivated. To be clear, sketch is still checked off as the desired render option, but the viewport behaves as if it's been turned off.
    3. Other times, all of the lines "beyond cut plane" simply don't display at all. Silver lining here is that for whatever reason, this seems to reactivate sketch mode for the cut plane elements and the annotation.
    4. There's also cases where the model line work maintains sketch display, but the annotative layer displays without sketch. I've also gotten the reverse situation, where only the annotation was displaying in sketch! It's really all over the map.

     

    There does seem to be one way to control this situation (at least it's worked so far). I discovered that by setting the line style of objects beyond cut plane to "use original" in the advanced properties, I can stabilize the sketch render setting, and both model and annotation maintain the correct display. When this is overwritten with a single class, all bets are off. Unfortunately, using the original line style of each modeling object requires a lot more work than being able to quickly set all lines to the same weight. So this is an unfortunate work around to have to accept.

     

    Thanks,
    Matt

  5. @sbarrett, could this be reworked so that the "A" polygons were on one design layer named "A", and the "B" polygons were a second design layer named "B", and then the resultant geometry gets placed on a 3rd layer? I'm thinking about how this may be applicable to creating and defining exst/demo/new surface areas on a site plan.

    Thanks,

    Matt

  6. I like how this method ensures that the benchmark gridline updates with any changes to story/level data. That's pretty smart. Regarding issue with graphics, it's already very easy to apply the benchmark elevation tool directly to the annotative layer of the Section viewport. Why not just have the grid datum slab in the model w/o the anno, and apply the anno in the viewports as necessary? This carries with it the same benefit as with the data tag trick. You get to put the tag wherever it's needed. If you put it in the model, it's stuck in one location, and is only really useful for the full view drawings. You'll have to re-annotate your benchmarks for any enlarged or partial (cropped) drawings.

     

    matt

    • Like 2
  7. This is FANTASTIC! It works!

    I'm calling this the gridtangle tool!

     

    9 hours ago, Hans-Olav said:

    It can be enhanced by classing the horizontal and vertical gridlines 

    one question, what extra "enhancements" are you getting from classing the horizontal and vertical gridlines? Is this so you can prevent a horizontal line from appearing in the section cut if you crop above or below the extent of the gridtangle?

  8. 13 minutes ago, line-weight said:

    I think that it's top-plan that may be the redundant part. I'd be happy to see the back of top/plan, alongside section viewports (including horizontal sections) being improved and made a bit more clever/customisable.

     

    I did a thread on this subject a while back:

    Yes, i agree with your assessment of top-plan view. It seems like it might be slowly going away. Looking at the advancements to symbols in 2019 (2D views), including more control using detail levels, it's more about individual elements having their own planar display settings, which could be paving the way to eliminating a global top/plan paradigm in favor of a 3D model paradigm (w/ object based 2D view overrides). AutoCAD was more like this, and I must admit that customizing display properties for every little thing was quite overwhelming  

  9. On 9/28/2018 at 10:50 PM, Pat Stanford said:

    'Space'.'Proposed Area'
    'Space'.'Area'
    'Space'.'Gross Area'
    'Space'.'GSA BIM Area'
    'Space'.'Custom Area'
    'Space'.'11_Proposed Area'
    'Space'.'11_Area'
    'Space'.'SubtractionArea'        TEXT
    'Space'.'SubtractionAreaNum'   REAL
    'Space'.'MeasuredNetArea'        TEXT
    'Space'.'MeasuredNetAreaNum'       REAL
    'Space'.'11_Gross Area'
    'Space'.'EnergyArea'
    'Space'.'EnergyAreaFac'
    'Space'.'SpaceCommon_NetPlannedArea'
    'Space'.'SpaceOccupancyRequirements_AreaPerOccupant'
    'Space'.'SpaceThermalDesign_BoundaryAreaHeatLoss'

     

    @Pat Stanford, you can add =AREA to this list!

    After reporting my bug, tech wrote back to let me know they're on the case. They also offered a few alternatives to try, one of which was "=AREA". Works like a charm!

  10. I know this is a bit of a tangent, but I'm having problems in 2019 with my drawing label, and can't find any thread on the forum directly discussing  it. My drawing labels aren't synching to the viewport OIP fields anymore. I have to go into the annotative layer and edit the information directly. This is occurring on viewports where the drawing label is created automatically, which prior to 2019, always synched up with the Drawing Title and Drawing Number OIP fields. Is anyone else experiencing this?

     

    thanks!

    Matt

    • Like 1
  11.  

    On 1/10/2019 at 3:58 PM, line-weight said:

    One way I have tried doing this is to have the main floorplan in top/plan view as you have, and then level(s) below that viewed in hidden line as a top (not top/plan) view. This done with two viewports, cropped around each other. A bit of a fiddly workaround though. At present I am experimenting with abandoning top/plan altogether and doing the whole thing as a horizontal section...that is kind of another story though.

     

    I'm kind of liking line-weight's direction...

    I think if you peel this onion away enough, you'll come to the brave conclusion often voiced throughout this forum, and that's the need to do away with design layers altogether.

     

    A pure BIM experience really only needs:

    1. stories (available)
    2. horizontal section and cut planes (the later just being the story default setting for the former) (available)
    3. option to view a set distance (# of stories) below the cut plane. (available)
    4. option to to configure the horizontal section at the cut plane as a Top/Plan view. (available?)
    5. option to control display of cut plane classes and display of beyond classes separately (available)
    6. option to control display of beyond classes in their own Top/Plan representational mode. (not available)

     

    I haven't messed around with the horizontal section yet, but from what I understand, the functions represented by 1-5 are currently available? Actually, I'm not sure about #4. Can the horizontal section be viewed in Top/Plan mode at the cut plane? 

     

    Am I wrong in suggesting that all of these display issues might be a bit simpler to control if we didn't have to deal with the merging of two somewhat redundant organizational/display paradigms?

     

    Matt

  12. 16 hours ago, Pat Stanford said:

    Are you sure all of them are scaling by exactly the same amount?  If so, then there is something else going on. If they are by different amounts, I would bet it is an effect of rounding somewhere in the floating point routines.

    yup,

    Using the factor 92903.384, I can get all the correct areas to show up. I need to revise my initial statement though. It's not precisely  92903.384. The corrected values are only correct to the 1/100th decimal place. But to your point, whatever the fudge factor is, it seems to be consistent for all values. 

  13. This issue has always bothered me. When all the good options are work arounds, especially work arounds that require redundancy (duplicate classes, stacked viewports), things are going to get sticky. I've used both strategies, and in an office with multiple users, it's inevitable that someone else will mess up your stacking order, or delete one of the viewports, or not know to turn off/on sub-classes. They'll hate you. You'll hate them. Eventually, someone will eat your food in the fridge. Was it an accident? You'll never know for sure...

    It's better if we just get the software right!

    • Like 2
  14. On 12/28/2018 at 10:05 AM, Pat Stanford said:

    Did you ever get this figured out? 

     

    The 92903 number is about right for conversion of mm2 to ft2.

     

    Check the Area Units in the Document Preferences.

    No, I'm still stuck with this. The document area units are set to sqft. Also realize that when using 'Space'.'11_Area', the area is reporting correct. So the units don't seem to be the issue. It's only when using 'Space'.'Area' that everything it goes haywire.

  15. @cberg and @Jim Wilson

    Does this bug fix also address the issue where the spaces all get reset to the style default info, whenever an existing space is switched to that style? I'm having this issue (and some similar style related implosions) too. 

    On 12/6/2018 at 1:03 PM, Liene Cikanovica said:

    - Applying Space Style to an existing space it change all space info (Space ID, Occupancy etc) to default Space Style info, though the parameters in those fields are set By Instance. Besides it changes Space class to 2D Boundary Class not to Space Object Class which is set in Space Style. 

     

    Thanks,

    Matt

  16. I'm encountering a different problem related to calculating space areas, and have officially run out of brain cells on this. This seems totally screwed up to me, but I'm new to 2019, so maybe I'm missing something here...

     

    When using 'Space'.'Area' in my worksheet, the values are getting multiplied by precisely 92903.384. See screenshot.

     

    When using 'Space'.'11_Area', the area is reporting correct however, so there's no issue with my units or anything like that.

     

    I'm trying to tabulate total areas of multiple spaces, so I need to be able to apply the SUM function to these values. The worksheet will not SUM the space areas when delivered via text field, so I need 'Space'.'Area' to work for this.

     

    Also, can someone please tell me how the new database header option called "sum values" factors into any of this? Clicking this on or off doesn't seem to do much, other than add a little 'plus' symbol at the header.

     

    please help me!

    ...and thank you!

    Matt

     

    space_areas_WTF.png

    space_areas_WTF.png

  17. Hi @Alan Woodwell,

    Great job on these marionettes! I'm trying to use a chunk of the V002 script (just slab and walls) in VW2019. I'm pretty much a novice with marionette, so I'm running into few obstacles I'm hoping you can help me with...

    1. The 1st issue I'm having is that when the walls get created, the insertion options associated with the wall style I'm using are getting overridden. Instead of the height being bound by story levels, it reverts to layer elevation. And instead of the wall object coming in on a specific class, it reverts to the current class. As mentioned, both of these parameters are hard wired into the wall style I'm using, as insertion options, so I wasn't expecting the marionette to override any of this, and can't understand where this is happening.
    2. In addition, regardless of the class the objects come in on, the whole thing comes in as a group within a group, and with the opacity overridden to 95%. This is a complete riddle to me. Any idea what going on here?
    3. Finally, is there any quick way to spread out 2016 nodes when the file is transferred to 2019? Because of autoscaling introduced in future releases, the 2016 marionette nodes are all bunched up, sitting on top of each other.

     

    Thanks,
    Matt

×
×
  • Create New...