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 >> listpythonocc-us...@gna.orghttps://mail.gna.org/listinfo/pythonocc-users >> >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org >> https://mail.gna.org/listinfo/pythonocc-users >> >> > > _______________________________________________ > Pythonocc-users mailing > listpythonocc-us...@gna.orghttps://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
