OCP

[adam-urbanczyk]

No description provided.

[jmwright]

@adam-urbanczyk I apologize. I meant to commit my changes to the OCP branch on my fork, but pushed them upstream instead. I was using GitKraken instead of the command line and my lack of experience with GitKraken tripped me up. I want to roll back my changes, but don't back commits out very often and don't want to make things worse by doing it wrong. Please feel free to rollback my commit, or let me know the best way to do it myself.

Here are the changes where they're supposed to be.

jmwright@3c9a6b3#diff-242f28f413504cbf8abdc809c8ca32b5R23

I may be looking in the wrong place, but I don't see Interface_Static anywhere within OCP. I have started experimenting with the changes suggested by @bragostin here.

[adam-urbanczyk]

No worries @jmwright , fixed. BTW: I think you are looking for the OCP.Interface.Interface_Static class.

[dcowden]

@adam-urbanczyk I started looking at the OCP branch, and it's clear I need remedial training. What's the difference between all of the OCP methods that have _s postfix ( OX_s, etc ? ) I dont have a problem with them, but it would help my understanding

[adam-urbanczyk]

These are static methods.

[dcowden]

@adam-urbanczyk one high-level recommendation: i'd change README.md in this branch to reflect use of OCP and pywrap, vs the existing verbiage, which still describes using pythonOCC:

[dcowden]

These are static methods.

@adam-urbanczyk thank you!

[dcowden]

@jmwright will cqeditor will function on the OCP branch? I think that's essential, CQ was going nowhere till we had it!

[adam-urbanczyk]

The OCP branch of CQ-editor works with the OCP branch of CQ.

[jmwright]

@dcowden The FreeCAD module doesn't support CQ 2.0 or OCP, if that's what you're wondering about. I think CQ-editor will be our main GUI moving forward, and @adam-urbanczyk is the lead on that project.

[dcowden]

@adam-urbanczyk @jmwright I looked through the new code this morning, I really can't see anything wrong with it at all. If the tests, pass, its must be good! ( Actually i'm serious, we have good test coverage).

While i was reading the code again, a very random improvement flew into my brain, which i logged as a ( #361 ). I've been doing a lot of 'manual' CAD lately, and for some reason that thought struck me as i was reading through 'workplane'.

My only other comment i guess comes from spending a LOT of time in enterprise programming, and not having been in CQ for a while. Some of these files are BIG! I left thinking it would be good to split it up some.

[dcowden]

@dcowden The FreeCAD module doesn't support CQ 2.0 or OCP, if that's what you're wondering about. I think CQ-editor will be our main GUI moving forward, and @adam-urbanczyk is the lead on that project.

Excellent, thanks. I knew we weren't supporting FreeCAD, but i mainly wanted to determine if CQ Editor is working-- i think that's a pre-requisite for merging OCP into master.

[jmwright]

@dcowden Thanks for taking a look.

[adam-urbanczyk]

Thanks for the feedback @dcowden . I update the README. Are we now all comfortable with merging this? I still need to make the 0.1 release of CQ-editor, but after that I'd like to go ahead with this PR. Note that after a long struggle OCP builds for python 3.7 and 3.8. I can also add 3.6 if needed, but maybe it is time to move on.

[jmwright]

+1

[adam-urbanczyk]

@dcowden does this PR have you buy-in too?

[dcowden]

+1

[dcowden]

@adam-urbanczyk +1 to merge this one! thanks for all the hard, hard work on getting OCP version ready! Control of the stack all the way from ui to the native code will pay large dividends over time.

[michaelgale]

Sorry to chime in, but massive kudos to @adam-urbanczyk for the OCP integration. I've been using it for nearly a month and have seen enormous gains in performance and stability. Furthermore, there are many more OCCT goodies to expose up the stack to CQ such as "defeaturing" and more complex shape geometries.

[jmwright]

I echo the thanks and kudos for @adam-urbanczyk

[dcowden]

@michaelgale thank you for the comments about performance and stability! I hadn't been aware of those gains, it's wonderful.

I feel like a complete imposter still posting--- its been so long since i've been useful, but eventually i'll get back to to. CQ's one of the loves of my software life :)

[michaelgale]

@dcowden Lol! You're hardly an imposter! You should be proud of what you've created and how it has (and continues) to evolve in very capable hands. Laying a great foundation is essential to making a great building.

[dcowden]

@michaelgale thanks for those kind words! You're right, the project's in great hands right now, i don't have any regrets at all, except for the amount of effort i can contribute.

Given time, CQ will be a game-changer. The reality of CAD today is abysmal-- so much time spent (re)building models and interchanging through lossy formats. So much time spent modeling things manually when we have computers perfectly capable of computing the correct geometry. And so many tools to collaborate when you have plain text to work with, vs a huge proprietary file!

Onwards and upwards!

[michaelgale]

@dcowden I definitely share your views about how CQ changes the paradigm of what CAD is. If you have some sort of CS background, CQ's approach to CAD is perfectly logical and hugely productive. However, the CAD industry has a long traditional legacy of being built around expensive desktop application platforms, each with their strengths/weaknesses/communities etc. Most design and manufacturing activity will continue to use these traditional desktop applications.
However, for organizations that recognize that CAD can be done differently, i.e. within the software development paradigm, they will likely recognize and exploit the competitive advantage it offers. Market forces/natural selection will eventually self-select organizations that embrace this way of doing CAD. When you can innovate faster and produce designs with machine-learning/computational-optimizations that are impossible with traditional methods--the results will speak for themselves.
Personally, CQ "just clicked" for me. I can't think of doing CAD any other way. As an electrical engineer, it made me think: "is it possible to make a CQ equivalent for EDA (schematic/PCB) design?" The thought of expressing an electrical circuit design using python code is an exciting possibility. To some extent Verilog/VHDL achieve a similar goal in programmable logic devices--but to extend this paradigm to entire circuits and systems is exciting!
But I digress. Thanks again to you and the rest of CQ crew for making a great tool.

[dcowden]

@michaelgale EE eh? have you happened to come across a very early and very cool CQ project-- @jmwright 's eggbeater antenna One of the earliest and very cool projects demonstrating that frequency to model is only 1 step !

[michaelgale]

@dcowden I indeed see @jmwright 's antenna--it is a perfect application example of how parametric CAD can supercharge engineering design and workflows. Antenna structures in particular are completely dependent on their geometry. (I have built a Log Periodic antenna in my past life--although that was with spreadsheets and old-school CAD!) Every now and then I scour GitHub looking for CadQuery projects for inspiration, code tips, etc. (I wonder if we should have users showcase or inspiration gallery as a repo in the CQ organization...)

[adam-urbanczyk]

Thanks all, let's merge it then.