Jump to content

Andrew Bell

Vectorworks, Inc Employee
  • Posts

    16
  • Joined

  • Last visited

Reputation

9 Neutral

Personal Information

  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Possibly a fix for some other issue didn't slow that issue down significantly but did slow down handling a complex object like that. It looks like the next service pack should handle that object significantly faster.
  2. It looks like it's spending a lot of time in several of the viewports on a toilet that is invisible in the final rendering. Does hiding the A_PLAN-FF&E-EQUIP class give you a significant speedup and the results you're looking for?
  3. The triggering issue was shadow generation, as the window geometry was supposed to be put in the collection of geometry only for creating shadows but was instead being put into the geometry to be rendered. This has been fixed and the fix will be in an upcoming service pack.
  4. There shouldn't be any difference in this case between an extrude object or a generic solid, assuming they have "Merge with Structural Objects [...]" checkbox checked. I experimented a bit and was getting split lines in some cases but not others, though the fill was merged. (You can test that the fill has been merged by converting the viewport to a group, and checking if the fills inside the group that you expect to be combined are combined into a single polygon or polyline.) The merging can't simply use our standard Add Surface code because the incoming objects might have different pens from each other, no pen on certain edges, or even different pens on different edges (such as the individual component polygons from a wall with components.) That's why if you do that conversion of the viewport to a group, you'll find the edges are separate objects from the fills, and they are always drawn on top of the fills. It looks like in certain cases edges that should have been removed because they would be covered by the fills are not, and then they're being drawn on top. This should be reported as a bug if it hasn't already.
  5. It's a bug. Hidden line is incorrectly assuming all Add/Subtract/Intersect Objects create enclosed surfaces, when certain ones like this (extrusions of lines, in particular) do not. A workaround is to convert it to NURBS, which will turn it into an unconnected set of NURBS surfaces that render correctly in hidden line.
  6. The rotated view hidden line is a raster (bitmap) approximation using OpenGL, which does doesn't not support line weights, determining intersection lines, eliminating lots of wall join lines, etc. Nor can it be converted into lines, because it's just unconnected dots. It gets drawn as a placeholder until the final hidden line results can be drawn.
  7. Thanks to the nudge, this will be fixed in an upcoming service pack for VW2017.
×
×
  • Create New...