Future CQ Development

[jmwright]

There has been some informal discussion about making CQ work with multiple kernels, and I'd like to try to get a conversation started on the nuts and bolts of doing that.

[dcowden]

This is great!

Ok, so here are some relatively unstructured thoughts about this:

(1) The most important decision is whether to continue to require the use of BREP kernels, or whether to consider the use of CSG kernels ( like OpenSCAD).

(1a) CSG based systems are inherently much more stable. Having done lots of models in many CAD tools, it is absolutely true that BREP packages are subject to all kinds of odd conditions that can cause 'weird build errors'. CSG models are essentially immune to this problem. That's one reason why OpenSCAD is popular-- its hard to build models, but you can do pretty crazy stuff and still get some kind of object back.

(1b) BREP packages are faster and map better to human thinking. Its really a much heavier lift to build objects in terms of CSG. You get a lot in exchange for the drawbacks of 1a

(1c) Some CQ features are very hard to implement in CSG. For example, CSG has no representation of vertices or edges, so there's no direct way to provide CQ selectors. One solution might be to build things with CSG, and then convert to a BREP at the end of the operation to allow selectors.

(1d) even though STL is a truly horrible format, the most common feature request is to import STL and start modifying from there. BREP engines have big problems with STL because each little triangle is generally converted to a first-class face, which is very expensive. I dont know if a CSG model would do better or not.

(2) if we use BREP, the industry leader is Parasolid. I've spoken to them on pricing, and i have the documentation. Pricing is the most outlandish of any software i've ever seen. A developer license runs about $20k, and then pricing is 10% of all revenues for any product that uses it. Yikes! I doubt they would touch any open source project.

(3) The best open source alternative is still OpenCascade(OCC). The latest version allows creating 3d text based on fonts-- a feature i've been waiting for. The path forward would be to use OCE+pythonOCC . https://github.com/tpaviot/oce. OCE has fixes and and contributions that make life easier and fix issues-- and pythonOCC has python bindings.

(4) I used FreeCAD instead of pythonOCC because (a) at the time i started, pythonOCC was not as far along, and (b) pythonOCC remains a VERY low level API. FreeCAD already had high level APIs for many of the operations i needed. In retrospect this was penny wise and dollar foolish-- i was able to get CQ done much faster, but now there are limitations that i cannot get around.

(5) using FreeCAD is of value primarily to get the benefit of an available GUI, and a user community.

(6) if we want to consider using a CSG kernel, this one would probably be the best choice http://brlcad.org/. It is actively developed with support by the US military, and is very robust. some CQ features would be very hard to implement using CSG, but the overall stability would be better. BRLCAD supports STL import.

(7) As i was nearly done with the current version of CQ, i have realized that there is a fundamental architectural issue. The CQ library combines two concents that should be separate:

(a) a stack, which can be used for selectors and operations, like in jquery
(b) a feature tree, which is used to define the history of features as they are constructed.

the current implementation is missing (b), and it creates real problems and confusion. These concepts needs to be split apart, so that there is a proper feature tree , and then selectors need to operate on the tree separately. This is analogous to how jquery works-- the HTML DOM is like a CAD feature tree, and CQ is like JQ. This structuure would solve a very common problem Jeremy came up with, in which you need to select edges, faces, or vertices that were contributed via a certain feature, rather than the entire object ( as it is today).

Whew! That was more than i thought it woudl be!

[jmwright]

As you've said, Parasolid is pretty much out for an Open Source project then. That's crazy expensive.

On BREP vs CSG - Is one going to outshine the other when CQ beings to be used on large and complex designs? I'm thinking beyond hobbyist use, to the heavy use that you might expect from a company that specializes in mechanical design, or an organization like Mach 30 five to ten years down the road. It sounds like BREP might start to pull away from CSG in performance in that case, and would be a more natural fit for CQ's way of doing things anyway. My personal preference would be to target the platform that gives the best professional level performance/experience, even if we as developers have to jump through some more hoops on the back end to deal with oddities, like the ones inherent in BREP. I'd also prefer to sacrifice short term development speed in favor of having a more capable platform long term. The dream for me would be to have somebody like NASA or SpaceX be attracted to CQ because of the "whoa, that's an incredible new way of doing things" factor, and then stay with it because it's powerful enough for some of their most serious work.

[dcowden]

There Is no doubt at all they a BREP kernel is more suited to industrial use. All of the leading CAD packages used seriously in industry are parasolid based.

The ​re are many reasons for this, but i think the main one is the same thing that was debated at Mach30 a while back-- the importance of 2d drawings.

The truth is that most things are still manufactured mostly in 2D, and still concepted mostly in 2D. that's because "2.5D" designs are still the cheapest to manufacture in most cases. As a result, good designers still tend to think about easy to manufacture designs, which will tend to be ones that can be done with 2.5D operations, or a combination of them first. And of course 2D drawings are still the perferred way to communicate-- they are simply cheaper than 3d drawings to deal with.

BREP has the huge advantage that it maps more directly to the manufacturing process. You draw a 2d picture, and extrude it to an object. Or you start with a 3d plate, draw a 2d profile, and then extrude a cut. These two steps map directly to what will happen during manufacturing. In solidworks or freecad , you can literally screenshot your sketch before you extrude it, and send it to someone for manufacturing. That's really quite a huge deal. Yes, its true that a CSG based package could create a drawing for you anyway to print, but that's not the point-- the BREP package had you thinking they way you would communicate the design to others-- whereas CSG you were thinking bout all kinds of odd elementary operations.

​Which leads to the last reason i think BREP is better for industry-- because when an engineer thinks about a design, they think about what the part needs to look like, not how to do that. A good example is a fillet. if you have a corner, you just want to fillet it to a 0.25 radius. That's what you'll communicate in the drawing, and to the machinst. You definitely can't be bothered to think you need to create a 0.5" cube, subtract a 0.5" diameter cylinder centered at the bottom right corner, and then subtract that from the original model! That's just crazy. fillet has to be one operation!

​

On Sep 13, 2014 12:27 AM, "Jeremy Wright" notifications@github.com wrote:

As you've said, Parasolid is pretty much out for an Open Source project then. That's crazy expensive.

On BREP vs CSG - Is one going to outshine the other when CQ beings to be used on large and complex designs? I'm thinking beyond hobbyist use, to the heavy use that you might expect from a company that specializes in mechanical design, or an organization like Mach 30 five to ten years down the road. It sounds like BREP might start to pull away from CSG in performance in that case, and would be a more natural fit for CQ's way of doing things anyway. My personal preference would be to target the platform that gives the best professional level performance/experience, even if we as developers have to jump through some more hoops on the back end to deal with oddities, like the ones inherent in BREP. I'd also prefer to sacrifice short term development speed in favor of having a more capable platform long term. The dream for me would be to have somebody like NASA or SpaceX be attracted to CQ because of the "whoa, that's an incredible new way of doing things" factor, and then stay with it because it's powerful enough for some of their most serious work.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-55481478.

[jmwright]

1) It sounds to me like BREP is definitely the way to go then. It certainly has its disadvantages, but there's a reason it's the industry standard.

2) I agree that Parasolid is a non-starter for an open source project like CQ.

3) Based on the conclusion from number 2, OCE+pythonOCC sounds like the winner. Is there anything about OCE that doesn't map directly to pythonOCC, which I assume is designed to utilize OCC as a standard?

4) I think that in the near term, CQ will have to continue to rely on FreeCAD. This will give us time to use CQ in projects to test the limits of its core philosophies, and to design the OCE+pythonOCC branch of CQ.

7) I like the idea of having a feature tree and then having the selectors operate on that. It seems like the transition to OCE+pythonOCC would be the perfect time to implement a seismic shift in the architecture like this. Selectors are such a huge advantage of CQ, I think it will be well worth the time spent to get this right.

It seems to me like we've got a path forward if you and Jason agree. OCE+pythonOCC with a feature tree that selectors act on rather than on a stack. Dave - You have a branch for pythonOCC already if I remember right. Is that in a state where it would be a good starting point, or will we need to start from scratch? Do you have any examples of feature trees to use as templates? Maybe the feature tree code in FreeCAD?

[dcowden]

Yes, good memory, there is a pythonOcc branch already. But i agree that we should start from scratch ( at least initially), and pull in old code rather than starting with what's there and refactoring.

I dont know of any feature trees to use as an example. I would guess it is pretty much a standard tree.

[jmwright]

With what you've discovered about the Parasolid kernel pricing, is the abstraction layer to accomodate multiple kernels off the table now, or is it still a must-have?

When you envision a standard tree data structure, it's like what is outlined in these pages, correct? http://interactivepython.org/runestone/static/pythonds/Trees/trees.html http://interactivepython.org/runestone/static/pythonds/Trees/implementation.html

[jmwright]

Is a discussion of using Python 2.x vs 3.x relevant here?

[dcowden]

A python 2 v 3 discussion is relevant for sure. i still just cant seem to make the jump to 3. there just seem to be too many libraries that are 2.x ones. i would be open to moving to 3, though, especially if we start new.

Regarding trees: yep pretty much. I envision a 'typesafe' tree with extra methods that make the tree more suitable for our use, rather than a generic data structure. this would probably use a tree under the hood. And we may not need all of the tree methods ( for example left and right methods). For example, we might have::

class Feature List getParent() <-- the features that were involved to get this one List getChildren() '<-- features that were produced from this one

getOperation() '<-- the operation that resulted in this feature Feature getRoot() <-- get the topmost feature that's a very good point about parasolid pricing-- if we built a BREP based solution, it seems quite unlikely that we'd ever add parasolid-- unless we wanted to make a commercially licenced verison of CQ. THat would be the opposite of interesting to Mach30, but might be to me :) I guess i would vote to keep a compatibility layer-- not really because of the possibility of commercialization, but because i think a well thought out interface is essential to good software, and making an interface will keep us honest

[jmwright]

The main reason I ask about Python 2 vs 3 is because of this article by Nick Coghlan. http://www.curiousefficiency.org/posts/2014/08/python-4000.html

In it he mentions how Python 2 will start to fall behind Python 3+ as time goes on. The lack of 3.x compatible libraries is a pretty significat barrier though.

For the getOperation function of the Feature class, I'm guessing it would return an Operation base class that all operations (cut, extrude, revolve, sweep, etc) inherit from?

When you say "interface", are you talking about implementing a Java-style interface (or the Python equivalent)?

Documentation on Python interfaces http://ref.readthedocs.org/en/latest/understanding_python/interfaces/index.html

zope.interface Package for Python Interface Classes https://pypi.python.org/pypi/zope.interface/3.6.7

The accepted answer here has some interesting commentary on Python abstract classes vs intefaces. http://stackoverflow.com/questions/372042/difference-between-abstract-class-and-interface-in-python

[dcowden]

Hmm, yeah.. I would say on python 2 vs 3 we can start with 3 and see if we run into libraries that dont support it.

by "interface" i really meant the concept, not a real extra class. when in python i dont really like adding the extra layer of classes-- 'duck typing' is fine. i just like the idea that we think about how it works in a way that the methods/classes are not specific to the implementation. As an example, if an operation has a method 'translate' needs a 3-d point, we would avoid having its parameters be a FreeCAD Vector or PythonOCC Vector, and instead would prefer using a 3-tuple, which is implementation independent.

Yes, by Operation i had in mind that an Operation produces features, as you say. So the entire tree can be re-built from the root by replaying the operations through the tree. This is a very powerful concept, because it means that i could modify a parameter at one node in the tree, and then re-compute all of the nodes below that be re-applying the operations in order as they cascade through the tree.

[jmwright]

Jason asked a question in an email that got me thinking about how the feature tree would actually work in practice. Attached is a diagram that I roughed out to try to get an idea of how things would work. Notice that getOperation() returns the operation(s) that lead to the creation of the feature, so the operation was actually applied on the level up from the current one in the tree. This may be backwards from how Dave was envisioning it so that you could replay the operations and have them cascade down the tree. Also, two features can have the came child if the operation combined the two features into one feature.

Is this anywhere close to the way it would be?

[dcowden]

Thanks for drawing that up Jeremy!

The big question i think is "what type of thing is important enough to be a feature?" I need to think about this a bit more. In this diagram, a feature is either a solid, or a 2-d construct ( EG, a wire). But this may be too granular.

The main reason to add the feature tree is for ability to do better selection. Our goal is to be able to select, say, all faces that lie parallel to the Z plane-- but to LIMIT that selection to only those that were produced by a particular feature. For this functionality, we only need a very broad node for each feature-- a produced solid.

I"m not sure that we'd need the ability to isolate a Circle in order to perform selectors on it.

Let me look at some additional code and see if i can lay out a direction.

On Mon, Sep 29, 2014 at 4:51 PM, Jeremy Wright notifications@github.com wrote:

Jason asked a question in an email that got me thinking about how the feature tree would actually work in practice. Attached is a diagram that I roughed out to try to get an idea of how things would work. Notice that getOperation() returns the operation(s) that lead to the creation of the feature, so the operation was actually applied on the level up from the current one in the tree. This may be backwards from how Dave was envisioning it so that you could replay the operations and have them cascade down the tree. Also, two features can have the came child if the operation combined the two features into one feature.

[image: cadquery feature tree diagram] https://cloud.githubusercontent.com/assets/1015439/4449119/86a60310-4819-11e4-9098-4157673688e6.png

Is this anywhere close to the way it would be?

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-57227659.

[jmwright]

Two questions on this front. It will be quite awhile before I can circle back around to this, but these were on my mind.

1. How much of a train wreck would it be to try to bolt on a feature tree to the existing CQ implementation? It would be kind of nice to experiment with some of the advanced selector and tree concepts that we've discussed, even if it only ever lives on a git branch.
2. Advanced sweep operations were one limitation of FreeCAD that you've mentioned. What are the other show stoppers?

[dcowden]

Regarding 1, i think anything on a branch would be good, but i think its a pretty major undertaking. CQ was definitely written very tightly to the stack-- so nearly everything would need to be touched to change this way of working.

Regarding 2, another issue was stability. A lot of things simply 'weird out'. this might not be FreeCAD's fault, however. I also ran into a lack of functionality around surface projection and detection. For example, one really good feature we need is the concept of "extrude to next". that means, extrude a sketch until it hits the next surface. I was unable to figure out how to implement that in FC

On Mon, Nov 3, 2014 at 10:03 PM, Jeremy Wright notifications@github.com wrote:

Two questions on this front. It will be quite awhile before I can circle back around to this, but these were on my mind.

1.

How much of a train wreck would it be to try to bolt on a feature tree to the existing CQ implementation? It would be kind of nice to experiment with some of the advanced selector and tree concepts that we've discussed, even if it only ever lives on a git branch. 2.

Advanced sweep operations were one limitation of FreeCAD that you've mentioned. What are the other show stoppers?

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-61587138.

[jmwright]

To approach this from a different angle then, do you feel it's even possible to add things like blind selectors and selectors by ID to the current CQ stack implementation? Or do those things absolutely require a feature tree?

I'm trying to figure out how far is too far to push the current implementation, keeping in mind the resources that we have available right now. I could see the CQ-PythonOCC rewrite taking hundreds of hours, which will take us many months at our current pace of development. Whether we like it or not, we're heavily reliant on the FreeCAD based implementation of CQ right now. I do think the current implementation is still great and hope that we can start building a user base around it, while working towards the future at the same time.

[dcowden]

You are right about the rewrite effort.

anything is possible. We definitely have to do a feature tree to get the selectors we want,but it is probably possible to bolt that onto the current code rather than rewriting it all. What that might roughly look like is to create a feature tree, and then go into the places that manipulate the stack, adding code that updates the festure tree if a new solid was produced. then all of the existing selectors get a new flag that allows them to perform selections against BOTH the current object and the last one on the feature tree. Only objects different in the last one are selected.

Still it would be a challenge, and hackey,but doable I suppose On Nov 4, 2014 10:41 PM, "Jeremy Wright" notifications@github.com wrote:

To approach this from a different angle then, do you feel it's even possible to add things like blind selectors and selectors by ID to the current CQ stack implementation? Or do those things absolutely require a feature tree?

I'm trying to figure out how far is too far to push the current implementation, keeping in mind the resources that we have available right now. I could see the CQ-PythonOCC rewrite taking hundreds of hours, which will take us many months at our current pace of development. Whether we like it or not, we're heavily reliant on the FreeCAD based implementation of CQ right now. I do think the current implementation is still great and hope that we can start building a user base around it, while working towards the future at the same time.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-61755694.

[jmwright]

Regarding 2, another issue was stability. A lot of things simply 'weird out'. this might not be FreeCAD's fault, however. I also ran into a lack of functionality around surface projection and detection. For example, one really good feature we need is the concept of "extrude to next". that means, extrude a sketch until it hits the next surface. I was unable to figure out how to implement that in FC

Another way to address this might be to contribute to FreeCAD at a lower level, adding the OCC plumbing to allow things like extrude to next, and contributing stability fixes. The question then becomes, is time any better spent doing this than doing the CQ-PythonOCC implementation from the ground up?

[dcowden]

Let's see what users demand. What I've learned so far is that it's best to see how we can pick up steam, and support what t hose few critical first users need. On Nov 20, 2014 11:53 PM, "Jeremy Wright" notifications@github.com wrote:

Regarding 2, another issue was stability. A lot of things simply 'weird out'. this might not be FreeCAD's fault, however. I also ran into a lack of functionality around surface projection and detection. For example, one really good feature we need is the concept of "extrude to next". that means, extrude a sketch until it hits the next surface. I was unable to figure out how to implement that in FC

Another way to address this might be to contribute to FreeCAD at a lower level, adding the OCC plumbing to allow things like extrude to next, and contributing stability fixes. The question then becomes, is time any better spent doing this than doing the CQ-PythonOCC implementation from the ground up?

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-63924439.

[burdickjp]

I'm just getting started into using CQ, but there are a few ideas I like: 1 - moving to Python 3 2 - moving to PythonOCC

I think both of those would make CQ more flexible and expandable and allow it to grow beyond FreeCAD.

[dcowden]

Thanks for the feedback!

100% with you on the PythonOCC move-- that's a plan.

Unfortunately that plan means no python 3-- its not supported by pythonOCC i dont think....

On Fri, Dec 5, 2014 at 9:32 PM, burdickjp notifications@github.com wrote:

I'm just getting started into using CQ, but there are a few ideas I like: 1 - moving to Python 3 2 - moving to PythonOCC

I think both of those would make CQ more flexible and expandable and allow it to grow beyond FreeCAD.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-65882104.

[jmwright]

@burdickjp Welcome! Thanks for the feedback.

If you haven't already, you might want to check out the CQ module for FreeCAD. It's only a few weeks old and still in alpha, but it's gotten some good feedback so far and has come a long way in just the last couple of days.

Most of the documentation for CQ is on ParametricParts.com/docs

There are also good examples embedded with CQ and the FreeCAD module that are expanded as we add new features.

Please don't hesitate to ask questions. We'd love to see examples of what you're doing with CQ too!

[jmwright]

Just wanted to capture a quick thought here.

Based on what we've seen with the CQ module for FreeCAD so far, I would propose that any rework of CQ to be based directly on PythonOCC should have a companion GUI incorporated in the same code base. This would be similar to what OpenSCAD does (I believe). The GUI should not prevent CQ from being used as a stand-alone library though. If there's not support for putting the GUI in the same code base, I'd want to find some other way to more tightly couple the CQ library and the GUI.

[dcowden]

+1-- agreed. this should be very doable. pythonOCC actually comes with a number of examples ( most of which, i think , are based on wxpython )

On Sun, Dec 7, 2014 at 11:50 PM, Jeremy Wright notifications@github.com wrote:

Just wanted to capture a quick thought here.

Based on what we've seen with the CQ module for FreeCAD https://github.com/jmwright/cadquery-freecad-module so far, I would propose that any rework of CQ to be based directly on PythonOCC should have a companion GUI incorporated in the same code base. This would be similar to what OpenSCAD does (I believe). The GUI should not prevent CQ from being used as a stand-alone library though. If there's not support for putting the GUI in the same code base, I'd want to find some other way to more tightly couple the CQ library and the GUI.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-65975876.

[emdash]

I would want to see the gui made available. Maybe as a companion library, or something. That gui needs to work better than OpenSCAD's though. I can't stand the way rotation works. A solid 3D viewer is the foundation of any CAD tool. FWIW, FreeCAD's viewer is one of the better open-source ones.

[dcowden]

Hi!

Right now, there are two GUIs for CQ:

(1) cadquery-freecad-module -- https://github.com/jmwright/cadquery-freecad-module. It is a pretty sweet module that embeds easily in FreeCAD

(2) parametricparts.com -- browser based tool where you can create models using scripts.

We have talked about making a stand-alone GUI ( based on pythonOCC), but honestly it probably wouldnt be much better than the freecad module is now..

On Sun, Dec 14, 2014 at 2:00 PM, emdash notifications@github.com wrote:

I would want to see the gui made available. Maybe as a companion library, or something. That gui needs to work better than OpenSCAD's though. I can't stand the way rotation works. A solid 3D viewer is the foundation of any CAD tool. FWIW, FreeCAD's viewer is one of the better open-source ones.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-66924759.

[jmwright]

We have talked about making a stand-alone GUI ( based on pythonOCC), but honestly it probably wouldnt be much better than the freecad module is now..

However, building a native PythonOCC implementation should give us more more flexibility and control. There are advanced things that I'd really like to do with the CQ GUI long-term that I don't think we'll be able to do through FreeCAD. Having a tight coupling between the script window and the point-and-click GUI is one thing that comes to mind.

[dcowden]

That's true. I definitely think given enough effort a stand alone guide could be better... On Dec 14, 2014 2:57 PM, "Jeremy Wright" notifications@github.com wrote:

We have talked about making a stand-alone GUI ( based on pythonOCC), but honestly it probably wouldnt be much better than the freecad module is now..

However, building a native PythonOCC implementation should give us more more flexibility and control. There are advanced things that I'd really like to do with the CQ GUI long-term that I don't think we'll be able to do through FreeCAD. Having a tight coupling between the script window and the point-and-click GUI is one thing that comes to mind.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-66927061.

[jmwright]

A solid 3D viewer is the foundation of any CAD tool.

@emdash What features do you feel would make the ideal 3D viewer?

[emdash]

@jmwright

You spend most of your time turning and rotating parts and staring at them from various angles trying to decide what to change next. Pan / zoom / rotation has to feel intuitive and natural. It needs to be easy to look at exactly what you want to look at. It should not have weird bugs which cause you to get "stuck" or go into "gymbal lock". You should not have to restart the viewer because it's screwed up in some way. And it should be easy to reset to one of several known views. This is the bread-and-butter of your workflow. It needs to be extremely stable.

One thing I like about FreeCAD is how the num-pad becomes a short-cut for moving between certain views -- but they don't take it far enough. Expanding on that concept in some way would be super awesome.

Inventor does a better job with that weird view cube. I don't like how like how you have to use the mouse. If, for example, you made the num pad a short-cut for the view-cube like interface, that would be pretty awesome. I.e. the num pad buttons are relative movements, not absolute positions. This makes it easy to see all around the part.

---

OpenSCAD's viewer is a good example of how NOT to do it. It's too sensitive to mouse movment. Your part spins at 10000RPM if you move your mouse half an inch. If you try to pan, you can actually get lost to the point where you can't find your part any more. If you're looking at the part upside down it rotates backward. It gets into gymbal lock easily to the point where it just spins around one axis. No. no. no.

---

We need to be able to assign materials to different objects in a scene. The viewer needs to support translucency, because it's a useful tool for visualizing interior dimensions. FreeCAD does an OK job at this, but there's something "funny" about the way it looks. I guess it's hard to get decent looking translucency. Autodesk 123D and inventor do a pretty good job. Something about it just feels right. Maybe it's that they add just a touch more specularity. Or maybe they use a different type of depth peeling.

Currently I have to re-assign the material colors every time I re-render. Obviously that's unacceptable over the long run. I would be fine with designating materials in the code itself. I dunno if that violates some kind of abstraction. There's probably a million other ways to do it. Anything's fine with me so long as it's persistent and reasonably intuitive.

---

I really like the idea of interaction between the gui and the code. I don't know how feasible it is, but what seems like the holy grail to me is that you can click-and-drag things in the viewer, and your code updates. Or you somehow select features in the source, and bits of the view highlight and you can then interact with them. You can add parameters to your model, and a GUI is generated that allows you to interact directly with the feature. (Clicking on spin buttons and waiting for the regeneration is not a good experience). I know that sort of thing is wayyyy off in the distance, but it would be amazing if you pull this off. I have ideas about how it might be possible, but there are probably going to be some weird limitations with my approach that might prove frustrating and counter-intuitive to many people. In any event, this is bottom priority.

First priority is just to get a decent viewer that's easy to interact with, is snappy, responsive, and stable. If it does nothing more than import STL meshes you'll at least be doing all of open-source CAD a huge favor.

---

I don't want it to seem like I am unhappy. CadQuery is already miles above OpenSCAD in terms of usability. For mechanical design, you need to be able to do fillets, chamfers, counter bore / sink, extrusions, lofts, etc. The selector model was a stroke of genius. I had looked at OCC before and found their iterator-based API really confusing and verbose.

I don't think you made a mistake by leveraging FreeCAD. If you had tried to start by writing an OCC wrapper, you would still be hacking on it. It's good to have a proof-of-concept. Now you're motivated to write that OCC back-end / stand-alone viewer so you can overcome FreeCAD limitations. And I don't blame you for not wanting to hack on that codebase. And OCC is way too low-level / way too verbose to program in directly.

BREP is definitely the way to go, for all the reasons mentioned. Although I am not sure it has to be one or the other. It's code. It all becomes triangles in the end. You can probably combine approaches. Have a CSG dialect and a BREP dialect. Maybe even ways to convert between objects (obviously won't be guaranteed to work in all cases, but ...). Maybe even an implicit function dialect, like implicitCAD for those who want to get really mathy and wierd (just don't use Haskell for god's sake).

[dcowden]

I love the number pad view idea.

I think of all cad packages solid works is my favorite. Mouse wheel zooms, left click and drag rotates, right click and drag pans. On Dec 15, 2014 12:39 AM, "emdash" notifications@github.com wrote:

@jmwright https://github.com/jmwright

You spend most of your time turning and rotating parts and staring at them from various angles trying to decide what to change next. Pan / zoom / rotation has to feel intuitive and natural. It needs to be easy to look at the exactly what you want to look at. It should not have weird bugs which cause you to get "stuck" or go into "gymbal lock". You should not have to restart the viewer because it's screwed up in some way. And it should be easy to reset to one of several known views. This is the bread-and-butter of your workflow. It needs to be extremely stable.

One thing I like about FreeCAD is how the num-pad becomes a short-cut for moving between certain views -- but they don't take it far enough. Expanding on that concept in some way would be really.

Inventor does a better job with that weird view cube. I don't like how like how you have to use the mouse. If, for example, you made the num pad a short-cut for the view-cube like interface, that would be pretty awesome. I.e. the num pad buttons are relative movements, not absolute

positions. This makes it easy to see all around the part.

OpenSCAD's viewer is a good example of how NOT to do it. It's too sensitive to mouse movment. Your part spins at 10000RPM if you move your mouse half an inch. If you try to pan, you can actually get lost to the point where you can't find your part any more. If you're looking at the part upside down it rotates backward. It gets into gymbal lock easily to

the point where it just spins around one axis. No. no. no.

We need to be able to assign materials to different objects in a scene. The viewer needs to support translucency, because it's a useful tool for visualizing interior dimensions. FreeCAD does an OK job at this, but there's something "funny" about the way it looks. I guess it's hard to get decent looking translucency. Autodesk 123D and inventor do a pretty good job. Something about it just feels right. Maybe it's that they add just a touch more specularity. Or maybe they use a different type of depth peeling.

Currently I have to re-assign the material colors every time I re-render. Obviously that's unacceptable over the long run. I would be fine with designating materials in the code itself. I dunno if that violates some kind of abstraction. There's probably a million other ways to do it.

Anything's fine with me so long as it's persistent and reasonably intuitive.

I really like the idea of interaction between the gui and the code. I don't know how feasible it is, but what seems like the holy grail to me is that you can click-and-drag things in the viewer, and your code updates. Or you somehow select features in the source, and bits of the view highlight and you can then interact with them. You can add parameters to your model, and a GUI is generated that allows you to interact directly with the feature. (Clicking on spin buttons and waiting for the regeneration is not a good experience). I know that sort of thing is wayyyy off in the distance, but it would be amazing if you pull this off. I have ideas about how it might be possible, but there are probably going to be some weird limitations with my approach that might prove frustrating and counter-intuitive to many people. In any event, this is bottom priority.

First priority is just to get a decent viewer that's easy to interact with, is snappy, responsive, and stable. If it does nothing more than import STL meshes you'll at least be doing a huge favor all of open-source

CAD.

I don't want it to seem like I am unhappy. CadQuery is already miles above OpenSCAD in terms of usability. For mechanical design, you need to be able to do fillets, chamfers, counter bore / sink, extrusions, lofts, etc. The selector model was a stroke of genius. I had looked at OCC before and found their iterator-based API really confusing and verbose.

I don't think you made a mistake by leveraging FreeCAD. If you had tried to start by writing an OCC wrapper, you would still be hacking on it. It's good to have a proof-of-concept. Now you're motivated to write that OCC back-end / stand-alone viewer so you can overcome FreeCAD limitations. And I don't blame you for not wanting to hack on that codebase. And OCC is way too low-level / way too verbose to program in directly.

BREP is definitely the way to go, for all the reasons mentioned. Although I am not sure it has to be one or the other. It's code. It all becomes triangles in the end. You can probably combine approaches. Have a CSG dialect and a BREP dialect. Maybe even ways to convert between objects (obviously won't be guaranteed to work in all cases, but ...). Maybe even an implicit function dialect, like implicitCAD for those who want to get really mathy and wierd (just don't use Haskell for god's sake).

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-66952008.

[jmwright]

You spend most of your time turning and rotating parts and staring at them from various angles trying to decide what to change next. Pan / zoom / rotation has to feel intuitive and natural. It needs to be easy to look at exactly what you want to look at.

Agreed. I spend most of my CAD time using a 3D mouse, but am always frustrated by buggy, non-intuitive, or broken 3D view controls when using a regular mouse. I've talked to @dcowden about the idea of doing a live mock-up of what the new GUI could be. This would give us a chance to really get the 3D view dialed in during the journey towards a PythonOCC-based CQ, and also test some other UI concepts. My guess is that the CQ community would need to contribute a significant amount of code to PythonOCC's 3D view to get what we want. That would have the effect of making things better for us and a project that we depend directly on at the same time.

I really like the idea of interaction between the gui and the code. I don't know how feasible it is, but what seems like the holy grail to me is that you can click-and-drag things in the viewer, and your code updates.

My thoughts exactly. This will take a lot of work to get right though. A lot more work than getting the 3D view right even. It's a low priority, but something I'm very interested in exploring at some point.

First priority is just to get a decent viewer that's easy to interact with, is snappy, responsive, and stable. If it does nothing more than import STL meshes you'll at least be doing all of open-source CAD a huge favor.

Again, I'm hoping that we can do this through contributing to the PythonOCC viewer, but I haven't researched this direction at all yet.

The selector model was a stroke of genius.

That's what I think every time I use them. Selectors, and the overall design philosophies behind CQ, totally changed my view of what CodeCAD can be.

[dcowden]

You guys might find this interesting: here is a llink to the viewers that come with pythonOCC

https://github.com/tpaviot/pythonocc-core/tree/master/src/addons/Display

might make a good basis for a GUI-- the heavy lifting has been done.

On Thu, Dec 18, 2014 at 4:46 PM, Jeremy Wright notifications@github.com wrote:

You spend most of your time turning and rotating parts and staring at them from various angles trying to decide what to change next. Pan / zoom / rotation has to feel intuitive and natural. It needs to be easy to look at exactly what you want to look at.

Agreed. I spend most of my CAD time using a 3D mouse, but am always frustrated by buggy, non-intuitive, or broken 3D view controls when using a regular mouse. I've talked to @dcowden https://github.com/dcowden about the idea of doing a live mock-up of what the new GUI could be. This would give us a chance to really get the 3D view dialed in during the journey towards a PythonOCC-based CQ, and also test some other UI concepts. My guess is that the CQ community would need to contribute a significant amount of code to PythonOCC's 3D view to get what we want. That would have the effect of making things better for us and a project that we depend directly on at the same time.

I really like the idea of interaction between the gui and the code. I don't know how feasible it is, but what seems like the holy grail to me is that you can click-and-drag things in the viewer, and your code updates.

My thoughts exactly. This will take a lot of work to get right though. A lot more work than getting the 3D view right even. It's a low priority, but something I'm very interested in exploring at some point.

First priority is just to get a decent viewer that's easy to interact with, is snappy, responsive, and stable. If it does nothing more than import STL meshes you'll at least be doing all of open-source CAD a huge favor.

Again, I'm hoping that we can do this through contributing to the PythonOCC viewer, but I haven't researched this direction at all yet.

The selector model was a stroke of genius.

That's what I think every time I use them. Selectors, and the overall design philosophies behind CQ, totally changed my view of what CodeCAD can be.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-67562573.

[jmwright]

Thanks, I'll take a look. I like that there's a PySide display example. PyQode (our awesome code editor) is PySide or PyQt4 based depending on how you set it up. I was hoping there was an example out there covering PySide.

[dcowden]

yeah i thought you'd like that!

On Thu, Dec 18, 2014 at 9:35 PM, Jeremy Wright notifications@github.com wrote:

Thanks, I'll take a look. I like that there's a PySide display example. PyQode (our awesome code editor) is PySide or PyQt4 based depending on how you set it up. I was hoping there was an example out there covering PySide.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-67591023.

[jmwright]

We've already got the script to set up the PythonOCC-OCE environment in Ubuntu 14.04. It's shouldn't take much to add the PySide development packages onto that. That would be a quick way for me to start developing the next gen GUI mock up. We could figure out how to embed everything with the GUI later.

[jmwright]

I'm interested in experimenting with making units easy in CQ. This may just take the form of some best practice documentation, but I'm not sure yet. This library came across Twitter today and looks promising. http://pint.readthedocs.org/en/0.6/

[emdash]

Did you mean to paste a different link? That's just the cadquery page...

[jmwright]

Yeah, thanks for catching that. http://pint.readthedocs.org/en/0.6/

[jmwright]

This isn't really a future development item, but I wasn't sure where else to put it. A thought occurred to me the other day that the following code should work fine, and not surprisingly, it did.

import cadquery
from Helpers import show

length = 2.0
height = 1.0
thickness = 1.0

result = eval('cadquery.Workplane("XY").box(length, height, thickness)')

show(result)

If used carefully and not abused, this could lead to some interesting techniques like dynamically generating parts of a model's code at runtime. I would not promote the use of eval for everyday scripts, but it could open some doors on challenging modelling/analysis situations later on.

[emdash]

I think this is a good example of the sort of turing-complete trouble you will get into because you've chosen an imperative language for scripting rather than a purely-functional one, or a domain-specific declarative one.

You literally cannot predict all valid usage.

The advantage of python is that you have a lot of library support. The disadvantage is that it's impossible to analyze a script in the general case. It's the same problem that other analysis tools like coverity have: you can spot a particular instance of a construct, but you can't prove that a construct isn't used, that a certain class of error doesn't exist, or even that a script terminates.

I completely understand why the OpenScad folks designed their own language. I actually think they had the right idea, but the OpenScad implementation has some frustrating behavior. Some are due to it's being a CSG kernal, rather than BREP. But others are due to silly, avoidable problems, like the semantics of variable scoping within loops (which is entirely nonsensical, and I consider it to be a bug not a feature. They could have implemented proper lexical scoping and it's a mystery to me why they did not.

At this point I am not sure whether the Turing-complete / imperative nature of python is an asset or a liability. It lets me get away with some things, but I feel like most of them could be covered with a targeted set of declarative features. And I might well be willing to trade Turing-completeness in exchange for various guarantees: i.e. that a script can be evaluated in a reasonable amount of time, that it can be analyzed for useful properties (like parameter names).

In other words, I'm not entirely on board with the fundamental CadQuery assumption: that pure python is the right language to express CAD models. There are various alternatives I would consider. On the one hand, a completely domain-specific language (like OpenScad's) that has syntactic support for CAD operations. On the other hand, a restricted subset of python which allows for meaningful static analysis. Even some kind of XML dialect wouldn't be out of the question in my book.

Anyways, apologies for the essay.

What CadQuery has going for it right now is that it's a concise programmatic interface to a BREP kernel, with some really useful innovations, like the concept of selectors. There are many ways you could go about doing that. Python has some things going for it, but there are other languages out there.

[dcowden]

The advantages of using a real language far outweight the few problems associated with problems like the above.

Sure you end up with a language where you can concoct a bunch of things that you can try to but don't work-- but who cares-- that's not practically worse than simply not supporting them, given that the alternative is to design a complete other language, or, to use a language that has no native bindings available for the open open source BREP kernel out there.

At this point I am not sure whether the Turing-complete / imperative nature of python is an asset or a liability

I am. Python is clearly the right choice here. If you want to use OCC, you get python, C, or C++, or a custom designed language. There's not enough value in building ( and maintaining ) your own language just to avoid a few weird scenarios that someone might try, and dont work anyway.

On Wed, Jan 7, 2015 at 12:00 AM, emdash notifications@github.com wrote:

I think this is a good example of the sort of turing-complete trouble you will get into because you've chosen an imperative language for scripting rather than a purely-functional one, or a domain-specific declarative one.

You literally cannot predict all valid usage.

The advantage of python is that you have a lot of library support. The disadvantage is that it's impossible to analyze a script in the general case. It's the same problem that other analysis tools like coverity have: you can spot a particular instance of a construct, but you can't prove that a construct isn't used, that a certain class of error doesn't exist, or even that a script terminates.

I completely understand why the OpenScad folks designed their own language. I actually think they had the right idea, but the OpenScad implementation has some frustrating behavior. Some are due to it's being a CSG kernal, rather than BREP. But others are due to silly, avoidable problems, like the semantics of variable scoping within loops (which is entirely nonsensical, and I consider it to be a bug not a feature. They could have implemented proper lexical scoping and it's a mystery to me why they did .

At this point I am not sure whether the Turing-complete / imperative nature of python is an asset or a liability. It lets me get away with some things, but I feel like most of them could be covered with a targeted set of declarative features. And I might well be willing to trade Turing-completeness in exchange for various guarantees: i.e. that a script can be evaluated in a reasonable amount of time, that it can be analyzed for useful properties (like parameter names).

In other words, I'm not entirely on board with the fundamental CadQuery assumption: that pure python is the right language to express CAD models. There are various alternatives I would consider. On the one hand, a completely domain-specific language (like OpenScad's) that has syntactic support for CAD operations. On the other hand, a restricted subset of python which allows for meaningful static analysis. Even some kind of XML dialect wouldn't be out of the question in my book.

Anyways, apologies for the essay.

What CadQuery has going for it right now is that it's a concise programmatic interface to a BREP kernel, with some really useful innovations, like the concept of selectors. There are many ways you could go about doing that. Python has some things going for it, but there are other languages out there.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-68979203.

[emdash]

Any weird scenarios allowed by the framework will eventually be employed by some user in a script. That's the curse of the framework designer. It's always better to err on the side of not allowing things initially. It's easier to restrict now, then relax later, than be permissive now, and then deal with breaking people's scripts later when you are forced to restrict functionality.

I think what is ultimately at stake is your eventual goal of pairing interactive editing with programmatic CAD.

If you want to be able to do things like, for example, click and drag a face with the mouse, and have the source code be automatically update to reflect this change, then you don't really want python as a source language. You will find that it's not possible in general to determine which expressions in the source code produced that face, or that it's not clear how to modify them so that the face moves as intended. So the feature will be unreliable.

With some kind of declarative input language, interactive updates would be least be possible (though still likely very tricky). The more directly the source code maps to OCCs internal representation of the model, the easier it will be to support interactive editing. In the best case scenario, you have a direct mapping between the source code and the feature tree. In the worst case, you have the feature tree being created as a side effect of the execution of python code (the current state of affairs).

Maybe the right approach is to do both, and keep CadQuery strictly as a library, but use it to implement a declarative modeling language. This would at least allow people who want to go nuts with imperative programming the freedom to do so.

[dcowden]

If the use case is updating a script from a 3d view of a model, the complexities of updating the variable in the script are the least of your worries. You wouldn't have any straightforward way to know that a particular mouse movement corresponds to any particular parameter. In fact, in the general case that will not be the case. Regardless of what language you use, the best you could do is to identify a feature with a click, and then let the user change the inputs for that feature. there's no way to know which inputs to change just based on a click-- unless the click is interacting with a text field that controls the variable's value. then, its easy-- you just re-run the script with the new variable value.

I'd be happy if we had the ability to select, by clicking, a given feature. that's already sufficiently difficult, but doesn't begin to associate which input(s) generated that feature.

On Wed, Jan 7, 2015 at 4:46 PM, emdash notifications@github.com wrote:

I think that if you ever want to support interactive updates to the code, where interactive changes cause live code updates, this won't be possible in general if the input language is turing complete. It might be possible if the input language is declarative.

Let's try a simple example:

show(Workplane("XY").circle(3).extrude(10))

Let's say I want to select the top face of the cylinder with the mouse and drag it upward 3mm, with the result that the code now says:

show(Workplane("XY").circle(3).extrude(13))

In something simple like this, you could work backward from the top face to find out it's created by a call to extrude, and then use some internal book-keeping to point you at the source code line and know that we are adding 3mm to the first parameter to the call to extrude. But if we instead had:

show(Workplane("XY").circle(3).extrude(HEIGHT))

It gets less clear. Probably the expression be transformed to:

show(Workplane("XY").circle(3).extrude(HEIGHT + 3))

Which is still doable, but what if instead we have:

while x > 0:

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-69097849.

[emdash]

Source highlighting would definitely be the first step.

It's really a book-keeping problem. On the one hand you have your feature tree, which has to do book-keeping already in order to implement all the selectors. Each node in the feature tree needs to know the which objects it produced. Then you can construct your reverse mapping from vertex / edge / face / solid to feature nodes. So when the user selects one, you know which nodes in the feature tree are of interest.

To implement your selection highlighting, you also need another reverse mapping from feature nodes to source lines. There needs to be some way to capture the source code line in the script which produces a feature. In pure python, that will be the tricky / ugly, but I believe it is possible. You would probably have to introspect the call stack, but this could maybe be factored into a function decorator, such that any method that needs to know what source file / line it came from gets that passed in as a keyword argument. Either that or PDB or some other profiling tool could be employed to trace execution.

There might be multiple results for a given vertex / edge / face. If that happens, I guess you just highlight all the relevant lines. You might even consider highlighting all the way up the call stack, in the event that the call occurs in something other than a module-level statement.

[emdash]

Actually, you probably also want to be able to go the other way: you should be able to see which features were produced by a given line of code. But if you can do the one, you can also do the other.

Another useful feature, which I may have mentioned already, but the viewer should have an "interactive selector builder". I.e. I can type a selector expression into a bar, and it interactively highlights the features that match. And puts it in the clipboard.

What would be really cool is if you could go the other way: I click on some feature, and it produces a list of selector chains which will match that feature. My gut tells me this it is computationally intractable to find an optimal selector chain. But maybe if it could be useful as a short-hand for the "in the direction-of" or "nearest-to-point" selectors.

[emdash]

For code updates, you would need not just line numbers, but the AST for the script. Instead of features mapping to line numbers, the feature tree would map to the AST node which produced the feature (this is much easier to handle with a declarative language. There will be cases in python where a useful syntax node can't be identified).

What interactive model changes would do is update the feature tree, which would in turn update the AST, and then the code would be "rendered" into the editor from the AST. I have implemented this kind of thing before, though not for a general-purpose programming language. Preserving the arbitrary formatting of the input would be a challenge in python (I don't think the python parser module preserves white space, unlike a conforming XML parser).

As for deciding what to change, when there's multiple possibilities, you can allow the user to choose among the available ones. Consider:

show(Workplane("XY").rect(width, width * 2).extrude(5).edges("|Z").fillet(6).translate((0, 0, 1))

So, If I understand correctly, the feature tree / graph looks like this (or the reversed version):

• translate
  • fillet
  • extrude
    • rect
    • workplane

Now imagine, you select a wire that was created by the fillet operation. Since a fillet node is in the selection, the following options should appear:

• fillet radius (provided by the fillet node)
• extrusion depth (provided by the extrude node)
• (read only) rect width
• (read only) rect height

I.e. what we can manipulate from the viewer are any arguments to the feature tree that map to literals in the source code.

[dcowden]

that feature tree is definitely what i had in mind, except for two things:

(1) i think we may not want to create a new feature for things like rotate/translate that we know do not produce any different 3d features. (ie, no new feature for translate ), (2) not sure we want to have features for 2d constructs ( rect)-- but not sure about that yet.

My plan was to mirror the way Solidworks does it, which seems to work pretty well. In SW, you have an object in the feature tree for a workplane ( because you need to specify a workplane in order to extrude), and you have objects for newly created 3d solids. but you dont have objects for each line/arc/curve/rect on the plane, and you dont have a new feature when you move things around.

I'd be happy to achieve selecting features by clicking as a start. IE, you click on one vertex/edge/wire/face and select all of the other wire/edge/faces that were produced in the same feature.

On Thu, Jan 8, 2015 at 1:35 AM, emdash notifications@github.com wrote:

For code updates, you would need not just line numbers, but the AST for the script. Instead of features mapping to line numbers, the feature tree would map to the AST node which produced the feature (this is much easier to handle with a declarative language. There will be cases in python where a useful syntax node can't be identified).

What interactive model changes would do is update the feature tree, which would in turn update the AST, and then the code would be "rendered" into the editor from the AST. I have implemented this kind of thing before, though not for a general-purpose programming language. Preserving the arbitrary formatting of the input would be a challenge in python (I don't think the python parser module preserves white space, unlike a conforming XML parser).

As for deciding what to change, when there's multiple possibilities, you can allow the user to choose among the available ones. Consider:

show(Workplane("XY").rect(width, width * 2).extrude(5).edges("|Z").fillet(6).translate((0, 0, 1))

So, If I understand correctly, the feature tree / graph looks like this (or the reversed version):

• translate
  • fillet
  • extrude
    • rect
    • workplane

Now imagine, you select a wire that was created by the fillet operation. Since a fillet node is in the selection, the following options should appear:

• the move command (provided by the translate node)
• fillet radius (provided by the fillet node)
• extrusion depth (provided by the extrude node)
• (read only) rect width
• (read only) rect height

I.e. what we can manipulate from the viewer are any arguments to the feature tree that map to literals in the source code.

— Reply to this email directly or view it on GitHub https://github.com/dcowden/cadquery/issues/40#issuecomment-69141737.

[emdash]

Conceptually, I think a rotate or a translate produces a new solid, no? In which case it should appear in the feature tree.

I kindof don't like the notion that basic transformations mutate the node in the feature tree rather than produce a new object.

If I say the following: plate = Workplane("XY").box(l, w, h) hole = Workplane("XY").polygon(6, size).extrude(depth) plate = plate.cut(hole.translate(leftHoleLocation)) plate = plate.cut(hole.translate(rightHoleLocation))

What I want is clearly a plate with two holes in it. Currently, you only get one hole (the right one). To work around this, I have to make a "hole function" so I can create a multiple instances of the hole to cut from. I shouldn't have to do that, though. It's especially problematic with loops.

As for whether 2D operations should produce features, I feel like they should exist in some form. At the very least, it would be useful to see unconsumed points and wires hilighted in the output. This could indicate a bug. But it could also be a useful visualization tool.

[jmwright]

Here's a link to the ast module in Python, which I'm thinking would help with source highlighting. Line numbers could be a fall-back when a useful syntax node couldn't be found for a feature.

[emdash]

Yeah, I had originally envisioned using the ast and compile modules. Basically, if your input language looks enough like python syntactically, you don't have to write your own parser. It becomes trivial to do validation and to identify line numbers and offsets for a given bit of syntax. To update the code, you update the source node and then pretty-print the AST back into the editor. This would be easier if we enforce a particular style, so that you don't have to worry about preserving arbitrary whitespace.

The trouble is that the AST can't necessarily tell you where a feature comes from unless we do some pretty crazy graph analysis -- or we define custom semantics.

I've written some code that makes heavy use of the Ast module and have a good idea how to work with it. If you want to restrict that certain things not be done (like forbidding the creation of parameters within functions and loops), an Ast pass makes it pretty easy to do.

Crazier things are possible. Once you have the AST, you are free to change the semantics as you see fit. You don't have to execute the code as-is.