Correct Tools Query Call for opBoolean Union of Shelled and Intersected parts

jasen_raboin

Very frustrated.  I'm at the very end of my Feature script that creates 3D lattice infill for parts and I can't get the last operation to work

Below is the tail end of my script, the very last operation "//Union of Shell and Intersect" always throws an error 

"@opBoolean: BOOLEAN_BAD_INPUT".  I've tried everything from calling the shell and intersects, setting attributes and calling the attributes, creating variables to assign the qUnion to and using the variable.  There is something about the order of operations that i don't understand where I can't query the right thing.  By the way, you can manually create the Union outside of FS, so I know it can be done! Any help would be appreciated.

        // do this only if the 'preview' option is un-checked

        if (!definition.BeamPreview)

        {

            // Union of all Beams

            opBoolean(context, id + "Union1", {

                        "tools" : qAttributeQuery("Beam"),

                        "operationType" : BooleanOperationType.UNION

                    });

            // Make a copy of the part to fill

            transform(context, id + "Copy1", {

                        "entities" : definition.PartToInfill,

                        "transformType" : TransformType.COPY

                    });

            //Intersect Copy with Beams

            opBoolean(context, id + "Intersect1", {

                        "tools" : qUnion([qCreatedBy(id + "Copy1", EntityType.BODY), qAttributeQuery("Beam")]),

                        "operationType" : BooleanOperationType.INTERSECTION

                    });

            //Shell Original Part

            opShell(context, id + "Shell1", {

                        "entities" : definition.PartToInfill,

                        "thickness" : -definition.WallThickness

                    });

            //Union of Shell and Intersect

            opBoolean(context, id + "Union2", {

                        "tools" : qUnion([definition.PartToInfill, qCreatedBy(id + "Copy1", EntityType.BODY)]),

                        "operationType" : BooleanOperationType.UNION

                    });

        }

        // endif BeamPreview

jasen_raboin

Ran debug on all queries for the Union1, Copy1, Intersect1, Shell1, definition.PartToInfill.  All resolved to nothing except Intersect1 and definition.PartToInfill which resolved to 1 body. So I used those two entities in the query call and it worked!  I should use debug more often!  So bottom line is that an opBoolean Intersection takes over the attributes of the tools used which then go to nothing.  However a opShell does not affect the attributes of the tool entity and the shell query is nothing. Thanks.

ilya_baran

This is hard to debug from just the snippet you shared.  Please make a version and share a link to it so we can see what's going on.
A piece of general advice is to use

debug(context, qCreatedBy(...))

to see what a query resolves to.

lana

Try calling debug(context, qCreatedBy(id + "Copy1", EntityType.BODY)) right before this opBoolean call. I suspect you need to track it through intersection Boolean : 
var trackIntersectionQ = startTracking(context, qCreatedBy(id + "Copy1", EntityType.BODY));
in the last boolean use qUnion([definition.PartToInfill, trackIntersectionQ]);

jasen_raboin

Ran debug on all queries for the Union1, Copy1, Intersect1, Shell1, definition.PartToInfill.  All resolved to nothing except Intersect1 and definition.PartToInfill which resolved to 1 body. So I used those two entities in the query call and it worked!  I should use debug more often!  So bottom line is that an opBoolean Intersection takes over the attributes of the tools used which then go to nothing.  However a opShell does not affect the attributes of the tool entity and the shell query is nothing. Thanks.

NeilCooke

Have you tried opPattern instead of transform/copy - that is the preferred method

jasen_raboin

what's the syntax to make a copy in place?

NeilCooke

opPattern(context, id + "Copy1", {
                        "entities" : definition.PartToInfill,
                        "transforms" : [identityTransform()],
                        "instanceNames" : ["1"]
                    });

NeilCooke

If you copied the code from the HexInfill feature, that was using the old FS library.

NeilCooke

Although if Union1 is failing, so will everything else.

jasen_raboin

That worked, thanks.  Just FYI, would be nice to have the transforms parameter under opPattern linked to the section that describes transforms in the Std Library Documentation.  

Jake_Rosenfeld

I've logged this in our system.  Thanks for the suggestion @jasen_raboin

philip_thomas

Just like Peter Parker was told, "With great power comes great responsibility".




Onshape is a very powerful and open system - you can do things (like build a lattice) that are impossible in other systems.
That said, a lattice will be VERY VERY VERY VERY SLOW!
Think about it, a casting may have 100 faces - a lattice will have 10,000 or 100,000 faces. This is more than any part you would ever design.
This large number of faces will manifest in very slow boolean times (almost definitely longer than the 10 minute time out for custom features) and even if it succeeds, the complexity of the body will cause very long open times and very long operation times.
Bottom line, please do not create lattices of any complexity.

This is not a limitation of Onshape, this is a limitation of Brep modeling.

I hope this helps