Results 1 to 3 of 3

Thread: Presentation Argument

  1. #1
    Revit MEP Moderator mjdanowski's Avatar
    Join Date
    2007-03
    Posts
    890
    Login to Give a bone
    0

    Default Presentation Argument

    I was recently readying Kyle.Bernhardts blog over Here about a well trodden subject of analysis vs. presentation within Revit MEP. The subject dealt with a request for more customization with the presentation of Revit data on sheets, and then Kyles response that such "standards" customization is not the current priority of the development of this product.
    Now to a large extent I agree with this response, we shouldn't be reinventing the wheel here. AutoCAD is an awesome tool that does its job quite well. However, we do not want to un-invent the wheel either.

    I view Revit as an all inclusive design tool that lets us input data from multiple places, stores it in a central location and then makes that data available for analysis by multiple people. Then after that analysis is complete, the data can be linked to drawings with little or no coordination.

    The problem I am seeing a lot is that I am having a hard time getting the latter part done there, and I will explain why.
    For our pilot project we did all of our schedules in CAD rather then Revit. Electrically, the panel schedules were (are) useless and they could not be put on sheets. Because of this, we had a massive coordination issue between dynamic circuit organizing of Revit and the manual circuit drafting of AutoCAD. On our regular schedules we found that we could not properly express dynamic data from the BIM model into schedules because of formatting issues with the data, therefore again everything had to be transfered and coordinated with CAD. I hate to use this example of schedules again as I have beaten it to death in other threads, but it is the best example of where presentation shortfalls directly impact work load and undermines the advantages of Revit. I guess this is my point here, that when the presentation issues are too much of an issue, it will force people to retreat back to other programs which in turn totally defeats the purpose of what Revit is supposed to be.

    Anyway, in conclusion, yeah I agree that the development team should not be beating their selves over the head to make fully customizable duct and riser symbols, but at the same time the customizable presentation of BIM data is an important part of the needed functions of this product for its users. We need to be able to show the data we want, how we want it and I think this is being pooled in a lot with the stupid nitpicky stuff which, although would be nice to have, isn't really needed.



    Sorry if this is a bit rantish/makes no sense. Its the end of a Monday after a long weekend and I may be a little coherent. (anyone who spent the day/night at McCarren knows what I am talking about)
    Matthew Danowski, PE, LEED AP BD+C
    Project Electrical Engineer
    Baltimore, MD

  2. #2
    All AUGI, all the time kyle.bernhardt's Avatar
    Join Date
    2005-10
    Location
    Inside the Factory
    Posts
    705
    Login to Give a bone
    0

    Default Re: Presentation Argument

    Matt,
    First, nice meeting you at AU. Second, I love that you have the passion about this to raise this point.

    I think I'm guilty of being too black and white, even though I tried to be as clear as possible with my post on this subject. I think you might have interpreted my "don't chase the doohicky" message as "limit information display". I recognize that the nature of my post would stir the pot a bit, but I think that's really necessary for today's market to make everybody think about why we do what we do, and if it's really necessary.

    What you've identified here in your example is not a case where you're chasing a particular office standard. You can't convey your design intent, and thus you're forced to use a hybrid workflow. While this solved the problem for you, I think we both recognize that this is not the long-term solution for you. This is exactly the type of feedback we need so we can shape our output capabilities to convey the design intent sufficiently for your needs.

    You've been incredibly articulate about the problems of the current panel schedules in previous threads, and that has not gone unnoticed. These objections have been based upon practical obligations about the current state of that functionality, rather than a particular glyph or doohicky that you need on the schedule. We need to investigate these issues in the short-term, not the long-term, as they relate to your ability to leverage the tools that exist inside the box.

    I hope that helps you to be clearer on our purpose here and our focus.

    Cheers,
    Kyle B

  3. #3
    Revit MEP Moderator mjdanowski's Avatar
    Join Date
    2007-03
    Posts
    890
    Login to Give a bone
    0

    Default Re: Presentation Argument

    Yeah, I hate to beat the dead horse with the panel schedules, as I know you are well aware of the problem, however it always makes the best example of how formatting and the "look" of things can greatly affect issues such as the BIM work flow within Revit.

    I don't think panel schedules are the only instances of this either, though. Scheduling in general is quite limited in many respects to the topic of formatting, and there are many instances on my schedules where I sometimes need to use workarounds with "dead" parameters for the sake of presentation because of the way the "linked" parameters are hard code formatted. Feeders, as I mentioned at the AU lunch, are the perfect example of this.

    Either way, I think there has always been some confusion over this touchy subject, and seeing how a lot of posts seem to revolve around this topic around here, that a clarification of your definition of "design intent" and our definition of "design intent" would be a good thing to dwell on.
    Matthew Danowski, PE, LEED AP BD+C
    Project Electrical Engineer
    Baltimore, MD

Similar Threads

  1. Bad argument type issue
    By tntdraftsol in forum AutoLISP
    Replies: 13
    Last Post: 2014-01-10, 06:11 PM
  2. Help with Defun Argument
    By jeff.richards in forum AutoLISP
    Replies: 4
    Last Post: 2011-08-03, 04:23 PM
  3. Bad Argument
    By omorah in forum AutoLISP
    Replies: 2
    Last Post: 2009-03-13, 05:03 PM
  4. use variable for command argument
    By anycganycg in forum AutoLISP
    Replies: 0
    Last Post: 2007-11-02, 08:42 AM
  5. bad argument type: FILE nil, help plz
    By jgroh in forum AutoLISP
    Replies: 11
    Last Post: 2007-10-30, 01:15 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •