P Retondo

I've had problems with auto hybrid objects, but I've heard on this forum that a lot of visibility issues have to do with the "cut plane elevation" setting. In tinkering with this object type, that setting remains mysterious i.e., I can't make an object below the cut plane disappear, but, like I say, allegedly it does something. You also have the key visibility options, 2d only, or 2d and 3d. There are also settings related to the class of the hybrid objects, and it can happen that an object appears on screen after it's been pasted, even though it's class is set to invisible, but once something is done it disappears. As a VW user for over 25 years, I still can't figure out why auto-hybrid was invented, but one thing is for sure - they require a lot more study and understanding than I've been willing to devote to them. A lot of manufacturers seem to favor these concoctions in their downloadable content, and it's been nothing but a pain. I tend to think that Art probably has the right idea. In edit space, select all and press <ctrl+6> to see everything, that might clarify what is in the object.

MH, you're converting to lines, but the lines are probably "layer plane" lines. To fix this, convert them in the OIP to "screen plane" lines. To avoid this happening in the first place, make sure your preferences are set to "screen plane only".

The "line style" – solid or dashed – is controlled by the default set in the Attributes palette. Change that, and your lines will be drawn as you wish them to. You set the defaults in the attributes pallet by changing the settings with nothing selected.

What Alan said. Your symbol instances can be scaled, so when you change the profile all the lengths will remain the same. Extrusion symbol.pdf

Yes, rD, same issue. Do you find the specific steps I outlined cause the error for you?

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

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?

Digital, those are nice drawings - but what is the difficulty you are having?

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.

Matt, sounds like a job for the mask! I can't tell you how many times I have had to mask over glitches in VW automation, I sometimes think it's easier to mask than to even think about a better way.

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.

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.

Every text object has its own rotation parameter in the OIP. You can select all the text and edit that parameter in the OIP in one operation.

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

Alan, if you end up confirming this I'll submit a bug report.

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.

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

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.

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

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

Wow! Wow. Wow.

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.

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

Brilliant bug report ideas, Jim