Unexpected results for a cube with holes in its faces

[winksaville]

I've tried to recreate the cube with holes in the faces similar to what's shown in the csgrs/README.md. But I've obviously done something wrong, below is the code, here is a repo:

use nalgebra::Vector3;

fn main() {
    // Alias the library’s generic CSG type with empty metadata:
    type CSG = csgrs::csg::CSG<()>;

    // Create two shapes:
    let cube = CSG::cube(2.0, 2.0, 2.0, None);  // 2×2×2 cube at origin, no metadata
    let sphere1_25 = CSG::sphere(1.25, 16, 8, None); // sphere of radius=1 at origin, no metadata
    let trans_sphere1_25 = sphere1_25.translate(Vector3::new(1.0, 1.0, 1.0));

    // Difference one from the other:
    let difference_result = cube.difference(&trans_sphere1_25);

    // Write the result as an ASCII STL:
    let stl = difference_result.to_stl_ascii("cube_minus_trans_sphere1_25");
    std::fs::write("cube_trans_sphere1_25_difference.stl", stl).unwrap();
}

Here is what f3d is displaying:

Please let me know what I've done wrong.

[timschmidt]

Thanks for reporting this! I'm not yet sure what's going on, but I am able to reproduce it all the way back to 0.2.0. Still some bugs to shake out of csgrs, it's only really been under active development for a little over a month. I'll see what I can do about tracking the cause of this issue down. Might take a couple days.

[timschmidt]

Well, I'm not quite sure what it means yet, but these are the same two shapes differenced from one another. Only difference is the translation. I know the answer is in this image, I'm just not quite sure what it is yet.

[timschmidt]

The plot thickens. Positive and Negative look like, well, positive and negative versions of each other. Clearly something funky going on.

[winksaville]

For what it's worth I changed the code to take the sphere_trans and sphere_radius from the command line provides equally interesting results:

use std::env;

use nalgebra::Vector3;

fn main() {
    // Alias the library’s generic CSG type with empty metadata:
    type CSG = csgrs::csg::CSG<()>;

    let args: Vec<String> = env::args().collect();
    let sphere_trans = args[1].parse::<f64>().unwrap();
    let sphere_radius = args[2].parse::<f64>().unwrap();

    // Create two shapes:
    let cube = CSG::cube(2.0, 2.0, 2.0, None);  // 2×2×2 cube at origin, no metadata
    let sphere = CSG::sphere(sphere_radius, 16, 8, None); // sphere of radius=1 at origin, no metadata
    let trans_sphere = sphere.translate(Vector3::new(sphere_trans, sphere_trans, sphere_trans));

    // Difference one from the other:
    let difference_result = cube.difference(&trans_sphere);

    // Write the result as an ASCII STL:
    let name = &format!("cube_trans{:0.2}_sphere{:0.2}", sphere_trans, sphere_radius);
    let stl = difference_result.to_stl_ascii(name);
    std::fs::write(name.to_owned() + "_difference.stl", stl).unwrap();
}

Here I have sphere_trans at 0.00 (no translation) and just change the sphere_radius from the your original 1.00 to 1.25 and it behaves as expected:

cargo run -- 0.00 1.25

Then nudge sphere_trans at 0.10 sphere_radius stays at 1.25 and cube is gone:

cargo run -- 0.10 1.25

[winksaville]

I've pushed the above to my repo: https://github.com/winksaville/cadx-csgrs-example1 with other examples

[timschmidt]

There's definitely something fun going on in the polygon clipping code related to signedness and distance from origin. I've started instrumenting functions to see if I can find it.

[winksaville]

definitely funkiness :)

[timschmidt]

This should be fixed in 0.15.2. Issue was that I needed to recalculate plane normal / w on each transformation to keep the BSP logic happy. Thanks for reporting the issue, that was a good bug to get worked out.

[winksaville]

Great, 0.15.2 working for me too, TXS!

cargo run -- 1.00 1.25: