| --- Day changed Sat Sep 05 2009 | ||
| -!- ve [n=a@94-193-95-252.zone7.bethere.co.uk] has quit [Read error: 110 (Connection timed out)] | 00:09 | |
| -!- ve_ is now known as ve | 00:09 | |
| -!- mason-l [n=x@202-89-188-136.static.dsl.amnet.net.au] has quit [Remote closed the connection] | 00:12 | |
| fenn | "A more subtle virus which targets intellectual property is the GNU public license, which has infected countless pieces of property to date, destroying capitalistic opportunity; the GNU public license is 35kbytes." | 00:32 |
|---|---|---|
| fenn | poor poor capitalism | 00:33 |
| -!- mason-l [n=x@202-89-188-136.static.dsl.amnet.net.au] has joined #hplusroadmap | 01:23 | |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 104 (Connection reset by peer)] | 01:29 | |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap | 01:29 | |
| -!- parolang [n=user@keholmes.oregonrd-wifi-1261.amplex.net] has quit [Read error: 110 (Connection timed out)] | 01:32 | |
| -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has joined #hplusroadmap | 01:42 | |
| wrldpc2 | http://www.filedropper.com/theblacksmithscraft-1952 | 01:43 |
| -!- mason-l [n=x@202-89-188-136.static.dsl.amnet.net.au] has quit [Read error: 60 (Operation timed out)] | 02:13 | |
| -!- mason-l [n=x@202-89-188-136.static.dsl.amnet.net.au] has joined #hplusroadmap | 02:26 | |
| -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has quit [] | 02:43 | |
| -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has joined #hplusroadmap | 02:48 | |
| -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has quit [Read error: 104 (Connection reset by peer)] | 03:05 | |
| -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has joined #hplusroadmap | 03:05 | |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 60 (Operation timed out)] | 03:57 | |
| CIA-32 | skdb: fenn * r de3d4d3 /packages/threads/threads.py: start describing standard thread series | 04:39 |
| CIA-32 | skdb: fenn * r 0c58288 /packages/threads/threads.py: finished UNC and UNF series. not sure where to find data for ISO_Fine_Thread yet | 04:39 |
| -!- drazak [n=drazak@drazak.net] has quit [Read error: 60 (Operation timed out)] | 05:08 | |
| -!- drazak [n=drazak@drazak.net] has joined #hplusroadmap | 05:19 | |
| -!- wrldpc2_ [n=benny@ool-ad03fe34.dyn.optonline.net] has joined #hplusroadmap | 07:04 | |
| -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has quit [Read error: 104 (Connection reset by peer)] | 07:04 | |
| -!- wrldpc2_ is now known as wrldpc2 | 07:04 | |
| fenn | guh. from UN declaration of human rights: (3) Parents have a prior right to choose the kind of education that shall be given to their children. | 07:25 |
| fenn | Elementary education shall be compulsory. | 07:26 |
| -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has quit [] | 07:44 | |
| CIA-32 | skdb: fenn * r a68395c /core/units.py: uncertainty is actually a range of units, not a unit itself | 08:05 |
| CIA-32 | skdb: fenn * r fa04ebe /packages/threads/threads.py: Merge branch 'master' of adl.serveftp.org:/var/www/skdb | 08:05 |
| -!- any25527960 [n=someone@75-120-45-160.dyn.centurytel.net] has joined #hplusroadmap | 08:18 | |
| kanzure | IBM autopass: "Autopass: An Automatic Programming System for Computer-Controlled Mechanical Assembly" | 08:32 |
| kanzure | hm there's an ieee comp sci journal called "tutorial on robotics" | 08:33 |
| -!- any85001797 [n=someone@75-120-45-160.dyn.centurytel.net] has joined #hplusroadmap | 08:33 | |
| -!- katsmeow-afk [n=someone@75-120-23-164.dyn.centurytel.net] has quit [Nick collision from services.] | 08:33 | |
| -!- any85001797 is now known as katsmeow-afk | 08:34 | |
| kanzure | "The AUTOPASS language is oriented towards objects and assembly operations, rather than motions of mechanical assembly machines. It is intended to enable the user to concentrate on the overall assembly sequence and to program with English-like statements using names and terminology that are familiar to him." | 08:35 |
| kanzure | "To relate assembly operations to manipulator motions, the AUTOPASS compiler uses an internal representation of the assembly world. This representation consists of a geometric data base generated prior to compilation and updated during compilation; it thus represents the state of the world at each assembly step." | 08:35 |
| -!- kardan| [n=kardan@p54BE454F.dip.t-dialin.net] has joined #hplusroadmap | 08:36 | |
| kanzure | stalk: lieberman, wesley | 08:36 |
| -!- any25527960 [n=someone@75-120-45-160.dyn.centurytel.net] has quit [Read error: 60 (Operation timed out)] | 08:39 | |
| kanzure | ibm journal of research and development, ridiculously large bibtex bibliography: http://ftp.math.utah.edu/pub//tex/bib/ibmjrd.html | 08:40 |
| kanzure | http://en.wikipedia.org/wiki/A_Manufacturing_Language | 08:46 |
| kanzure | stubs suck :( | 08:46 |
| fenn | pot, meet kettle | 08:49 |
| kanzure | ah here's the pdf: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.4319&rep=rep1&type=pdf | 08:49 |
| kanzure | for the autopass paper, I mean | 08:50 |
| fenn | just from the quote it sounds like it was written in fortran or something | 08:50 |
| fenn | it's impeccably typeset for a 1977 paper | 08:53 |
| fenn | looking at the 'functional module hierarchy' of the movement planner, it seems to be pretty advanced | 08:55 |
| fenn | collision detection with swept volumes.. i can't even do that with all the tools at my disposal | 08:55 |
| kanzure | page 332 shows the grammar (somewhat) | 08:56 |
| kanzure | it was a PS/1 language | 08:57 |
| kanzure | IIRC, that dates even fortran | 08:57 |
| kanzure | not sure why those commands just so happen to be the ones they cohse | 08:57 |
| kanzure | *chose | 08:57 |
| -!- |kardan| [n=kardan@p54BE5EDB.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)] | 08:57 | |
| ybit | well i'm impressed | 08:57 |
| fenn | eh? what's special about the commands? | 08:57 |
| ybit | heh, not the commands, autopass itself | 08:58 |
| kanzure | place, insert, extract, lift, lower, slide, push, orient, turn, grasp, move, release, operate, clamp, unclamp, load, unload, fetch, replace, switch, lock, unlock, attach, drive in, rivet, fasten, unfasten, verify, open state, closed state, name assembly | 08:58 |
| kanzure | well why are those the commands? | 08:58 |
| kanzure | I mean, how did they figure that this would be good enough? | 08:59 |
| fenn | seems rather arbitrary to me | 08:59 |
| kanzure | yeah | 08:59 |
| ybit | kanzure: how'd you come across autopass, nearly every page with it is expired | 08:59 |
| ybit | would have to be while scraping for papers | 08:59 |
| kanzure | ybit: no, it was a search result for one of my google scholar queries about assembly operations and assembly planners | 09:01 |
| fenn | i don't think it's super worthwhile to worry about what particular verbs to use if there's no code to back it up | 09:03 |
| kanzure | well I had this dream last night that a better way to do it would be as follows: | 09:04 |
| kanzure | actions are specified as some collection of Vector, Torque, Force objects (the last two have yet to be written) | 09:04 |
| kanzure | or, actually, those are Unit objects, so nevermind | 09:04 |
| fenn | ugh | 09:04 |
| kanzure | anyway, these actions have a definition | 09:04 |
| kanzure | and they are matched to whatever verbs the tool has | 09:04 |
| kanzure | so the tool then executes the verb that fulfills the action | 09:04 |
| fenn | but that says nothing about what you're actually trying to do | 09:05 |
| kanzure | yes but it solves the other problem | 09:05 |
| fenn | vector+torque+force != drilling a hole, or aligning some part wrt another part | 09:05 |
| kanzure | the one where you're making up batshit fucking crazy verbs | 09:05 |
| kanzure | I think it would be adequate to have a text description appended I guess | 09:06 |
| kanzure | vector+torque+force "drill a hole from here to there" | 09:06 |
| fenn | the thing is they're intrinsically closed loop processes.. and you're trying to describe it as if it were open loop | 09:06 |
| kanzure | what is a closed loop process? | 09:06 |
| fenn | uh, like the difference between a stepper and servo | 09:06 |
| fenn | not some ecological bullshit | 09:06 |
| kanzure | you lost me | 09:07 |
| fenn | servos utilize feedback from sensors | 09:07 |
| fenn | steppers blindly assume that everything is perfect | 09:07 |
| kanzure | which one is closed and which one is open | 09:07 |
| fenn | servo = closed feedback loop | 09:07 |
| kanzure | yet it's getting data input? | 09:07 |
| fenn | because a command goes out, changes the state of the motor, is sensed, and comes back into the control | 09:08 |
| fenn | closed like a closed circuit | 09:08 |
| kanzure | ok | 09:08 |
| kanzure | so just add an end condition then | 09:08 |
| kanzure | vector+force... the vector has a starting position and an end position | 09:09 |
| kanzure | er that's not a vector | 09:09 |
| kanzure | but you get the idea | 09:09 |
| fenn | FAIL | 09:09 |
| kanzure | some geometric description object | 09:09 |
| kanzure | like a line maybe | 09:09 |
| fenn | yeah, welcome to my world | 09:09 |
| fenn | remember me asking about a geometric constraints language? | 09:09 |
| kanzure | yes but that was in a different context | 09:09 |
| fenn | not really | 09:09 |
| * kanzure is thinking about instruction generation if you haven't noticed | 09:10 | |
| kanzure | I'm sure it can be applied in both areas | 09:10 |
| fenn | putting a slab on a milling machine is a sort of assembly process | 09:10 |
| kanzure | "putting" isn't in your taxonomy though | 09:10 |
| kanzure | your process taxonomy I mean | 09:10 |
| fenn | it doesn't just sit there, you have to bolt it down a certain way | 09:10 |
| fenn | the manufacturing techniques book assumes it's a machine doing the work | 09:11 |
| fenn | blarg | 09:11 |
| kanzure | we are the blarg, you will be assimilated | 09:11 |
| fenn | a robot would have a certain positioning tolerance, but depending on the human and how much effort they expended you could get anywhere from 0.001" to 10" position error | 09:12 |
| kanzure | yeah | 09:12 |
| fenn | or more, depending on context | 09:12 |
| fenn | 'put beacon at these geospatial coordinates' | 09:12 |
| kanzure | yes but where did that string come from | 09:13 |
| fenn | package "robot corral" | 09:13 |
| kanzure | wtf? | 09:13 |
| kanzure | so there's a corral tool that is telling you to put something somewhere? | 09:13 |
| kanzure | honestly I don't think you've thought this out either | 09:14 |
| fenn | what's the problem now? | 09:14 |
| kanzure | instruction generation | 09:14 |
| kanzure | it's on the todo list, you see | 09:14 |
| fenn | that's so overly broad as to be almost useless | 09:14 |
| kanzure | the todo list? | 09:15 |
| fenn | no, "instruction generation" | 09:15 |
| kanzure | do you know what instructions are? | 09:15 |
| fenn | yes | 09:15 |
| kanzure | an assembly doesn't just magically assemble | 09:15 |
| fenn | it's sort of like "write me a program that plays games" | 09:16 |
| kanzure | does it need to play well? | 09:16 |
| kanzure | actually I think you could do something where you have a config file where you tell it what key codes to send | 09:16 |
| fenn | and then getting mad because the program doesn't understand your poker terminology | 09:16 |
| kanzure | and then have it randomly select which keys to press | 09:16 |
| kanzure | no, most games have only a limited amount of input | 09:16 |
| kanzure | and games that require a mouse suck anyway | 09:16 |
| fenn | i wasn't talking about computer games | 09:17 |
| fenn | any sort of game | 09:17 |
| fenn | that's how broad "instructions" is | 09:17 |
| kanzure | I disagree | 09:17 |
| kanzure | to me I see an assembly graph and I see connections between parts | 09:17 |
| fenn | that's just assembly instructions | 09:17 |
| kanzure | yes | 09:17 |
| fenn | there's a lot more to manufacturing than just assembly | 09:18 |
| kanzure | when we come up with manufacturing classes we'll do that then | 09:19 |
| kanzure | but for now shouldn't we be working with the assembly graph class we already have? | 09:19 |
| fenn | the igraph thing? | 09:19 |
| kanzure | er, the graph of connections for assemblies | 09:19 |
| fenn | -_- | 09:20 |
| kanzure | so yes? | 09:20 |
| kanzure | I haven't looked at the code | 09:20 |
| kanzure | you deleted what I wrote, but I'm assuming it does the same thing | 09:20 |
| fenn | well, for one thing there's not enough information there | 09:20 |
| fenn | i didn't delete it | 09:20 |
| fenn | anyway it does the same thing i guess | 09:21 |
| kanzure | ok you put it into a go_away string :p | 09:21 |
| fenn | only my local copy | 09:21 |
| fenn | rest assured your crap is still there | 09:21 |
| kanzure | what information do you think is missing? | 09:22 |
| fenn | uh. so anyway as i was saying, there's not enough information to figure out how to assemble the lego graph, because we don't have geometric collision detection or even something like david's rectangular constraint | 09:22 |
| kanzure | "press lego1 to lego2" isn't good? | 09:23 |
| fenn | no | 09:23 |
| kanzure | I think we should try it out actually | 09:23 |
| fenn | how do you know what order to assemble the legos? | 09:23 |
| kanzure | you make a lego assembly, we press "generate" | 09:23 |
| kanzure | the order in which they were added would be a good start | 09:23 |
| kanzure | and then I try to make it on the table | 09:23 |
| fenn | magical thinking | 09:23 |
| kanzure | ? | 09:23 |
| fenn | it won't work. actually you were the one that told me that | 09:23 |
| kanzure | was I on or off the drugs? | 09:23 |
| fenn | sometimes it adds bricks in between other bricks (not colliding, just impossible to do in that order) | 09:24 |
| * ybit wants to know what is doing the adding of lego bricks | 09:24 | |
| fenn | add_lego() | 09:24 |
| ybit | what machine | 09:24 |
| kanzure | a chimpanzee | 09:24 |
| fenn | uh, "minsky" | 09:24 |
| fenn | ybit: not a robot, if you're confused | 09:24 |
| fenn | this is virtual legos | 09:25 |
| ybit | no i figured it was a name of one of the computers there so you are saying it's simulated | 09:25 |
| fenn | i guess i could constrain it to only add bricks where the interface vector is clear.. but without collision detection i dont know how to implement that | 09:25 |
| kanzure | "is clear" what? | 09:26 |
| fenn | sweep the volume of the added brick along the interface vector; boolean intersect with all the other bricks; if you get a volume back it must have collided with something | 09:26 |
| fenn | but that's horribly computationally expensive | 09:26 |
| fenn | humans do it with feedback; in effect using reality as a massively parallel computer | 09:27 |
| kanzure | oh you mean to check if the approach motion would be possible | 09:27 |
| fenn | yes | 09:27 |
| fenn | ever played "operation"? | 09:28 |
| ybit | :) | 09:28 |
| fenn | in other news, metric thread tolerance classes are confusing | 09:30 |
| ybit | kanzure: when you lieberman, are you referring to J. Lieberman who was a co-author of 'introduction to operations research'? | 09:31 |
| kanzure | no | 09:31 |
| ybit | +say | 09:31 |
| kanzure | the author of autopass | 09:31 |
| ybit | wouldn't know since i can't read pdfs currently | 09:31 |
| ybit | LI Lieberman | 09:32 |
| fenn | kanzure: do you know of any papers that actually do collision detection in assembly planning? | 09:42 |
| kanzure | no | 09:44 |
| fenn | "development of computer aided assembly planning systems have not, in general, been successful... One of the main reasons for this lack of success is that assembly is dependent on a great deal of expert knowledge which has proven very difficult to formalize" | 09:45 |
| kanzure | eh? that's the difficulty? | 09:45 |
| ybit | Virtual Reality in Assembly Simulation?Collision Detection, Simulation Algorithms, and ... | 09:45 |
| kanzure | some of these may be useful: http://adl.serveftp.org/papers/review/ | 09:45 |
| ybit | that's the closest thing to what you guys are doing currently | 09:45 |
| kanzure | but none of them are specifically about collision detection | 09:45 |
| kanzure | for instance: A connector-based hierarchical approach to assembly sequence planning for mechanical assemblies | 09:46 |
| ybit | http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.125.7125&rep=rep1&type=pdf Fast continuous collision detection between rigid bodies | 09:46 |
| kanzure | Constraint-based interactive assembly planning | 09:46 |
| fenn | ybit: that paper (VADE) is basically just "make a human do the assembly planning, wah!" | 09:46 |
| ybit | heh, i can't read, just finding titles which seem relevant | 09:47 |
| ybit | i don't see anything as requested | 09:48 |
| kanzure | how about this one? | 09:49 |
| kanzure | http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.4931&rep=rep1&type=pdf | 09:49 |
| fenn | VADE simulates inter-part interaction for planar and axisymmetric parts using constrained motions along axes/planes. These axes and planes are obtained as part of the assembly design intent from the CAD system. This allows simulation of sliding, rotating, etc., without compute-expensive numerical methods | 09:49 |
| kanzure | "A general framework for assembly planning - the motion space approach" | 09:49 |
| ybit | http://www.informaworld.com/smpp/ftinterface?content=a713804846&rt=0&format=pdf Motion planning for multi-robot assembly systems is kind of what you were talking about a few mins ago | 09:49 |
| kanzure | ybit: you can stop | 09:49 |
| kanzure | at least read the paper a little bit :) | 09:49 |
| ybit | :) | 09:49 |
| ybit | that was the last one anyway | 09:49 |
| fenn | gah that citseer paper is so slow to render | 09:53 |
| kanzure | it renders just fine in evince | 09:53 |
| kanzure | why am I using evince | 09:54 |
| ybit | because you haven't realized kpdf is the bomb-diggidy | 09:54 |
| ybit | only gripe is that it doesn't handle chm files | 09:55 |
| ybit | have to use a seperate viewer such as kchmviewer | 09:55 |
| fenn | does evince do chm? | 09:58 |
| fenn | too slow and too mathy.. /me gives up | 09:59 |
| kanzure | "spatial constraint graphs" | 10:02 |
| kanzure | "this graph represents the list of obstructing parts that prevent the mating of other part along certain mating directions if the blocking parts are placed earlier in the sequence than the other part." | 10:02 |
| kanzure | "the SCG is a directed graph in which the source node denotes the obstructed part and each of the arcs ends in an obstructing part" | 10:02 |
| kanzure | apparently there are some algorithms for generating SCGs in "An integrated approach to automated assembly planning for three-dimensional mechanical products" | 10:03 |
| fenn | i don't really think graphs are the way to do thi | 10:03 |
| fenn | s.. | 10:03 |
| kanzure | well using a GPU for collision detection of loaded models isn't the way to do it either :p | 10:04 |
| fenn | no? | 10:05 |
| fenn | sounds like awesome to me | 10:05 |
| fenn | i'm thinking something involving voronoi diagrams or electrostatic force like the graph layout algorithms | 10:06 |
| kanzure | gah isn't this campbell's job? | 10:06 |
| fenn | don't make me talk bad about the man behind his back | 10:07 |
| kanzure | how about in front? | 10:07 |
| fenn | i guess i can add assembly planning to the lunch agenda since i have no idea what we're going to be talking about next week | 10:08 |
| kanzure | lunch agenda? | 10:08 |
| fenn | wants to meet on 9/9 for some reason | 10:08 |
| -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has joined #hplusroadmap | 10:32 | |
| ybit | well that was a quick arch install | 11:40 |
| ybit | thank it took a total of 1 hour to get to xorg+xmonad | 11:40 |
| ybit | thin* | 11:41 |
| kanzure | http://www.kickstarter.com/projects/701662757/makerbeam-an-open-source-building-kit | 11:42 |
| kanzure | why the fuck does he need $10k? | 11:42 |
| kanzure | http://makerbeam.com/ | 11:43 |
| kanzure | http://www.garagefab.cc/contraptor/ | 11:50 |
| kanzure | http://contraptor.svn.sourceforge.net/viewvc/contraptor/tags/contraptor-1.5.0.tar.gz?view=tar | 11:50 |
| -!- ybit [n=ybit@unaffiliated/ybit] has quit ["leaving"] | 12:10 | |
| * kanzure compiles heekscad r819 | 12:16 | |
| kanzure | hopefully dxf->anything will have improved | 12:16 |
| -!- parolang [n=user@keholmes.oregonrd-wifi-1261.amplex.net] has joined #hplusroadmap | 12:31 | |
| kanzure | hey parolang | 12:33 |
| parolang | hi | 12:38 |
| -!- splicer [n=patrik@h55n1c1o261.bredband.skanova.com] has joined #hplusroadmap | 12:58 | |
| -!- ybit [n=heath@unaffiliated/ybit] has joined #hplusroadmap | 13:06 | |
| -!- strages [n=strages@c-68-62-216-5.hsd1.al.comcast.net] has quit [Read error: 113 (No route to host)] | 13:54 | |
| -!- strages [n=strages@c-68-62-216-5.hsd1.al.comcast.net] has joined #hplusroadmap | 13:55 | |
| CIA-32 | skdb: kanzure * r 5a3e4b6 /geom/ode_collider.py: pyODE collision detection code in progress. weird error, see last two lines in file. | 14:10 |
| kanzure | note that pyODE is no substitute for a propper engineering-level collider | 14:10 |
| -!- splicer [n=patrik@h55n1c1o261.bredband.skanova.com] has quit [Read error: 104 (Connection reset by peer)] | 14:17 | |
| -!- dira [n=chatzill@86.99.40.183] has joined #hplusroadmap | 14:18 | |
| kanzure | hey dira | 14:52 |
| dira | hey | 14:52 |
| dira | how are ya doing? | 14:52 |
| kanzure | doing well | 14:52 |
| kanzure | what's up? | 14:52 |
| -!- Irssi: #hplusroadmap: Total of 31 nicks [0 ops, 0 halfops, 0 voices, 31 normal] | 14:53 | |
| dira | not much here, struggling to setup DotNetNuke web portal | 14:53 |
| dira | what's up with you? | 14:54 |
| kanzure | nuke is very old | 14:54 |
| kanzure | doodling around with collision detection | 14:54 |
| dira | OpenGL ? | 14:54 |
| kanzure | a little. actually I'm using pyODE, the python bindings to the open dynamics engine | 14:54 |
| kanzure | but there's an opengl visualizer around here somewhere | 14:55 |
| dira | if your python programmer and you are serious in game development AND you can deal with M$ take , http://en.wikipedia.org/wiki/Microsoft_XNA and http://en.wikipedia.org/wiki/IronPython might be good mix | 14:56 |
| kanzure | sorry, I'd rather not | 14:57 |
| kanzure | been there, done that | 14:57 |
| kanzure | this is for collision detection between brep models | 14:57 |
| dira | hmmm, GPA inline features? | 14:58 |
| kanzure | GPA? | 14:58 |
| dira | *GPU ! | 14:58 |
| kanzure | not at the moment | 14:58 |
| kanzure | but I'm considering that, yes | 14:58 |
| kanzure | not sure how to do it. maybe opencv? | 14:58 |
| -!- kanzure changed the topic of #hplusroadmap to: http://adl.serveftp.org/dokuwiki/skdb | 14:59 | |
| dira | I'm not sure if there is one standard portal for such hardware specific actions but take a look at www.nvidia.com , I'm sure I saw something about collision detection there | 15:00 |
| kanzure | gpgu.org has some stuff, but no specific libraries | 15:01 |
| kanzure | not everyone is using nvidia | 15:01 |
| dira | true | 15:01 |
| * dira gets headache every time he thinks of game development | 15:02 | |
| dira | btw , what portal do you suggest ? | 15:02 |
| kanzure | back in 2003 I wrote my own called "mPort Gold" | 15:03 |
| kanzure | but I wouldn't recommend it. these days all the cool kids use django or drupal. | 15:03 |
| dira | does they support multi portal systems ? | 15:04 |
| kanzure | what does that mean? | 15:04 |
| kanzure | btw, why are you in here? have we met? | 15:04 |
| dira | having N web sites with one shared code based and administration | 15:04 |
| kanzure | sure drupal has something like that | 15:05 |
| kanzure | django too | 15:05 |
| kanzure | python plugin for sketchup: http://www.cosc.canterbury.ac.nz/greg.ewing/SuPy/ | 15:05 |
| dira | and I'm here because H+ sounds interesting to me ? | 15:05 |
| kanzure | ah | 15:06 |
| kanzure | how'd you find me? | 15:06 |
| dira | find you ? you found me ! | 15:06 |
| kanzure | you came in here :p | 15:06 |
| dira | then if "H+ channel" == "kanzure" then I found you , correct | 15:07 |
| dira | ;) | 15:07 |
| kanzure | so you searched for a transhuman channel? | 15:07 |
| dira | Utopiah is the link | 15:08 |
| kanzure | oh okay | 15:08 |
| * Utopiah was watching silently | 15:08 | |
| kanzure | hi Utopiah | 15:08 |
| Utopiah | hi kanzure , hi dira , hi #hplusroadmap | 15:08 |
| dira | howdy | 15:09 |
| Utopiah | afaik is knowledgeable in physics and CS and interested in H+ thus... his presence | 15:09 |
| kanzure | neat | 15:09 |
| Utopiah | unfortunately he's also developing a cult to Feynman and C# ;) | 15:10 |
| dira | Feyman is the Man ! | 15:11 |
| Utopiah | (shouldn't have started it) | 15:11 |
| kanzure | a carl feynman cult wouldn't be too bad | 15:11 |
| dira | Utopiah, I know your weak spot , http://research.microsoft.com/apps/tools/tuva/#data=5|0||d71e62e2-0b19-4d82-978b-9c0ea0cbc45f|| | 15:12 |
| dira | the relation of Mathematics to Physics , but that's more than that ... it's more like philosophy of mind and science ! | 15:14 |
| Utopiah | either that or talking on IRC before finishing my dinner ;) bbl | 15:14 |
| dira | TYT | 15:15 |
| -!- ybit [n=heath@unaffiliated/ybit] has quit ["leaving"] | 15:22 | |
| kanzure | gear-wheel.py http://www.salome-platform.org/user-section/tui-examples/gear_wheel.py | 15:29 |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap | 15:51 | |
| kanzure | technically the collision detection only needs to be done when making the virtual assembly. path planning for whether or not it is possible to actually make it is a different question. | 16:00 |
| -!- wrldpc2 [n=benny@ool-ad03fe34.dyn.optonline.net] has quit [] | 16:34 | |
| kanzure | neat, uzbl made slashdot | 17:06 |
| -!- dira [n=chatzill@86.99.40.183] has quit ["ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]"] | 17:09 | |
| -!- dira [n=chatzill@86.99.40.183] has joined #hplusroadmap | 17:09 | |
| -!- dira [n=chatzill@86.99.40.183] has quit ["ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]"] | 17:16 | |
| -!- ybit [n=heath@unaffiliated/ybit] has joined #hplusroadmap | 17:20 | |
| parolang | I wasn't able to get uzbl to compile. | 17:22 |
| kanzure | ouch | 17:22 |
| kanzure | uzbl just made slashdot, btw | 17:22 |
| parolang | yeah, I'm looking for it right now | 17:22 |
| parolang | I'm gonna use conkeror for now. | 17:23 |
| kanzure | it's on github | 17:23 |
| parolang | Yeah, that's where I got it from. Maybe that's the problem, I got a version that won't compile. | 17:25 |
| kanzure | dieterbe's repo? | 17:25 |
| parolang | Yeah. | 17:25 |
| parolang | I love your approach to the web, btw :) | 17:27 |
| parolang | I've seen some of the files on your site about bookmarking, etc. | 17:27 |
| kanzure | thanks :) | 17:27 |
| kanzure | did you see my slashdot comment? | 17:28 |
| parolang | Yeah. Googling surfraw now :) | 17:29 |
| -!- ybit [n=heath@unaffiliated/ybit] has quit ["leaving"] | 17:37 | |
| kanzure | parolang: ? | 17:39 |
| parolang | You mention surfraw in your slashdot comment. | 17:39 |
| kanzure | yeah | 17:39 |
| kanzure | did you find it? | 17:39 |
| parolang | Yes I did, I'm reading about it now :) | 17:39 |
| parolang | I guess I don't know what it does. Does it download the web pages? output the pages to stout? | 17:41 |
| kanzure | it's a scraper | 17:41 |
| kanzure | so for google search results, it spits out links and titles | 17:41 |
| kanzure | and for other things it does other things | 17:41 |
| parolang | Okay, cool. | 17:41 |
| kanzure | the problem though is that there are too few developers to keep up | 17:41 |
| kanzure | so that's why I came up with that xpather+uzbl plan of attack | 17:42 |
| parolang | Yeah, I read that, but I have no clue about xpath. | 17:42 |
| kanzure | xpath is like a URL except it specifies a specific element in an HTML document | 17:42 |
| kanzure | for pages with generated content, you just look for an element with the CSS class that you want, or something | 17:43 |
| -!- ybit [n=ybit@unaffiliated/ybit] has joined #hplusroadmap | 17:43 | |
| parolang | But don't you have the same trouble if the div structure, for instance, changes between layout changes? | 17:43 |
| kanzure | so you can say: /a @attr(href="http://google.com/")/b/ and get back the text inside any link that is also bolded | 17:43 |
| kanzure | that's right | 17:43 |
| kanzure | so that's why uzbl is great for this | 17:44 |
| kanzure | let's say you're using some shell scripts to do your scraping | 17:44 |
| kanzure | and suddenly it detects that the layout has changed | 17:44 |
| -!- kibombo [n=ubuntu@unaffiliated/akafubu] has joined #hplusroadmap | 17:44 | |
| kanzure | and everything is fucked up | 17:44 |
| kanzure | in the traditional way, you have to go into a browser and spend an hour writing a new scraper | 17:44 |
| kanzure | in the uzbl way with xpather, it might be only a two minute task | 17:44 |
| kanzure | of you clicking on the regions of the page that correspond to the content you want | 17:44 |
| -!- kibombo [n=ubuntu@unaffiliated/akafubu] has left #hplusroadmap [] | 17:45 | |
| kanzure | then your shell-based scraper is updated and everything is all well | 17:45 |
| parolang | How do you return the selected section of the page in uzbl? | 17:45 |
| kanzure | yeah I'm working on that | 17:45 |
| kanzure | not sure yet | 17:45 |
| kanzure | it's more of a webkit issue I think | 17:46 |
| parolang | That's a question I had in mind for a somewhat different task: annotating web pages. | 17:46 |
| parolang | I want to be able to select a section of the web page, hit a command, the command opens emacs and I can edit my annotation there. It could save teh page offline in case the page changes. | 17:47 |
| parolang | *the | 17:47 |
| kanzure | okay | 17:48 |
| kanzure | yeah firefox has this "view selection source" feature, so I know it's able to figure out relatively where in the document corresponds to the general region you're clicking in | 17:48 |
| parolang | Yeah. Which is why I think this might be easier in conkeror which uses javascript for scripting. I'll see :) | 17:49 |
| kanzure | I had some complaint about KHTML back in the day | 17:50 |
| kanzure | I forget what it was | 17:50 |
| kanzure | I mean, what I disliked about it | 17:50 |
| kanzure | besides the way the rendered pages look :p | 17:50 |
| parolang | heh :) | 17:51 |
| kanzure | is O(nlog(n)) less or greater than O(n**2)? | 17:52 |
| parolang | Don't know. | 17:52 |
| kanzure | ah looks like it | 17:53 |
| kanzure | er, looks like it's always less than | 17:53 |
| parolang | That would be my guess but don't want to steer you wrong :) | 17:53 |
| kanzure | I think I can do a collision detection algorithm that is O(nlog(n)) | 17:54 |
| kanzure | oops, O(n**(k) * log(n)) where k is the number of parts | 17:55 |
| kanzure | hm wait does that even make sense? | 17:56 |
| kanzure | n**k makes it suck immensely | 17:57 |
| parolang | Sorry but this stuff is over my head :) | 17:57 |
| kanzure | n**k means n multiplied by n except k times of that operation. | 17:58 |
| parolang | Well, I know math. Just not O-notation (what does the n mean?) | 17:59 |
| kanzure | let's say you had a for loop (for each blah in some_list). in this case, n is the length of some_list | 17:59 |
| parolang | And in the collision detector? | 18:00 |
| parolang | I thought n would be the number parts. | 18:00 |
| kanzure | that's correct | 18:00 |
| kanzure | so O(n) would be an absolutely ideal situation | 18:00 |
| parolang | Then what's k? | 18:00 |
| kanzure | but you need to check if parts are intersecting | 18:00 |
| kanzure | well, there's this certain algorithm you can use called k-means | 18:00 |
| kanzure | k-means is a way of clustering up all data points into k clusters by taking the values' means | 18:00 |
| kanzure | then if I have stuff from one part in two different clusters, I know something is fucked up | 18:01 |
| kanzure | with respect to a given threshold value of course that I'll have to tweak | 18:01 |
| kanzure | but if the computational complexity (big o notation) tells me that k-means is going to suck worse than just doing collision detection regularly (which is the O(n**2) method where you compare every part to every other part), why should I bother | 18:01 |
| parolang | ah :) | 18:02 |
| parolang | That's clever. | 18:02 |
| kanzure | if I was thinking more clearly I'd have my answer | 18:02 |
| kanzure | the points that I would cluster would be the vertices in the part models I guess | 18:02 |
| kanzure | minus all vertices involved in mated interfaces | 18:03 |
| kanzure | because in those cases, parts are supposed to be very close to each other :) | 18:03 |
| kanzure | so those vertices shouldn't be considered | 18:03 |
| kanzure | but if there are other clusters of vertices/points that are within the same cluster, then that should be a red flag | 18:03 |
| kanzure | doing this without comparing every point to every other point, or every part to every other part, is key | 18:04 |
| parolang | So you just want to know whether the objects collide, and not when they collide? If you are moving parts around, then you'd want to know the latter. | 18:04 |
| kanzure | that's right | 18:04 |
| kanzure | but in this case I just want to know whether or not adding a part in a certain location will suck | 18:04 |
| parolang | makes sense then | 18:04 |
| kanzure | for path planning, yes, you'd want to detect whether or not the sweep of the part over some path would make it collide with anything | 18:05 |
| kanzure | that would be useful for figuring out whether or not steps can actually be carried out to put something together | 18:06 |
| kanzure | although in some cases you can be pretty sure that anything you can make (per some rules) can be made, like with legos | 18:06 |
| kanzure | as long as you don't violate some laws of physics .. like collision and the whole pauli exclusion principle deal | 18:06 |
| parolang | Okay...you're thinking about the interfacing of parts, right? That is, if it is physically possible for one part to interface with the other part, given the law that they can't coexist in the same space. | 18:06 |
| kanzure | right | 18:06 |
| kanzure | so skdb already has the part interface mating code down | 18:07 |
| kanzure | I even wrote some code to check for the "common" intersection set between two part models | 18:07 |
| kanzure | but this requires you to do O(n**2)-- to run the algorithm for each part against each other part | 18:07 |
| kanzure | the problem is that this "common intersection" takes 2 seconds to compute for each part | 18:07 |
| kanzure | so even if you only have ten or twenty parts, your computer cries | 18:07 |
| kanzure | this is non-ideal :( | 18:07 |
| -!- ybit [n=ybit@unaffiliated/ybit] has quit [Remote closed the connection] | 18:09 | |
| parolang | But isn't there a way you can narrow down the edges and vertices you have to consider? | 18:09 |
| kanzure | the only way I can think of to do that would be to do some proximity testing | 18:10 |
| kanzure | but the way to figure out what's in the local proximity is to scan through the list | 18:10 |
| kanzure | I guess that's O(n) and not as terrible | 18:10 |
| parolang | For what it's worth, it seems to me that there should be some data attached to the part itself that contains the criteria on what kind of parts can fit into it's interfaces. You can save this data with the part so you don't have to generate each time you want to combine it with another part. | 18:13 |
| parolang | Maybe it gets more complicated than what I'm thinking of in my head where this won't work. But determining the criteria might be what takes most of the processing, so this can be "compiled" when the part is first constructed. | 18:15 |
| kanzure | yes parts already have that | 18:15 |
| kanzure | check it out: http://adl.serveftp.org/skdb/packages/lego/data.yaml | 18:16 |
| -!- ybit [n=ybit@unaffiliated/ybit] has joined #hplusroadmap | 18:16 | |
| parolang | So, for instance, a part should be able to say "Whatever part that firts within this solid can interface" with me on this juncture. | 18:16 |
| kanzure | right | 18:16 |
| kanzure | yes mating compatibility for an interface/port is simple | 18:16 |
| kanzure | but what if the part that connects has this weird thing | 18:16 |
| kanzure | that comes back around and goes through the part it just mated to? | 18:16 |
| kanzure | this should generate an error right? | 18:17 |
| kanzure | or what if it collides with another object in the design, too? | 18:17 |
| parolang | I'm having trouble picturing what you're talking about. | 18:18 |
| kanzure | uhrm. | 18:18 |
| kanzure | imagine an assembly with multiple parts | 18:18 |
| kanzure | one of these parts connects properly, but another region of the same part collides with another part in the assembly | 18:19 |
| parolang | Okay, that's clearer. | 18:20 |
| parolang | Yeah, see what you mean. | 18:20 |
| -!- xp_prg [n=xp_prg3@dsl081-249-107.sfo1.dsl.speakeasy.net] has joined #hplusroadmap | 18:20 | |
| parolang | You'd have to recompute the clearance not just for each individual part, but also for each combination of parts. | 18:21 |
| parolang | So you couldn't save it each individual part. | 18:21 |
| kanzure | well in skdb there's a way to figure out which "options" exist | 18:21 |
| kanzure | but maybe collision detection would be used only when you want to try an option | 18:21 |
| kanzure | actually that kind of sucks | 18:21 |
| kanzure | if the detection algorithm is good enough, computing it for the part.options(other_thing) would be nice | 18:22 |
| parolang | It would be nice if there was some way to memoize that collision detection, I think that's all I've added to the discussion :) | 18:22 |
| parolang | I'm overthinking it. It's an interesting problem though. | 18:24 |
| kanzure | you're not overthinking | 18:24 |
| kanzure | actually now that I think about it, | 18:27 |
| kanzure | solidworks has this sort of part mating feature of sorts | 18:27 |
| kanzure | and what they do is totally ignore any collision detection issues | 18:27 |
| kanzure | you can literally mate a part that screws up the rest of the assembly by intersecting oddly | 18:27 |
| kanzure | you can also make screws go through walls, etc. | 18:27 |
| parolang | Hmm. | 18:28 |
| parolang | How does skdb figure out what position can the parts interface at? e.g., what angle; or does the port specify only one angle? | 18:29 |
| kanzure | pixel perfect (or voxel or "bounding box") methods might be a good fall back. it's what's used in most 2D/3D games. plus you can add in a resolution throttle/knob/variable thingy. | 18:29 |
| kanzure | in skdb an interface has an "interface point" or "control point" | 18:29 |
| kanzure | this control point has a vector pointing out of it | 18:29 |
| kanzure | this vector is defined as the mating vector | 18:30 |
| kanzure | if you mean "can an interface be at an angle", yes | 18:30 |
| parolang | I'm thinking in terms of legos here...things get more complicated quickly after that (e.g., materials that can bend, or squish like a sponge). | 18:31 |
| kanzure | if a cylinder in a cylindrical hole has to have a certain rotation, ther'es currently nothing about that at the moment because a cylinder is completely unlabeled | 18:31 |
| kanzure | but it wouldn't be hard to add that in | 18:31 |
| kanzure | so anyway, since the commercial CAD systems don't do collision detection when making assemblies, maybe it doesn't have to be done here either, until "the end" where it can be checked | 18:32 |
| kanzure | and then you'll get a report about what sucks | 18:32 |
| kanzure | one expected use of skdb is generating alternative designs | 18:32 |
| kanzure | so in that case you might be generating hundreds of thousands of bullshit designs that, in the end, are evaluated to be impossible due to collision | 18:32 |
| parolang | :( | 18:32 |
| kanzure | solidworks (etc.) were made with the idea of a person looking at the design at all times I guess | 18:33 |
| kanzure | oh maybe it could be something like this: | 18:33 |
| kanzure | each part has a certain volume | 18:33 |
| kanzure | the total assembly has a certain volume as well (the sum of the volumes of the parts) | 18:34 |
| kanzure | the current BRepAlgoAPI_Common method does O(n**2) to figure out the volume between every part to every other part | 18:34 |
| kanzure | but a better way might be to just take the volume of the entire object and make sure it is within a certain threshold | 18:34 |
| kanzure | in some cases there will be proper interference fits so that has to be taken into account | 18:34 |
| kanzure | but that shouldn't be more than a total that you can count by looking at the assembly | 18:35 |
| ybit | could you please stop talking so you don't f' my logs ;) | 18:35 |
| kanzure | what's wrong with your logs? | 18:35 |
| ybit | (i'm about to reboot again) | 18:35 |
| kanzure | oh | 18:35 |
| kanzure | try getting on adl? | 18:35 |
| ybit | that's an idea | 18:35 |
| kanzure | there's a local copy of irssi | 18:35 |
| ybit | a good one too | 18:35 |
| -!- ybit2 [i=ybit@unaffiliated/ybit] has joined #hplusroadmap | 18:37 | |
| ybit2 | continue on :) | 18:37 |
| parolang | Well, you know if the sum of the volumes of each of the objects is greater than the sum of the objects together in configuration, then you have a collision. Not sure if that's what you're talking about above. | 18:37 |
| kanzure | er I think you're wrong | 18:37 |
| -!- ybit2 [i=ybit@unaffiliated/ybit] has quit [Client Quit] | 18:38 | |
| kanzure | oh, no, that's what I said | 18:38 |
| kanzure | yes | 18:38 |
| kanzure | ybit: it died | 18:38 |
| -!- ybit2 [i=ybit@unaffiliated/ybit] has joined #hplusroadmap | 18:38 | |
| ybit | i realized i hadn't started it in screen, so i restarted | 18:38 |
| parolang | I think CAD programs store solid objects as being composed of geometric primitives (or I think BRLCAD did, when I last looked at it), so it could be easier doing the math this way. | 18:39 |
| kanzure | right, but not all CAD models are made up of primitives unfortunately | 18:39 |
| kanzure | maybe STEP and IGES are, actually | 18:39 |
| kanzure | and in that case I agree that breaking it up into the primitives and just doing primitive collision would be so much easier | 18:40 |
| kanzure | brlcad does do that, yes, that's the "dot g object database" format | 18:40 |
| kanzure | poo poo to stl and dxf | 18:40 |
| -!- ybit [n=ybit@unaffiliated/ybit] has quit [Remote closed the connection] | 18:40 | |
| parolang | :) | 18:40 |
| kanzure | on the todo list in skdb/doc/todo there's a line that mentions coming up with an algorithm to convert from stl and povray into step or iges formats | 18:41 |
| kanzure | povray files are written in a scripting language of sorts, so with the parser from pypovray- if it can be subdued into reading povray files (not just writing them)- then we might have a chance at at least that. | 18:41 |
| kanzure | there's about ~700 lego parts in the povray format in some free lego software package .. but they are unusable because they are in the povray format | 18:42 |
| parolang | Yeah. | 18:43 |
| * parolang googles constraint satisfaction. | 18:44 | |
| kanzure | constraint satisfaction is usually mentioned (in here at least) with respect to geometric constraints on CAD models | 18:45 |
| parolang | Thinking practically about this, collision detection is something that people have been working on for years, so if there's a better way I'm sure someone has found it. Some of the game sites mention bounding boxes, which isn't relevant for this application (I don't think), as bounding boxes are an approximation. You need something exact. | 18:51 |
| kanzure | the problem is that the "exact" method takes a long time | 18:51 |
| kanzure | so approximations like bounding boxes might give enough speed.. | 18:52 |
| kanzure | if I was going to do an approximation, I would probably want to try a voxel grid approach or something | 18:52 |
| kanzure | where a part takes up a certain chunk of 3D space, little tiny boxes | 18:52 |
| kanzure | and then anything else that tries to "register" those same spaces gets the shit whacked out of it | 18:52 |
| parolang | So you fill the part up with voxels? How efficient is that? | 18:53 |
| kanzure | haven't done the calculation. probably not very efficient. | 18:53 |
| kanzure | it would be like doing a riemann integral on the interior of the part's surface or something | 18:53 |
| kanzure | and then registering those voxels in its name | 18:53 |
| parolang | You still have to figure out when the voxel is outside of the part. At least this can be precomputed and stored with the object. | 18:53 |
| kanzure | so yeah not a good idea overall | 18:53 |
| kanzure | right | 18:54 |
| parolang | It seems that filling the part just submitted to the repository with voxels is something that can be done on the repository server when idle. You want it to be fast when someone downloads a part and tries it in their design. | 18:56 |
| kanzure | ewww | 18:57 |
| kanzure | no thank you | 18:57 |
| parolang | I'm saying if a trade off has to be made. I don't know if it has to be or not. | 18:57 |
| kanzure | we'll see with the volume method | 18:58 |
| parolang | good luck | 19:00 |
| kanzure | what are the correct units on torque? | 19:44 |
| kanzure | joule per rad? | 19:45 |
| ybit2 | If you really need the data you'll have to hit the dead tree, I'm | 19:47 |
| ybit2 | afraid. | 19:47 |
| ybit2 | so eugen means google.com/books right? :) | 19:48 |
| kanzure | N*m =~ lbf * feet | 19:49 |
| parolang | Newton meter (N*m) according to Wikipedia. | 19:50 |
| kanzure | there's also a "wrong" torque that people like to use | 19:50 |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 148 (No route to host)] | 19:52 | |
| parolang | kanzure: You've been modded troll and some smartass gets modded up for giving you sarcasm. | 19:54 |
| -!- xp_prg [n=xp_prg3@dsl081-249-107.sfo1.dsl.speakeasy.net] has quit ["This computer has gone to sleep"] | 19:56 | |
| kanzure | aw :( | 20:00 |
| kanzure | well I'm probably a troll anyway | 20:00 |
| kanzure | rawr! | 20:00 |
| parolang | I corrected the error :) | 20:01 |
| parolang | Although...I've never used 450 tabs either :) | 20:01 |
| parolang | But...with recursive searching, you could easily go over 50. | 20:01 |
| parolang | But, ultimately, the userbase of slashdot has changed. | 20:02 |
| parolang | There used to be a lot more core Unix people, but most of them have all left, and now it's filled with Mac fanboys. | 20:03 |
| kanzure | it's weird now. I was late to show up on slashdot, | 20:04 |
| kanzure | but even when I did back in 2006 or 2007, it wasn't this bad | 20:04 |
| kanzure | now it seems that everyone wants to hate on RMS | 20:05 |
| kanzure | even though nobody knows him :p | 20:05 |
| parolang | I think the issue is with the lack of quality of slashdot articles, lots of dupes, poor summaries, and general flamishness. | 20:05 |
| parolang | So the people who used to frequent have all left. | 20:06 |
| kanzure | class II theta is interesting | 20:09 |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap | 20:19 | |
| kanzure | does anyone know the name and group who did the remix of the blue oyster cult song used in the 2010 lincoln mks commercial? | 20:33 |
| kanzure | http://www.lincoln.com/extras/tvads.asp?id=7&intcmp=B_FreeSongDownload_MKZHome_LincolnTVAds_20090408 | 20:33 |
| -!- any41308722 [n=someone@75-120-26-209.dyn.centurytel.net] has joined #hplusroadmap | 20:33 | |
| -!- katsmeow-afk [n=someone@75-120-45-160.dyn.centurytel.net] has quit [Nick collision from services.] | 20:35 | |
| -!- any41308722 is now known as katsmeow | 20:35 | |
| -!- davidnunez [n=davidnun@209-6-203-217.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [] | 20:36 | |
| -!- nchaimov [n=cowtown@c-24-21-45-17.hsd1.wa.comcast.net] has quit [] | 20:39 | |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 60 (Operation timed out)] | 20:39 | |
| -!- davidnunez [n=davidnun@209-6-203-217.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #hplusroadmap | 20:51 | |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap | 21:33 | |
| ybit2 | fenn_adl, kanzure: did either of you try using occ .deb? | 21:49 |
| kanzure | http://adl.serveftp.org/dokuwiki/occ | 21:51 |
| kanzure | http://adl.serveftp.org/dokuwiki/pythonocc | 21:51 |
| kanzure | you'll see that on the top of the pythonocc page in the instructions there's an apt-get call | 21:51 |
| kanzure | if you're asking whether or not it worked, the answer is yes :) | 21:51 |
| genehacker | http://www.physorg.com/news171034413.html | 22:15 |
| genehacker | this sounds very fishy | 22:15 |
| -!- xp_prg [n=xp_prg3@208.54.15.112] has joined #hplusroadmap | 22:19 | |
| CIA-32 | skdb: kanzure * r ccace42 /doc/ (lists/adesign-library.yaml todo): adesign library component list | 22:23 |
| CIA-32 | skdb: kanzure * r c021c3b / (core/interface.py geom/geom.py): functions to determine whether or not an added part collides unwantedly. see estimate_collision_existence in geom/geom.py | 22:23 |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has quit [Read error: 60 (Operation timed out)] | 22:26 | |
| ybit2 | the suzanne gilbert talk which was forwarded to tt Quantum Computers and the creation of human-level artificial intelligence - Uploading Schrodinger's Cat?!... will be recorded and the annoucement of the upload will be on the ExtroBritannia list | 23:07 |
| katsmeow | transcript? | 23:07 |
| ybit2 | dunno estropico@gmail.com might know though | 23:07 |
| ybit2 | he's the person whom told me he heard/read or found out somehow just a few hours ago | 23:08 |
| katsmeow | i broke Google again: | 23:09 |
| katsmeow | Results 1 - 10 of about 26,500 for suzanne gilbert talk which was forwarded to tt Quantum Computers and the creation of human-level artificial intelligence. (0.37 seconds) | 23:09 |
| katsmeow | Search ResultsMichigan Channel: Channel 22: Search Results for “um” | 23:09 |
| katsmeow | "um" ? | 23:09 |
| ybit2 | :) | 23:09 |
| -!- genehacker [n=noko@pool-173-57-48-104.dllstx.fios.verizon.net] has joined #hplusroadmap | 23:13 | |
| kanzure | >>> geom.shape_volume(box1.Shape()) | 23:19 |
| kanzure | 1000.0000000000001 | 23:19 |
| kanzure | >>> geom.shape_volume(box2.Shape()) | 23:19 |
| kanzure | 1000.0000000000001 | 23:19 |
| kanzure | >>> geom.shape_volume(fused_shape) | 23:19 |
| kanzure | 1000.0000000000001 | 23:19 |
| kanzure | where: box1 = BRepPrimAPI_MakeBox(gp_Pnt(0,0,0), gp_Pnt(10,10,10)) | 23:20 |
| CIA-32 | skdb: kanzure * r 1047d2e /unittests/test_geom.py: test fused shape volumes and shape_volume function in geom/geom.py | 23:28 |
| fenn | ok what if you move one cube to the side a bit | 23:29 |
| fenn | and how long does it take to calculte that? | 23:29 |
| kanzure | it doesn't take long at all as it is right now | 23:31 |
| kanzure | but we don't know how long it takes to calculate the BRepAlgoAPI_Common of two boxes either | 23:32 |
| kanzure | it might be that custom brep models take longer across the board | 23:32 |
| kanzure | or BRepAlgoAPI_Common sucks | 23:32 |
| CIA-32 | skdb: kanzure * r e900647 /unittests/ (test_part.py test_transformation.py): cleaning up some tests | 23:33 |
| kanzure | is there some profiling module in python that you prefer? | 23:34 |
| CIA-32 | skdb: kanzure * r 7a8b75f /geom/ode_collider.py: ode collider link | 23:35 |
| kanzure | http://pyode.sourceforge.net/tutorials/tutorial3.html | 23:36 |
| -!- tropology [n=michael@adsl-68-255-98-211.dsl.chcgil.ameritech.net] has quit [] | 23:40 | |
| kanzure | uhrm... what? | 23:41 |
| kanzure | for box 0,0,0..10,10,10 and box 5,5,5..15,15,15, the fused volume is 1875.0 | 23:42 |
| kanzure | I should probably do something I can mentally check | 23:42 |
| kanzure | AssertionError: 125.00000000000001 != 125.0 | 23:47 |
| kanzure | fenn: http://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions | 23:59 |
| kanzure | http://en.wikipedia.org/wiki/Time_complexity | 23:59 |
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!