Jump to content

P Retondo

Member
  • Content Count

    1,759
  • Joined

  • Last visited

Posts posted by P Retondo


  1. Perhaps you are not looking at the object in a rendered mode (OpenGL or Renderworks)?  Otherwise, the most common reason for this problem is that the object does not have a solid fill.  Although you seem to be aware of this, double check - select the object and look at the attributes palette, first item.

     

    Also, something seems odd about what you say about seeing the texture when you edit the extrusion 2d object.  Textures cannot be applied to a 2d object and would not show up.  Are you sure you are clear about the difference between a texture, fill and hatch?


  2. This situation is just unavoidable with the way VW works right now.  Peter's first suggestion is actually pretty close to how you would conceptualize the walls if you imagine the rafters having a seat cut on top of wall plates, but normally a framer would not do that on the gable walls, their sloping top plates would actually be lower at the outside corner.

     

    David is suggesting that if you fit walls at the interior edge, the side walls would be higher than the gable walls at the corner instead of lower, but there will still be an anomaly at the miter.

     

    But since you don't have fit walls to objects, none of that would be of any use to you.  However, you could join the corners using "capped join" mode, and then you won't have a miter.  But there will be an extra vertical line at the corner on the exterior, unless you are viewing in OpenGL or Renderworks and your textures are properly assigned and aligned.


  3. Count me as one who would not like to have a different file format every year.  We pay for Service Select to have access to the most up to date and powerful version of the program, with decent tech support.  That would not change if there weren't a yearly "version," I'd be happier with service pack upgrades and perhaps a big housecleaning every three years.

     

    On the other hand, if VW were thinking about going to a subscription whereby I would have zero VW unless I paid for Service Select every year, I'd have to treat that like I do Autodesk, which has gone to that model.  In other words, I would purchase another software tool.

    • Like 2

  4. dc, I take your point that it is logistically much easier to update maybe several hundred instances of a program on cloud servers than many thousands in offices around the world.  Plus, that sounds like outstanding response to a bug!  All the same, we theoretically have the ability to update our desktops - my internet security program does it automatically every day.


  5. Christiaan, I see your points 6 and 7 as being inherent to a cloud-based system (access from anywhere, easier sharing).  Other than that, the rest just speaks to superior software engineering - which I will stipulate the software you like does have, given the high level of your experience.  Yes, file management should be made more simple.  I'm sure that if file management is better with Onshape, that is due to software, not some personal file management nanny assigned to the project.  Updates should be smoother (if NNA could get their engineering together, user control over whether to update would cease to be a necessary thing).  The biggest drawbacks in cloud-based are that we lose control of the tools and their management, and that we may be paying more for CAD - if not now, in the future.  Good engineering does not come for nothing, and file management, access and server space cannot be free.  If the cloud server goes down due to cyber attacks or other problems, all users will be dead in the water.  If we are worried about files being pirated, wiped out by hackers, or just lost due to neglect, we will be at the mercy of the corporation to which we have ceded control.  That concerns me very much, almost as much as parametric tools starting to dictate a narrow range of design solutions.

     

    PS: regarding the point of file security.  Correct me if I am wrong, but the project files for a cloud-based CAD system will have to live on the cloud server.  My assumption is that the CAD software is loaded on a cloud computer and works with that computer's RAM.  Otherwise, every operation and processor request would have to travel over a very small pipeline between your desktop and the cloud.  This means your desktop is just operating as a terminal to send commands and receive screen updates.  The program is operating in the cloud, the application memory is on RAM on the cloud computer.  So every file save is between the cloud computer and the cloud storage server, otherwise we would be waiting forever with every save and that would not work.  The only alternative is that the cloud server file is just temporary, requiring that at the beginning and end of work on any CAD file we would have to wait for the entire file to be transferred over the internet.  Slow, not really viable.  That's why I assume we would have to give up physical custody of our work for this to be practical.

     

    BTW, I did check out this scenario for how cloud applications work with AIA Documents tech support, and they confirmed that is exactly how their system operates.


  6. But, Christiaan, is it the cloud or is it software engineering?  What is it about being in the cloud that make any software inherently more usable or stable, or whatever?  I would argue that better software is better software, regardless of how it is delivered or accessed, and that for my purposes as an architect seeking to have control over the security of my files, my ownership of my files, and my ownership of CAD tools, the cloud is not where I would like to be.  The cloud is the place for those who sell time on cloud computers and want to monetize the use of software as a commodity instead of a tool, since we become totally dependent on them and their equipment.  In this sense, selling the cloud as a technological solution as opposed to what it really is - a money-making scheme - that is a hype.

     

    When you say there is "no pushing in Onshape," I assume that means the document is actually stored on the cloud computer.  It has to be for CAD work of any substance, otherwise every save from RAM has to go through the internet connection.  That also means - drum roll - that your design documents now live on someone else's computer, subject to whatever insecurities that implies.  Hostageware, poor management, shutdowns, going out of business, all outside your control.  This is exactly why I no longer use AIA contract document software, all my contracts would have to be in the possession of the AIA and live on their server.  Thanks, but no.


  7. dc, I think the issue has more to do with engineering standards and corporate practices than it does with how the software is delivered or where it is installed.  The cloud is, IMHO, a much-too-hyped magic solution.  The big advantage is that you can use your workstation from any internet-connected location the same way computer "terminals" used to be used when we had mainframes.  The big disadvantages outweigh that: 1) the user does not control and own the software, totally dependent on the cloud server's security, availability, and you have to pay the rent, and 2) limited bandwidth - which increases your dependence on the cloud server because you have to save files to the server and keep them there instead of on your own computer.  We should be very afraid of such a technology model.

    • Like 2

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


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


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


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


  12. 10 hours ago, Christiaan said:

    I'd also like to see the need for multiple Design Layers removed altogether.

     

    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?


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


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


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

 

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