Intersect Tool Missing! Available as separate plugin.

[puzzledpaul]

using ... 22-26

Having separate menu listings is a backwards step (imo) ... it's the equivalent of having all the move (or any other basic command) options listed in the first menu.

The natural place for booleans to reside (in wings core, if it gets there) is in the object / body menu as a single listing - this is how it should be approached - imo.

I've only had a quick play - with subtract, mainly - so comments on that.

As oort (and I previously mentioned) better use of the info line could be made ... I'd suggest going much further than oort

Instead of just
L: Boolean Subtract (as user hovers over this option)

L: Boolean Subtract [Subtracts 2nd object(s) from 1st object(s) - ALL 1st objects MUST be combined before using Boolean Subtract ]

(could use ... and probably better, imo ... 'primary' and 'secondary' instead of 1st / 2nd ...but depends on info line space.

I note that whilst subtract seems to need primary objects combined prior to op ... union doesn't ... also needs sorting, imo.

Next stage

Instead of L: select second bodys for CSG R: Execute

L: Select secondary object(s) to subtract from primary object(s) [secondary objects DO NOT need to be combined] R : Execute

Obviously if subtract worked in the same way as union, then appropriate text could be removed.

Aim should be to provide user with all relevant info (if possible) so's they get what they expect to get - in a clear, consistent manner ... without any surprises.

Personally, I don't see the need for separate (main menu) listings for the 2 other options that've arrived on the scene (inverse / ++)

Think such things as these should be made available to user in the same way as other similar existing tools - eg pressing 1 for dark side of moon option on Tools | Connect.

Not returning hard edges looks / feels better (to me) ... if I was using Booleans ... this is the pref I'd probably use

pp


btw - can't seem to find power user option ... to add final selected element / object to total (with RMB execute) ?

[oort]

I may have to disagree with puzzledpaul on the following...

I note that whilst subtract seems to need primary objects combined prior to op ... union doesn't ... also needs sorting, imo.

I don't know that union and subtract have to behave exactly the same. They just have to work with the same logic....

Subtractions
If I select one object > boolean Subtract > Select the object or objects to be subtracted > RMB to exectute.

or I can Select several objects I want to boolean Subtract > Select the object or objects to be subtracted > RMB to execute.

Unions
If I select one object > boolean Union > I can choose additional objects > RMB to exectute.

or I can Select all the objects I want to boolean Union > RMB to execute.

Are you saying that because I can choose one or all objects to start with for Union that we have to be able to add additional objects when using Subtract??? After thinking this through I can see it might be nice to add additional items for subtract but it might make things more confusing/complicated???

oort

[puzzledpaul]

I may have to disagree with puzzledpaul on the following...

I don't know that union and subtract have to behave exactly the same. They just have to work with the same logic....

I have zero problems with ppl who disagree - providing they use logic(al) approaches to do so

The crucial word in my previous post was 'combine' ... maybe I should have referred to it as Object | Combine to remove any ambiguities ...

I used 6 objects for my test - 4 cubes (as primary) + cyl and sphere

For subtract ... the only way I could get it to work properly was if I selected the 4 cubes first, then combined them with Object | Combine.

The Object | Combine stage wasn't needed for the Union op - Union worked by just selecting the 4 objects (no combine) ... then the Bool Union stage.

This difference seems illogical to me ... dunno about you?

... or - again possible... I've done something wrong / missed summat.

Enough for now - light + owls await

pp

[oort]

I know you have no problems with people disagreeing... I just don't know that I have ever had to disagree with you before...

I am not having to use Object > Combine at all. Strange that you did but I was just playing with cubes...

oort

[yaak]

What is Logical depends, if your thinking process is left to right or right to left. Its like reading. Not everyone in the world reads left to right. Or drives on the wrong side of the road, thanks to the British. That's why I say Boolean subtraction remains problematic with a 50/50. chance of getting the right results. clearly 10 - 8 is not the same as 8 - 10.

However since we are dealing with words that translate into 3d visual information, why can't we get the computer program help the user generate 2, 3D previews, from which he/she simply clicks on the 1 indented?

Would that not be an elegant solution?

[puzzledpaul]

...I just don't know that I have ever had to disagree with you before...

Hmmm ... think the 'better 95%' ... (mrs pp) might not be singing from quite the same hymn sheet as you

Re the Bools issue ...

Construct a 'barbell / weight' type shape ... ie 2 spheres, moved apart some distance, with a cylinder / rod between both, so that each cyl end is inside a (different) sphere.

Then try Boolean subtract on this setup

Select both spheres > Bool sub > select rod > execute.

undo and repeat, with following difference ...

Select both spheres, Object|Combine > Bool sub > select rod > execute.

If you get something different from myself ... then start the x files theme.

pp

[puzzledpaul]

Again using,...22...26

A brief play with Boolean | Intersect ... using multiple primary objects shows similar behaviour as Subtract, re using Object | Combine (or not) on the primaries before executing the op ... but worse ...

If user only selects(multiple primary objects) ...and doesn't Combine, then they get a crash upon execution of op.

Combining prior to op, all's fine ...even with multiple secondary objects also being used.

pp

[puzzledpaul]

Would that not be an elegant solution?

It might well be ... altho' it probably wouldn't suit everybody ...

... however, whilst we're waiting for you to write the code, we'd also welcome ways by which the greatly underused (and often overlooked) info line text could be improved in order to minimise ambiguities about what the user is going to end up with when they press 'execute'
[assuming that the feature is working correctly in the first place]

Since we don't have the space available to contain the number of words generally considered to be a pic's equivalent ... it can sometimes be quite challenging.

pp

[yaak]

puzzledpaul.... I don't know the first thing about Erlang nor do I have enough time to learn another language. I'm already somewhat proficient in Ruby and AutoLisp. Both of which have no ability to display graphical information. Hence I deal with the same problems when I design a dialog box in Ruby based API ....its words only.

I was always amazed how structurally suited Lisp was for math, it would take 4 times as much code to write the same code using Ruby.

However there is a movement in programming that now recognizes these graphical shortcomings, with the addition of Java and Web Dialogs. With this additions these older languages can be given new life. Unfortunately this means the programmer ONLY has to go and learn 2 more languages, but that's a big investment in time. Particularly with the emergence of Python that has now become the new standard API interface in such programs as Houdini and Maya.

Unfortunately there is no other easy solution when the only option is....words!

[ggaliens]

http://www.youtube.com/watch?v=b1a4n-m8A...e=youtu.be