Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by kyle.kyler

  1. I was working in a VW 2019 file today and realized that ALL of the information in the "Plant Data" tab of my plant symbols had been reset/overwritten to match the "field" name. There are hundreds of customized plant symbols that have been affected. The only reason the screenshotted plant's "Category" says Understory Deciduous tree is because I've begun manually correcting the issue. Despite the fact that all of these values have been reset in the Plant Data tab, information like Latin and Common name remain unchanged in the "Schedule" tab. This is a serious issue that negate months worth of work and diminishes my confidence in the reliability of the plant symbol system. What could have caused this? __________ Since posting the issue, I was able to find a recovery version of the file from several days ago where the plant symbols were unaffected. See screenshot below of the plant data tab with data as I had originally input. Please reply with an explanation of how this could have happened so that I can avoid it in the future.
  2. I have a similar question but don't need contours to be shown. Is there a way that Vectorworks can display the cut and fill shades in Top/Plan view? When I go to Top/Plan (a 2D mode) I am not able to see the shades on the model. When I go to Top view instead, the shades are visible, but this makes downstream issues for exporting. Essentially, when I try to export what should be a simple graphic of two polygons representing cut and fill over the site plan, the output is incredibly grainy and not usable as a sharable graphic. See PDF attached below. I have changed the output settings to be the highest quality/higher DPI but I think it's a more fundamental display issue of 3D elements in a 2D view which is the problem. When I look at the 2D/3D display options for the site model itself, cut fill is not a listed option for the site model in 2D. It would be great to add that as an option. Ultimately, we brought the grainy graphic into Adobe Illustrator to image trace but I'd rather keep everything in VW in the future. Cut and Fill graphic_grainy.pdf
  3. Thank you both for your replies. Bryan- there is a grade limit in the file that I have attached here, and it does significantly improve the site model. We will work to close our contours and remove overlapping conflicts. Tamsin- Thank you for the advice on bypassing the contour conversion step. I was not aware that assigning the 3D polys to the Site-DTM-Modifier class could be done instead. Have either of you had situations where you convert an object to a "contour" site modifier and it results in a "pad" site modifier? Thanks again
  4. Recently, our office has had some issues with 3D modeling while trying out the the Cut/Fill features of Landmark. Namely, portions of the model appear choppy, as if they are jumping around regardless of where our contour site modifiers are located. Most of the model is behaving as we would expect, but certain portions seem to be rogue. See attached images to see specifically what we are talking about. While creating the model, we noticed a few hiccups. For example, when creating contour site modifiers from our 3D polygons, we selected "Contours" in the drop-down menu. However, once the modifier was created, it appeared as a "Pad" in the OIP. We have manually changed this in the attached file, but are unclear about why this is happening. Although this is a recent issue, it has occurred on more than one file/project in our office. In previous months, contour site modifiers have been created from 3D polygons as expected. Even after altering the site modifier type in the OIP, any conflicts that pop up in the model are listed as intersecting "pads". The question is not whether or not a conflict exists (we can see where certain site modifiers do overlap), but we don't understand why they are listed as "Pad" intersections. Another potential issue: We've noticed that when contour site modifiers are selected, vertices display on the ground plane instead of on the actual elevation of the object. Does this present an issue in terms of modeling, or is this simply the way that the program displays vertices? Other actions we've taken: - Updated Vectorworks to the most recent service pack (2019 SP6). - Shifted the internal origin to be at the center of the model Cut Fill 3DM.vwx
  5. That was the issue - Thanks for the help!
  6. The issue is that even after moving the height of one vertex to 0, the round wall from Image two remains unchanged, i.e. the wall heights are even and there is not a ramp. Strangely, when I copy/paste the objects into a blank file, things are working as they should. I will send you a private message with both the clean file and my existing file to see where the discrepancy might be.
  7. @Matt Panzer - Thanks for the simple workflow for creating a curved sloping ramp. Unfortunately, it is not working for me. I wonder if something has changed since VW 2016, or maybe I have different settings for my round wall tool, but for some reason I can't get one end of the wall to move to elevation 0. I can get this to work for a straight wall, (Image 1) but curved walls stay at a constant height. Do you or somebody else know why this would be? In the attached images, I show the curved wall that I'm trying to edit, (Image 2) and how moving the vertex does not change the wireframe outline of the ramp. (Image 3) There is a red reference line that appears to accurately slope from the vertex at 0 and the vertex at 1.5' Changing render modes/adding textures has not resolved the issue. Regardless of what render mode I am in, the ramp remains flat. I also tried adding fill/textures to the class's attributes, but the slope remains unchanged. Strangely, if I set the wall to "curtain wall" instead of standard wall, the slope appears. (Image 4) Thanks for any insight y'all might have
  8. Thanks Bryan - That's what I was looking for. The model is working much faster on our end now.
  9. My office is having issues with site model file size and have been working through a variety of suggestions from VW staff. However, we continue running into problems. Here is our latest: We created a site model in Vectorworks via the following steps: 1. Existing topo created from original survey. a. CAD lines with 3D info. b. Converted to 3D polys. c. Simplified to 6 inches. d. Create DTM of existing topo. 2. Proposed Topo: a. Take 2D polylines and directly convert them to contours. This maintains the smaller number of vertices. It also means each contour needs the z-elevation assigned during the contour process. b. Make sure the contour creation is assigning the 2D polylines to “proposed” contours. c. Create a grade limit polygon. You can create multiple grade limit polygons if the disturbed areas are not contiguous. ______________________ Step 1 worked well, i.e. with a relatively fast processing speed and a manageable number of vertices. However, Step 2 did not go as well. Although the vertex number remained low for 2D polylines that were converted into site modifiers (Both contours and grade limits alike) – the Modifier Vertex Count ballooned whenever a line was changed into a site modifier. (See 191119_SiteModifierVertices.png) These vertices are not visible/editable like ordinary vertices, but the Site model is clearly being generated with these modifier vertices. In the other screenshots provided, you can see that although the site modifiers (in red) have few vertices, the model (in green) is triangulating with many more points of information. These screenshots are being taken at roughly the same place in the model. Does anyone have suggestions about how we can limit the modifier vertex count and create an efficient workflow moving forward? In order for you to walk through the issues outlined above, we included a clean file with: 1) Our existing survey lines as 3D polygons with a low number of vertices 2) The grade limits Site Modifier with a low number of vertices but a high modifier vertex count. 3) Our proposed contour Site Modifiers- all with low numbers of vertices but high modifier vertex counts. High Site Modifier Vertex Count.vwx
  • Create New...