- 24 Mar, 2012 1 commit
-
-
Whitham D. Reeve II authored
-
- 17 Mar, 2012 2 commits
-
-
Whitham D. Reeve II authored
-
Whitham D. Reeve II authored
-
- 16 Mar, 2012 1 commit
-
-
Whitham D. Reeve II authored
Original developer left out a condition in a trailing else to generate an additional line to close a polyline when specified.
-
- 15 Mar, 2012 1 commit
-
-
Whitham D. Reeve II authored
-
- 10 Mar, 2012 3 commits
-
-
Whitham D. Reeve II authored
-
Whitham D. Reeve II authored
-
Whitham D. Reeve II authored
Made changes to remove consecutive duplicate points, combined two loops that iterated through points into one.
-
- 09 Mar, 2012 1 commit
-
-
Whitham D. Reeve II authored
This code commits draw_direction_cone_mesh which is an adaptation of draw_direction_cone to generate a mesh of triangles for compression inside a vertex buffer object. The rest of the opengl code in Toolpath has been changed to use this. Only remaining use of old rendering path way is simulation. Whitham D. Reeve II
-
- 07 Mar, 2012 3 commits
-
-
Whitham D. Reeve II authored
-
Whitham D. Reeve II authored
Profiler suggests that the min/max functions for x/y/z of the Toolpath object were the main bottleneck. They iterate through all the points in each path every time they are accessed. These values are now cached which provides a huge speed boost. Originally I thought the problem was the opengl drawing code so I created a new code path that converts moves into an arrays of vertices and indices. The vertices array particularly is stored in video memory. While faster, I don't think it is all that much faster. Whitham D. Reeve II
-
Whitham D. Reeve II authored
-
- 05 Mar, 2012 1 commit
-
-
Whitham D. Reeve II authored
PyCam has been spending about 75% of it's time creating point objects. I decided to replace the pycam Point object with a 3 position tuple, and the pycam Vector object with a 4 position tuple. All of the point object methods were rewritten to accept and emit tuples. The transform_by_matrix method was rewritten to accept both 3 and 4 position tuples with behavior dependent on that size. The normalized method is the only method required to emit the same kind of object that it is called on, and this has been taken care of with the tuple version. What does this mean? All instances of Point(x,y,z) have been converted into (x,y,z) All instances of Vector(x,y,z) have been converted into (x,y,z,'v') The notation to access the x,y,z of the Point objects has been been changed from p.x,p.y,p.z to p[0],p[1],p[2] The notation for the point math functions has been completely changed. Instead of p1.sub(p2) it has been converted to psub(p1,p2) Instead of p1.sub(p2).mul(0.5) it has been converted to pmul(psub(p1,p2), 0.5) It is very important to point out that the tuple is an immutable type. You can not change it once you create it. t[0] = calculated_x_value # syntax error You have to replace the reference (t) to the old tuple with a new reference to a new tuple. t = (calculated_x_value, t[1], t[2]) # works There was a particularly hairy mutable/immutable barrier in the next() generator present in each class that inherits TransformableContainer. The TransformableContainer.transform_by_matrix function uses these generators to collapse polygons and lines and triangles into points where a shift is performed on each. Now that point is immutable, you can not change the value emitted by the generator. Geometry/__init__.py transform_by_marix and the associated next() generator in each sub class has been rewritten to transfer the attr used to store the reference to the tuple. Geometry/__init__.py transform_by_matrix now sets these attributes which effectively gets around this limitation. There could be some old point object code in any of the files not contained in this commit. It is impossible to know without running the code path and/or careful analysis of each file. Some list comprehensions that convert a list of point objects into a 3 position tuple have been removed. Whitham D. Reeve II
-
- 08 Feb, 2012 1 commit
-
-
Lars Kruse authored
-
- 25 Jan, 2012 3 commits
-
-
Lars Kruse authored
additionally mention a corner-case regarding urllib2.urlopen.read() see: https://sourceforge.net/tracker/index.php?func=detail&aid=3476811&group_id=237831&atid=1104176
-
Lars Kruse authored
* add a UUID to all interesting objects * include models in dump
-
Lars Kruse authored
-
- 24 Jan, 2012 2 commits
-
-
Lars Kruse authored
* the real issue was sys.stdin (see http://bugs.python.org/issue10174)
-
Lars Kruse authored
-
- 23 Jan, 2012 3 commits
-
-
Lars Kruse authored
-
Paul Bonser authored
-
Paul Bonser authored
-
- 22 Dec, 2011 1 commit
-
-
Paul Bonser authored
-
- 21 Dec, 2011 1 commit
-
-
Paul Bonser authored
-
- 21 Jan, 2012 2 commits
-
-
Paul Bonser authored
-
Paul Bonser authored
-
- 30 Jul, 2011 1 commit
-
-
sumpfralle authored
added "unit_string" for human readable unit values fixed ModelExtrusion visibility fixed ModelSupport visibility added "Models" dependency to OpenGLWindow (temporarily: until the offending calls are gone) git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@1141 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 17 Jul, 2011 1 commit
-
-
sumpfralle authored
git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@1121 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 14 Jun, 2011 1 commit
-
-
sumpfralle authored
git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@1096 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 24 May, 2011 1 commit
-
-
paulusmax authored
Put in a bunch of debug messages which are commented out in the search for why this triangle (and some others) don't work right with the cylindrical cutter.... seems to have something to do with it being upside down.... as problem doesn't happen when right side up. seems to have to do with the "circle_triangle" detection scheme. git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@1073 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 14 Apr, 2011 1 commit
-
-
sumpfralle authored
* new default model * fixes for support grid generation * more verbose error message for missing converter programs git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@1072 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 09 Apr, 2011 1 commit
-
-
sumpfralle authored
git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@1059 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 24 Mar, 2011 1 commit
-
-
sumpfralle authored
git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@1026 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 13 Feb, 2011 2 commits
-
-
sumpfralle authored
improved implementation of GCode step width (for each axis) adjusted GCode positioning accuracy according to the number of significant digits of the step width git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@987 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
sumpfralle authored
fixed typo git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@985 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 07 Feb, 2011 2 commits
-
-
sumpfralle authored
git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@974 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
sumpfralle authored
git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@973 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 02 Feb, 2011 1 commit
-
-
sumpfralle authored
simplified the "minimum_step" parameters for the GCode generator (fall back to x, if y/z are not given) git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@953 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 01 Feb, 2011 1 commit
-
-
paulusmax authored
An attempt to get the resolution for each axis to be controlled individually. Now all axes properly named and working just fine... changed the default to 0.0001 for now untill gcode resolution selection is available. git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@946 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-
- 28 Jan, 2011 1 commit
-
-
sumpfralle authored
git-svn-id: https://pycam.svn.sourceforge.net/svnroot/pycam/trunk@943 bbaffbd6-741e-11dd-a85d-61de82d9cad9
-