P Retondo

Content Count
1,794 
Joined

Last visited
Posts posted by P Retondo


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 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, multipleextrude 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 whizbang features.

Brilliant bug report ideas, Jim

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 multiprocessor capability for rendering! With reliable and stable progress updates, and the ability to stop and start processing at any point in the rendering.

Markus, how would this be so much better than what we already have  recalculate on the rightclick list on a Worksheet window, and recalculate in the worksheet edit window under "File"?

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

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.

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.

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

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.

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.

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.

First thing to do is close and restart VW.

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.

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.

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.

It's more likely that I haven't any clue about mathHaha, not likely!
Here's the wikipedia on an "oval," in case you are interested:

Zoom, perhaps math definitions are different in Europe, but in the US a cylinder is sometimes considered the special case of a cone with infinite height, and any slanting section through a cone (or cylinder) that is closed (reaches from one side to another) is an ellipse. An ellipse in (x,y) coordinates has a quadratic equation similar to but more complicated than a circle, which, again, is a special type of ellipse where the 2 focii coincide.

Raymond, I initially had your thoughts, and I think we are 99% in agreement, except that there is an object type you don't mention germane to the question  the "Oval." Unlike an ellipse, the oval does not have a consensus mathematical definition, so I think it is telling that VW does not call their object an "Ellipse." What the VW "Oval" is I couldn't really say, and it may in mathematical definition be a bezier curve. So the fact that an Oval when trimmed becomes a series of polylines may not really represent a change of geometry. Donald, you originally raised this question, do you find that a line snapped to the oval becomes different in length when snapped to the trimmed curves?
Zoomer, funny! I assume you are tongue in cheek. Seriously, though, are we really moving to a design world in which forms which have been commonplace since the Renaissance are now to be shoved aside by the dictates of CAD engineers? That goes so much beyond the current discussion on precision it belongs in a different thread, but it's a big question, who is leading the development of CAD  designers or coders or marketers?
PS: I did the test. In my instance, I created a 3" line snapped to an oval. After trimming the oval, resulting in a polyline curve, and snapping the same line to that curve, it was shorter by 0.002248". This may have to do with the mathematical definition of a Bezier curve, which I don't have a completely firm grasp on despite having at least attempted to read Bezier's book. In my limited view, if you change the endpoint of a Bezier you may be unable to get the same shape regardless of how you tweak the Bezier parameters. Anyone know if this is true?
Sorry about the edits changing this post, that's the way the thought process works for me: on the other hand, if the "Oval" as defined by VW is in fact mathematically an ellipse, which has an equation defining every point, then there is no excuse for a clipped portion of that curve being mathematically different from the unclipped shape.

Raymond, respectfully disagree. Any set of points that can be defined mathematically can be represented equally well, in theory, by CAD. Apparently in this case NNA engineers have chosen not to write the code for a portion of any given ellipse. I have my doubts whether an obect of the VW type "oval" is a true ellipse, actually. From a pragmatic standpoint we are splitting hairs, no screen representation is exactly accurate, we are dealing with pixels and irrational numbers.

rD, I tried this in v2016, and the angle was correct: 9.462 degrees.

GWS, your signature says you're on 2013. I believe this issue might have been resolved in v2016.

christo, you've not given us a very clear idea of what is in the file you are working with. It's a wellknown shortcoming that the radius dimensioning tool often does not work in annotation space. If you have actual 2d arc elements on the design layer, you can get the dimensions there. I often have to redraw an arc over the referenced objects when in annotation space to get a radial dimension to work.
Based on limited testing, VW2016 seems to perform a lot better in this regard, maybe this has been fixed with the current version.
Here's something that may be a bug: If you extrude a circle, the radial dimensioning tool can pick up the radius from an extrude. If you extrude a polyline that consists in part of arcs, the tool can pick up the radius from the 2d object but not from the extrude.

+1 It may not be that difficult to do, if we are talking about extrudes, which are generated from a 2d shape in the first place. While we are at it, let's make it so that when an extrude is moved it's 2d primitive "moves" with it so that when editing the 2d shape, the vertices are aligned with the actual location of the 3d object. Why is that important? Say you have an extrude in a location, and you can, by snapping to points around it, create a new 2d object to modify the extrude. By doing a "cut" and "paste in place" into the extrude edit space, you would have your new geometry precisely and quickly. There are other workflows that would benefit greatly from these improvements. Combine the 2 improvements, and you could use the 2d editing tools directly on the shape of an extrude when in Top/Plan view.
Vectorworks 2017
in General Discussion
Posted
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 problemfree.