Hi, Jelle: thank you for the input.
>Why the hatch? What is the distance between your scanlines? Distance is ideally user-variable. When you build an object, sometimes you want very dense spacing because you want a very strong object, and sometime you dont care so you space it very widely. Another odd quirk is that its actually better to have the hatching lines not be parallel. Printed objects are stronger with solid walls. So, suppose you have inner fill lines that are space 3mm apart. what you want, is for the lines to always end up very close together near the walls, but be further apart in the center. >Yes, given a high level precision of the machine ( where machine_precision < tesselation_error ) it sure could be interesting… Also, it would be less imposing on your hardware controllers, right? Definitely. as an example, I created a circle with diameter 2 inches, and exported it to STL with tolerance of 0.001. The resulting file was 450 lines of G01 moves. My machine's precision is probably on this same order: accuracy 0.0005 but precision 0.001 due to backlash. of course the g02 move for the same motion was 1 line of code. >You did see that we paralleled your slicer, right? No i didnt notice that, but i do now. I see you used BRepAlgo_Section, which i suspect works must faster than my method. I ended up giving up trying to use BRepAlgo_Section because I couldnt find a good way to assemble the resulting compound back into something i could work with. For example, testing a point to see if it is 'inside' or outside a face, etc is easier when i have a first-class face instead of a compound. Thank you for your help and samples below. I will definitely make you guys a part when i get it done! On Thu, Feb 11, 2010 at 12:54 PM, Jelle Feringa <jelleferi...@gmail.com>wrote: > > Hi, Thomas, thanks! > > Thanks for the compliment ;') > > > 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. > > Actually that is a _wonderful_ design decision! > G-code is way preferable over obscure proprietary instructions… good to > hear… > > > 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. > > Why the hatch? What is the distance between your scanlines? > > > 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. > > Wow, that offers interesting possibilities… > So you'd need to know about the area of the slice for instance? > > > I thought about looping over the surface parameters, but then again > realized it would not create points along a uniform grid. > > Hard to say. You'd have to check for each sample whether this is trimmed > area or not. > > > Is there a function that will test whether a point is on the surface? > > Yes. > > class Blaaaat(object) > self.cl = self._setup_trimmed() > > def _setup_trimmed(self): > #tol = 1e-4 > tol = 1e-9 > u1,u2, v1,v2 = BRepTools().UVBounds(self.face) > dailen = (u2-u1)*(u2-u1) + (v2-v1)*(v2-v1) > #dailen = math.sqrt(dailen) / 400. > #dailen = math.sqrt(dailen) / 4000. > #tol = max([dailen, tol]) > return BRepTopAdaptor_FClass2d(self.face, tol) > > def is_uv_in_face_domain(self, u, v): > '''checks if curve is trimmed > ''' > uv = gp_Pnt2d(u,v) > if self.cl.Perform(uv) == TopAbs_IN: > return True > else: > return False > > > Maybe it would be easiest to make my own discrete x-y- grid, and then > simply test each point for membership on the surface. > > Like a gp_Lin per-face intersection test… hmm… > > > 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. > > Dave! True! You are bound to set off a revolution in resolution! > Yes, given a high level precision of the machine ( where machine_precision > < tesselation_error ) it sure could be interesting… > Also, it would be less imposing on your hardware controllers, right? > > > 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. > > Cool! > > > This would be the first tool that can prevent a triangulated > approximation during the fabrication process. > > Awesome! Promise me you will manufacture me something when you get it done > ( and Thomas too, that goes without saying ). > > > Thanks for the help! > > > Sure thing. > > Perhaps this saves you another 10 minutes staring doxygens documentation… > Don't forget to look into the Level2API and anything in /Utils ( > Construct.py could be nice for you ) > > You did see that we paralleled your slicer, right? > samples/Level2/Concurrency/parallel_slicer.py > > -jelle > > def face_normal(face): > umin, umax, vmin, vmax = BRepTools().UVBounds(face) > surf=BRep_Tool().Surface(face) > props= GeomLProp_SLProps(surf, (umin+umax)/2., (vmin+vmax)/2., 1, > TOLERANCE) > norm = props.Normal() > if face.Orientation()==TopAbs_REVERSED: > norm.Reverse() > return norm > > > def offset_wire(wire, offset_distance): > offA = BRepOffsetAPI_MakeOffset(wire) > try: > offA.Perform( offset_distance, 0.0) > offA.Build() > # offA.Delete() > except: > print 'failed to offset wire' > return None > te = ShapeToTopology() > offA_shape = te(offA.Shape()) > return offA_shape > > > > _______________________________________________ > 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
