Intersect Tool Missing! Available as separate plugin.

[Wegg]

I DID enjoy the show. And thank you for making these plugns. I have used them many many times.

[oort]

ggaliens,
Looks good in the video. I will download the standalone plugin and give it a whirl.

Thanks,
oort

[ggaliens]

Wegg : Thanks. Let me know of any issues you encounter. Nothing gets fixed when people don't complain. I like that Yaak filed a solid complaint that got be to look at Boolean again.

Oort : Even TARBALLs and my testing of same could be inadequate ... so please to try the new Boolean TARBALL sitting on my drop box page and let me know that it works for you ...

If it does not work with old wings3d ... please try new snapshot and "INSTALL PLUGINS".

[oort]

ggaliens,
I just tried the booleans tar on Wings 1.5.1. Works great so far. Since my Wings 1.4.1 has your old plugins in it I don't think it would be a good test to try it on my Wings 1.4.1.

I noticed a typo in the message (intersect requires 2 or more bodies selected) that pops up when you try to intersect with only one object selected. Intersect is missing the r...

It would be nice if Wings would automatically switch to body mode when it is time to select the second object, but this may not be possible???

I see what "Alt+R Impression" does but when would you use this?

"Experimental: Volume Information is listed in the menu. Is this required to make booleans work?

Thanks,
oort

[puzzledpaul]

Nothing gets fixed when people don't complain.

Several things cross my radar.

Make greater use of the info line - rather than just have LMR etc with title, add a brief description ... on that line ... since there appears to be capacity / space for additional text.

Personally, I can't see why all boolean ops can't be dealt with in the same way...ie user selects one object > Bool op of choice > then selects appropriate subsequent objects ... keep it consistent ... with info line content such as (for subtract, say) ... second object subtracted / removed from first object...or for union ... second (or more) objects added to first.

The results of subtract (especially - not tried intersect plug) appear to return hard edged results that are inconsistent ... depending on how the the second object is aligned with the first.

Eg a blind hole cut into a cube by a cylinder produces a different set of hard edges compared with a thro' hole cut by same cylinder ... and both different from a hole cut by cyl which has its end faces co-incident with the cube's relevant faces.

Also, the positioning of edges joining a cylinder to a cube's face(s) (after subtract) seems a little odd ... when one is central, the other past centre ... as well as such edges being hard?

Such anomolies - if can't be sorted, would, imo, make the provision of a user pref for hard / no hard edges to be returned worth considering.

This'd give user the option of selecting ... and making hard ... whatever edges *they* want to be so ... OR having to make soft the unwanted hard edges returned by the feature.

Swings'n roundabouts may be the response ... but at least the user could choose which they'd prefer.

Just some thoughts.

pp

[ggaliens]

PuzzledPaul says ...

"Personally, I can't see why all boolean ops can't be dealt with in the same way...ie user selects one object > Bool op of choice > then selects appropriate subsequent objects ... keep it consistent ."

PP, Let's take the case of UNION. And lets take the case where the user wants to union 5 objects together. Why should user have to single out 1 object from the 5 in order to do the workflow ?

The operations are not mathematically consistent. That is at the root of the problem for me. UNION is commutative operations. Subtraction is not a commutative operation.

---

I guess ... maybe ... I should just let the user do boolean UNION in two parts (two selections) if they want. If that's essentially what's being argued for. Give me some time to make it more flexible and also more consistent. Points taken.

---

Maybe it will go like this in the distant future ...

Step 1 ... pick Operation from Boolean menu with menu items UNION, SUBTRACT, INTERSECT, SPLIT, IMPRESSION.

Step 2 ... pick "A" set of objects (SUBTRACT or THINGS to get impressed upon). Or just pick some or all of UNION and intersect.

Step 3 (as optional) ... pick "B" set of objects such as item to be subtracted or more items to UNION or intersect.

Part of the problem I have is the foundational code needs some cleaning up. I might do bunches of under the covers things that don't aftect users for a bit.

[puzzledpaul]

PuzzledPaul says ...

And lets take the case where the user wants to union 5 objects together. Why should user have to single out 1 object from the 5 in order to do the workflow ?

You ask 'why should' ... I ask 'why not'

Assuming user knows which objects they want to Union ... then there's surely little difference between the 2 options.

User selects all 5, hits Union, done
or
User selects one, hits Union, selects other 4, done.

In both, user has to select 5 objects.

And what of the other issues mentioned in previous post

All hard edges
No hard edges
'Best guess' hard edges

... user's choice ... as opposed to having no choice about what to accept?

pp

[ggaliens]

What about the case where ...

The primary selection is 5 objects ... and the secondary selection is 7 objects ... and the operation is subtract 7 from 5 ... are there implications if the 5 objects are already "OVERLAPPING" ?

I think I could go on and on and one with the what-if and what's next thinking; and despite the answers being fast in terms of theoretical-design ... I would imagine the practical design might be perilous.

I think the cost of going generic is not free or cheap for me. It is a good goal. But I still think I'm going to have to "STEP" my way there. Let me just try to clean up what I have ... hopefully only improving the user experience along the way.

[puzzledpaul]

The primary selection is 5 objects ... and the secondary selection is 7 objects ... and the operation is subtract 7 from 5 ... are there implications if the 5 objects are already "OVERLAPPING" ?

Seems like an illogical response - to me, anyway

I've been suggesting a Union workflow similar to the existing Subtract one.

Whatever problems there might be with Subtract under the 5-7 circumstances outlined above ... presumably already exist. Re-thinking /re-working Union w/flow to be consistent with Subtract has little - if anything - to do with it, surely?

If this way round causes issues - what about considering the other approach?

Ie select both / all objects to be subtracted > Subtract > select - in 2 separate stages ... with appropriate info line guides - the 2 relevant objects / groups ... ok .

... and the hard edges issue?

pp

[ggaliens]

... and the hard edges issue ?

Not ready or in a good position to comment on hard-edge issue yet.
Was busy trying a build of 1.5.x on Mac since the one in the snapshot thread didn't work on my silly Mac. 1.5.x seems to build and run fine on my Mac.

BOOLEANS: I will try to let the users have it their way ... more than they have it their way right now. That's all I can do.