Whatever you did, it is notable for opening up a portal to the netherworld right through my computer screen! It is not new to me that buggy display glitches can be found when zooming and panning around SCAD designs. However the bug that you triggered with your shell code is more persistant than any I ever found! We might be expand on it and learn to control it for real dimensional travel and exploration!
Anybody gets similar effects? I use Windows 7 with AMD Radeon graphics...
Not a bug. That's a known "feature" of the preview, usually caused by an insufficient "convexity" parameter in a key place. If you render the part for saving as STL, it should look fine.
Are you serious now? I never understood what that convexity parameter was good for, and I also dont see to which statement it could even be applied?
The convexity parameter basically tells the preview engine how many intersections a ray of light would have with a part. A convex part has a convexity of 2 (a ray goes in, and then comes out, two intersections). A concave part, such as a bowl, has a convexity of 4 (a ray can go in and out through each wall, total of four intersections). The letter E would have a convexity of 6 (a ray going vertically down through it would intersect six times going through each leg of the E). If you extrude a concave shape, the default convexity is 2, and you'll get these visual artifacts unless you set the convexity to 4 or higher. For efficiency, the OpenSCAD preview uses a convexity of 2 by default.
This affects only preview. If you render the part for saving as an STL file, the rendering engine doesn't need the convexity parameter and the render doesn't have those visual artifacts. You can see this when you render the part being discussed here; the artifact disappears.
However, you are correct that the code for this part doesn't have any statements that take a convexity parameter. So the preview engine is going to show this. The bug isn't the fact that this artifact appears (that is expected, by design). The bug is that there is no option in any of the statements to get rid of it for this particular case.
thanks for that explanation! I am surprised that there is not simply an environment variable that can be set?
I tried adding:
rotate_extrude(angle=360, convexity =6) translate([100,0])circle(r=1);
and it didn't change anything...
however adding a
before the boolean operation that creates the penomena indeed brings the results back to conventional projectable 3d space...
I normally avoid sticking render() into my code, as it really slows things down when I need to make a minor update. I've downloaded OpenSCAD code in which the author put render() everywhere and the thing took 10 minutes before I could make any changes or before anything would appear on the screen. The first thing I do when I get someone else's code is to remove any render() calls. I don't mind the preview artifacts.