Cleanest way to work with existing sketches?

adamohern

Let's say I have a whole bunch of profile sketches, and I want to offer them as options in a FS I'm making. I've sketched them out in a Part Studio in separate sketches.

I assume I could reference those by name in my FS, then somehow insert that geometry into a sketch in my feature, right?

Let's say I'm building a hose feature, and it sweeps a shape along a curve. The hose could be any shape: round, square, star shaped, whatever. I've sketched each profile (round, square, star) in a Part Studio accessible to my FS. How do I pull that geometry into a sketch within my FS?

kevin_o_toole_1

Documentation for how to do this is coming soon. In the meantime, you can take a look at this post. It's a bit outdated (we now have an import dialog!) but the main idea is at the bottom: Importing a Part Studio into a Feature Studio.

Basically, you can call the Part Studio's build function inside your feature, and merge in the resulting context. In your case, this will give you some sketch bodies, which you can reposition and use to construct the rest of your feature. You can do this with an imports of several Part Studios by giving them all their own namespaces, and call a different build function based on logic in the feature.

Note that because this reference is done through a FeatureScript import (just like a lot of other things in Onshape), you get automatic updating for free. That is, within a document, updating the underlying Part Studio will automatically update everything with features that reference it. Outside the document, when you reference a version feature, you're also referencing a version of the Part Studios.

Our hope is that this free intermixing of Part Studios and Feature Studios promotes workflows that allow you to use code for the portions of your features that need code, and use Part Studios for the parts of your features that are just static geometry. Your hose w/ profile feature is a good example.

adamohern

Complicated.

So when will this be easy to use? Right now it looks too hard for me.

kevin_o_toole_1

There's now docs for this here. The code does involve few steps, but it's not that complicated (especially considering that you're getting a robust reference to the Part Studio geometry that updates with any changes).

adamohern

Sigh. I guess I'd hoped that FS would be less programmy. Yes, it's powerful, yes, I see the engineering logic behind it. But I also think things like this will be far beyond what a typical user can be expected to understand. Essentially this implementation ensures that only coders will be able to use FS. That's fine, but it's a big missed opportunity IMO.

victor_salit

Why not create the sketch inside your feature? Provide the user with a choice of a section_type and construct everything programmatically. (Just thinking out loud, I am not an expert).

adamohern

Some things are just far faster and easier to do graphically. If it's a simple rectangle, sure. But if it's a router profile with a dozen line segments, a couple of arcs, and a spline, constructing it programatically could take a couple of hours and hundreds of lines of code. Doing it graphically is easy.

billy2

Seems like you need to set this whole thing up to succeed which isn't trivial. 

So there's 2 documents:
1. sketch library with many part studio tabs
2. receiving document with a part studio and a featurescript

sketch library document
All sketches to be defined at the origin, on the x-y plane and with an understanding of the x direction.

receiving part studio
Has to have a mate connector which locks down rotations and translations for incoming sketches. Put this
incoming sketch here on this mate connector, boom, done.


-I'm not sure you can access a sketch in a part studio, I didn't see any code for this. I'm thinking derived part.
-If you do all of this, why limit it to sketches? Just create a library of parts, sketches & featurescripts.
-When I created a mock-up library document, it's revision level went to the moon fast. But who cares, it's just a number.

Show us how it's done Adam, you go boy!

billy2

victor-I like it

I'm not sure of a way to inject my code into an existing OS function. Wouldn't it be nice to add an enum to all extrudable OS features? This way you'd have a drop down listing all library sketches to be used. I think this is what you're wanting.

Unfortunately- you have to decide where the sketch goes.
Each time OS posts a revision, you'd have to update all the code again.

It'd be nice to extend an OS feature. Maybe this is possible so you can manage what you're suggesting without updating everything all the time.

billy2

So I was looking at Jacob's code "Extrude Profile Feature":
https://forum.onshape.com/discussion/3844/extrude-profile-feature#latest

I think he's done it. Each of his profiles is carefully laid out in a part studio which he inserts (derived) into another part studio "profiles". I think I'd define everything in one part studio called "8020 profiles" to simplify the structure.

Also he has everything in one document so there's no revisioning going on. I'm not sure having "8020 profiles" in a global library document under revision control is a bad thing. In fact I like the practice. I think it's a good idea.

Jacob are you a student? Your code is well done and could the seed for many good things to come.

 

kevin_quigley

@adamohern Yes totally agree. What will happen is Feature Script will find its niche in bespoke apps and a network will grow up of consultants offering support...much like databases like Filemaker. But without a full on graphical interface it will be ignored by most users, in the same way that scripting in SolidWorks is ignored by most, whilst library parts, configurations and equations are used by many, as are systems like Driveworks

adamohern

I agree completely, Kevin. I do think, however, that they've one things the right way 'round: rather than starting with a graphical UI, they've built on a much firmer foundation. With that in place, graphical systems are easier to implement. A great example of this is the Part Studio itself, which is really just a big graphical interface for writing FeatureScript (a Part Studio is really  just one big FS, after all).

A great example for inspiration would be Fabric Engine. Their nodal system is really just a visual way of writing KL code. You can drag and drop nodes and connect them up like any other node system, but under the hood you're just creating KL code as if you were writing it by hand. I could imagine something very similar happening in Onshape.

billy2

Kevin-You don't like progress? David Taylor who wrote designwave & spaceclaim has always been critical of CAD companies that don't eat their own garbage. Criticisms during Solidworks 95 & 96 due to the dysfunctional app environment was prevalent in some CAD circles back in the early days.

With a fresh start and a new architecture, I think OS is on the right track, why not share your developers API? I think it's a major step forward for the CAD industry. 

I'm not sure if featurescript is for everyone but I'm surprised at what's been done. There's college students that have written some bitch'n code and many of the OS application engineers have written code that needs to go main stream. I'm shocked at what I can do in 5 lines of code (ok, maybe 25 lines of code).

I'm not sure where this is going. Will onshape's customers write the next version of onshape?

I see featurescript (open developer's API) as the next step in the CAD industry. Any CAD company that doesn't expose their developers API is old fashion and out of date. One good thing is they didn't choose LISP as it's programming language, thank goodness there's a little sanity in this world.

I see the glass half full and not half empty.

billy2

Fabric Engine is really cool. Adam is it web based or do you produce web stuff? The video talks about building and deploying as if it's a desktop system producing web content. At any rate it's really nice and what you can publish makes drawings look really old fashion.

adamohern

Fabric Engine is kind of a weird concept to explain, but really exciting if you can wrap your head around it.

It's hard to think of a CAD analog, because nothing really exists.

You might say it's very loosely like Grasshopper for Rhino, except imagine if Grasshopper were available as a plugin for every CAD system: Grasshopper for Rhino, Grasshopper for SolidWorks, Grasshopper for Inventor, etc. You could use Grasshopper in any CAD system, and the results would be identical on all of the other ones.

Imagine how powerful that would be: you could build your feature intelligence in, say, Grasshopper for Rhino, and then open the exact same data in SolidWorks, with all of the parameters intact. Everything would still be editable, fast, and stable. You can even copy/paste features from Rhino to SolidWorks to Inventor, and everything is completely compatible.

That's effectively what Fabric does for the VFX industry. It's allowing people to build complex rigging logic in, say, Maya, and then use those rigs interchangeably in 3DStudio Max or MODO. You can copy/paste logic between DCC apps, and everything is completely seamless.

It can be used for generative modeling, character rigging, particle effects, shading, lighting, rendering, animation... basically anything you'd expect a robust DCC to do for you these days, except that it works with whatever DCC you're currently using.

So yeah, it's pretty exciting. The developers are the same guys that developed ICE for XSI (then Softimage, now killed by Autodesk). If you've heard of ICE, you have a huge respect for those guys. They're amazing. Basically FE is like ICE, but re-built for maximum flexibility and performance.

billy2

I'll read up on it. I've been stuck in this block & fillet world too long.

Thanks for the references, maybe these worlds are about to collide?

kevin_quigley

@billy not sure why you say I don't like progress? I like progress when it benefits the maximum number of people and not just a few. That was my point. 

If FeatureScript stays script only then it will simply be supersceded by applications that offer a more usable front end. For the techno geeks, scripting is pure. For the rest of us, who want outcomes, we need tools that perform when deadlines are tight. Purity and perfection don't come into it.

html hand coding vs visual design tools
open source 3D printing vs plug and play machines

the world is full of people who are prepared to hack and put in the hours to learn something because it intersts them. But there are many many more who just want tools that make their jobs easier. They are the ones who fund companies like Onshape.

So yes, good progress is worthwhile.