Jump to content

P Retondo

  • Content Count

  • Joined

  • Last visited

Posts posted by P Retondo

  1. Just to be clear about what I have said, I think this thread and Jim's comments are an extremely constructive response - not at all an attempt at deflection or obfuscation, rhetorical or otherwise.  If you have ever worked on a software project (I have), you will know that testing is probably the most important part of the process.  In that regard, developing some benchmark tools, which run the software through a series of speed tests, would be extremely important to be able to know whether the code as written is helping or hindering the specific goal of optimizing the speed of operations.  Making the result of benchmark testing available to users, compared across versions, is what both Jim and I would like to see.  Not as a way of solving every user's particular problems, but as a way of knowing in general whether a new version of the program is improving performance, or not.  Just as getting a faster processor may not solve someone's issue, having a version that benchmarks better may not solve every issue, but it will at the least tell us whether a performance problem is due to a basic software design issue.

    • Like 1

  2. For what it is worth, I'm a strong advocate of NOT being constrained by a software engineer's vision of what I should be designing.  Tools that guide the process, or make certain results more efficient to achieve have the potential to seriously crimp creative freedom.


    BTW, yes, a serious distraction from the topic at hand, which is benchmarking!


    On that topic:  the tests that occur to me as being key are 1) OpenGL 3d navigation, 2) Final Renderworks, 3) operations in sheet layer viewports (which have been subject to slow performance in the past), 4) site model updates, 5) undo certain operations (such as convert polygons to lines), 6) applying linetypes (much slower now than it used to be), 7) populating the resource palette, 8) booting.

  3. Jim, thanks for the thoughtful response.  Obviously, specific dysfunctionality of certain files and workflows are not going to be a good subject for benchmarking.  But that doesn't mean benchmarking is useless.  On the contrary, having some set of reasonable tests for various aspects of VW (rendering, certain 2d operations, certain sheet layer tasks) would be just enormously helpful, so that we can compare speeds - let's say, going back to VW15 - and get an idea of what we are in for if we upgrade.  The other issue you mention is that this would have to be done on different machines, let's say three or four generic representatives of the kinds of machines your users tend to have.


    It's not an end-all-be-all, but head and shoulders above the information desert we currently face.  I tend to think that almost any simplifying decision about files, testing categories, and machine types made by you and your team would be enthusiastically welcomed.

  4. Melanie, if you are reading this, the topic is not closed.

    I sympathize with your problem, and don't have much to offer since I am sticking with v2017, despite owning three v2018 licenses and two v2019 licenses.

    Jim, VW needs to deal head on with these speed and efficiency perceptions / reality (?) by instituting performance testing and releasing the data.  When I buy a processor I look at all the available data, and it is both voluminous and convincing.  CAD programs need to do the same thing - if for no other reason than to let their engineers know whether they are doing a good job.  When I make the time-consuming commitment to convert my files and resources to a new version, I want to know if my performance is going to be at least equal to the previous version.  That's just a simple business decision, and I don't base those on sales department press releases.

    Processing is ever more heavy, and Melanie I would be interested to know about your video card and it's RAM cache.  16 GB RAM on your computer is not as big as I would target for a new computer - I'd be looking at 32 or 64, minimum.

  5. 22 minutes ago, BenV said:

    What are the advantages of keeping objects on the screen plane? with the exception of temporary construction geometry, I always find myself putting items on layer plane or a 3D working plane.

    Those of us who have worked with VW for a long time have developed systems and workflows that depend on screen plane objects.  You may work a different way, but bear in mind that others may not.  For my part, I have no use at all for layer plane objects.


    As you point out, the power of screen plane objects is that they can be copied into a different view and used as geometry to inform design - transferring geometry from plan to section, for example.  Think of it like having a layer of trace over your 3d view.  If all your plan geometry is layer plane, you can't use it this way.

    • Like 2

  6. It would be great if we could designate a unit type to each dimension object individually.  I run into the problem where some of our site drawings have to be in decimal feet, and the rest of the drawings in feet/inches.  As it stands now, changing the units preference changes everything globally, so I have to set up a separate file just for those sheets and viewports that need to be in decimal feet.

    • Like 1

  7. There is a known issue that causes the preference to change from "Screen plane only."  If you edit a crop in a sheet layer viewport, it will change the setting and it has to be changed back.  This has been known now for at least 2 years, and as far as I know nothing has been done about it.  I just automatically reset the preference every time I edit a crop.

  8. You should talk to your professor about updating the class standard to at least 2018.  In the meantime, you can work in 2018 and export your files to 2017 version if they need to be submitted electronically.  2017 and 2018 are pretty similar.

  9. Mike, I think the current system is based on the idea that you may want to edit a symbol in the context of its placement in the drawing.  Sometimes that is useful, sometimes not.  So if you have toggled "show other objects while in editing modes" in settings, you will see all visible objects in relation to the symbol's placement, allowing you to snap to other objects that are not part of the symbol definition.

  10. Select the object, and go to the Attributes Palette to change color, lineweight, fill, etc.  Make sure an object is selected, otherwise changes made in the Attributes palette will change your defaults for new objects you create.


    The above assumes you are talking about 2d objects.  If you are working in 3d and displaying the masses in OpenGL rendering mode, you will not necessarily see the lines at the edges of an object.

  11. This is a constant annoyance and problem.  As Kevin says, it has to do with 2d screen objects in views other than Top/Plan.  When this happens, if you marquee-select, you can see the object highlighted and you just have to feel around blind for the snap points.  By the way, I have isolated when VW switches from "Screen plane only" to some other 2d object creation mode.  It happens when you edit a viewport crop in a sheet layer.  I haven't found any other event that causes that particular problem.


    PS: still haven't found anything but the very rare occasion when layer plane objects are actually useful.  3d polys do most of the same things, except display with fills and hatches.


    PPS:  in the same vein, screen plane objects in other than Top/Plan no longer display their line color.  And objects with white fill have a black fill, with my hardware at least.

  12. My XPS has a GT 750M, which is benchmarked way lower than your GTX1050ti.  And I have no noticeable performance problem.  It renders slower than my desktop because of the lower number of parallel processors, but otherwise is fine.  Bear in mind that I don't use Spotlight objects - but it doesn't sound right that you should have that level of performance issues with your setup.

  13. It doesn't make sense.  Bear in mind that I have not moved past 2017, even though I have licenses for 2018 and 2019, fearing the same kind of risk.  (NNA, are you listening to the level of distrust expressed by many?)  All the same, I would suspect some kind of anomaly.  Perhaps Jim or someone at NNA can take a look at your file and attempt to run it on one of their machines.  One thing I would look at based on your most recent comment:  updating Renderworks viewports can take significant time, and if your file settings or actions are triggering unwanted viewport updates, maybe that is the cause of your performance problem.

  14. You are not using site modifiers in the way they were intended.  As far as I know, the site model doesn't work by direct manipulation of contours - it works through objects like pads, which then generate proposed contours.  I think you are asking the site model to analyze the difference between two sets of contours, which (again, as far as I know) it is not designed to do.  The site model is interpreting your contour polygon modifiers probably in the only way it understands, which is to treat them as pads - something far different from what you expect.

  15. Based on my experience with now dated versions of ACAD, AutoCAD and VectorWorks handle scaling and units differently.  All VW objects, as I understand it, are stored in memory as 1:1 in the underlying unit (I think it is millimeters, correct me if I am wrong about that).  Layer scales, as Mark points out, only affect graphical display of the attributes he mentions, plus font size.


    You cannot change the way a line looks while working in a design layer.  You can scale attributes in a Viewport by using the "Advanced Properties" dialog box in the OIP.  But I use this only for instances when I want to output the content of a drawing at different scales in different Viewports.  It makes no sense to have an arbitrary rule that design layers must always be 1:1.  There is no difference in the drawing experience or actual geometry of objects drawn in layers with different scales, except with respect to the presentation attributes Mark and I have mentioned.  If you want to know how your dashed lines will look, or how much space a block of text will take, draw in a design layer scaled to the output desired for the drawing.

    • Like 1

  16. You are looking at either grayed layers (most likely) or classes.  Check your navigation palette:  is your general class setting (at the top) Show/Modify Others (it should be)?  Are any individual classes set to gray that shouldn't?  In the general layer setting, you should see either Show/Snap Others or Show/Modify Others.  Are any of your individual layers gray that shouldn't be?


    BTW, when you take a screen shot like this it would be helpful if you included the navigation palette.  Also, it is sometimes important to know the VW version you are using.

  17. Jim, I don't understand your comment.  My understanding is that ECC detects and corrects errors in memory transfer between RAM and storage, which would be at the operating system level, not at the application level.  Is there something I am not aware of?


7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114


© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

  • Create New...