Jump to content

Samuel Derenboim

Member
  • Posts

    471
  • Joined

  • Last visited

Posts posted by Samuel Derenboim

  1. 5 hours ago, matteoluigi said:

    another issue would be referencing stories. I can imagine that there seemed to be no more need, since project sharing.... however, project sharing imho doesn't totally replace referencing...

     

    We haven't implemented that yet as I've head many complaints about projects not getting saved, problems assigning layers, etc...

    How is your experience with sharing a single file with multiple users?

  2. I came across this problem recently and I think adding these two functions into tags would be the solution. Let me explain :

     

    There are numerous times when we as professionals need to provide information on construction documents that reference a specific element inside a unified workspace. I have been trying to unify various different code references to a single type of space object reference system without re-creating the their ID's from scatch all over again. Let, for example, take building code and lighting areas.

    1. For building code - in order to analyze any spaces, i have come to the conclusion that a space would be described the envelope the building code dictates. In commercial spaces, this can be resolved by creating a space of all tenancies into the design layer, or into another design layer overlaying the plans. However, this is where the challenge comes in. Let's say you need to calculate the number of fixtures (i.e. takeoffs) by space. Or more importantly, let's say you need to provide a tabulation of the individual spaces for energy code - note by tenancy, but by rooms. What do you do?

    a. Option 1 - provide a single space for every room. That is the easier solution to showing on a worksheet the number of objects in a room. But, what if you also want to use those spaces to calculate occupancy for every tenant for the building code? You would essentially have to provide a record tenancy for every room that is in said tenancy space. However, for buiding code purposes, you would eliminate the ability to create a unified tag that summarizes the occupancy for the entire tenancy. Instead, you would only be able to do it room by room. Overall tenancy would then have to be on a worksheet level. Unifying and combing different elements like building code, energy code, zoning, and program would be easy on the one hand, on the other, checking the number from a plan examiner standpoint - would be a nightmare - the worksheets would be tremendously long.

     

    b. Option 2 - provide an overlay of spaces governing their own functions. If you need to provide an overall area for a space in building code - and given that the space would provide the area, it is easy to calculate the number of people for that tenancy. If you need to show the number of fixtures for each room, another space overlay would be created that can summarize the number of symbols and what symbols are in that particular room. The problem becomes - room id's. Tenancy would have one id. Space by spaces would have another, and there is no way to link them - except for location in space by ID and location in space by Name (as the function used in worksheets). This would ultimately join the complexities of different spaces that need to be shown on various drawings into a single coherent package - because these spaces ultimately overlap each other. Tags - is something that can be shown on drawings automatically, and adding just those two function would prove to be very useful especially when overlaying and unifying many different elements of construction drawings.

    • Like 1
  3. I don't know if this was proposed earlier, and if that's the case, just putting it up again. Wanted to request the ease of importing stories and levels from another file, or as a template, or choose to import part of stories from a different file more easily. This is especially the case if a referenced file uses stories, but the annotation file requires them to be added once more.

    • Like 1
    • Love 2
  4. Thank you  @Pat Stanford

     

    Not sure how a script would work if there are a number of database rows that would be generated for the number of records in the document per column. It's not simply a summary of one item in a database row. If that was the case, maybe there can be some kind of field entry into a worksheet that describes the criteria and the record and field information summary you are trying to pull out. My hunch though is that that information would be summarized in one table cell. (unless I'm misunderstanding something)

     

     In this case, a column could generate multiple records, maybe even dozens, the only detail is the output of database rows that it would be limited to a specific number of columns (or simply just that column).

     

    The only way (I think) it would work is if a column had a similar hide feature for database rows that would function like new type of database header for that column, or a series of columns. That way, that dummy column can set the database criteria to be pulled out and the column limit (in case you wanted the criteria to control multiple columns rather than just one). Once you set that information, then you can generate and populate the record and field name call outs in the database row header just like you normally would in a worksheet. The only difference is, it limits the information to only two columns (or the number of columns that you specify limiting the database row criteria to be populated) 

     

    See below for a diagram :

     

     

    image.thumb.png.7cca5a9ab858f372792d2f82abb872ad.png

  5. Good afternoon everyone!

     

    @ericjhberg @lgoodkind @twk @EricK @Pan.Gad @jg@swcm 

     

    Why cannot we do the same thing, only with the datatag tool? Same thing, but flexible in the way the output is written. 

     

    The only problem - the current datatag tool cannot callout elevations, Z distance from elevations, and levels in stories (which is what you want). 

    The flexibility of the datatag tool is that you can arrange the information any which way you want without using the stake datatag information. 

     

    The stake tool is only useful in this case if you were to use GIS information, is this something that's also integrated into the workflow?

  6. @Pat Stanford 

    If a number of objects have a different orientation, it would leave all the other records empty that are in the latter fields. 

    So when callout out a record, you can only call one out at a time since a single object can have one record. So 2 objects cannot be in the same database row, hence the request for a database column with a separate database query. 

     

    For example, in the chart above calling out objects currently would look something like this : 

     

    image.thumb.png.6d623f40a44f3b2c362e849dc2b29e23.png

     

     

    each row is a database row, and can be applied to a single record. In this case, the record is north, west, east, etc... If it fills up only that row for that specific information, all other orientations are namely 0, and the summations would need to be charted differently, not withstanding the fact that the chart itself would be 4 times larger than it should because a database row cannot describe two different objects at the same time in a single row

     

    The example that I'm requesting would look something like this

     

    image.thumb.png.ef1d8ee24c8fd2c8e90adcbdb9fd08d2.png

     

    The database columns would function the same way callout out record information in table rows. The only difference is that the information can be cut off at the column level as well, that way, multiple objects with same database records for ID's but different values for orientation can be described on a single row (in this case it would be 4 database columns). It can additionally be handy if the records were different, and you needed to multiply, add, divide two different objects with different records on a single worksheet row. The latter would get very tricky because I don't know how the worksheet would react if one database column had more rows than another database column, and consequently aligning information could get tricky or tedious. (In essence though, it would be very useful in summaries of database rows, that way information with relative records is summed up)

     

    Hope it makes sense 🙂

  7. In order to align several databases along the same row, I believe we need to provide the ability to reference a separate database formula for different columns (using if statements). It could prove to be useful when managing different datasets that don't have related record information, or have the same record information, but isolated extraction methods.

    Example below illustrates something that currently isn't possible in vectorworks that is driven by databases because each orientation would require a separate database callout with the rows controlled by an if statement. If they were controlled only by one datase record request, every orientation would be blank and distributed onto later database rows (rather than the same database row). Is something like this possible?

    image.thumb.png.0a95957166d4865b6e2154b404499935.png

  8. On 7/7/2020 at 4:27 AM, gester said:

    @Samuel Derenboim 

    yeah, the polish certification document for the usage permit is formally standardised.

     

    - the first page is the overall information of the building with the graphic display of its energy performance (enclosed is some older version before the tightening of the energy performance demand - the change is in the scope spread on the graphic ribbon - in this case the building doesn't comply with the requirements). the software can handle dwg imports, but not ifc models, so the calculations take approx. 90-95% of the creation time (a pretty cumbersome task, especially calculating walls and openings, depending on geographic directions), the rest is the adjustment of the installation systems. energy calculations are similar for all energy certification standards, what matters is the overall result, regarding particular requirements.

     

    - second page is the description of the installation systems

     

    - third page is the calculations with improvement recommendations

     

    - the last page is the guides and notes - usually left as it is.

     

    the certificate is valid for 10 years, and the creator is liable for any claims within this period. there's also a possibility to buy insurance for this scope, along with the professional designer's insurance.

     

    is it somehow similar in the u.s.a.?

    hth,

    rob

    certificate1.png

    certificate2.png

    certificate3.png

    certificate4.png

    Our requirements have been much more rigorous as of late. There have to be areas for every fenestration and opaque wall face on the building per wall type for every floor each with their designated orientation (east, west, north, south). If we need to do something like performance values, we have to do average UA calculations for opaque wall types and total average UA calculations for total building areas in order to determine performance. The math itself is quite easy, just extracting the information out of energos and Vectorworks is the challenge.

  9. Gester, thats interesting. I know that you are regulated by a different code in Europe (could be something like PASIVHAUS). Do those 4 sheets include calculations, areas, and visual summaries of the building? I'm sure there are performance approaches and prescriptive approaches to energy compliance / performance. I know here in America, the IBC (international building code) shows 2 different requirements that allows for flexible wall design based on a performance method, and a typical wall design based on a prescriptive method. Which one does the Polish legislature require from you?

  10. I've been having a great amount of trouble getting geometric information from polygons due with respect to different orientation. Among those options are :

    #ΔX#, #ΔY#, #ΔZ#. Upright polygons do not display length, height or width unless they have a thickness. Sometimes it is easier to calculate areas of surfaces rather than geometry because of the way it can be pulled from larger geometry

  11. Good afternoon,

    After tinkering around with the data visualization feature, it has become extremely hard to tag objects like walls or windows that are behind the desired objects to be viewed. In this case, in the image below, I am trying to tag walls, curtainwalls windows and doors by orientation, but all other objects behind it get in the way. Tag all objects doesn't work anymore in the viewport for some reason (it doesn't align the tags). Additionally, on older machines, the amount of processing required is substantial, and takes a long time to render. Not only that, its extremely unresponsive when adding annotation to the annotation layer.

     

    In an effort to save memory, improve memory efficiency and not have objects being tagged that are behind the desired objects in the viewport with the same record or OIP, I wanted to request an option to not render the objects that either do not have certain information (like hide all other objects, rather than greying them out) or hide objects based on field value etc... I think it would be a very welcome addition for efficiency of using the visualization feature without expending an extreme amount of memory. (This is referring to the option all the way at the bottom of the screen - instead of see normally or greyed out, add "Do Not Show" or "Do Not Render")

     

    image.thumb.png.46b4e9533f0de7a680cdc47823bf2bd6.png

    • Like 1
  12. @michaelk  Yep, a lot of it makes sense. A lot of these problems could be simply solved by using the #ΔY#, #ΔX# or #ΔZ# in the worksheets like they do in tags. My question is, why wouldn't the information in the tags match the same information in the worksheets? I mean, one could link the fields to the #ΔY#, #ΔX# or #ΔZ# functions via tag, but it only updates it when the object is tagged. If it didn't have that information before, it has to be re-tagged. If the geometry is updated, the same thing. :/. Its a little frustrating. 🙂

     

    Few questions here :

    1. Based on your answer, I'm guessing #ΔY#, #ΔX# or #ΔZ# cannot be called out in worksheets? (as these functions would solve all of the above concerns regarding orientation.)

    2. If I link the #ΔY#, #ΔX# or #ΔZ# Tag functions to a field, and i need to update the geometry, is there a script that can update the tag references upon updating the worksheet?

    3. By the looks of it, #ΔY#, #ΔX# or #ΔZ# functions cannot be transferred via link using an integer/number function, only the text based function. Is there a way to convert them to numbers after they have been converted to text? (something like txt2num?)

  13. Thank you@michaelk . I forgot to mention it was a polygon extracted from a 3d surface. So the polygon was oriented in the xz and / or yz direction. I have attached a file for you to look at. Width returns the length. Length returns perimeter. I cannot extract true height. and Area returns the correct surface area. Do you think it is a bug? I've read on other forums that even on extrusions, height width and length don't exactly work properly because of their orientation in space, i'm guessing it might be a similar issue.

    I've also tried subtracting topbound and bottom bound to get the height, but that also doesn't work.

    PolyTest.vwx

  14. Hi everybody,

     

    The functions like #ΔY#, #ΔX# or #ΔZ# can be used for polygons to callout rough dimensions of polygons via the data tag tool. I can't seem to be able to find it in the worksheet functions. do they exist? Functions like length width and height cannot be called out if the polygon has punch outs, and only these functions will call out the proper information.

     

    Thank you in advance.

  15.  Thank you @Luka Stefanovic , I agree with most of what you say, doing energy calculations, one has to be extremely tedious and meticulous with the conveyed information in the worksheet. If you want to work for only the client - this would be enough. If you need to present this information to local building department and zoning ordinance (in my case - New York) the information has to be verifiable (this ultimately tests the tools legitimacy to the building department)

     

    Since Energos only provides summed areas and no charts or worksheets to sum up wall UA averages between every cardinal axis,I've since needed to use the information directly from plugin objects to display in a worksheet, rather than using energos directly. I do not know if it is a requirement in other states, but in New York, i can definitely attest to the fact that tabular approaches to spaces, wall areas and U values are required. In fact, it is something i am working on as we speak. This only came up now because I am working on a project that attempts to implement the same rules I've used below. My solution to the problem is a separate matter.

     

    After having tested energos first hand i wasn't able to extract several things. (look through the earlier message board to see some of the attachments i've provided as a resource...otherwise i can send them to you directly if you wish). The things spoken about in this thread that cannot be extracted directly was the biggest area of concern.

     

    1. Exterior surface area (Like Energos does) - you've commented on this, and you are accurate in your description. If you have another way of extracting it, would love to hear it.

     

    2. Orientation of the walls in reference to Cardinal Axis (like Energos does). As far as I know, and @Nikolay Zhelyazkov  mentioned, only the energos label tool can do it. If you can extract it without the tool, would love to utilize that feature as well!

     

    3. Length of exterior surface area (inside wall length and outside wall length cannot be obtained, only the center line of the wall). Can be deduced if you divide surface area by the grosswallheight. but it goes back to problem 1 above.

     

    3a. There is a trick you can use in order to calculate pure exterior wall surface area. By using an additional component in the wall, you can make the component thickness .001 inches or something similar. That way when you calculate ComponentArea in this case, it will return the area of that component (net area at least), and length can be deduced from it as well. Problem is, using the component area trick - only works on solid walls - it does not work on curtain walls.

     

    4. Since all wall lengths are calculated from the center of the wall, any walls connected to other walls (L connection) must add wall thickness in order to get the pure exterior surface. Full wall thickness is added to a wall connected on both sides, half wall thickness is added to walls connected to only one side. Unfortunately, there is no function in worksheets that can be inserted to check for walls joined in L mode, nor is it possible to check if it is connected on only one side or on both sides of the wall. Had there been such a worksheet function, this problem can possibly be solved using a conditional =if() statement for both Lengths, and by extension, net wall surface area for both curtain walls and solid walls.

     

    5. Corner windows are also measured differently, they can end up having a different measured length from the outside than the computed length provided in the PIO. (needs to be dimensionally verifiable for the building department). This is the same center line problem as the walls.

     

    6. In order to get information that's taken from energos, record information can be extracted from the label tool. This includes cardinal axis and exterior surface area. (problem 2) It is possible to extract but it is modifiable - not like parameters PIO like walls, windows, doors, etc... can be computed through functions like area, length, etc... that end up being greyed out. Additionally, energos creates a separate record for every object that in the document. If every object has a separate record, it would be impossible to document or extract properly or conveniently. This was the basis and the crux of my criticism.

     

    Thank you again for looking into this. As far as I know, very few, if not, no other software company listens to the user posts and concerns. Your team has addressed many concerns in the past of this forums wishes, and I am personally grateful for it.

    • Like 1
  16. @Luka Stefanovic 

    Thank you for your reply.

     

    I agree, that it is a useful to evaluate the information when you are designing, however, These calculations can be reiterated just by using worksheets as well. Much of the information that energos shows goes through an additional plugin object that doesn't necessarily work the parametric aspects of the model itself. This is something I ran into when trying to get gross wall areas and net wall areas from curtainwalls and regular walls. I think that is a severe limitation because you cannot extract certain information from energos like exterior wall surface area, interior wall surface area, etc... What energos does instead it takes a one time extraction of the plugin objects and copies that information into a the label plugin object making it much more cumbersome to verify the information that it calculates. It would be easier to extract the information in realtime just like a worksheet does from any plugin object, that way any information energos uses can be extracted into custom worksheets. Just some food for thought 🙂

     

    Regarding much of the information from space objects that A Mcdonal mentioned can be cleverly manipulated without having to enter energos information, but rather extracting information from a separate record and combining it with space objects with plumbing or heating records. If information matches, it calculates demand temperatures for those particular areas. It is something I plan on integrating in the future of my workflows. But as it stands, Energos still doesn't display the surface area of wall and curtainwall objects correctly, no does it display the areas for corner windows correctly (this is a bug that was submitted) that prohibit accurate results. As a reference, I used grosswallarea_net versus Component net area and it had a difference of 6 - 8% fenestration  area percentage with the same geometry using windows, corner windows and curtainwalls as fenestration objects. 6-8% can be a very large difference between heat loss / gain, and consequentially, a substantial impact on mechanical system requirements.

  17. There is a way to convert revit models into vectorworks, but it does involve quite a few steps. Bottom line is, there is a method to import an entire directory worth of revit models into VW and then modify them one by one unfortunately.

  18. Hi Everyone,

     

    Is it possible to assign dimensional properties of a wall, curtainwall, etc... to IFCWallStandardCase.BaseQuantities using the expert formula function? I can't seem to be able to find WallArea_Gross or WallArea_Net under object properties like I would in the worksheet object properties. Can something like this be done?

×
×
  • Create New...