Back
[01:09:38] <jmkasunich> fenn_: I've used PovRay for about 15 years (intermittently), so I find writing a "source file" to describe a geometry to be quite natural
[01:10:28] <SWPadnos> I wonder if POVRay could do realtime raytracing on todays machines (for non-trivial, but not too hairy models)
[01:34:16] <jmkasunich> no
[01:34:39] <jmkasunich> even a simple model is still a few seconds, not many per second
[01:37:49] <jmkasunich> I suppose if you limited it to 320x240 you'd get multiple frames per second, for some moderate value of "multiple"
[01:57:41] <jepler> but you could post-render with pov if you had halsampler of joint positions -> pov variable settings
[01:57:50] <jepler> maybe vismach could even be modified to output pov files
[02:02:37] <jmkasunich> but why?
[02:02:46] <jmkasunich> vismach is good for live updates
[02:03:20] <jmkasunich> povray is good for quality, and its language is far more capable
[02:03:43] <jmkasunich> I can model material removal in pov using "difference"
[02:06:51] <jmkasunich> although it bogs down quite a bit
[02:09:13] <jmkasunich> wish it would use both cores
[02:12:44] <jmkasunich> http://jmkasunich.com/pics/povball.png
[02:13:03] <jmkasunich> I chopped it with a plane to show the cross section
[02:13:23] <jmkasunich> 6 mins 13 seconds
[02:14:19] <jmkasunich> 278 million cone/cylinder tests, ditto for CSG intersections, and spheres
[02:15:19] <jmkasunich> toolpath consisted of approximately 900 tool poses
[02:16:43] <jmkasunich> jepler: cradek thinks you might have max5 config files on your laptop...
[02:32:01] <jepler> jmkasunich: I doubt it..
[02:32:09] <jmkasunich> ok
[02:32:16] <jmkasunich> (he thought you were running max at one point)
[02:32:29] <jepler> not on either of my current laptops -- they're no good for rt
[02:32:39] <jmkasunich> I see
[02:47:02] <cradek_> whee I'm back
[02:47:07] <cradek_> cradek_ is now known as cradek
[02:47:08] <jmkasunich> yay
[02:47:13] <jmkasunich> (where were you)
[02:47:22] <cradek> we're not in kansas anymore
[02:47:32] <jmkasunich> mpm?
[02:47:35] <cradek> err
[02:47:40] <cradek> I don't think we're in kansas anymore
[02:47:43] <cradek> whatever the quote is
[02:48:02] <jmkasunich> and your little dog too!
[02:48:07] <cradek> nope, not mpm this time
[02:48:10] <cradek> what'd I miss?
[02:48:35] <cradek> I should go look for that config before it gets any later
[02:48:36] <jmkasunich> some neat machinging you-tube vids over the last couple days
[02:48:39] <jmkasunich> http://jmkasunich.com/pics/povball.png
[02:49:06] <cradek> oh cool, I think I see what that is
[02:49:28] <jmkasunich> the actual ball is cut by one line of g-code
[02:50:26] <cradek> brb
[02:50:31] <jmkasunich> the effort on vismach and configs is to make sure that the machine does what pov says its doing
[02:59:25] <cradek> http://timeguy.com/cradek-files/emc/max5.tar.gz
[02:59:34] <jmkasunich> thanks
[04:33:05] <CIA-32> EMC: 03jmkasunich 07TRUNK * 10emc2/configs/vismach/ (6 files): tweaks to max5 vismach model, added config that uses it (in the configs/vismach directory)
[04:33:15] <CIA-32> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/max5gui.py: tweaks to max5 vismach model, added config that uses it (in the configs/vismach directory)
[04:33:51] <jmkasunich> goodnight
[15:24:23] <rayh> I see another upgrade to the linux kernel used in the 64 bit ubuntu
[15:30:27] <rayh> Looks like I've got versions from 12-18 now.
[15:31:32] <SWPadnos> heh
[15:31:53] <SWPadnos> I was just looking at the boot list on my big Opteron machine - there are probably 30 or 40 kernels there
[15:32:07] <SWPadnos> and none of them runs the nvidia drivers or vmware correctly any more :(
[15:37:50] <rayh> Guess I'd better clean up some of the unused.
[18:07:41] <jepler> seb_kuzminsky: what's new?
[18:08:01] <seb_kuzminsky> hi jepler, not much new going on here
[18:08:11] <seb_kuzminsky> i wasted like 2 weeks on what turned out to be a bad parallel port cable
[18:08:15] <seb_kuzminsky> that was a bit frustrating
[18:08:32] <seb_kuzminsky> what's new with you? getting ready for the emc fest?
[18:09:29] <jepler> I don't really have anything to prepare -- but yeah I'm looking forward to it
[18:12:19] <jepler> I've been working on a path offseting library recently but unfortunately I feel like I've hit a wall on it again.
[18:13:53] <seb_kuzminsky> what is path offsetting?
[18:15:39] <jepler> given an outline, produce another outline (or group of outlines) which is inside the old outline by a given distance d. One way of pocketing a shape is to offset by a whole range of different values each just a little less than a tool radius apart.
http://emergent.unpy.net/index.cgi-files/sandbox/offs-one-more-bug-fixed.png
[18:16:03] <jepler> here the very outermost loop is the one given as the program's input, and the other loops are all found by the program
[18:20:23] <jepler> (in firefox make sure you click the image to see it unscaled)
[18:21:39] <SWPadnos> out of curiosity, does it do outside offsetting too?
[18:22:21] <SWPadnos> (they're mostly the same thing, but maybe different enough that it matters)
[18:25:10] <jepler> yes, modulo bugs
[18:25:41] <jepler> (but it looks like you do hit some bugs if you try to offset that path on the other side)
[18:31:18] <SWPadnos> ok - it's never easy :)
[18:54:26] <cradek> jepler: I'm still impressed by that image. Looks so close to being done.
[18:55:16] <jepler> cradek: looks, yes
[18:55:38] <jepler> (for all I know it's already good enough to be a sellable cam algorithm :-P)
[18:56:33] <jepler> I am also convinced that the number and frequency of bugs like the one in that screenshot (the unfilled area in the upper left) would be less if I repeatedly offset a path, instead of always offsetting the original path by a greater amount each time..
[18:56:58] <jepler> (I haven't tried doing that yet because I'd rather know about the bugs than look for ways to paper over them)
[18:57:34] <SWPadnos> oh - interesting. offsetting the new path may be more correct because there may be additional elements added, or elements removed, from the offset paths
[18:58:00] <cradek> SWPadnos: not really; you should always get all the resulting paths
[18:58:51] <SWPadnos> true, you should be able to offset by 1/2" instead of 1/4" twice
