Andrew Bell
-
Posts
32 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by Andrew Bell
-
-
2 hours ago, line-weight said:
This bug has been resolved for an upcoming update.
-
1
-
-
3 hours ago, line-weight said:
@Andrew Bell I would be interested to know, whether viewports rendering differently according to my zoom level, viewing a sheet layer, is something that is working as intended. Surely the rendering-out of a viewport should be consistent regardless of how I happen to be viewing the sheet layer at the moment of update.
That is definitely unintentional, as there is code specifically meant to prevent it. Structural changes to support multithreading and backgrounding of viewport updates have made it so the condition it checks to prevent it is no longer true. So that's a bug.
-
The offset of planar objects is done to make stacked, coplanar planar objects look like the plan-view equivalent, otherwise the overlapping objects will show all their lines (in hidden line), or with their fills overlapping and tearing (in Shaded rendering and possibly Renderworks.) If the objects are viewed face-on, you generally won't see the offset, but since it offsets based on the planar object's plane, if viewed edge-on the offset is most visible. It's actually happening in the iso view but because the offset is small, it's not apparent. For a workaround, do these need to be 2D polygons rather than 3D? The latter are not offset.
-
1
-
-
@BarrymacKOA Can you share a file with the two walls with us? Thank you!
-
If you create a viewport with only the design layer with the section viewport on it, does it show? A flattened, rendered section viewport won't be in the same "space" as the rest of the model.
-
This should be fixed in VW2023 SP3. Apologies for the inconvenience.
-
2
-
-
Are you seeing this only with files imported from earlier versions, or in new files as well?
-
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.
-
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?
-
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.-
1
-
-
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.
-
On 7/31/2017 at 6:47 PM, Tom Klaber said:
It is weird. Hidden line seems to rotate fine - but when you finish - it then asks you if you want to re-render - even though it seems as if it has the view you want ready.
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.
-
On 9/20/2016 at 8:00 AM, Matt Panzer said:
Yes, these are both separate known issues. I just linked this thread to the bug report for the dashed hidden line problem. It needed a little bump. ;-)
Thanks to the nudge, this will be fixed in an upcoming service pack for VW2017.
-
3
-
Objects in Hidden Line Renders are Randomly Red
in Troubleshooting
Posted
Inconsistent color changes seem like a bug. But are there any data visualizations or class colors that could be the source of the red? If you have nothing selected and turn off by class pen color, what color is your default pen? Maybe we can find the source of the red and change it as a workaround.