Version 5 introduced a handy new lightweight object called an extrusion. Also new were a couple of surface offset tools. I haven’t detected much dissatisfied whining about them on the forums, so it would seem the McNeelies got them pretty close to right. Perhaps there’s enough expertise now at McNeel for something more.
Which brings me to my question. Is it time for another lightweight object called a shell? This would be a solid stored, more or less, as a surface and an offset. An additional property would be which side the offset is on (or equally on both sides as a third option). It would be used mainly for arbitrarily shaped solids that have one dimension considerably smaller than the other two and constant over the domains of the other two.
How useful or time-saving would this be? How well could it work with history and cage editing? Could it be useful in speeding up thin panels with holes in them? etc, etc.
So that is your assignment, Mr. Phelps, should you choose to accept it. (Or am I the only one who remembers the “A-Team”? )
That would be Mission Impossible, not the A-Team. “Mission impossible” in terms of tv, not in terms of a shell object, I don’t have an opinion on the feasibility of that.
There are a number of practical considerations though:
Having a reliable brep offsetter is a prerequisite for a shell object, and we’re a long way away from that.
Offsetting a brep, even if it works reliably, is a very computationally expensive operation. Loading a file with 5000 shell objects will significantly delay the loading time. Extrusions on the other hand are both easy to solve and fast to do.
Extrusions are way more memory efficient than breps, because they only require a profile curve, extrusion vector and cap data. Also the shading meshes can be computed quickly and minimally because -for once- we’re allowed to make a set of simplifying assumptions about what shapes the geometry can and cannot take. Shell objects would be significantly less efficient. The base ‘sheet’ of a shell object would already have to be a brep. The shell itself might also have very complicated topology where the offset self-intersects. The final result of a shell object may well have to be stored as a brep too (contrast this to Extrusions, which only have to be stored as a bunch of wireframe curves and a shading mesh), so now we’re storing the sheet brep and the final brep, resulting in a memory increase.
ps. “brep” is the same as “trimmed surface” or “polysurface”.
You are, in fact, quite right about Mission Impossible. Thanks. I still can’t get the image of Mr. T out of my mind, though.
I can see where things could get complicated pretty fast if one tried for a completely generalized shell object. What about starting with something that is a workable subset of all cases but covers some high percentage of uses for shells? For instance, limit to trimmed surfaces initially and forget about polysurfaces? Maybe limits on curvature inflections or even magnitude?
I must admit, too, that I am (naively) thinking that the representation would be simplified (as it is with extrusions) because the shell would be calculated from the base sheet and thickness as needed. I can see that self intersections would be a concern, but the larger ones would be obvious to the designer, who could undo and try something different. “Invisible” micro ones could be a problem, though.
The main benefit of the sheet, if it could be done, would be greater ease and time-saving in construction and the fact that the thickness would be saved as a property of the object, making shape adjustments possible without manual re-offsetting. And let me mention again history and cage-editing.
Even if it’s a bit more computationally expensive than working with the finished result of manual offsetting, perhaps the true value would be in automating the construction of a frequently used (and altered) shape which would otherwise be a multistep user controlled process. I know the computer is quite bit faster than I am and if we are talking about a frequently used object that’s always built the same way…
There is also the fact that we are solidly in the era of multiple processors, single instruction quad-double floating math and the same thing in GPUs. Maybe “computationally expensive” isn’t what it used to be. The “coffees per command” metric is getting pretty small these days.
Perhaps the first thing to determine is what a practical shell object would be, if there is one.
)