Thomas, I like that idea a lot.
I use solid works (SW) as my primary solid modelling package, so I think it
is useful to compare these ideas with SW, since it is quite powerful and
easy to use.
Here are some thoughts regarding this :
*
SW is highly parametric-- I think that using PAF is a key and
important feature
*
SW uses a completely proprietary format. all operations are 'point
and click' and then are saved in a proprietary format that is binary and
cannot be merged/stored in CVS. Were a solid model a 'script'-- a series of
instructions that builds the models, it would be much more powerful. The
user story I have in mind here is " i use a tool that lets me build a model.
i drill a hole with parameter P1 as the diameter, and save the file into
CVS. later on, i change paramter P1 to a new value, and when i do a cvs
diff, i see only this line of text changed.
*
SW has many, many custom modules that provide highly specific
functions for differing needs. A good example is the sheet metal package,
which allows computing bends from flat sheets. Another example is a
fasteners module that automatically produces ANSI fasteners. These are
pefect illustrations of your point, Thomas: this kind of specificity would
be very expensive to build for all disciplines.
*
SW provides shows a 'model tree' that shows each operation and its
children operations. As you modify properties of any particular operation,
the changes automatically cascade through the model. This makes SW very
powerful, but interestingly makes it a lot more like programming because you
have to essentially design the model with this tree in mind.
There is another intruiging point when you consider building a solid from a
3GL program like a python script. The two big CAD packages, SW and
Pro/Engineeer ( PTC ), differentiate themselves primarily by whether models
are hierarchal and all parameter changes cascade thrhough the model ( like
SW ), or whether the model is static, and changes do not cascade in this way
( PTC has a fancy name for this-- but basicaly they argue that the cascades
in SW are more difficult than they are worth.
If you build the model from a script, this debate is essentially moot,
because using either approach you can programmatically build the model
again. And, having a 3GL language driving the creation of the model is much
more flexible and expressive than the proprietary way SW does it.
_____
From: pythonocc-users-boun...@gna.org
[mailto:pythonocc-users-boun...@gna.org] On Behalf Of Thomas Paviot
Sent: Saturday, December 11, 2010 3:48 PM
To: pythonOCC users mailing list.
Subject: Re: [Pythonocc-users] Anyone seen this?
Dear Dan, Dave,
I didn't know about the openscad project, thanks for introducing me this
project. Dave, you write "it is a tool that allows programmatically building
solids using python and a CSG kernel", but I don't see any python scripting,
I have rather the feeling that the scripting language of openscad is a kind
of specific language, am I wrong?
I agree with both of you regarding the high-level API that could be built
upon pythonOCC. Abstracting the low-level OCC api/data model would be
something really helpful. From a development viewpoint, there is not big
issue : we all developed or our own classes/methods or function in pythonOCC
in ordre to speed up development and make our programs modular. The big deal
is rather : what classes/methods should be made available to the user? How
could this set of functions be complete, i.e. how to ensure that *all* the
needs from any user are covered by this API ?
In my opinion, there's no way to get it done (I've been thinking about this
for a long time). We'll always find a user that is not satisfied with the
API and who requests for another method/class etc. The risk is then that
this high level API become as big and complex as the original one (OCC).
We could then imagine a different workflow than the usual one. I think about
something that was used for the standardization of the AP239 of the STEP
standard (also known as PCLS) : a very generic data model were designed (and
standardized), and the specialization of the data model was also
standardized. As a consequence, users with very specific business just join
their efforts to define a standardized specialization of the generic data
model suitable for their needs (aviation maintenance, operational feedback
etc.).
This development model could be moved to the pythonOCC high level API
development :
* a generic data model would be defined, with basic and fundamental
elements ;
* a framework for specializing this model is also defined. Both of
this two points could be viewed at an ontological level ;
* we then set up a 'high level API' repository with a set of basic
classes/methods already defined ;
* from these 2 points, we just let the user contribute new
classes/functions/methods if what he is looking for is not already available
from the repository.
It could be a way for us (developpers of pythonocc) to share the development
efforts of this needed high level API. And to have, as a consequence, a huge
web-based repository of python classes/methods/functions, classified by
businesses (FEM, manufacturing etc.), level of granularity, functions
(gears, bearings etc.) etc.
pythonOCC would then become a kind of distributed library : a core component
(the python wrapper), required, and thousands of optional components
available online, supported by a powerfull request engine. Setting up such
an architecture is more a scientific project than a simple python
development activity.
What do you think about that idea?
Thomas
2010/12/11 Dave Cowden <dave.cow...@gmail.com>
Yes, definitely a higher level of abstraction is needed than just pure
python.
I am thinking ( not surprisingly ) of an environment a lot like a java
ide. You write code, but the ide provides syntax highlighting,
function completion, refactor support, code templates, a way to
include other libraries, etc.
On 12/10/10, Dan Falck <dfa...@frontier.com> wrote:
> 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
>
--
Sent from my mobile device
_______________________________________________
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
