using pre-existing predicates

EvanReese

I'm trying to add all of the merging magic of the native extrude feature to my Speaker Pattern feature.

As someone uneducated in programming of any kind, I'm trying to understand how to use some of the code that is re-used across features, like the booleanStepTypePredicate and booleanStepScopePredicate. My understanding is that it lets the same code be written once and instantiated across different features (since booleans in Revolve and Extrude behave the same way, for example). What I'm not understanding is how to use it to boolean bodies. It seems like there's a function to use instead of opBoolean that will automatically take the correct inputs and just work, but I'm having a tough time understanding how to do that from looking at the native features (even very early versions of them, which I assume are simpler to understand).

I'd love advice of any kind. Explanations are preferred, but straight up solutions are also appreciated.

NeilCooke

Hi Evan, don't worry, it took me a while to get my head around it.
When you call booleanStepScopePredicate(definition), it substitutes "definition" for "booleanDefinition" in the code block above. It would have been clearer if they just stuck with "definition".
So in that code block, at runtime it is really testing definition.operationType which was set when you called booleanStepTypePredicate(definition). Therefore, in your opBoolean code, test for definition.operationType == NewBodyOperationType.ADD (for example) and get the bodies to add from definition.booleanScope.
It's also extremely useful to look at the source code for inspiration: https://cad.onshape.com/documents/12312312345abcabcabcdeff
Hope that makes sense. Happy to jump on a call to walk you through it.

NeilCooke

Is there a reason you are avoiding just using opBoolean? It’s the simplest way. 

EvanReese

NeilCooke said:

Is there a reason you are avoiding just using opBoolean? It’s the simplest way. 

Nope. I just don't know what the "merge scope" body query is called when I create that part of the UI with booleanStepScopePredicate(definition);

That and I'm just trying to learn more about what's under the hood of the professionally written features.

NeilCooke

Those predicates are for populating the UI only, sort of like a subroutine (not a function, since it is not returning anything, it is simply inserting the code at runtime). You pass in definition and the merge scope query is then called definition.booleanScope

/**
 * Used by body-creating feature preconditions to allow post-creation booleans,
 * specifying the merge scope (or "Merge with all") for that boolean.
 *
 * Designed to be used together with [booleanStepTypePredicate].
 *
 * @param booleanDefinition : @autocomplete `definition`
 */
export predicate booleanStepScopePredicate(booleanDefinition is map)
{
    if (booleanDefinition.operationType != NewBodyOperationType.NEW)
    {
        if (booleanDefinition.defaultScope != undefined)
        {
            annotation { "Name" : "Merge with all", "Default" : false }
            booleanDefinition.defaultScope is boolean;
            if (booleanDefinition.defaultScope != true)
            {
                annotation { "Name" : "Merge scope", "Filter" : EntityType.BODY && BodyType.SOLID && ModifiableEntityOnly.YES }
                booleanDefinition.booleanScope is Query;
            }
        }
    }
}

EvanReese

Thanks, Neil. That did work for me, but I still don't understand it. I also don't know how to let opBoolean know what operation type to use (New, Add, etc). I think if I can understand why the scope is "definition.booleanScope" then I should also be able to figure out the type. How could I have figured this out for myself?

NeilCooke

Hi Evan, don't worry, it took me a while to get my head around it.
When you call booleanStepScopePredicate(definition), it substitutes "definition" for "booleanDefinition" in the code block above. It would have been clearer if they just stuck with "definition".
So in that code block, at runtime it is really testing definition.operationType which was set when you called booleanStepTypePredicate(definition). Therefore, in your opBoolean code, test for definition.operationType == NewBodyOperationType.ADD (for example) and get the bodies to add from definition.booleanScope.
It's also extremely useful to look at the source code for inspiration: https://cad.onshape.com/documents/12312312345abcabcabcdeff
Hope that makes sense. Happy to jump on a call to walk you through it.

EvanReese

Neil, Thanks. I don't think I need a phone call, but the willingness means a lot. If the offer stands I'll reserve it for a more intractable problem later. For now, I got all of the booleans working based on your prompt above. The only issue I have left before I consider my feature ready for "beta testing" is the intersection option. with UNION, I just did a qUnion([tools, targets]) and that worked. Since the generated tool bodies don't touch I don't get an intersection result unless I have an instance count of 1. I also tried setting tool bodies to be an array ( i.e. [tools, targets]), instead of a qUnion, but that didn't work either. 

Here's where I am with it so far

EvanReese

@NeilCooke
here's an illustration of the issue I'm having. Does the solution have anything to do with "targetsAndToolsNeedGrouping"?

MBartlett21

@Evan_Reese
Try opBoolean with BooleanOperationType.SUBTRACT_COMPLEMENT
The sets of parts will then go respectively into tools and targets.

EvanReese

MBartlett21 said:

@Evan_Reese
Try opBoolean with BooleanOperationType.SUBTRACT_COMPLEMENT
The sets of parts will then go respectively into tools and targets.

Well, that was embarrassingly easy. Coulda sworn I'd tried that. Thanks!

I've moved my Feature Studio out of the original document to clean things up and I'm ready for people to start using this thing!
https://cad.onshape.com/documents/7357473bee84cfbece0caa72/w/6b1397ebf6249eadf5cb37c5/e/685da06f47a08a112cd05cdf

An improvement wishlist that I may or may not get to would be:

1. more pattern types
2. better default values
3. end conditions
4. option for custom input body (instead of a cylinder)
5. figure out something to make the center of the Fibonacci pattern not look so funny (even though it's right as far as i can tell)

I'm open to ideas.

Here's an example of what the feature can do.

owen_sparks

Good stuff and thanks for taking the time to share it.

Thanks, Owen S.

owen_sparks

Might be worth a new thread to announce that it's available to all.  The current thread title doesn't have mass clickme appeal IMHO.

O.S.

EvanReese

owen_sparks said:

Good stuff and thanks for taking the time to share it.

Thanks, Owen S.

Happy to! I'm super thankful for all of the help people have given me in learning this stuff. 

EvanReese

owen_sparks said:

Might be worth a new thread to announce that it's available to all.  The current thread title doesn't have mass clickme appeal IMHO.

O.S.

lol! good call. i'll do it soon.