Jump to content

P Retondo

  • Content Count

  • Joined

  • Last visited

Everything posted by P Retondo

  1. v2016, I am unable to make sheet layer viewport class visibilities work. If a class is turned off in a viewport, it still appears unless the class is turned off in the "current view" in the navigation palette. This makes it impossible to have a certain class appear in one sheet layer viewport, and invisible in another. Does anyone else experience this problem? Class visibility bug.vwx
  2. Alan, if you end up confirming this I'll submit a bug report.
  3. True, Jonathan, so the solution to that is not to have so many different kinds of walls . Seriously, though, if classing works you could reduce the number of styles by 1/2. Not solid on the details, I've always been a bit vague on the relationship of the "overall" wall attributes and the effect of various options for the wall components. I always use <object class> for the structural component of a wall, which I think makes it take on fills/hatches per the wall class. It makes a difference if the viewport is showing components or not, and I think if components are showing the Wall Attributes choices may not have the same effect compared to if the components are not shown. I did some fooling around, and although the Wall Attributes window doesn't say so, if everything is "Class Style" the wall does pick up class linestyle settings, so I just figured out how to make two walls with the same style be either a wall to be removed or a wall to stay, using classing.
  4. Jonathan, using "edit wall attributes" in a wall style dialog box, you can select options to assign class values to the fill, colors and line weight - but you can't select a different line style (i.e., a dashed style), which is the standard where I work. If VW could add line style to that set of options, it would complete the ability to control the look of styled walls with classing. From your example, it looks like you use color and fill, so maybe class control of styled walls would work for you. Wall Attributes.pdf
  5. If you want to copy 2d geometry from top/plan view to another viewpoint, e.g., "front", etc., a screen plane object is necessary. If you attempt to copy a layer plane object into a different point of view, VW will ask if you want to convert it to screen plane, in which case it will show up aligned to your new point of view instead of looking like a line (the layer plane object viewed from the side). I have never been a big fan of layer plane objects, but they're here to stay and have a leg up over 3d polygons in that they can display hatches, fills, etc.
  6. I think there is a bug (v2016) with the display of chain dimensions with a dual-dimension standard selected. The OIP does not display the choices between primary and secondary units and precisions. For a single dimension, all is well, and if you right-click an individual dimension in a chain dimension, you can edit the precision, etc. Anyone else see this? Dual dimension OIP bug.vwx
  7. +1 on this request. Autoclassing is a problem. It's an example among many of how software engineers are pressing THEIR solutions and priorities on us. Software engineers are great at what they do, but we are also professionals working in a different area of expertise, and we need to have control over decisions that work best for our purposes.
  8. There's a big difference between a new version of a program and a new version of the file format. Doing a VW 2017 without changing the file format would be more like a service pack, even if it requires loading a whole new executable file and associated utilities and resources. Doing a VW 2017 with a new file format, the usual practice, requires that we convert all files with previous formats if we want to work on that project in the new version. I have requested that file formats change only every 3 years, so we don't have this kind of problem. There are a lot of technical reasons this is difficult, particularly if the new version requires new object types. But new features don't always require new object types, and planning to implement that kind of feature only every other or every third year seems like a reasonable way to bring more stability to the program and less hassle for users. BTW, I have not noticed any issues with translating files to the new format in several years now. 2008 to 2009 was, if I recall, a big problem, but for the work I do conversion has become more problem-free.
  9. What would be great for an iPad is a VW utility that could take measurements from a bluetooth EDM in the field and convert it to plan geometry in a .vwx file.
  10. +10 to have add and subtract solids for site models. The pad/fence tool just doesn't work for any but the simplest situations, the retaining wall tool is way too complicated and difficult - when it works at all. Generating the site model from contours or 3d loci is about the only thing that really does a good job. Don't even try to model grading for a driveway or parking area. For roads and paths, we should be able to go from a series of 2d lines representing station points, convert them to NURBS with proper elevations, loft into a surface, multiple-extrude into a solid with sides sloping to grading limits, then subtract or add to the site model. I'd rather have a terrain modeling tool that works than any dozen new whiz-bang features.
  11. Brilliant bug report ideas, Jim
  12. It's pretty difficult and frustrating to set up an animation in VW. Been basically unchanged for years. I wish I could do the following: do a walkthrough onscreen in OpenGL, save the path - including stops, rotation of viewpoint, and spins - then have that path generated in a list and be intuitively editable to tweak the speed, duration of various events, viewer height, etc. Then an easy setup for type of rendering and a quick preview capability, and, of course, faster multi-processor capability for rendering! With reliable and stable progress updates, and the ability to stop and start processing at any point in the rendering.
  13. Markus, how would this be so much better than what we already have - recalculate on the right-click list on a Worksheet window, and recalculate in the worksheet edit window under "File"?
  14. Matt, amazing that you were able to get the basic info on this! Thanks, it's great to have some clarity. I think Ray filed a bug on the other aspect of this, which is that snapping calculations on the Oval curve appear to be incorrect. Nothing to do with screen representation, just a verifiable error of geometry (see my post above).
  15. Yes, the stipple is enormously memory and processor intensive. It's basically useless, for something that at first glance seems to be a simple thing.
  16. Raymond, after talking with you and testing, I have discovered the source of my error, which causes us even more distress if we are concerned about accuracy and the integrity of the CAD calculation engine. I now agree that the VW "Oval" must be a true ellipse, and is probably generated from the algebraic ellipse equation ((x/a)^2 + (y/b)^2 = 1). First, here was the source of my error, and without talking to Ray I would never have guessed. In my attempt to cause the calculation engine to reveal its secrets, I used two methods interchangeably: the join tool, whereby the program calculated the intersection between a line and a curve, and a snapping method, whereby I extended a line beyond the curve, and dragged it back to the "object/object" snap cursor. It turns out that those two methods give different results!! I believe in the case of an "Oval" that the "object/object" snap point does not actually lie on the oval curve (the difference in my test situation on a 2" wide oval was about 0.0003" - which could amount to feet on a large site oval). I also verified Ray's method by calculating the coordinates of two random points on the ellipse (using the formula above) and placing loci there, and discovered that they exactly coincide. I tested the coincidence by creating a 1.0000000000" line horizontally from the locus, then joined that line to the oval, resulting in exactly the same length to 10 decimal places, the limits of VW accuracy.
  17. Raymond, no!! not the hole!! We can't rely on screen representation of curves at high magnification. They aren't drawn perfectly accurately, and that can be proved, case in point. The magnification test shows lack of coincidence, my test shows perfect coincidence despite the apparent discrepancy on screen. I use a test that does not rely on the uncertainties of screen representation at high magnification. My test relies instead on the underlying math. I join a line to the curve at any randomly-selected point, adjust it so that the line's length is a whole number (like 2.0000000000 inches). Then after overlaying the quarter arc on the oval, take away the oval and join again. It's easy to see if there is a difference. In this case, it's still 2.0000000000 inches, indicating coincidence at that point within VW's minimum tolerance. Now since that quarter arc is a bezier polyline, doesn't that suggest that the oval is also based on a bezier polyline? Tomorrow in my abundant spare time I will perform a test on a locus with coordinates calculated from the oval's major and minor axes, and report what I observe.
  18. PS, pdrake, you need to create a signature that has your VW version and OS so folks can know that to better understand your issue.
  19. You need to convert to a polygon, then you will be able to add vertices. When you edit a rectangle and move a vertex, it automatically converts to a polygon. Or you can use the "Convert to polygons" tool. That's why you are seeing this behavior, which is normal.
  20. Not sure what you mean by "it works after i move a vertex," but no handles probably means some kind of corruption. If just that object but not others in the file, then that object is corrupt. If the whole file, it may be corrupt. If all objects in all files, VW is corrupt.
  21. First thing to do is close and restart VW.
  22. Confirmed that the "quarter arc" does indeed do what Kevin says. The curve is identified in the OIP as a "polyline" and has, in the example I generated, 2 bezier control points. Proof positive, I think, that the "Oval" is not a true ellipse. Kevin, since Rhino is NURBS based software, I'm not surprised that its version of an ellipse is just a bezier approximation, which is what I think you have confirmed.
  23. It has been noted that when an "Oval" is trimmed, the resultant curves are polylines that don't exactly match the original oval's shape. Guessing that the "Oval" is generated from the equation for an ellipse with major and minor axes as parameters, this request is for an curve that would be a portion of an ellipse (=? oval), with control points at the end points and the 2 focii. The OIP could still display the lengths of the axes.
  24. Raymond, that's pretty interesting. Did anyone from NNA confirm that their "Oval" is generated from an ellipse equation? That would dispose of all the doubt, but like you say it's pragmatically of zero consequence. I like the idea of a separate object type for a segment of an ellipse. Its control points could be the 2 focii, plus the endpoints.


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