OpenSCAD preview bug: after rendering parts of model are missing by rotation

[Hermann-SW]

I noticed a preview display problem for OpenSCAD model nearly completely filling view. I stored the model here:
https://stamm-wilbrandt.de/en/forum/C60.preview_problem.scad.txt

With 10-step 1fps animation the problem clearly shows like this:

I see this problem with OpenScad preview under Pi400 64bit Raspberry Pi OS (based on Debian), as well as on Intel Celeron J4125 with Ubuntu 22.04. Also the cuts shown are not along the gray spherical triangles I create with modules, so I would say this is caused by OpenSCAD previewer.

Unrelated, but I generated same model for JSCAD, and JSCAD in browser does not have this partially missing view issue:
https://openjscad.xyz/?uri=https://stamm-wilbrandt.de/en/forum/C60.preview_problem.jscad

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[jordanbrown0]

Note for the future: it makes it a lot easier for people looking at your problem if you can reduce it to the simplest program that demonstrates the problem, rather than asking them to understand a 400-line program.

I suspect that what's happening is that the previewer doesn't like it if the camera is inside any part of the model - notably including the invisible parts that are used to cut away from the model.

Here's a simple program that demonstrates that problem:

difference() {
    sphere(10);
    cube(1000);
}

As you rotate the view, when the camera is in +XYZ the side of the sphere reappears.

Whether this is a bug or a limitation, shrug, but it's a known behavior. The previewer cheats a lot to get performance, and this is one of the places where the cheating shows.

I see that your model has significant chunks of invisible geometry used to cut away from the model. (You can see them with View/Thrown Together.) Check to see if the artifacts that you are seeing are tied to having the camera inside those volumes.

[Hermann-SW]

Thanks for the comments.
Sorry for the 400-line program, it is autogenerated by node.tetra.js from my planar_graph_playground ...
https://github.com/Hermann-SW/planar_graph_playground/blob/main/node.tetra.js
... and embeds any planar embedding onto sphere.

Most of the difference()s go to the inside, the big sphere to get white sphere hull only, and small cubes to remove half of the vertex spheres inside (right):

Oh, and there really is one difference() that goes to the outside, for each of the spherical triangles.
I had to use difference() with hexagon to cut ovverlapping stuff from union of 2 sp_tria2()s that should build a single spherical triangle:
https://forums.raspberrypi.com/viewtopic.php?t=333342&sid=dc083482c0247511935f106f2a9d318d&start=50#p2023738

I will try to generate a small standalone example, but I am pretty sure that camera position is not inside, although that could explain behavior based on your comments.

[Hermann-SW]

Wow, you were right.
I replaced the "difference()" with hexagon hull() with union():
https://stamm-wilbrandt.de/en/forum/C60.preview_problem.2.scad.txt

<         intersection() {
---
> //        intersection() {
>         union() {

Need to investigate why there are hull()s reaching out soooo far! (that get difference()d away normally):

[Hermann-SW]

Not exactly the same view, but already demonstrates what happens with the too far reaching out difference()d hexgon hull()s:

[Hermann-SW]

I should have read

(You can see them with View/Thrown Together.)

then no change "difference() --> union()" would have been needed to see the same thing.

[Hermann-SW]

Now I did capture animation from same camera position, first with "Preview", then with "Thrown Together".
I don't understand why the gray parts that become visible in "Thrown Together" mode are the parts that are missing in "Preview" mode:

[nophead]

When OpenCSG draws the preview it draws both the positive and negative objects. If the negative objects are too close to the camera the faces that cross the front clipping plane are not drawn and that breaks the simulated CSG difference.

[jordanbrown0]

Yeah, like I said, the previewer cheats. It stacks up triangles with exactly the right modes in exactly the right order to simulate boolean operations. It can do that very fast, but there are a number of ways that it's fragile.

[jordanbrown0]

Nophead makes a good point: I said that the problem was when the camera was inside the model. That's not quite right. It's when the camera is too close to the model, because stuff that's closer to the camera than a certain distance is dropped.

[Hermann-SW]

Thanks for the explanations.
The embedded graph is a fullerene.
All fullerenes have exactly 12 pentagons.
So there are 36 sp_tria() calls for spherical triangles.
I commented out the sperical triangles in 11 of the other pentagons, and for the 12th I commented out the two other sp_tria() calls. And in sp_tria() I commented out one sp_tria2() call.

This time no rotation, but varying distance with $vpd = 34.6+$t*1:
https://stamm-wilbrandt.de/en/forum/C36.preview_problem.3.scad.txt

This is 10step animation with "Preview":

This is 10step animation with "Thrown Together":

So the problem happens when moving out of the convex hull of hexagon, as @jordanbrown0 said.

Here is new approach I tried, much less maximal distance (~12) than before (35), radius of white sphere around origin is 6.
I will work on getting more close triangle of the hexagon I use to difference() from the sp_tria()s ...

[Hermann-SW]

Thanks for all the information.
I did rethink the problem I wanted to solve with difference() to hexagon hull().
And I came to conclusion that using centroid of vertices of spherical triangle was wrong.
What was needed was to determine the distance of the plane spanned by triangle vertices to origin.
Then taking inverse of that distance as factor (plus 1% to be sure) results in least invasive hexagon.
Just committed the small diff, small because OpenSCAD provides needed "cross()", "norm()" and vector operations:
Hermann-SW/planar_graph_playground@e4bfce2

Toggling "Preview" and "Thrown Together" views:

You can close this issue based on explanations on how OpenCSG preview works for delivering fast viewing experience.