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