Gumball: Does not "Align to Object" for an Extrusion

(OSX 10.7.5, build 510)

Is it normal for the Gumball to not “Align to Object” for an extrusion? (By clicking on the white circle in the Gumball to change the orientation, for those who wish to play with the enclosed file). Works fine for a lofted surface.


Gumball_Problem.3dm (39.0 KB)

Software information

Software versions
Rhinoceros version: 5.0 Wenatchee 2014-04-21 (510)
OS X version: Version 10.7.5 (Build 11G63)


Hardware information

Computer hardware
Hardware model: MacBookPro8,3
Processor: Intel Core i7-2860QM CPU @ 2.50GHz
Memory: 16 GB
Architecture: Intel 64 bit

Video hardware
Graphics: AMD Radeon HD 6770M 1024 MB
Memory: 1024 MB
Screen size: 1920 x 1200, 1920 x 1200
Displays: Cinema HD, Color LCD

Third party kernel extensions
com.Logitech.Control Center.HID Driver (3.6.0)
com.Logitech.Unifying.HID Driver (1.2.0)
com.parallels.kext.prl_usb_connect (7.0 15107.796624)
com.parallels.kext.prl_hypervisor (7.0 15107.796624)
com.parallels.kext.prl_hid_hook (7.0 15107.796624)
com.parallels.kext.prl_netbridge (7.0 15107.796624)
com.parallels.kext.prl_vnic (7.0 15107.796624)

USB devices
Apple Computer, Inc.: IR Receiver
Apple Inc.: FaceTime HD Camera (Built-in)
Logitech: USB Receiver
Apple Inc.: Apple Internal Keyboard / Trackpad
Apple Inc.: Bluetooth USB Host Controller

Bluetooth devices

OpenGL information

OpenGL software
OpenGL version: 2.1 ATI-7.32.12
Render version: 2.1
Shading language: 1.20
Maximum texture size: 16384 x 16384
Z-buffer depth: 24 bits
Maximum viewport size: 16384 x 16384

Implementation settings
Use texture compression: No

Appearance settings
Antialiasing: 4x
Mip map filtering: None
Anisotropic filtering: None

seems something to do with the one plane being an extrusion object instead of a nurbs surface? (explode the plane and the gumball will align as expected)…

not really sure though if the gumball should properly align to an extrusion surface… i quit using those a while back as i was experiencing some accuracy issues with them.

Explode… So that’s how to get an extrusion into a surface. Thanks!!!

1 Like

There’s also ConvertExtrusions… Keeps joined (polysurfaces) objects together --Mitch

Even better. Practically speaking, why do “extrusions” exist as a separate kind of entity type? Is there some benefit instead of these simply being “surfaces”? ~Dave

Here’s the description of them and what they’re for:

If you don’t need them - 95% of people don’t - then just turn them off altogether:

Command: UseExtrusions Extrusion objects use less memory and mesh faster than polysurface objects. Planar extrusion output object type. <Extrusion> ( Polysurface  Extrusion ): Polysurface Commands will not create lightweight extrusion objects.

I have lobbied to have extrusions off as default with no success… Note that use of extrusion objects by default has created a sufficient number of problems for them to actually feel the need to explain/promote their use via advertising inside the command…

In their explanation (from JB’s link above):

“In models containing large numbers of extrusions represented by traditional polysurfaces, performance can be sluggish due to the relatively high demand on resources.”

This does not represent the typical modeling scenario by a longshot - therefore I state again that their use should be off by default…


The developer’s requirement was for the use of lightweight extrusions to be transparent to the user. This solved the problem of the large architectural models they were designed for. It isn’t possible to take a big file packed up with polysurfaces and convert them to Extrusions, so the only way to make that work was to have Extrusions on by default and work diligently to convert them on the fly to polysurfaces when needed. To a large extent, that was successful. There are a very small number of differences that are irritating but not game stoppers.
We were left with the choice of a few irritating situation as described in this thread, or not solving the original problem at all for the big architectural models.
That is the reason your lobbying was not successful.
It’s not perfect, but it’s a lesser of evils.

Yes, but that doesn’t address the issue. The issue is not whether to take them out entirely, just whether they should be on by default. Those people working on “large architectural models” should know how to turn them on, in the same way that they need to know about other things like use of blocks and worksessions when working with Rhino files containing a large number of objects.

The solution of one problem for the few has created other problems for the many… leading to lots of questions like:

“Why doesn’t my object have isocurves even though they are on by default?”
“When I turn SolidPtOn on this object it only has 3 control points, why?”
“Why is the texture mapping this object different from that object?”
“Why does this object look/behave differently from that object, they look virtually the same?”



I’m still wondering why intersecting a radius surface with an extrusion object results in a non-radius.

(I know you’ve seen that thread already Mitch… just wondering if there’s more info since then)

We think the architects will not turn them on and that would be a bigger problem than the ones you listed. The architect can’t recover from the mistake. The user that doesn’t need extrusions is confused and inconvenienced, but not stuck with starting over.

We could have the same discussion over default tolerance settings or if CheckNewObjects is turned on by default.
There is no correct answer for every Rhino user. The defaults are more of a (one size doesn’t fit most), but they are the best compromises we can make given the feedback we get.
As you well know, we do not take a cavalier view of any of these defaults. We argue both sides over and over and try to find a setting that will work for the most number of users.

Well, I’m glad we’re considering that architects are uneducated - well, they do need all the help we can give them :wink: - and that it’s OK to confuse and inconvenience users… Whatever…

Just as an aside - how many people (like architects) are actually using extrusions in their pure unedited form? I mean, if you’re making metal I-beams beams or wood joists, you almost always need to trim the ends, punch bolt holes in them or notch them somehow… no? Which turns them into polysurfaces anyway…

Well, I’ve plead my case… I’ll shut up now… :no_mouth: --M

This now makes a LOT more sense. Thanks, everyone. And, many apologies for missing the introduction of extrusions as separate elements—for curves especially, since this is a lot more intuitive for solids. Nifty feature for very large projects, no doubt.

Both John and Mitch’s POV about defaults have merit. Defaults are tough choices for such a broad range of users and I don’t envy RMA on these decisions since, often, “no good deed goes unpunished”. :wink:

No doubt the various “File > New Using Templates” were created to help address some of these issues (which are still only V4 files?). But, in truth, I have no idea of the differences between large and small templates. I had always assumed that the main and only difference was related to tolerances. However, I just checked this and it seems I’m wrong! While there may be other differences, the only one I actually noticed was the display precision being different? (How do users determine the differences between templates, other than the obvious units designation?)

As for the defaults question at hand, here’s a possibly crazy idea that might help address the large number of users/projects for Rhino – and yes, I predict this will be an increasingly large problem once MacRhino hits the shelves since the power of Rhino has the potential to scare the living daylights out of new users due to the (sometimes unavoidable) complexity.

I’ve often thought it would be great to choose an optional interview of sorts, where the desired template would be presented based on answers to a series of questions regarding (off the top of my head) things like: user experience level, tolerances, units, extrusions/surfaces, etc, etc. The power of such an approach could go far beyond defaults and settings, extending all the way to A) the interface that’s presented (such as what windows and tools are open or closed, B) a “click here” to learn more about this question, and C) possibly new features introduced and explained.

Good luck wrangling with this eternal challenge!


[quote=“Helvetosaur, post:13, topic:8044”]
Well, I’m glad we’re considering that architects are uneducated - well, they do need all the help we can give them [/quote]
Let me sum up the typical post on the Grasshopper forums:
“Hi, I’m an architect (student) and have no first clue about modelling in Rhino. I’ve heard about this great tool Grasshopper. I don’t have time to learn how to “code” in this program. Can you just show me how to recreate this famous structure? My deadline is close…” :wink:

From my experience it’s safe to assume that architects don’t bother about the technical difference between Polysurfaces and Extrusions. They just want them to work and will complain about any slowdown.

I’m with you… kind of. Problem is, for most of your many questions there’s two points of view.

Just as an example: I can’t see any reason to display isocurves for any flat patch of NURBS surface. Most beginners (and a lot of more advanced users I know) aren’t used to the concept of UV coordinates. So from that POV, disabling “show isocurves” as a default, would solve the visual confusion between Polysurfaces and Extrusions just as well.
If you know about UVs and actually put them to use, you should be aware of the difference and since Extrusions don’t really have a (complex) UV, it might be a good idea to visually tell them apart.

As for the other questions:

Never used texture mapping on Extrusions, how are they different?

For what I know, Extrusions work exactly the same as Polysurfaces and once the result cannot be made an extrusion, it will be a Polysurface. Any example of how they behave different in a way to confuse the user?

SolidPtOn: I’m not sure what you are talking about here. For me the SolidPtOn command looks and behaves the same for Extrusions and Polysurfaces. Once I edit the points, the extrusion is converted to a Polysurface. For PointsOn you get the triplet on Extrusions and for Solids you get nothing at all… Don’t see any reason for confusion here.

btw. @John_Brock : that Extrusion Widget editing seems to be broken.

This, in fact, is a really good question. As it stands, Extrusions are hard to come by in the final result. The only sensible Scenario I can think of are large 3D sitemaps. But in that case you’d be even better off using simple mesh extrusions.
Revit uses a pretty cool extrusion concept: there’s solid and void extrusions. Once you can punch out holes or trim ends of Extrusions with other (Void)Extrusions without converting the result to a Polysurface, then Extrusions will be able to cover about 95% of an architects model.

Finally back to the original topic: I think the behavior of the gumball with regards to Extrusions needs some improvement. I don’t see any reason why I should not be able to align to object in the same way it aligns to Polysurfaces.