Hi Bryan, *Very* intersting thread, thank you for opening it.
The topic you're talking about is still an open issue in CAD and contributions from the open source community would certainly be a great thing. However, it's not only a technical problem (in terms of implementation), but rather a scientific one. As far as I know, a good starting point is the second edition of the AP203 STEP application protocol, especially the ISO10303-55 (‘Procedural and hybrid representation’). Being able to implement this part of the standard in a scripting langage would already be a huge step. I recommend the reading of a famous paper of M.J.Pratt et al. (Pratt being one of the world guru of the STEP standard): "Towards the standardized exchange of parameterized feature-based CAD models" (2005), Computer-Aided Design 37 (2005) 1251–1265. Here is the abstract of the paper: "The paper describes the status of work aimed at extending the international standard ISO 10303 (STEP) to permit the exchange of parameterized feature-based models between different CAD systems, in terms of the constructional history of the models concerned. Such procedural models have the advantage of being easy to edit following an exchange, by contrast with the models that can be exchanged using current STEP methodology, which prove to be difficult or impossible to edit in the receiving system. The use of the approach described has already been demonstrated in the exchange of realistic procedural shape models of mechanical parts, and the paper includes a brief account of some of the tests performed and the projected benefits of the use of this extension of STEP technology." Here is a sample extracted from this paper: #1030 PROCEDURAL_SOLID_REPRESENTATION_ SEQUENCE(’BASIC-SOLID’, (#1040,#1050,#1060),$,’RATIONALE: TEXT...’); #1040 BLOCK(‘BASE-FLANGE’,#1070, 275.0,130.0,38.0); #1050 EXTRUDED_FACE_SOLID (‘PROTRUSION’, #1080,#1090,100.0); #1060Z BOOLEAN_RESULT(‘COMBINATION’, . UNION.,#1040,#1050); I think this approach would certainly be the easiest way to get started: the STEP data model has been widely discussed and validated. Best Regards, Thomas 2010/2/21 Bryan Bishop <kanz...@gmail.com> > Hey Thomas, > > A while ago, you and Jelle were talking about creating an API for > pythonOCC that would simplify and hide the ugly guts of OCC. I haven't > seen too much on this front in a while, but a few days ago I was > talking with Christian Siefkes, Ben Lipkowitz, and a few others about > a potential look and feel for python that would hide away OCC, or even > BRLCAD or anything else that we opt to throw under the hood. > > I was wondering if I could get some thoughts on how this feels: > > http://designfiles.org/~bryan/csg.py > > sphere = Sphere(position=(0, 0, 0), radius="5 mm") > base = Circle(diameter="20 mm", position=(0,0,0)) > cylinder = base.extrude(length="10 mm", direction=Vector(0, 0, 1)) > sphere.position = (0, 0, 10) > lamp_post = cylinder.fuse(sphere) > > #if you're in an X11 opengl session thingy: > display.add(lamp_post) > > #or if you want to export it: > iges_data = lamp_post.to_iges() > file_handler = open("lamp_post.iges", "w") > file_handler.write(iges_data) > file_handler.close() > > And maybe some parametric PAF stuff? > > base = Circle("base of base plate", diameter="20 mm") > base_plate = Extrusion(base, "10mm", Vector(0,0,1)) > #OR: base_plate = base.extrude("10 mm", Vector(0, 0, 1)) > #OR: base_plate = extrude(base, "10 mm", Vector(0, 0, 1)) > base_plate.name = "cylinder 1" > > assert base_plate == Cylinder("cylinder 1", diameter="20 mm", > height="10 mm"), "Cylinder and base plate should be exactly the same" > > base_plate.diameter = "25 mm" > assert base.diameter == "25 mm", "base diameter should have been updated" > > base.diameter = "32 mm" > assert base_plate.diameter == "32 mm", "base plate diameter should > have been updated" > > I am not entirely sure how to do this sort of feature tree. Any hints > or advice from interested bystanders would be hawt. Also, I am sending > this over to OpenSCAD because they have a similar thing going on, with > their own parser, but nevertheless would probably be interested in > python hooks and somehow influencing how those hooks feel & work. > > Thanks, > > - Bryan > http://heybryan.org/ > 1 512 203 0507 > > _______________________________________________ > 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