Jump to content

Samuel Derenboim

Member
  • Posts

    407
  • Joined

  • Last visited

Posts posted by Samuel Derenboim

  1. 21 minutes ago, Mark Aceto said:

    VW users: we want a maintenance update focused on performance and stability--no new features!

     

    VW: for the first time in 20 years, every user finally has true multicore performance the entire time the app is being used

     

    VW users: we're not upgrading because there are no new tools!

     

    VW: there are ton of new things we haven't announced yet in these 4 Trigger Tuesdays

     

    This is why we need better communication vis a vis a Public Roadmap. Also, just end Teaser Tuesdays. They used to be 8 min DIY BTS deep dives followed by Q&A's. Now they're just the same 3 min promo videos that drop on release day when we can dive into the new release ourselves to explore (which is extremely fun to do under those circumstances vs rage-posting in the the forum for a month straight).

     

    LOL. But does it blend????

     

     

    • Laugh 1
  2. I've been hoping to get this into the works for a while. Great for details and great for axonometric representations that are to scale. Scale is very important in architectural presentations and construction documents, and currently no isometric view can scale the presentation properly. Does anyone feel the same way?

  3. Don't know if anyone has run into this issue before, however, data tags with text for some reason scale differently than symbols do. From what I understand, data tags scale at page scale, where as symbols scale at world scale. When I take a symbol, and at 1:1 scale w/ size 10 text, the true size of the text inside symbol at 1:10 would be 1 instead of 10. Data tags automatically adjust its size based on text size according to design layer scale, and as a result cannot be truly scaled based on its world size. Is it possible to give  data tag a world scale so that the text would adjust based a 1:1 ratio in the design layer view port irregardless of the design layer view port scale?

     

    Data Tag @ 1 : 1 scale representation

    image.thumb.png.568f5f4a3186781098f061503141784e.png

     

    Real world scales

     

    image.thumb.png.6b2a9e0cc337620f7cab85ce1fde8a84.png

     

  4. Hi everyone,

     

    Don't know if anyone works with point clouds here, but it's definitely the future of surveying. There is a feature i wanted to enhance. Currently, there is only one right click option for extracting loci from a point cloud model, however it extracts from the entire point cloud model. My feature request enhancement is to selectively show where in the point cloud model I would like to extact the loci. If using the clip cube, it would be great to extact only the loci in the clip cube. If its a section for example, that has been generated from the point cloud, perhaps the same feature, extract loci from point in viewport (i.e. a viewport that has a min and max setting for below and above clipping points.) It is great to use if someone needs to model a terrain of some sort without having to regenerate the model itself.

     

    Another feature would be to generate a 3d model from a series of loci, or a 3d terrain, but it would not generate the object if it has overlapping elements / loci in it. So i.e. to generate a model from a point cloud set of points that are spherical, or vertical. Just a thought. Thought Id share these ideas in the forum in case anyone runs into similar requests in the future.

     

    image.thumb.png.e38e969b04a142e708af6cf8c3db2a00.png

     

    Versus

     

    image.thumb.png.df824d17b74b7383c0b8639b45fa9dd2.png

     

     

    • Like 1
  5. @Tamsin Slatter 

     

    Your suggestions for the tag tool regarding the bounding boxes is an excellent idea, don't know if you already submitted this enhancement, but I second the motion to add that feature (along with @Michal Zarzecki  I presume).

     

    I agree that the tag tool needs multiple additional functions in order to use some of these things properly. Particularly, the feature that is sorely missing is simply getting the tag to read the Z in reference to the story. It should also understand what level in the story it might be referencing. This pertains to one of the questions you ask - how would you do it in plan mode?

    In my opinion there are two ways - either copy the z value of the symbol in reference to the floor elevation (not absolute zero), or copy the elevation of the level the symbol or PIO is on - i.e. - ceiling elevation, FFE elevation, T.o. slab elevation etc.. in both a numerical format and perhaps also callout the level itself, that way if it needs to be changed from the tag level, it can easily be done so. These two things can be done in plan mode without going into 3d or providing a working plane for the object you are referencing. This might be particularly useful since i have a feeling you guys might be integrating levels in symbols as well (or so i presume)

     

    Just a thought. What do you think?

  6. Hi everyone,

     

    I know there is a simple fix to do this, but wanted to inquire within. The chart below shows Areas UA and UA averages. In order to get UA average formula looks like UA / Area. The bottom (totals) row returns the correct value, however the table cells in the database return the incorrect value. I know a conversion must be made or something like =value () or num2int or something. Does anyone know the correct formula to do the math properly ? (the UA column are summarized by sum)

     

    image.thumb.png.9ddb96297f856150995b8bf5d2b8c881.png

     

     

     

    Here is another example. The Table columns showing wrong are doing the math in the table cells because they are summarizing and adding the values. Formula under the 1st (from left) column with the word wrong above should calculate 433.2 / 8374.571 = .0517. It shows 4.3038 because it summarizes and sums all the criteria for the values. The same issue is the other columns. The totals cell at the bottom has the correct answer because it is not using a database header.

     

    image.thumb.png.7d1eb2290dab4254f091330684e6d154.png

  7. Thank you @Pat Stanford 

     

    You're right, I didn't get into detail of how it worked and checking part of the file. My concern is if there is a single crash or problem on one computer, how would the information be saved and would it affect the integrity of the master file that is being worked on.

     

    I also noticed that the larger a file gets (annotation + BIM model), the harder it is to work on because more ram is required not withstanding any other unknown conditions. The more gears involved ,so to speak,, the easier to cause problems. Hence the solution for referencing information and using reference files to do annotation in a separate one.

  8. @jmanganelli 

    What you say makes 100% sense. That is why i bypass the guess work and do the calculations from wall areas and other tricks with different types of geometry with records referenced in the file. However, even the areas of exterior walls are very difficult to get given different conditions of wall types and walls. Wall surface areas still cannot be calculated properly (curtainwalls in particular). I would even go so far as to say I'd be happy if VW got out of the energy modeling department, and simply fixed the current toolbase in order for the community to assemble together and make one that suits our needs. 

    • Like 2
  9. 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?

  10. 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
  11. 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
  12. 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

  13. 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?

  14. @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 🙂

  15. 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

×
×
  • Create New...