P Retondo

Member
  • Content count

    1,645
  • Joined

  • Last visited

Community Reputation

22 Great

About P Retondo

  • Rank
    1000 Club

Personal Information

  • Occupation
    Architect
  • Homepage
    www.retondoarch.com
  • Location
    CA
  1. First positive comment I've heard from a veteran user regarding 2018! Could you tease me with just one or two examples?
  2. I have a few, but no more than I have always had. Not a problem with previous versions, so I assume something has changed since the advent of v 2017.
  3. Jim, thanks for that explanation. It goes a long way to know that the engineers are aware of a problem and are working on it.
  4. Hi Jim, to be clear, handling of resources also affects startup delay. I know it's difficult to separate these delays out, but based on the screen hints I am seeing, something on the order of 10-15 seconds to load the resources after activation verification, where the total startup process used to take 15 seconds. v2017. Have you been able to verify this extra processing time with the new resources handling? If not, could you lay this perception to rest? If yes, can you explain why NNA thinks it was advantageous to re-design the resources interface at such a cost?
  5. Hi Jim, with great respect, I see the activation delay and that is a very important thing to fix. But I am talking about issues that are specific to the time it takes for resources to populate, both at startup and when going to the attributes palette. Anything having to do with resources now involves a very noticeable delay. Do you not experience this delay when using v2017 (can't speak to v2018, because even though I have paid for upgrades, we have not installed 2018 due to fear of even greater productivity dings)? Just for example, I click on the attributes palette, click on the fill style button, click on hatches, click on the hatch dropdown list and wait for several seconds while that list populates - it takes so long at first I clicked several times because it didn't seem to be working. Finally get a hatch and apply it - the whole operation taking around 10-12 seconds where it used to take less than 2. PS: You have to test this immediately after startup, because once you have used the attributes palette this way the list has been loaded and persists, reducing the delay
  6. As of v2016, all the resources, crap or not, were loaded on my machine with an SSD in 15 seconds to complete the whole startup cycle. As of v2017, with the new look and handling of resources, time has ballooned for startup and lots of other operations - such as, just assigning a hatch to an object. It is really not acceptable that we pay for poorer performance with supposedly improved software. Can someone from NNA explain why this has happened, and if there is some benefit we should be getting from all these slowdowns?
  7. Christiaan, I like removing the wall lines and windows spanning stories, but thinking about a wireframe 3d view of the whole building gives me a queasy feeling! I would think that writing the code to eliminate hard lines between walls that butt each other (I assume hidden line view is the issue) could be done. If you "corner join" two colinear walls, you can already eliminate that vertical line, so more of the same? I think windows could be layer-aware in the same way stairs are - granted, that idea is a bit cumbersome, but being able to view the building layer-by-layer seems a reasonable tradeoff.
  8. Christiaan, tell me more. I can't imagine looking at my model with everything jumbled into one view, so what is your vision of how to do things differently? Zoomer, in addition to your catalogue of horrors, as my example points out, there are layers - such as site measurements on a sloping site that span all stories - where you have to pick a layer z level, which will necessarily be out of whack with all your design layers except for one of the stories. That's why I just use layer z = 0 for all design layers, and why I'm kicking myself for trying the longstanding VW recommended way of doing things. To me this is an example of putting a lot of engineering time into something of limited value, when other ways of doing things could have been pursued that would have been "truly great" (- Steve Jobs) and possibly less complicated. E.g., ever try to get a wall height correct when you have 3 values (wall height, upper offset, lower offset) that are (seemingly) randomly interdependent?
  9. I just made the mistake, against my better judgment, of setting up a project with different layer z values for different stories. What a mess it makes of my work process - and all because of one crucial, missing bit of functionality. Let me give an example: I have maybe 100 surveying stake objects from a survey on a steeply sloping site. I can't look at these objects from the side and tell which is which (labels from side view wish?). So I copy a particular locus, and paste-in-place on the appropriate layer to see if my measured floor finish corresponds accurately to the floor level of a particular story in this 4-story structure. Guess what - because of layer z values, that object does not paste in at the correct height. It pastes in with respect to the layer z value of the layer I am working in, not the z value relative to "world z". If we could have the option to paste in place relative to world z, that would be a great help and I could use the "story" structure that VW promotes as a major feature. I use paste in place across layers very frequently, maybe a dozen times a day for various purposes. I would post this in the Wish List forum, but I don't see that in forum navigation - does it no longer exist?
  10. zoomer, so <stairs class> is not <class = "stairs class">, but whatever class is assigned to the stairs object? I see a Settings / Graphic Attributes dropdown list called "Attribute Styles," and one choice is "Use Object Class Attributes." That selection does not persist after clicking OK (reverts to "None"), but it does seem to cause the stairs to accept the object class attribute settings. "Attribute Styles" is not the word choice I would use to label this part of the interface.
  11. When I assign a class to a stairs in order to show it differently in a sheet layer viewport, it apparently is of no use because there are 20 or so objects in the stairs each of which has a different class assignment. Impossible to use. Also, changing the characteristics of a 3d object by means of editing its class works for line types and line weights, but if you change the fill to "None" the object is still opaque. Trying to get foreground objects to appear as unfilled dotted outlines in an elevation. It seems like this would be a common use of class attributes overrides. v2017
  12. Unlike walls and other objects, increasing a roof object's line weight does nothing in 3d views - such as elevations, etc. Is this a bug (v2017 and v 2016)?
  13. Yes, this has been a problem since v2017. I am currently sticking with v2016 because the 2017 and 2018 versions I have paid for cost me too much time.
  14. I can't stop the "next version available" update notification from showing, hate that also. When you say "hit the numbers" are you referring to the numbers in the 3x3 numbers pad? If so, your "problem" has to do with the way the program is designed (going back forever, not a 2017 change). Use the QWERTY numbers row at the top of your keyboard to enter numbers in fields and for commands. The numpad is designed to show different axonometric views (see the manual), not to enter numbers. It works differently depending on whether NumLock is activated - it moves your view around if NumLock is off.
  15. I'm noticing this problem. Your version?