Hey Jelle, if you need assistance with the skdb source, you're more
than welcome to show up in #hplusroadmap on irc.freenode.net, we have
a few pythonOCC users who have been bitbanging against the OCC API for
the past six months now, so if you ever want to talk about things,
you'll know where to find us.
Many thanks for the invitation!
Well, in a way you are doing something similar: condensing/abstracting
your experience in a module.
For instance we both implement a make_wire function.
Have a look at the OCC.Utils.Construct module, and you'll see a pretty
nice module that abstract classes for creating geometry into simple
functions.
Again; moving away from OCC's C++ idioms, to something pythonic.
Perhaps its interesting to present the pythonOCC version of make_wire.
It accepts a list of edges, and uses the `with` context, to make sure
a wire is succesfully created before returning it.
If not, a AssertionError with the message "failed to produce wire" is
raised.
It reduces:
wire = BRepBuilderAPI_MakeWire()
for i in edges:
wire.Add(i)
wire.Build()
assert wire.IsDone(), 'failed to build wire'
to
wire = make_wire(edges)
# snippet from OCC.Utils.Construct
def make_wire(*args):
# if we get an iterable, than add all edges to wire builder
if isinstance(args[0], list) or isinstance(args[0], tuple):
wire = BRepBuilderAPI_MakeWire()
for i in args[0]:
wire.Add(i)
wire.Build()
return wire.Wire()
wire = BRepBuilderAPI_MakeWire(*args)
wire.Build()
with assert_isdone(wire, 'failed to produce wire'):
result = wire.Wire()
# wire.Delete()
return result
# snippet from OCC.Utils.Context
class assert_isdone(object):
'''
raises an assertion error when IsDone() returns false, with the
error specified in error_statement
'''
def __init__(self, to_check, error_statement):
self.to_check = to_check
self.error_statement = error_statement
def __enter__(self, ):
if self.to_check.IsDone():
pass
else:
raise AssertionError, self.error_statement
def __exit__(self, type, value, traceback):
pass
Not exactly rocket science, but these simple things do make
programming pythonOCC a lot more fun for sure ;')
Now that a solid fundament has been build, our hope is that more
python code will be built on top of it.
A great example is Sebastien Ramage's module that couples pythonOCC &
Yafray:
http://code.google.com/p/occray/
( great work Sebastien! )
I figure the most constructive thing to do is to condense many useful,
general methods into pythonic objects.
My request is really concrete; Thomas & I really could use some help
in building the pythonic high-level API.
I'm confident that all pythonOCC users will benefit hugely from this
work.
At this point in the development of pythonOCC, I think it really would
be wonderful to engage the pythonOCC community more and more in the
development of pythonOCC.
The hardcore wrapping process is pretty much perfected, from here on
it comes down to writing beautiful python code!
The Level2API module has a pretty decent design, but it is a lot of
work to get it done ( with doctests & all ).
You'll see 63 methods that aren't yet implemented, we really would
appreciate some help in getting this work implemented.
We need some help to fill in the blanks here!
In order not to have a Curve with a zillion methods, it makes sense to
use helper classes such as DiffGeomCurve:
crv = Curve(aTopoDS_Edge)
# the diff_geom attribute is an instance of the DiffGeomCurve class,
which contains all methods for related to differential geometry:
crv.diff_geom.normal(u)
crv.diff_geom.curvaturel(u)
PS: some how posts to Open Manufacturing aren't getting there... could
you please CC'? Thanks for fwd'ing!
Cheers,
-jelle
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
