> BTW, the splitting is usually done with the octtree approach (which was > mentioned before). > It can still generate a huge amount of data. If you want a block of 10" > split down to 1mil (0.001"), or 4 orders of magnitude, then you need a > tree-depth of 14. That would be worst case 10^12 leaf nodes, which is > computationally unfeasible. Even a measly 1% fill is 10^10 leaf nodes, > which no ordinary computer would want to deal with. > My guess is that you could get max. ~2.5 orders of magnitude resolution > for any result that should complete in the near future. >
The problem with a simple voxel model is that for a resolution r, the storage requirement scales with the volume as r^3 (or 1/r^3 depending on how you define resolution). Dan Heeks's cutting simulation uses this approach I think. http://code.google.com/p/voxelcut/ The adaptive approaches subdivide only when necessary, at the stock surface, and so in theory the memory requirement scales with the area or r^2. I'd suggest the future insanely-great linuxcnc cutting-simulator should allow for easily swapping out the stock-model / cutting-engine. The voxel approach might be faster but coarser, and we all have 32 gigs of RAM anyway right? For slower and more accurate work an adaptive octree might be preferable. I'm probably sounding like a broken record player, but I'll repeat anyway: what is needed now is a sound basic framework for pushing these ideas forward - the basic algorithms or individual parts already exist. we need: - a GUI that displays G-code in one window, and a 3D opengl view in another window. - play, pause, stop buttons that run the interpreter on said G-code, and produces internal 'canon' calls for the cutting-engine - a sound, minimal but complete, API for the cutting engine -- tool library (G-code does not define tools!) -- method for defining stock (G-code does not define stock!) -- 'canonical' G-code moves -- graphics output for the 3D view. probably vertex-arrays and polygon-arrays in memory that is shared between the cutting-engine and the 3D view. This should probably run in two or three separate threads, to keep the 3D view and G-code view/buttons responsive. Anders ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
