Interference

[bcd]

I've long wished VW would tackle the issue of interference / fit / tolerance in a comprehensive way.

We do have an existing issue with coplanar surfaces causing geometry & rendering fails (features?). Perhaps herein lies a germ of the solution:

An interference on/off switch.

This would allow coplanar objects to exist (as in a book lying on a table) and render appropriately. It may also offer a valid starting point to enable/disable 3d interference-aware modeling.

[Benson Shaw]

+1

bcd's ideas are right on. A common strategy to resolve 3d render problems with interfering surfaces is to nudge them apart. Sometimes the separation required for clean render is greater than required drawing precision. We shouldn't have to do this at all.

I'm not trained in this, so curious - How is interference handled in old fashioned 2d linework drafting (mechanical design standards)? In a section, say of a glass sitting on a table, the bottom of the glass would overlap the table top. But how is this typically represented? Is the glass nudged up so that the table is revealed? If so, how are dimensions handled.

-B

[PVA - Admin]

I think a UI element that would call attention to coplanar geometry would be very useful, a visual alert for a user that could be disabled, perhaps one that would appear before a Renderworks rendering, but could be dismissed at will/permanently if the user chooses.

I only say an alert system rather than asking Vectorworks to resolve the situation automatically, because if there are coplanar objects, what would make one of them the "correct" surface to render and hide the other? How would it determine which way to nudge one of the surfaces, if that was what was needed? As far as the rendering engine knows, they are both equally important and in the correct position.

Another thought though... should it just pick one of the surfaces so that you have a chance of getting the correct result, as opposed to the coplanar collision-look which is ALWAYS incorrect?

[Kevin McAllister]

This is an interesting discussion and feeds into more than just rendering. These overlaps or co-planar surfaces cause more than just rendering errors. They can cause problems with solids operations and with STL exports for 3d printing.

(See http://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Main=37563&Number=190541#Post190541 ) for a wish about tolerances and solids operations)

Going the opposite way causes different issues (ie. actually modelling in tiny spaces between objects) like failed solid additions and double lines in renderings. I agree with the original wish that VW needs a way to address this.

Software like Adobe Illustrator deals with this in a 2d way where the user is given the option to stroke and object along its boundary, inside its boundary or outside it boundary. Perhaps the entire VW geometry system needs to recognize and live within an objects exterior boundary....

Kevin

[Benson Shaw]

Interesting - stroke options to define object or dims of the object at edge of line instead of center. Same as kerfing in cutting operations.

Not being critical of ideas here. Just trying to understand:

Isn't the math the same? The stroke/lineweight is a graphic convenience to display the surface extents in various ways. The vectors represented by those stroked lines have no thickness. Two surfaces would still be coincident even if alternately stroked. If the two objects interfere (coincident) when both are determined at center of line, wouldn't they still interfere if one is inside stroked and the other is outside stroked?

On the other hand, what happens during a render when two surfaces intersect? eg crossed planes. Vectorworks seems to handle that with no problem, even though the intersection is an interference zone.

-B

[PVA - Admin]

On the other hand, what happens during a render when two surfaces intersect? eg crossed planes. Vectorworks seems to handle that with no problem, even though the intersection is an interference zone.

-B

A number of things can happen.

In these images, I have drawn two walls at exactly the same location, and size. One with a brick texture and one with a carpet texture.

In OpenGL, the graphics module normally picks one and forces that object to be the rendered surface, I do not know how it picks which one but in this example the brick wins:

[img:center]http://techboard.vectorworks.net/ubbthreads.php?ubb=download&Number=10383&filename=2wallscoplanarOpenGL.PNG[/img]

However in the two below, I have rendered in Final Quality Renderworks, and the only difference is a slight change in view angle. You can see it both picking a different texture per-face in one example, as well as an odd blending/hashing of two textures together in the other:

[img:center]http://techboard.vectorworks.net/ubbthreads.php?ubb=download&Number=10385&filename=2wallscoplanar2.PNG[/img]

[img:center]http://techboard.vectorworks.net/ubbthreads.php?ubb=download&Number=10384&filename=2wallscoplanar1.PNG[/img]

Edited March 14, 2014 by JimW

[Benson Shaw]

I've noticed this, too. In animations, it can used as a "shimmer" feature if the two textures or colors are chosen with care. Even works with walk through in Open GL (well, it did up to v2013. I haven't tested that file in 2014).

I was thinking of the simpler situation of crossed planes or other linear intersections of textured surfaces. Vectorworks manages to calculate the same points from two definitions, but that never seems to present a "shimmer" or other problem.

-B