Jump to content

P Retondo

  • Content Count

  • Joined

  • Last visited

Posts posted by P Retondo

  1. I've discovered actions that cause the fill mode to switch from eyedropper to bucket spontaneously.  This is observed in v2016, can anyone confirm this before I submit a bug report, and does the same thing happen in v2017 which I haven't installed yet?  Here's the procedure:

    • Create a group
    • Set fill mode to eyedropper, and pick up a fill
    • Switch to select tool with <X>, select and enter the group with <ctrl+[>
    • Select an object, and activate the eyedropper tool with the keyboard shortcut
    • Without changing tools, exit group by <ctrl+]>.  Note eyedropper mode has switched to bucket

  2. There's a 3-dot depiction of a line in the OIP, and if you click on the endpoint dots you will see the coordinates X and Y.  I can believe I've never noticed this because I don't think I've ever tried it in all the years using VW, but if you modify a coordinate for the endpoint of a line in v2016, the WHOLE line moves, not just the endpoint.  Is this new behavior with v2016?  Does it make sense to anyone?  Seems like if we want to move the line, there are other ways to do that, but to be able to change the coordinates of the endpoints individually would be very useful - but not possible as things now stand.  Is this WAD (working as designed)?  A bug?  Would it be a desired feature, if not a bug, to be able to edit the endpoints individually, like we do with a polygon?

  3. Steebeebo,  after years of wishing there could be an easier way, our standard procedure is to convert 3d objects to lines, then using a combination of drawing over the lines, composing certain lines into polylines, and creating polygons using lasso and bucket modes, basically recreate the drawing in 2d over the geometry derived from 3d.  For me its the only way to get a classic heirachy of lineweights, distinguishing between objects seen in profile (a silhouette that can involve multiple objects), secondary objects seen in profile, corners of objects, and corners + other minor lines.

  4. It may not matter from certain perspectives, but imagine trying to cover such a shape with textile in the real world.  In this case the problems with applying a texture mirror the real-world problems of trying to cover an organic shape with planar materials.

    • Like 1

  5. Michael, thanks - bugsubmit engineer contacted me with the same observation, and when I restarted VW this morning, I'm not seeing the bug either.  So it's not a corrupted installation, but some state that is triggered by some as yet unknown event.  It does happen, trust me, and I created a new file to upload when I noticed this behavior in a project file I'm working on.  So the bug is not related to the file, either, but to some state that is a mystery.  Have you, or has anyone else, experienced this?  Jim, what is the VGM cache?  Not familiar with that.

    Whatever is going on, it happens frequently.

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

    • Like 1

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

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

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

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

  11. Eventually, and I know the first portion of this comes in 2017 but won't majorly affect users for another version or two, our file format rework will be complete and we won't need to have a new VWX version for each year. We will be able to only upgrade the format once every 4-5 years or only as needed. This will eventually mean that you won't need to export back to older versions within a range, only if the format handling was different.

    Wow! Wow. Wow.

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

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

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

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

  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.


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