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
I wonder if POVRay could do realtime raytracing on todays machines (for non-trivial, but not too hairy models)
even a simple model is still a few seconds, not many per second
I suppose if you limited it to 320x240 you'd get multiple frames per second, for some moderate value of "multiple"
but you could post-render with pov if you had halsampler of joint positions -> pov variable settings
maybe vismach could even be modified to output pov files
vismach is good for live updates
povray is good for quality, and its language is far more capable
I can model material removal in pov using "difference"
although it bogs down quite a bit
wish it would use both cores
[02:12:44] <jmkasunich> http://jmkasunich.com/pics/povball.png
I chopped it with a plane to show the cross section
6 mins 13 seconds
278 million cone/cylinder tests, ditto for CSG intersections, and spheres
toolpath consisted of approximately 900 tool poses
jepler: cradek thinks you might have max5 config files on your laptop...
jmkasunich: I doubt it..
(he thought you were running max at one point)
not on either of my current laptops -- they're no good for rt
whee I'm back
cradek_ is now known as cradek
(where were you)
we're not in kansas anymore
I don't think we're in kansas anymore
whatever the quote is
and your little dog too!
nope, not mpm this time
what'd I miss?
I should go look for that config before it gets any later
some neat machinging you-tube vids over the last couple days
[02:48:39] <jmkasunich> http://jmkasunich.com/pics/povball.png
oh cool, I think I see what that is
the actual ball is cut by one line of g-code
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
EMC: 03jmkasunich 07TRUNK * 10emc2/configs/vismach/ (6 files): tweaks to max5 vismach model, added config that uses it (in the configs/vismach directory)
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)
I see another upgrade to the linux kernel used in the 64 bit ubuntu
Looks like I've got versions from 12-18 now.
I was just looking at the boot list on my big Opteron machine - there are probably 30 or 40 kernels there
and none of them runs the nvidia drivers or vmware correctly any more :(
Guess I'd better clean up some of the unused.
seb_kuzminsky: what's new?
hi jepler, not much new going on here
i wasted like 2 weeks on what turned out to be a bad parallel port cable
that was a bit frustrating
what's new with you? getting ready for the emc fest?
I don't really have anything to prepare -- but yeah I'm looking forward to it
I've been working on a path offseting library recently but unfortunately I feel like I've hit a wall on it again.
what is path offsetting?
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
here the very outermost loop is the one given as the program's input, and the other loops are all found by the program
(in firefox make sure you click the image to see it unscaled)
out of curiosity, does it do outside offsetting too?
(they're mostly the same thing, but maybe different enough that it matters)
yes, modulo bugs
(but it looks like you do hit some bugs if you try to offset that path on the other side)
ok - it's never easy :)
jepler: I'm still impressed by that image. Looks so close to being done.
cradek: looks, yes
(for all I know it's already good enough to be a sellable cam algorithm :-P)
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..
(I haven't tried doing that yet because I'd rather know about the bugs than look for ways to paper over them)
oh - interesting. offsetting the new path may be more correct because there may be additional elements added, or elements removed, from the offset paths
SWPadnos: not really; you should always get all the resulting paths
true, you should be able to offset by 1/2" instead of 1/4" twice