Yes, this technique does work- I've used it for commercial design work
with some proprietary modelers (Ashlar Cobalt and PunchCad Shark FX)
that used a crude scripting language-called of all things 'Macro
Parser'. I was able to make simple changes to the scripting that would
be major changes to the model. This allowed for very flexible revisions.
It also made it easy to recover from a crash if the application was
acting finicky.
I was able to do fork crowns for bicycles (classic Italian style-not the
modern stuff) by using techniques that emulated a cnc mill tool path
through the solid block. The whole time I was working the model as a
machinist would at a mill or lathe- subtracting shapes from the solid
that I started with. Python code was necessary to keep me from losing my
mind during these projects :) I created some functions that made dealing
with the crude 'Macro Parser' scripting a lot easier.
PythonOCC looks a whole lot more attractive to me than my old work with
this crude scripting. But, I would like to be able to abstract it a
little more though to make it easier to remember how to use it, without
having to go to the OCC docs all the time. I would bet that Thomas and
Jelle are working on something like this.
I think this project might be similar to what we are talking about:
http://www.caddd.org/
Dan
On 12/10/10 2:27 PM, Dave Cowden wrote:
I assume that someone has seen this:
http://openscad.org/
it is a tool that allows programmatically building solids using python
and a CSG kernel.
If such a tool used pythonOCC instead, it would be _much_ more powerful.
This kind of tool is really interesting to me. Anyone who has done
much solid modelling for a living quickly realizes that a complex
solid model is much like a programming problem. You cannot just
'start building' a complex model: you have to plan how the object is
built, which references are used, etc, so that the object is
extensible and easily changed to accommodate design iterations. It
becomes really important to plan reference planes and other reference
geometries to reference each other in a way consistent with the rest
of the model.
Using a programming language to capture the [currently always
proprietary] way that solid modelling packages capture the build order
and dependency chains of a solid ( especially parametric solids ) is
brilliant. As programmers, we are very familiar with the ability to
use CVS merge and other utilities to track fine-grained changes to
software over time, even when under concurrent development. Imagine
the power of this capability applied to scripts that produce solid
objects! No more huge binary solid object files that are opaque from
a change management viewpoint!
Does anyone know if such a package is underway anywhere based on
pythonOCC?
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users