Intersect Tool Missing! Available as separate plugin.

[puzzledpaul]

using ... 18 - 48

pros and cons (imo)

re video above
Good ex of undo messup
select both spheres
scale Y a little ... leave spheres selected
Bool subtract, select secondary objects > execute
ok ... ignoring H edges issue
Undo ... and you get to the original (unscaled Y) state of the spheres ... and not (as i see it) being able to return to the un-booleaned state with final scale (in this case) op on the spheres.

Btw - even tho the subtract op is working without combining the primaries, actually combining same will return consistent results on the primaries ...ie all hard edges.

Intersect - with multiple (4) uncombined primaries, single secondary ... execute produced a completely blank screen ... nada / nowt ... no crash dump. (combining primaries worked ok and produced predictable h edges on all relevant objects.

Imo, the bool access route is now worse than before
What's the point in having a 'dead' Boolean operations menu listing after 'lots more'?

Should it be more like
Lots more
Boolean ops ... with LMR options in the info line (+ Alt(say) for inverse options ... vol info is a red herring imo ... top left info readout if anywhere, surely?

Info line still way underused ... and again, imo ... using 'object' rather than 'body' allows for the cleaner plural option to be used .

Downstream issues of using / tidying up the mess caused bool ops aside ... where are all the Boolean users / advocates at the moment?

I find it hard to believe that you've been messing around with these ops without getting stuff like this tidied up ... or are you just not bothered ... or far, far worse - to me - not seen them??

The name of the game, folks, is to actively look - as hard as possible - for all and every possible way to break something like a feature / tool that's being developed.

pp

re vid setup again ... I'm sure it's already been noticed ... but if geometry exists on the secondary that's inside the volume of the primary (ie an eloop around the cyl) ...then no hard edges on the thro' hole are returned after subtract op.

[ggaliens]

Simple anwsers ... I notice probably about 66% of all issues you cite (PP) before hand (before you do).

IMPORTANT NOTES: I still need help with the 33% unidentified. I still need time to add or fix things contributing to the 66%. And it is true ... if on balance ... if feels just a bit different and is moving in simpler direction ... maybe I don't worry too much about UNDO.

This has been a major code rewite and it will take time to battle harden this. I'm not done. This was for you PP ... since you were the more discriminating user. Give me some more time to look at remaining issues.

This is software development by consensus and by way of public input ... which means I do need to toss things up that are still in flux and maybe only 70% complete.

[puzzledpaul]

This was for you PP ... since you were the more discriminating user.

I've got nothing to do with it ... it's all about the correct way that a feature should work...irrespective of who's written the feature and what it does.

I'd have thought that it's the people who've been (supposedly) keen / regular users of the features who should be at the forefront of this ... not a passer by like me...

pp

[ggaliens]

Well ... I would imagine that other folks might be more forgiving. But possibly not forgiving if I don't take a stand and freeze some aspects of this plugin.

I'm tempted to FREEZE the basic menu structure and invocation with primary and seconday selection. Can anyone say that the basic menu items should be frozen ? Gosh I hope so ... and sorry took so long to get here.

[oort]

I too am surprised that those interested in booleans are not testing the plug-in to get it to a state where it can be part of the official release. I am just playing with it out of curiosity and maybe to help a little.

I agree with puzzledpaul's recommendations. As far as menus go... maybe LMB for Union. RMB for Subtract. MMB for Intersect. Too many booleans in the menus takes up too much menu space. I questioned having the extra "Volume info" as well...

Thanks,
oort

[puzzledpaul]

Well ... I would imagine that other folks might be more forgiving. ...

You . have . really . got . to . be . kidding.

If this response is associated with today's date ... then you got me good and proper ... if not, loop back to the first sentence.

At no time ... repeat no ... have I ever heard a comment such as this from any other dev associated with wings, when discussing feature implementation.

Over the last 11+ yrs that I've had some interaction with devs (mainly offline) about features has there ever been any suggestion of any degree of 'settling for' ... anything.

In the early days of wings, when I started reporting bugs / issues etc, I felt bad about this ... as if always complaining about stuff to the guys that were doing the actual work ... until Bj (and others) said that's the only way to get things right.

Since then ...the rest is history ... as they say

... and sorry took so long to get here.

Much of what's going on / being said now has been covered before - several times - both specifically with reference to Booleans - and generally with respect to overall implementation and quality control aspects of same.

Personally, I suspect many / most users would be satisfied with the presence of the 3 main options - bug and issue free - accessed as per 'wings way / oort's suggestion - but coded in such a way as to allow the addition of the other 2 options sometime in the future, in a relatively seamless / painless manner.

pp

[ggaliens]

Well ... I know for a fact that others are more forgiving. So ... not I am not kidding PP.

---

The volume item is in fact related to the booleans in an interesting way. Anyone care to venture a guess as to why I had it there ?

[Dimitri]

'I too am surprised that those interested in booleans are not testing the plug-in to get it to a state where it can be part of the official release. I am just playing with it out of curiosity and maybe to help a little.'

Oort, who says that there is not such a testing? There is a lot of testing going on. I tried to make whole models based solely on them. They work fine (apart from some very small irregularities that appear in some cases). So, getting them to the 'official' release is a matter of will any more. : - )

As to the better way the commands may be inserted in a scroll is the most simple one to my opinion... that's to say a simple array of all choices, namely, 'combine', 'subtract', 'intersect' and 'impress' (in a subscroll which opens under the general 'booleans' command)... You just select the primary object (or objects) you give the command, there appear the prompt to select the secondary object (the one which will do the 'carving' or the 'impression', for example), you select it, right click and there... it is ok.

The most easy routes are the most easy ones...

[oort]

Dimitri,
I did not say there was not any testing just that those interested were not posting in this thread... The original subject is different from what this thread has become so some may just be ignoring it...

Doing the simple fly out is not a bad way but maybe not the best way. Assigning the various boolean commands to LMB,MMB,RMB should be a simple task for ggaliens...

Most users complain about having too many clicks to do a command. By using the LMB,MMB,RMB method you save a click. Also, I would like to see ggaliens finalize Scatter bodies and Random color tools and be able to add them under Lots more as a separate plugin. The more items added to the menu the harder it is to find the tool you are looking for. This is not a show stopper just a nice thing to have.

I am sure that when ggaliens gets the major issues, like Undo not getting you back to where you started, ironed out it will become part of official Wings3D.

oort

[ggaliens]

Well ... I like the one more menu as I have it right now. I like that LMB , RMB is for simple things right now. I want to save any other MMB or ALT keys for things like Hard-edges or no hard edges. Most of all .. I want to reach a compromise state ... which I think we are arguably there.

Differences == exlusive OR-ING to objects.
Subtract++ is like splitting ... but not exactly.

Point being ... the extra menu just under BOOLEANS should have enough room for UNION, SUBTRACT, INTERSECT and TWO or THREE other macros of the three basics. I think it is important to be able to 1 click the macro versions. People have asked me for these things ...

I'm trying to reach a common-est ground between all the things and set-ups we have tried orver several years of fiddling with Booleans.

I'm sure this current implemention and arrangement is that "common ground" ... probably to someones dismay.

PuzzledPaul ... will you agree with me that things like UNDO aside ... and not being quite done with hard-edges and making them a secondary option ... the general trend is towards more usable ? I'm trying PP.

UNDO will invariably be broken in a lot of my plugins because many are MACROS of existing oter wings3D operations interleaved with some of my own. So when you "UNDO" ... it is probably onlu UNDO-ING part way. Because of my leanings towards creating new plugins as a STREAM of existng operations ... well ... UNDO is going to be foo-bar for many of my plugins until I specifically revisit UNDO.

Personally ... because of the COMMAND-LINE tool behind BOOLEAN plugin ... I don't think I would ask Dan to include it into the core. I don't think he should. I don't think he or Bjorn would. It won't be a PURE ENOUGH solution ... even if I polished every aspect cited by PP ... would still be gross because of the native code being SHELLED-OUT-TO. Best to do these things in a "LAB" where we experiment.

You see me trying to get back to TARBALL distribution ... trust me ... I'd be back there a year ago if I could have done it logistically.