Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:

  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

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

jasen_raboinjasen_raboin Member Posts: 4
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

Best Answer

  • jasen_raboinjasen_raboin Posts: 4
    Accepted Answer
    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.

Answers

  • ilya_baranilya_baran Onshape Employees, Developers, HDM Posts: 919
    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.
    Ilya Baran \ Director of FeatureScript \ Onshape Inc
  • lanalana Onshape Employees Posts: 454
    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_raboinjasen_raboin Member Posts: 4
    Accepted Answer
    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.
  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 2,156
    Have you tried opPattern instead of transform/copy - that is the preferred method

    Neil Cooke, Director of Technical Marketing, Onshape Inc.
  • jasen_raboinjasen_raboin Member Posts: 4
    what's the syntax to make a copy in place?
  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 2,156
    opPattern(context, id + "Copy1", {
                            "entities" : definition.PartToInfill,
                            "transforms" : [identityTransform()],
                            "instanceNames" : ["1"]
                        });


    Neil Cooke, Director of Technical Marketing, Onshape Inc.
  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 2,156
    If you copied the code from the HexInfill feature, that was using the old FS library.
    Neil Cooke, Director of Technical Marketing, Onshape Inc.
  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 2,156
    Although if Union1 is failing, so will everything else.
    Neil Cooke, Director of Technical Marketing, Onshape Inc.
  • jasen_raboinjasen_raboin Member Posts: 4
    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_RosenfeldJake_Rosenfeld Moderator, Onshape Employees, Developers Posts: 1,285
    I've logged this in our system.  Thanks for the suggestion @jasen_raboin
    Jake Rosenfeld - Modeling Team
  • philip_thomasphilip_thomas Member, Moderator, Onshape Employees, Developers Posts: 1,245
    edited July 2017
    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 :)
    Philip Thomas - Onshape
Sign In or Register to comment.