Pyramid, tetrahedron or cone...

[Alphapage]

Hello,

I'm trying to make pyramid which seems to be made of multiple tetrahedrons.
I created a sketch, but I don't know how to sweep to only point to one vector or to sweep to another sketch.
Didn't try, but it seems to be impossible to make a cone ?
Am I true ?

Thank you in advance for your help.

[hannobraun]

Thank you for your interest, @Alphapage!

Before I go into specifics, a general note: Right now, only low-level tools to build geometry exist, for the most part (except sweep, but that's pretty limited, as you discovered). Building higher-level tools on top of them to make this more convenient will happen gradually. But for now, what you're trying to do is pretty involved.

First, a tetrahedron: This one's actually easy, because there's already a builder method to do it (it's used in various unit tests, where a basic solid is needed. Check out BuildSolid::tetrahedron.

Second, a pyramid: That is much the same as a tetrahedron, except that one of the faces needs to be a polygon instead of a triangle. You can look at the code that builds the tetrahedron for inspiration. Some notes:

• Joining the cycles together (as is done in BuildShell::tetrahedron is pretty inconvenient, using indices to refer to the edges within the cycles. I have ideas for how to improve this, but for now it is what it is.
• You can use BuildFace::triangle to build the sites, but there's currently no method for polygons. You need to create your own code for this, adapting BuildFace::triangle's implementation.
• Speaking of that implementation, it's not as nice as it could be. I'm not sure if there already are other operations that could be re-used to make it neater. If there aren't, those need to be created.

Lastly, the cone. I agree that it's probably not possible. I don't think we can currently represent the geometry of the side face.

---

I've made a bunch of notes on stuff that's missing or needs to be improved while writing this. I will open some issues to track those improvements later, probably on Monday.

---

Issues are for tracking actionable improvements. My answer mentions a few of those, but I prefer to open more specific issues for those later. Converting this to a discussion.

[hannobraun]

Short update: I haven't found the time to open those issues yet. It's on my list of things to do, and I'll get to it when I can.

[hannobraun]

I found some time to open the first two issues that relate to what I note here:

• Introduce new notion of object ID that survives updates #1904
• Make it easy to build polygonal faces #1905

[Alphapage]

Well, finally my goal to create a pyramid is to glue 2 tetrahedrons. Here is my code snippet:

let handle_pyramid = {
        let shell = Shell::tetrahedron(
            [[0., 0., 0.], [0., 1., 0.], [1., 0., 0.], [0.5, 0.5, 1.]],
            services,
        )
        .insert(services);
        let shell2 = Shell::tetrahedron(
            [[1., 1., 0.], [0., 1., 0.], [1., 0., 0.], [0.5, 0.5, 1.]],
            services,
        )
        .insert(services);
        let solid = Solid::empty();
        solid.add_shell(shell.shell).insert(services);
        solid.add_shell(shell2.shell).insert(services)
    };

But I only get the second tetrahedron drawn instead of both!
I don't understand the concept of services, so maybe it is the problem and do you plan to make it less verbose services, ) .insert(services); because it is redondant in my opinion.

Sorry to disturb you and thank you to give me a little of your precious time.

[hannobraun]

I wouldn't expect what you're trying here to work. Just putting those two shells next to each other would not create a pyramid, as there still is an interior face separating the two tetrahedrons. To make it work like you desire, you'd need a union operation, which isn't implemented yet (#42).

The desired outcome of doing this would actually be a validation error, because the coincident faces are most likely a mistake. This is another issue I need to open 😄

Why it shows only one of them, I don't know. I'll have to look into that!

I don't understand the concept of services, so maybe it is the problem and do you plan to make it less verbose services, ) .insert(services); because it is redondant in my opinion.

No, that's not the problem. Services contains the data structures that objects are stored in, infrastructure for validation, as well as some debug infrastructure that isn't really used, currently.

Having to provide it to so many method calls is verbose, but it is also needed. There is no global state in Fornjot, so all these methods need a way to access the data structures. There's probably a more clever way to do it though.

Sorry to disturb you and thank you to give me a little of your precious time.

No problem, you're welcome!

[hannobraun]

I tried out your example code, and the problem is a rather simple one:

let solid = Solid::empty(); // create an empty solid
solid.add_shell(shell.shell).insert(services); // create a new solid, but throw it away immediately
solid.add_shell(shell2.shell).insert(services) // add shell to the original empty solid, use the result of that

Fixed code:

Solid::empty()
    .add_shell(shell.shell)
    .add_shell(shell2.shell)
    .insert(&mut services)

That results in a validation error, as expected:

`Solid` validation error
    Solid contains Vertices that are coincident but not identical

        Vertex 1: Vertex @ 0x56044830316e => Vertex ([1.0, 0.0, 0.0])
        Vertex 2: Vertex @ 0x560448303162 => Vertex ([1.0, 0.0, 0.0])

Two notes:

• We can prevent this mistake, by adding #[must_use] to the operations methods.
• It seems that BuildSolid::tetrahedron gets the face orientation wrong (the faces shouldn't be that dark).

Two more for the list of issues I have to open!

[hannobraun]

Earlier, I wrote this:

It seems that BuildSolid::tetrahedron gets the face orientation wrong (the faces shouldn't be that dark).

This is actually wrong. The documentation of BuildSolid::tetrahedron references BuildShell::tetrahedron, which documents its requirements regarding the order of points.

What's actually missing here is a validation check, that makes sure the face orientation of Solid is correct. I've added that to my list of issues I have to open.

[Alphapage]

Yes my mistake sorry because of the chaining.
I get the pyramid as expected, but nothing is thrown to notify the validation error!
It seems to work fine except that first tetrahedron is red and the other is black.
Where do you find the validation error ?

[hannobraun]

No need to apologize!

The validation error is printed as output. The model program is aborted when that happens, and the viewer window doesn't open. So it should be quite obvious.

Maybe there's a difference in the code we used? I don't have mine handy anymore, but I basically inserted your code into the cuboid example and made the replacement I wrote about above, to fix the chaining.

[Alphapage]

I just click "debug" in the main.rs cuboid example from vscode after upgraded to the pyramid code.
The viewer shows without any validation error.
Maybe I am missing some parameters by using this shortcut.

[hannobraun]

Could you post your full code again? Maybe I can reproduce it.

[Alphapage]

I just copy paste cuboid folder then replace lib.rs with:

use fj::{
    core::{
        algorithms::sweep::Sweep,
        objects::{Cycle, Face, HalfEdge, Shell, Sketch, Solid, Surface},
        operations::{
            BuildFace, BuildHalfEdge, BuildShell, BuildSketch, BuildSolid,
            BuildSurface, Insert, IsInserted, IsInsertedNo, IsInsertedYes,
            JoinCycle, Polygon, UpdateFace, UpdateSolid,
        },
        services::Services,
        storage::Handle,
    },
    interop::ext::ArrayExt,
    math::{Point, Vector},
};

pub fn pyramid(
    x: f64,
    y: f64,
    z: f64,
    services: &mut Services,
) -> Handle<Solid> {
    let handle_pyramid = {
        let shell = Shell::tetrahedron(
            [[0., 0., 0.], [0., 1., 0.], [1., 0., 0.], [0.5, 0.5, 1.]],
            services,
        )
        .insert(services);
        let shell2 = Shell::tetrahedron(
            [[1., 1., 0.], [0., 1., 0.], [1., 0., 0.], [0.5, 0.5, 1.]],
            services,
        )
        .insert(services);
        let solid = Solid::empty();
        let solid1 = solid.add_shell(shell.shell);
        let solid1H = solid1.insert(services);
        let solid2 = solid1H.add_shell(shell2.shell);
        let solid2H = solid2.insert(services);
        solid2H
    };

    handle_pyramid
}

and main.rs with:

use std::{ops::Deref, path::Path};

use fj::core::algorithms::transform::TransformObject;
use fj::core::algorithms::{approx::Tolerance, triangulate::Triangulate};
use fj::core::services::Services;

use fj::handle_model;

fn main() -> fj::Result {
    let mut services = Services::new();

    let pyramid = pyramid::pyramid(3., 2., 1., &mut services);

    // The tolerance makes no difference for this model, as there aren't any
    // curves.
    let tolerance = 1.;

    let mesh = (pyramid.deref(), tolerance.into()).triangulate();

    fj::export::export(&mesh, Path::new("./pyramid.stl"))?;
    fj::export::export(&mesh, Path::new("./pyramid.3mf"))?;
    fj::export::export(&mesh, Path::new("./pyramid.obj"))?;

    handle_model(pyramid, tolerance)?;

    Ok(())
}

I watched your work and found you added "merge" operation today, but it simply adds other shells: shouldn't the operation remove duplicate faces ? Otherwise merge = add

[hannobraun]

Ah, I see what's going on. The relevant difference is your main.rs.

Validation is done on the fly, as geometry is constructed, by one of the services in Services. Validation errors are stored within Services. The idea is, that fj-viewer can display them together with the graphics one day, but for now, all that's done with them is to print them when Services is dropped.

Your services variable is simply not dropped, before the viewer is started. Why it's still not printing errors after the viewer exists, I don't know. It's probably due to the specifics of how winit (the windowing library we're using) is ending the program.

I watched your work and found you added "merge" operation today, but it simply adds other shells: shouldn't the operation remove duplicate faces ? Otherwise merge = add

It's deliberate that this is a very simple operation, because that's what I needed at that moment. Whether "merge" is the right name for it, I don't know.

[Alphapage]

I'm a little lost now: I exported to 3mf, stl and obj.
From Xcode, stl and obj seem to be cutted from inside.
Depending on 3d engines from online viewer, it shows a pyramid!!!
I think Xcode must show the true result, so there is something wrong with fj::viewer : maybe it shows the same 3d object, but the black part doesn't reflect the cutted edge.

[hannobraun]

I'm not surprised that you're getting different results. The 3MF file is definitely not valid, as the face orientation of the black part is wrong (the part is basically inside-out). And if the two tetrahedrons indeed form a pyramid, then there's still the inner wall where they touch, which is probably also not valid. STL is less strict, and doesn't define what's valid or invalid, as far as I know, and I don't know about OBJ. But still, the triangle mesh you're generating is very weird, regardless of format, so I'm not surprised you're getting weird results.

Eventually, Fornjot should catch all that with its own validation errors and only export valid geometry, but we aren't there yet.

[Alphapage]

I continue investigation.
What I don’t understand is why not all facets are counterclockwise ? In my opinion, this is where to digg !
For example, if I remove facets inside the 2 tetrahedrons from triangles before exporting to slt then it should generate the right file, but I must update 3 facets of 6 to make them counterclockwise and get the right slt.
All 6 facets should be counterclockwise from the mesh supplied to fj::export .

[hannobraun]

What I don’t understand is why not all facets are counterclockwise ?

That's easy! As I wrote earlier, there is a documented requirement on the order of points provided:
https://docs.rs/fj-core/0.47.0/fj_core/operations/trait.BuildShell.html#method.tetrahedron

The first shell does not meet those requirements, the second shell does.

[hannobraun]

I marked all relevant methods of the operations API as #[must_use], which should help prevent one of the issues we've seen here: #1934

And I've opened an issue about validating the face orientation of Solids: #1935

This is all that was left on the list I made from this discussion. As far as I know, every problem we saw here has been addressed (in the sense that at least an issue was opened to track it).