Am I just not ready for Rhino/Grasshopper?

[jeff_hammond]

use booleans for this?
no… duh

---

use booleans for this?
no… duh

---

use booleans for this?
yes… duh

(i think i might of used WireCut for some of that… if booleans trigger @Jim, i’d hate to see what he thinks of _WireCut )

---

[Mark]

I have great respect for Jim, I have learned a lot from studying his posts on this forum. That said, I boolean nearly everything. For my workflow I find it useful to model many discrete objects and then boolean them together for the final export to STL, preserving copies of all so I can return to any part and modify or update if the design needs change and then just re-boolean. I’m not saying that makes the prettiest model, but since it is the STL which ultimately leads to the product in my case, as long as those ugly bits are not compromising that in obvious ways I’m okay with that.

Looking back, when I started with Rhino in V1.1, booleans seemed like the easy way but failed so often that I almost completely stopped using them, similar to the viewpoint Jim takes. But somewhere around V3 I discovered that booleans were working for a lot of situations when I expected them to fail, so I began to use them again. Sure, they still fail a lot, but over time Rhino narrows the cases and I expect that to continue in the future.

I would appreciate better feedback to help quickly locate and adjust for those problems with coincident seams and the like. For instance, if I try and difference fifty objects from a polysurface and two of them won’t work, it would be great if Rhino could highlight those two instead of making me keep sub-dividing the set and trying again until I locate the culprits.

Similarly, if Rhino could highlight the area where it can’t resolve the intersection on any two objects it would be useful.

I’m not sure I like the idea of trying to eliminate “bad” geometry from the start. For instance, if I draw a figure 8 and pipe it the resulting closed polysurface with be self-intersecting. But I would hate for Rhino to refuse to create that surface, and I would rather be the one deciding where and how to split it than forced to accept an automated solution which may not meet my needs. Maybe I just want that surface to project a curve onto, or extract an isocurve, or check clearance with something else, of flow something onto–Rhino gives me the freedom to create it and doesn’t presume to correct me.

[wim (Wim Dekeyser)]

@Mark

I would appreciate better feedback to help quickly locate and adjust for those problems with coincident seams and the like.

I hope you are giving the RH6 WIP a try once in a while. The type of feedback you ask for is provided there.

@Mark

I’m not sure I like the idea of trying to eliminate “bad” geometry from the start.
[…]
Rhino gives me the freedom to create it and doesn’t presume to correct me.

I’m with you on that one. I’m still troubled over the fact that Rhino doesn’t allow you to revolve a curve that crosses the revolution axis. That is, it allows it but only creates one part of it and doesn’t allow a self-intersecting surface in this case.

[Helvetosaur]

@Mark

I’m not sure I like the idea of trying to eliminate “bad” geometry from the start.

Exactly - Rhino shouldn’t prevent you from doing stuff even if it considers it to be “bad”. However, what Rhino is missing is a place where the user can set some “problem flags” in order to be notified (or not) when an object that has a particular problem is created. I’m talking about things that Rhino does not consider “bad” currently but might cause downstream problems - such as stacked control points, non-manifold structures, etc. This is functionality that could be added to Check and CheckNewObjects by giving it a page in, say, Options>Modeling Aids.

I have campaigned for this functionality for the last 4 versions of Rhino - to no avail. --Mitch

[Nosorozec]

to the 1.st picture:
If I have a positive I can make the negative (like a mould on the picture) with boolean very easily. It is substracting of one volume from the second one. But It depends on the shape of positive.

[wim (Wim Dekeyser)]

@Helvetosaur

I have campaigned for this functionality for the last 4 versions of Rhino - to no avail.

Perhaps we could revive this thread:

Geometry Validation

I am looking at ways to improve our geometry validation functionality in V6. The following attachment ( VDA4955.pdf (838.0 KB) ) contains the VDA specifications for validating geometry. Section 2.3 gives a good list of potential problems that need to be detected at various times during modeling and file translation. The rest can be ignored unless you like this sort of document I am interested in hearing any input on how and when you would want to perform the tests. For example, should t…

[Helvetosaur]

@Nosorozec

If I have a positive I can make the negative (like a mould on the picture) with boolean very easily. It is substracting of one volume from the second one

But you still need to build the positive (correctly). --Mitch

[Nosorozec]

I agree.

[jeff_hammond]

@Nosorozec

to the 1.st picture:
If I have a positive I can make the negative (like a mould on the picture) with boolean very easily. It is substracting of one volume from the second one. But It depends on the shape of positive.

i would do that too if the situation called for it… in these cases though, it makes more sense for me personally to make the negative then just model the boxy perimeter around it.

[jeff_hammond]

@Mark

For my workflow I find it useful to model many discrete objects and then boolean them together for the final export to STL, preserving copies of all so I can return to any part and modify or update if the design needs change and then just re-boolean.

i have a sort of similar strategy as far as keeping copies of the non-booleaned solids in the file… for example, the curved displays in the post from a few days ago in this thread:
Am I just not ready for Rhino/Grasshopper? - #41 by jeff_hammond

the vertical elements are Blocks and they’re the actual size of the materials i’ll be cutting… but when cutting the negatives on the CNC, i’ll want a little bit of play in the grooves so things slip together nicely. (i.e., i can’t just Subtract the exact vertical element into the horizontal ones and expect things to fit together in the shop)…

so with Blocks as the cutters, i can easily edit one of them to give, say, an additional .020" in width as well as add any clearances i might need for the bit (if i’m using a 3/8" bit that day, i’ll make the slots 3/16 longer to avoid needing to clean the round corners left by the round bit or to avoid making dogbones etc)

anyway, using that strategy, i have a much (much!) more changeable model… if my materials show up and they’re .715" thick instead of .730 as i was expecting, i just edit the block accordingly and re-subtract from the copied solid… if i took a no_boolean approach, i’d have to redo pretty much the entire model from scratch in order to make these little adjustments… no thanks.

[emilio]

@norbert_geelen

Who in the real world positions objects so that they intersect and then does a boolean?

Hi Norbert, Dennis

What Jim means, as I read it, is positionig two objects IN THE REAL WORLD so that they intersect … and then ‘boolean’ them.

Hehe … this is clearly impossible … usually.

I think Jim will correct me if I’m wrong …

Regards

[Helvetosaur]

@emilio

What Jim means, as I read it, is positionig two objects IN THE REAL WORLD so that they intersect … and then ‘boolean’ them.

Hehe … this is clearly impossible … usually

On the other hand, if you want to put a round hole into a block of material, how would you simulate that procedure in Rhino so that it looks like a “real-world” operation using intersect/split/delete/join? The “real world” doesn’t work that way either… You drill or punch a hole in a block of material using a tool in a subtractive way, it’s about as close to a Boolean operation I can imagine.

–Mitch

[anon55473861]

@neobobkrause

Firstly, I am appreciative of the help and support the community as offered me. But Richard, I think it’s worth saying that I actually see my participation in this conversation as a means to pay some of that support back. This conversation isn’t just about me. It’s not speeding up my work, I can tell you. Quite the opposite. It’s an opportunity for Rhino stakeholders to sound off about their experiences – be they short or long -term, as users or developers.

yes true, but there is a sure difference between a fruitful discussion and a bothersome repetition.

@neobobkrause

For the record, Bob McNeel was not showing me the door. He was offering me an out, which I saw as a generous gesture not often made. Thank you, Bob.

i would never define such a neat gesture as done here like that.
but if you can stand above it and see only the positive in it, well suit yourself

[jim]

@Helvetosaur

On the other hand, if you want to put a round hole into a block of material, how would you simulate that procedure in Rhino so that it looks like a “real-world” operation using intersect/split/delete/join?

I viewed the claim by an admitted boolean addict that booleans work just like real world processes as evidence that supports my conviction that booleans impair your thinking just as other addictions impair thinking.

I will restate and clarify my stated position one more time:

Learning to model without booleans will make you a much more proficient modeler in Rhino.

That statement doesn’t apply to other programs. Take MOI for instance, If a boolean won’t get you what you want in MOI you are just out of luck. As far as I can tell, there is no other way to go.

But in Rhino you have tons of other options. And if you learn to pursue those other options you will discover that booleans would mostly not be saving you time or giving you more accurate results or mimicking what happens in the real world.

Most of the claims that the boolean addicts make in defense if booleans only hold up for a very tiny fraction of the things one might consider making in Rhino.

[jeff_hammond]

@jim

.

I will restate and clarify my stated position one more time:

Learning to model without booleans will make you a much more proficient modeler in Rhino. [/quote]

what does ‘beginner’ or ‘learning’ have to do with it?
i’m certainly an intermediate if not advanced user… should i not do a certain method because it might be difficult for a beginner to get proper results?

if your point is ‘beginners shouldn’t be taught to rely on booleans’ then fine… i would even agree with that.
but what about advanced users?
what’s your beef with someone who completely understands what booleans are doing behind the scenes and uses them accordingly?

[quote] boolean addicts

hyperbole much?

[jim]

@jeff_hammond

what does ‘beginner’ or ‘learning’ have to do with it?

Users who state that they are just beginning to learn Rhino are the ones I have offered this advice to, but for some reason you keep jumping in and acting as if the advice was directed at you.

@jeff_hammond

if your point is ‘beginners shouldn’t be taught to rely on booleans’

Yes and beginners should be cautioned that if they are being taught
booleans before they are taught the basics that they are being led into a trap that they are going to have a tough time getting out of.

@jeff_hammond

what’s your beef with someone who completely understands what booleans are doing behind the scenes

Who said I had a beef with anybody? Those who are interested in finding alternatives to using booleans are likely to discover that pursuing that interest leads to being more productive. Those not interested will not discover anything.

[jeff_hammond]

[quote=“jim, post:83, topic:37390, full:true”]

Users who state that they are just beginning to learn Rhino are the ones I have offered this advice to, but for some reason you keep jumping in and acting as if the advice was directed at you. [/quote]

were you not talking about about me, exactly me, in the post i responded to?

“”“jim said – I viewed the claim by an admitted boolean addict that booleans work just like real world processes as evidence that supports my conviction that booleans impair your thinking just as other addictions impair thinking.”""

aren’t i the ‘boolean addict’ with impaired thinking due to my addiction?
if not, my bad… otherwise, that’s why i jumped in… you see?

---

also this…
the people making the software read some of this stuff…
you seemingly want boolean commands removed from rhino as they flood the rhino user pool with a bunch of morons … i respond with “no, here are examples of scenarios which are perfectly suited for these types of tools… in fact, these tools are pretty much the best way to handle certain situations… ie- please leave the tools in the software and continue to improve on them… they’re useful and i use them often… as knowledgeable as this guy is about rhino modeling, please ignore him on this issue… thnx.”

[wim (Wim Dekeyser)]

@jeff_hammond

they’re useful and i use them often

The problem is that probably a combination of misuse and limits in the code are causing a LOT of support issues which are stealing resources from the McNeel support team. I wouldn’t shed a tear if they were removed from the toolbox - even though I use them. There have been a lot of calls for better feedback when booleans fail and this has been implemented in RH6. I’m not so sure if that is going to stop the support issues from running in but we’ll see…

[jeff_hammond]

@wim

There have been a lot of calls for better feedback when booleans fail and this has been implemented in RH6. I’m not so sure if that is going to stop the support issues from running in but we’ll see…

i haven’t seen v6 yet but i’m going to go ahead and guess the support issues will, for the most part, keep coming… as far as i can imagine at the moment, i think if a boolean fails then the reason will be “these sections don’t intersect properly”… there could be a thousand reasons why the intersection isn’t happening and i doubt this type of support/feedback can be built into the software.

booleans, for the most part, fail when intersect fails… it’s the intersector that’s failing so why place blame on the boolean command?

here’s the advantage of booleans:
it’s not that you don’t have to intersect, or split, or trim, or join… that’s usually pretty fast anyway…
it’s that you don’t have to select a bunch of leftover crap to delete it… it’s the automatic removal of the leftovers that’s most beneficial to me because one of the more annoying parts of modeling is selecting… especially when it’s many individual objects in tight spaces or adjacent to or inside of other non-deletable objects… you can’t even window select in a lot of circumstances so you’re left shift clicking for days and scrolling through the selectable objects etc…

that’s exactly the reason i’ll use booleans over other methods… it’s like a garbage disposal…
(it’s not the only reason however)

and if a boolean fails, it’s not like i can take the purist approach and be like ‘okay, forumMember suggests i don’t use booleans and instead, go about it manually’… that’s going to fail to… am i right? most of the time the model is crappy which is causing the intersector to fail which makes the boolean fail…

the failure feedback could simply read “junk in the model… sorry” and cover a huge swath of support issues.

---

(not much of a point… midnight ramblings is all )

[emilio]

Hi Mitch

Hehe … obviously you’re right.

I thought that Jim’s words about ‘real world’ might have not been clearly understood … so I tried to clarify … maybe I was even less clear …

After some 15 years, I think I’ve learned somehow ( maybe ) to understand what Jim means ( and I always appreciate his words ) … but I admit that for newcomers this goal might be a little hard … ( Sorry, Jim )

Regards

P.S.

BTW, being almost always short of time, I too have started to use solids and booleans to work faster.
I usually jump constantly between surfaces and solids, trying to use the faster tool for any operation.
I also think that surface commands in Rhino might be as fast as solid commands ( or almost as fast ), if they had better options and user interface.
Better surface commands would also help a lot ( I mean A LOT ! ) when using solid commands is not possible IMO.