Jump to content

Taproot

Member
  • Posts

    510
  • Joined

  • Last visited

Posts posted by Taproot

  1. Adding my vote to this topic. 

     

    This is a critical omission. 

     

    VW encourages a class reliant workflow and without the capacity to map and assign classes over time, the whole system breaks down.  We are in the process of investing significant resources into developing our office class standards ... and now I'm really wondering if that is even worth doing.

  2. Yes, it looks to be a dead end.  It only works for setting up the drawing.

     

    Apparently, "smart paste" was the closest solution - but support was discontinued last year. 

     

    So it seems the only solution is to periodically delete the offending classes and then "reassign" the objects to new classes until one's classes are finally scrubbed clean.  That seems like a really long, slow and terrible work-around.

     

    What seems like the obvious fix would be for the "Standard Naming" to re-assign new objects placed in the file according to the mapping laid out by User.

    I'm surprised this hasn't been implemented.  Now, if I can just remember how to move an existing thread to the wishlist part of the forum...

     

     

  3. I"m wanting to clean up our office class standards and having a devil of a time doing it.

     

    How do you "map" old classes to new ones?  Is it possible?

     

    For example, let's say I want "nonplot" to now be "2D-nonplot" so that I can group all of my 2D classes in one section.

    As soon as I bring in a legacy object / symbol from our last twenty years of work with an object assigned to "nonplot" it will recreate that class.

     

    I would like to have a "map" in place that automatically assigns all incoming obsolete classes to new ones.

    Is there a way to do this?

     

     

  4. On 4/10/2018 at 10:19 PM, Cory Pattak said:

    I think if you click on "File Export Options" in the publish window and uncheck "Create Folder for each file type", I think that might disable the publish log. It works for me.

     

    Cory

     

    I've been trying to figure out how to do this for years!

     

    Apparently, I didn't try hard enough because your advice worked.  Thanks for eliminating all of those annoying files from my desktop.

     

    • Like 1
  5. 2 hours ago, Tamsin Slatter said:

    To answer the question about crash reports, if you have Verbose error logging turned on, your crash logs are automatically uploaded to our engineering team. (Vectorworks > Preferences > Session tab).

     

    Regarding origins, the key thing is that the geometry is close to the INTERNAL origin and that there is nothing greater than around 5KM from the internal origin. The user origin is used to represent real world coordinates overlaid on the internal origin. If you are referencing files together, it is recommended that the same coordinates are overlaid on the internal origin in all files in the project.

     

     

    HI Tamsin,

     

    OK, I've enabled verbose error logging.  Hopefully that will help.

    That is good to know about the origin.  In our case, the user origin and internal origin are the same, so I don't think that could be causing the errors.

     

  6. Initially our experience with v.2020 was great - faster then 2019 by far.

    Now we're experiencing a lot of instability in the software and erratic rendering issues.

     

    This morning, the program crashed when I changed the view from plan to isometric for a very small model. We have the default view for isometric set to openGL (or is it called "metal" now?)

     

    1838849559_ScreenShot2019-10-04at10_23_44AM.thumb.png.bf135fc895993629b32d5cde87476c96.png

     

    Should I be collecting these crash reports somewhere?  I very much doubt that Apple cares about the report, but do the VW engineers want a copy?

     

     

    In this OpenGL rendering, you'll see that the lower part of the wall disappeared on the left side of the building.  Re-rendering the viewport sometimes will fix this kind of error, but often we need to close the software down and re-open it and then re-render for it to correct.  It happens sporadically in our openGL viewports:  Elevations, perspectives, etc.  The errors our weird and I find that I now have to check each viewport  methodically before publishing a set.  It takes a lot of time and I often feel like I have to get lucky to get all of the viewports correct before publishing a set.

     

    Related issues:

    • Viewports that are out of date often "jump" to other locations on the sheet / page.  They have to be updated to return to their original placement.  If you continually zoom in and out, the images are correct, but as soon as you stop moving they go wacky.
    • The software often crashes whenever we finish publishing a set - thankfully, the set is complete.  We habitually save before publishing.
    • The software usually crashes whenever we attempt to "Quit."  No biggee - as that was our goal anyway. 

     

     

    1721927160_ScreenShot2019-10-04at10_28_33AM.thumb.png.2a4783fb0db78b178096107d0b121963.png


    Here's a few more examples of mis-rendered elevations. 

     

    465061399_ScreenShot2019-10-04at2_08_35PM.thumb.png.ffea96bc926f2725685bd748c7695131.png

    1250009593_ScreenShot2019-10-04at2_08_49PM.thumb.png.0c7364ecc19b113ce8875a35d2bab9ee.png

     

    I expect that you may want a copy of the file. We can provide you with one if you let us know where to send it.  However, this is happening to most of our files.

    I looked at some older posts with related issues and can confirm that the user origin is the same as the internal origin AND we are not using layer links, only design layer viewports.  Furthermore, there are no design layer viewports employed in the elevation renderings.

    • Like 1
  7. I've found consistent access to user setting across our network to be somewhat problematic.  It's likely a function of the network itself rather than vectorworks, but it exists, so we've developed an alternate strategy.

     

    Our solution is to sync our user folder(s) with our office workgroup folder.  We use the mac based app "Chronosync Express" to selectively sync our resources based on whichever file is the most current.  That way, updated libraries etc. are populated to the central folder as well as our individual machines.  This works for us - as a small office where updates are intermittent, but if two different people changed the same library on the same day, one set of changes would be lost.  We haven't yet had that happen.

     

     

    • Like 2
  8. 6 minutes ago, Boh said:

    When you import classes from one file to another - if class names are the same VW will ask if you still want to import existing classes. If you do the existing classes will be updated to have the attributes of the imported classes with the same name. Class visibilities of existing updated classes don't change.

     

    Boh - That's a helpful tip, one that I'll likely use now that we're updating our class attributes.

     

    • Like 1
  9. Curious.  I've found this behavior to be repeatable in multiple files.  Here's some screen shots to further illustrate the behavior.  Note - these settings worked fine in 2019.

     

    First image:  Two viewports.  The one on the right is 50% the scale of the one on the left.

     

    579668000_ScreenShot2019-09-13at9_29_16PM.thumb.png.7501a0fb51fbd53c98dbe2c4d73743cd.png

     

    Second Image:  The test was to see if the "line type scale" could be reduced to 50%.  This screen shot is a "preview" of the setting.  Note the "X's" in the fence line.  They are shown at the same relative spacing as in the larger viewport - as intended.  However:

     

     

    260785353_ScreenShot2019-09-13at9_28_58PM.thumb.png.c1d20d10769ec630766729a1c18a7f61.png

     

    Third Image: Once the user clicks OK, the line type display reverts to its default size.  Note, the X's now appear at the same spacing in both viewports.

    Hatches don't change in either preview or after exiting the Advanced Viewport Properties dialog.

     

     

    1854489546_ScreenShot2019-09-13at9_27_50PM.thumb.png.538a5f82a22bb0258f32e4919d88c99b.png

  10. Larry - Wow - quite the innovative solution. 

     

    I tried following your advice and it looks like you have to delete all of your line styles and then repopulate them from elsewhere. 

    For me, each time I deleted the 'default' line style a different one would take it's place.

    I presume, therefore, that the attribute pallet maps the default to the "oldest" line style in the file. 

     

    Unfortunately, we have a lot of objects in our master file that would lose their mapping if I deleted all of the line types at once.  So, I'm going to use this current nuisance as the catalyst to shift our line types into class attributes and control them that way.

     

     

    • Like 2
  11. Ok this one seems like an easy one:

     

    We have our line tool default set to a solid line (for most uses) and want to leave it as the primary setting.

     

    However, we often want to draw a dashed line - so we select "line type" from the attribute pallet and ..... end up with an obscure dash style that we never use.

    Every time we do this we get the same obscure dash style.

     

    I've tried setting a default dash using the eyedropper, etc. to no avail.

     

    How do I set the "line type" default style so that it sticks to something (on purpose)?

     

     

    • Like 2
  12. 4 minutes ago, Matt Panzer said:

     

    The Barn Door configuration was implemented in the same manner as the other configurations and independent from the Marionette object. Integrating Marionette objects into the Door object sounds appealing, but I believe there would be a number of challenges with this. The first issue would be performance. That said, it still would be interesting to explore! 🙂

     

    Well, there goes that theory!  Matt - thanks for the insight.

     

    • Like 1
  13. After a day of testing out version 2020, my overall experience is positive.

     

    A bunch of us have been asking the software team to forego new features in exchange for quality, ease of use, stability, better implementation of existing tools, etc.

    While there is still so much on the "wish list," this release suggests that shift is in fact happening.

     

    Core Improvements

    Stability:  The fact that Christiaan feels comfortable enough to migrate the whole office to a SP0 release says a lot.

    File Size:  We're finding about a 40% compression rate for our files.  Removing the excess and making the file structure leaner is great engineering IMHO.

    Dark Mode & Retooled Icons:  Demonstrates that there is an awareness to updating the user interface and experience.

    Rendering Speed Enhancement:  Open GL is snappy - Moving about the model now feels like it should.  Wow good job on that one!

     

    Hope for future tool refinement:

    After studying the new door tool, the barn door functionality that was added appears to be a direct integration of the Marionette tool that was developed and posted elsewhere on this site.  If I am right in that regard, that means that the engineering team is using graphical scripting to code the standard tools AND that strikes me as a game changer for future tool development.  For example doors and windows can be constructed using if/then conditions versus all fixed parameters, etc. 

     

    I think the team is laying the groundwork for some breakthrough implementation of things like the Door / Window / Stair tools that we have been asking for.  Perhaps, I'm being overly optimistic, but that seems like the natural progression of where this strategy is headed.

     

    Challenges:

    Not every implementation is perfect yet. 

    • When switching to dark mode the text associated with my tool pallets doesn't toggle from black to white (or white to black) so it effectively disappears.  Fortunately, you can overcome this by entering the workspace editor and toggling the settings.  Once the workspace resets the screen condition it works fine.

    • The Notes Manager can now list the notes with the Note Description as the list # - that is awesome (as in we can finally add CSI ID's or office standard addressing to our note blocks).  However, it took a bunch of steps back at the same time.

    1. In 2019, the database note selection and note block organization were in one window, making the addition and organization of notes easy.  Now, they are in separate windows and the interface is cumbersome.
    2. You can no longer add multiple notes at once, but instead have to add them one by one.  Imagine that I'm using this tool for my sheet specs ... way too slow.
    3. Every time that you add a note, it forgets your current note database and requires you to reselect it...

    More to explore...

     

    • Like 4
  14. Hello Chris,

     

    For our purposes, we schedule directly in airtable rather than export data from VW objects.  Airtable holds our core information, so we can use it as a template when moving from project to project.  The only synch we need to make is the ID # from the drawings relative to the database - which we do manually.  So, we don't use an automated export method in our workflow.

     

  15. Yes, it can be done.  I'm not sure about v.2015, but it certainly can be done in today's version.

     

    Here's a link to the help page:  http://app-help.vectorworks.net/2016/eng/VW2016_Guide/Floors_slabs/Editing_Slab_Geometry.htm

     

    Here's how:

    Draw the slab and then draw an extrude along path for the geometry of the turn down footing.

    Select both and right click to pull up the context menu.  Select: "Add 3D object to Slab" and voila, the slab is now modified to contain the added geometry.

     

    1128564609_ScreenShot2019-08-01at9_44_46AM.thumb.png.5ea277d87680f3a808ae2d11fe80b86f.png

     

    634478686_ScreenShot2019-08-01at9_45_34AM.thumb.png.b4b2997f43de634f2b6699fc056eea05.png

     

    1456028949_ScreenShot2019-08-01at9_46_35AM.thumb.png.2fee4e1c64e280712b21a55cf9b838f1.png

  16. Yes, you can do this (and it's easiest if you have the four windows modeled separately).  In the OIP, experiment with the "Top Shape" set to "Sloped" and fiddle with the "Rise" amount to get the correct pitch.  In your case, where you have two bands of windows atop one another, you can also experiment with the "Transom" setting to closely approximate the upper window lites. 

    1326622641_ScreenShot2019-07-24at5_08_14PM.thumb.png.d0a6c981d93ef3ea33b004f72728bfca.png

     

×
×
  • Create New...