Improvements to OnShape for artists, natural forms, and more expressive design intent

neobobkrause

I’m an educator who uses OnShape with students in the studio. I’m also a designer who wants to create objects that users’ can get emotional about. That ability to evoke is an important skill/awareness/talent I strive for in the minds of my students in their 3D design work and elsewhere in their lives. As such, I’m always nudging students to come back with another iteration of a project, this time with a focus on evoking the users’ or viewers’ emotional connection. But students are finding this to be a difficult to impossible task when the design tool they’re using is OnShape.

Wait. Before you vote down this post because you think I’m about to yuck OnShape's yum, hear me out. This post is about why there’s reason for optimism about OnShape’s future. I have concrete capabilities that suggest new abilities that all OnShape users will benefit from - artists in particular. I want to encourage the OnShape product team to consider the strategic market potential possible if the product roadmap is expanded to include some of these additional capabilities and an evolution in mindset across its development teams to more fully consider the value that emotional impact can have on almost all design. 

* Richer Curve Repertoire and Support

During the 3+ years I’ve been working on and off with OnShape there have been a number of enhancements that incrementally support designers' ability to create more natural 3D forms. Splines and b-splines, both 2D and 3D, while basic, are steps in the right direction. Much richer support for these forms and others such as NURBS are needed.

* Query Variables

Consider new classes of variables that can be used to refer to rich geometric constructs. At this point, the goal of these variables would be to allow variables, expressions, and features to access the full richness available through FeatureScript queries. These variables would allow the ability to create a query and to create new “scratch contexts" into which entities can be added without muddying up a studio’s default context. Query variable support would include features for creating subqueries and joins of other already defined query variables. Query variable references would be accepted as parameters to certain classes of features.

Yes, I imagine that the OnShape team will worry that the biggest challenge in adding a richer, higher-level capability such as query variables may well be related to UX. And from what I’ve seen, heard, and read over the past few years, UX has been seen by the team as a challenge that slows down the development of new, really powerful, and desperately needed capabilities. (One need only ask why a richer feature list UX that includes capabilities like hiding, grouping, and deriving STILL hasn’t been introduced.) I, of course, encourage developers to lean into the UX challenge so that it’s a strength rather than an impediment to growth.

* Standard Library Level 2

Though I’m not entirely certain, I imagine that the developers of OnShape’s standard library can claim that it’s functionally complete. In my very limited experience, I’d probably go along with that claim if I unfocus my eyes and take it on faith in those (many) areas that I’m not a geometry or graphics guru. 

Yet, I experience the standard library as so low level as to be axiomatic. You can’t even ‘move’ things, you can only ‘transform’. The current standard library needs at least one more layer of capabilities that script writers can draw upon to do what they’re actually trying to accomplish without having to break their problem down to first principles. 

Straight up: The current low-level standard library generates so much friction that it limits users’ ability to get from problem to solution through new FeatureScript development.

* Feature List Design Patterns

{Some forum readers may not understand aspects of this point, though I’m certain that the OnShape development team knows this is an issue.}

One of OnShape’s capabilities that I’m very excited about these days is a design pattern based on ‘feature patterns’ using iteration variables. I equate this to be the equivalent to a for loop in the feature list. On a practical level, support for other essential design patterns like if-then-else and nested subroutines are desperately needed, as are the UX elements in documents, studios, expression syntax, and the feature list that are needed to support these capabilities.

I can break these ideas out into separate improvement requests. But that’s for another day. I’m posting them together here so they’re seen as a set of related improvements toward a larger goal.

My two cents,

- Bob

konstantin_shiriazdanov

From some point I would also like to have more high level instruments for things like free-form surfacing, 3d sketching, sketching on surfaces, nonlinear deformation tools for all kind of bodies and possibly tools for direct access to mathematical body definitions (define bodies by the systems of equations/ unequalities).

I also like the ability to keep and pass between features query content through part studio variables. @owen_sparks even had a logged IR for this.

Another powerfull concept that i keep in mind is reusing feature sequences defined in one part studio in the context of another only substituting external references/query parameters.

But even I can see the problems that you face if trying to implements something from this - the biggest is perfomance, another one is that most users of mechanical engeenering CADs never needed things described above, for most of us having big standart part library is far more usefull in the daily work and that is for what they get their money.