Jump to content

P Retondo

Member
  • Content Count

    1,704
  • Joined

  • Last visited

Posts posted by P Retondo


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

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


  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.

    • Like 1

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


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


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


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


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


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


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


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

 

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.

×