In general its interesting to look at how the Django projects is organized. There is the core django project, than lots of other projects, additional components that allow you to build up apps quickly. That's a simple and practical way of organizing efforts.
-jelle On Feb 12, 2010, at 6:09 PM, Dave Cowden wrote: > That makes sense, Thomas. > > I'll continue down the path of using OCC stuff, or re-implementing in python > to suit the needs of my application. If it becomes too cumbersome, i'll know > its time to consider wrapping another library that does it. > > Were i writing a cam package for conventional machining, i'd agree we need to > wrap something else-- though further i think in reality i'd argue a CAM > package is large enough to be its own project, dependent on pyOCC anyway. > > If the codebase i'm using becomes large that may end up being the case too. > Its debatable whether gcode generating stuff even belongs in pythonOCC. > Right now its there because that way its compiled and packaged with pythonOCC > without a need for the overhead of a separate project, so its purely a matter > of convienience. > > I wonder-- how do we decide which things 'belong' in pythonOCC/samples or > Tools, and which ones should just be separate projects? And, are my efforts > in that category? > > On Fri, Feb 12, 2010 at 11:57 AM, Thomas Paviot <tpav...@gmail.com> wrote: > 2010/2/12 Dave Cowden <dave.cow...@gmail.com> > > I understand and agree about porting to pure python. I think we'd probably > want to avoid another library dependency, though. Thomas/Jelle what do you > guys think? My assumption is that we want to avoid external dependencies, > especially when OCC already has something similar. > > I don't want pythonOCC to depend upon too many dependencies. Adding > dependencies means increasing complexity. However, it's sometimes required to > extend the functional scope quickly (by just using something already > working). So here is my opinion: > - there's no limit about dependencies that are python modules or packages. > For instance Traits, wxPython, PyQt, simpy etc. are dependencies but they're > pretty well packaged and easy to install, and it's pythonic to use other > python packages. > - some C++ libraries may be linked to pythonOCC. I used the following 'rule' > : if the C++ library has to be completely integrated to pythonOCC, so let's > develop a wrapper. For instance, the GEOM and SMEH libraries are developed > with C++ and all the classes/methods are required. It would have been too > long to port the code to python, so I wrapped the libraries. > - if the library aims at being partially used from pythonOCC, i.e. a small or > very small part of code is really useful, so it's better to port the C/C++ > code to python. It's feasible if the number of lines of code to port is not > too important. > > Thomas > > > I guess my hope/thought was that the algorithm itself could be ported, but > that most of the heavy lifting it does is already available in OCC functions. > For example offsetting curves, finding intersections, etc etc are already > available, we might just have to make the algo more intelligent. > > I'm also needing a bit more flexibilty because the toolpaths i need to create > are not for a tool, they are for a rapid prototyping (additive ) machine. So > for example, I dont actually want to do the entire pocket, i need to offset a > few cuves and then create a sparse cross-hatching kind of thing.... > > My experience is in line with yours about pure python. There is already a > tool called skeinforge that is pure python and converts STL files to gcode. > It runs on the order of 1/2 hour on my laptop, and using pyOCC I can perform > the same operation in under 1 minute. > > But i love python for the glue code. That's probably why i'm here. OCC is a > great library that's fast and expansive, but the python binding is perfect > for custom tools and addins. > > On Fri, Feb 12, 2010 at 11:31 AM, Dan Falck <dfa...@verizon.net> wrote: > Hi Dave, > > I don't know what it would take to integrate it with pythonOCC, but it > already has python bindings that are pretty straightforward. Somehow, I don't > think you would want to convert the whole thing to python, since it would > slow things down. I have used it from HeeksCNC (it's intended application) > and as a stand alone module on my Mac. I have done some CNC programming in > which I just used the modules that Heeks came up with from the terminal and > created some useful machining code. I think Dan Heeks did a good thing in > making all the separate machining modules into individual projects. He has > kurve -which is for simple profiling, libactp- adaptive roughing, libarea- > pocketing, and then he adapted Pycam for surfacing. Pycam, being written in > pure python is pretty slow at generating gcode. > > I think there is a test script included with the project that should be > pretty helpful in showing what input format it needs. You could probably > just do something like 'import libarea' and use it from your application. > > Dan > > > > On 2/12/10 8:04 AM, Dave Cowden wrote: >> >> Hi Dan, >> >> Yes that logo looks like a fairly good test case. It has some very sharp >> small portions. >> >> What do you think the possibility would be to "pyOCC-size" that algorithm so >> that we can use it convieniently in conjunction with the OCC objects? >> >> IE, how difficult would it be to make a python version of the library that >> would operation on a wire object? That'd save me some work. >> >> Last night i spent some time on a routine to convert an edge, wire, and >> gp_Pnt into code-- these were fairly easy, because I copped out and handled >> only edges that have lines as the curve. But with another few hours i >> should be able to handle curves of type circle and ellipse and convert them >> to G2/G3 ( which, by the way, is something very very few cam packages out >> there do today). >> >> After that, my next step would be the last one i need for my slicer-- to add >> 'convert a face to gcode'. Doing this part would need the offset algorithm >> available... >> >> >> >> On Fri, Feb 12, 2010 at 10:10 AM, Dan Falck <dfa...@verizon.net> wrote: >> Hi Dave, >> >> I will try and attach a screenshot. I think that this lib does pretty well. >> I used it for pocketing this logo and was pretty pleased with the results. I >> haven't used it extensively, but so far so good. >> >> Thanks, >> Dan >> >> >> >> On 2/12/10 4:14 AM, Dave Cowden wrote: >>> >>> Hey, Dan: >>> >>> How well does this routine handle geometries for which offset curves self >>> or boundary intersect? pyOCC actually has a very easy to use tool to do >>> the offsets, but it runs into trouble when the curves self-intersect-- >>> essentially it just punts and throws an error. >>> >>> So, with pyOCC i think i'd have to manually offset each curve and then find >>> the intersections, so that I can deal with what happens when the geometry >>> is odd.... >>> >>> On Thu, Feb 11, 2010 at 10:48 PM, Dan Falck <dfa...@verizon.net> wrote: >>> Hi guys. Would a 'pocketing' routine like this help?: >>> >>> http://code.google.com/p/libarea/ >>> >>> I use routines like this to mill away material, but you could also use it >>> for filling. >>> >>> Dan >>> >>> >>> On 2/11/10 8:34 AM, Dave Cowden wrote: >>>> >>>> Hi, Thomas, thanks! >>>> >>>> The target machine is a rapid prototyping (RP) machine-- RepRap. Thus, >>>> the infill for a slice is not necessarily a 'machine all material away' >>>> path. Ultimately it still uses Gcode, but it is additive rather than >>>> subtractive. I use EMC for machine control. >>>> >>>> The ideal is actually to offset all of the wires on the face inwards to >>>> create a user-configured number of 'shells' around the exterior >>>> boundaries, but then inside fill with a hatch pattern. For the offset I >>>> can use BRepOffsetAPI of course. >>>> >>>> The unusual variation that an RP machine has is that the interior hatching >>>> is ideally not uniform or 100% coverage. Sometimes a honeycomb is >>>> desired, and other times, a 'sparse' hatch is desired to save material. >>>> >>>> I thought about looping over the surface parameters, but then again >>>> realized it would not create points along a uniform grid. >>>> >>>> Is there a function that will test whether a point is on the surface? >>>> Maybe it would be easiest to make my own discrete x-y- grid, and then >>>> simply test each point for membership on the surface. >>>> >>>> I'm quite excited about this project. The main reason is that nearly the >>>> entire RP community ( including commercial ) still relies on STL files for >>>> production. This is a pain because it results in all toolpaths being >>>> little line segments. So for curves there end up being a billion little >>>> G01 moves. >>>> >>>> Using OCC represents the only way i know of to use STEP representations of >>>> solids, which when sliced still preserve the ability to generate Gcode >>>> arcs ( G02/G03 ), which result in much smaller Gcode and much smoother >>>> motion than having all arcs represented by tiny line segments. This would >>>> be the first tool that can prevent a triangulated approximation during the >>>> fabrication process. >>>> >>>> Thanks for the help! >>>> >>>> On Thu, Feb 11, 2010 at 11:16 AM, Jelle Feringa <jelleferi...@gmail.com> >>>> wrote: >>>> > I'm getting back to using pyOCC after a while. >>>> >>>> Welcome back Dave, we've missed you! >>>> >>>> > I am hoping someone can point me the right direction. After reading >>>> > documentation and samples for a few hours, I'm still not sure where to >>>> > start. >>>> > >>>> > Previously, I have written a slicing application ( samples--> slicer ), >>>> > and I would like to continue that work. >>>> > >>>> > The next step is to create toolpaths that fill in the faces created from >>>> > the slicing operation. >>>> >>>> Wow, so a g-code export? >>>> Have you seen pycam? >>>> >>>> > There are a number of general approaches that could be used: One is to >>>> > use BRepOffset to offset the wires inwards. >>>> > >>>> > However, the approach I would rather take is to use a 'grid' approach, >>>> > in which I first compute a grid of points on the face, and the fill them >>>> > all in afterwards. I feel like this approach will be more tolerant to >>>> > degenerate geometry. >>>> >>>> Yes, dekskproto of delft spline systems has that algorithm for instance. >>>> >>>> > So, to my question: I think looking at the SMESH sample, I could use >>>> > smesh to generate a set of points on my surface that are spaced evenly. >>>> >>>> Or just loop through the U,V domain of a face? >>>> And than offset via the normal of the face? >>>> >>>> > Looking at the sample I can see how to create the mesh, but I cannot >>>> > see how to extract the points from the mesh. >>>> >>>> You could do something similar ( if you decide polysoup is the way to go ) >>>> to just look up the triangles that represent a surface ( we always look at >>>> triangles in OpenGL, you don't get to see the actual nurbs but just an >>>> approximation ) >>>> >>>> > I am also unsure how to instruct the mesher to generate a grid that has >>>> > a fixed space between the points in a particular plane. >>>> >>>> No way a mesher will generate equidistant points uh uh... >>>> >>>> > In my case the face will always be a planar face in the x-y plane: what >>>> > I want is an array of points at a fixed spacing that cover the surface. >>>> >>>> Right, abscissa points… >>>> So, what about dividing up the contours of your slicer by n-points or a >>>> distance? >>>> >>>> For what machine are you writing the slicer exactly? >>>> Do you need an offset ( like we need when milling ) to the surface? >>>> >>>> Happy to see you back on this list ;') >>>> >>>> -jelle >>>> _______________________________________________ >>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 >>> >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 > > > > _______________________________________________ > 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
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
