| 00:00.09 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 00:00.09 | Ralith | a model of one of those would be pretty neat too. |
| 01:25.36 | *** join/#brlcad JoanW (n=5b698faa@bz.bzflag.bz) |
| 01:47.04 | *** join/#brlcad samrose (n=samrose@oh-69-69-33-40.sta.embarqhsd.net) |
| 02:11.19 | *** join/#brlcad dreeves (n=dreeves@67.130.253.14) |
| 02:13.08 | dreeves | I sent the patch to you brlcad I will work on pushing it to sf but I was having problems so decided to be lazy for now |
| 02:13.18 | dreeves | and send it directly to you |
| 02:23.27 | dreeves | ok got it submitted to sourceforge |
| 02:34.35 | brlcad | nice, just saw it |
| 02:35.09 | brlcad | didn't get anything direct though (at least not yet |
| 02:35.29 | brlcad | but no matter, I see the tracker |
| 02:44.02 | *** join/#brlcad dreeves_ (n=IceChat7@67.130.253.14) |
| 03:02.40 | starseeker | <snort> they're already offering discounts to try and get people to come to SIGGRAPH 2009 |
| 03:03.11 | starseeker | <sarcasm>wonder if perhaps they're worried about the economy...</sarcasm> |
| 03:13.54 | dreeves | Sorry about that I guess I should have spent a little more effort figuring it out |
| 03:13.55 | bjorkintosh | are SIGGRAPH papers any good? |
| 03:15.22 | dreeves | there is still room for improvement on the performance. Actually lost 15% somewhere on the end maybe something for later... |
| 03:16.49 | dreeves | probably move on to the NURBS stuff I suppose...although I think that is quite abit more involved. |
| 03:22.53 | starseeker | bjorkintosh: yesh |
| 03:22.55 | starseeker | er yes |
| 03:23.25 | starseeker | all conferences will have ups and downs in paper quality, but SIGGRAPH has lots of very good papers |
| 03:34.08 | bjorkintosh | really? |
| 03:48.16 | *** join/#brlcad ashishrai (i=d2d43dfb@gateway/web/ajax/mibbit.com/x-39632265f0993dad) |
| 06:31.03 | *** join/#brlcad ewilhelm_ (n=ewilhelm@pool-71-111-78-159.ptldor.dsl-w.verizon.net) |
| 07:13.50 | *** join/#brlcad madant (n=madant@117.196.133.86) |
| 07:21.29 | madant | slept for 15 hours straight :O |
| 08:19.29 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 09:24.10 | *** join/#brlcad madant (n=madant@117.196.142.174) |
| 09:51.15 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:00.17 | madant | howdy mafm |
| 10:55.36 | d-lo | Morning all. |
| 10:55.56 | d-lo | Bad traffic + thick fog = scary drive :/ |
| 10:59.53 | madant | does not have a driving license :P |
| 11:00.11 | *** join/#brlcad mafm_ (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 11:08.02 | d-lo | Hrm, lemme think: Bad traffic + thick fog + no license = even scarier!!! |
| 11:22.03 | *** join/#brlcad _sushi__ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 11:28.52 | madant | d-lo: :P true |
| 11:30.01 | *** join/#brlcad ashishrai (i=d2d43dfb@gateway/web/ajax/mibbit.com/x-cdc87fe2db0fc4ac) |
| 11:35.46 | mafm_ | hi |
| 11:40.14 | madant | hey :) |
| 11:41.30 | madant | freaky way to do pull-ups :p http://www.crossfit.com/mt-archive2/Queens-Palace-Pullup.html |
| 11:42.44 | d-lo | Just goes to show how well proper incentive can motivate! |
| 11:45.26 | d-lo | This one looks strangely familiar...... http://www.crossfit.com/mt-archive2/crossfit-AnzioAnnie.html ;) |
| 11:47.04 | brlcad | it'd be a lot more impressive if he was doing them off the barrel tip :) |
| 11:47.44 | d-lo | True, but with photoshot, anything is possible! :) |
| 11:47.46 | brlcad | thick fog + rowing = eerie cool row :) |
| 11:48.01 | d-lo | Yeah, i was wonding about that on the drive in :) |
| 11:48.18 | brlcad | fortunately not all the crews have started so the traffic was pretty low |
| 11:48.26 | madant | :D |
| 11:48.42 | d-lo | nice. Do you compete or is it just for the halibut? |
| 11:48.45 | brlcad | it can get very scary |
| 11:48.58 | brlcad | I compete |
| 11:49.13 | brlcad | do ocd and competitive to just paddle about |
| 11:50.24 | madant | has a backwater district nearby :) |
| 11:50.31 | d-lo | On a somewhat related note, i found out that my Patriot can corner VERY well :) 90 degree curve came up on me a bit suddenly and I had to take it a bit faster than I wanted :) Stiff suspension FTW. |
| 11:50.49 | d-lo | "every thing I know about performance driving I learned from Top Gear" :) |
| 11:51.14 | brlcad | is starving |
| 11:51.36 | brlcad | madant: those look like fun pull-ups actually |
| 11:51.56 | brlcad | I can see doing that |
| 11:52.24 | madant | yeah i mean height really doesnt matter ;) but a nice pic nevertheless :) |
| 11:53.01 | madant | I can do 20 .. ok 19 :P |
| 11:53.27 | madant | though not confident about 20 at that height :) |
| 11:54.04 | brlcad | hehe, nice .. http://www.torch.aetc.af.mil/shared/media/photodb/photos/061228-F-1936B-010.JPG |
| 11:54.55 | d-lo | lol\ |
| 11:55.36 | d-lo | brlcad: If you can get to see the most recent Top Gear (the one where the road test the Ford Fiesta) then you really REALY should. |
| 11:56.09 | d-lo | I laughed my throat raw. That Humvee pic reminded me of it btw :) |
| 11:57.18 | madant | yikes.. :) |
| 12:03.00 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 12:18.41 | CIA-40 | BRL-CAD: 03indianlarry * r34055 10/brlcad/trunk/src/other/step/src/ (4 files in 4 dirs): Added standard C++ library via LIBSTDCXX variable to build where needed. |
| 12:35.23 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 14:40.21 | *** join/#brlcad ashishrai (i=d2d43dfb@gateway/web/ajax/mibbit.com/x-df09e762b5abd51c) |
| 14:53.27 | brlcad | madant: woot, top 20 :) |
| 14:54.33 | madant | huh / |
| 14:56.15 | brlcad | https://www.ohloh.net/p/brlcad/contributors |
| 14:57.42 | madant | :) aah.. it is going to get better ;) |
| 14:58.25 | madant | am sure i would have been way lower if they didn't only count number of commits :D |
| 14:59.55 | brlcad | I've been wanting to do some mega visualization at some point |
| 15:02.06 | madant | mega visualization ;) ? |
| 15:04.28 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 15:15.01 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 15:22.53 | *** join/#brlcad piksi (i=piksi@pi-xi.net) [NETSPLIT VICTIM] |
| 15:25.01 | *** join/#brlcad CIA-40 (n=CIA@208.69.182.149.simpli.biz) [NETSPLIT VICTIM] |
| 15:27.36 | dreeves | how does the stuff work we submit as a patch? Does it get included in the next release or is somewhat unknown because someone needs to make time to look it over? |
| 15:32.11 | *** join/#brlcad ``Erik__ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 15:36.41 | madant | dreeves: depends on the type of patch i guess.. mostly it gets added to the trunk pretty fast once someone has a look at it .. some need a lot of regression tests and might take longer.. if the person submitting the patch has been given commit access then he is given the right to close the patch tracker as well.. brlcad would obviously be able to clarify all this better :) |
| 15:46.49 | dreeves | no big I was just curious if there was a formal process or if it was just somewhat loose. I think what I submitted is fairly low priority because I would guess not many people are using that feature. Also it is just a performance improvement. |
| 15:51.57 | *** join/#brlcad ``Erik___ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:00.35 | brlcad | madant, yeah visualization kinda like the code storm, but actually somewhat more practical :) |
| 16:01.30 | brlcad | dreeves: the latter, one of the existing devs takes the time to review and test/evaluate the patch |
| 16:04.33 | brlcad | yeah, basically what madant said -- it's not at all a formalized process very much intentionally |
| 16:06.47 | brlcad | highly formalization in open source projects is often a sign of a dying project, most operate under meritocratic and high-iteration agile practices (or at least gravitate towards them) |
| 16:07.29 | dreeves | Yeah I'm not a big fan of very formalized process at all |
| 16:07.49 | dreeves | good way to bring a project to it's knees |
| 16:07.52 | brlcad | that said, yeah, your patch isn't what I'd call "high-priority" but it's actually very important because it's from a new contributor :) |
| 16:08.06 | dreeves | :) |
| 16:08.37 | brlcad | and it's not just a performance improvement, it's a _substantial_ performance improvement |
| 16:08.40 | brlcad | :) |
| 16:09.25 | dreeves | I think there is still room for more improvement but I want to get on to the high priority stuff I really just did that get warmed up |
| 16:10.31 | dreeves | I didn't want to start with something where I was trying to get familiar with what was what at the same time as tackling a tough problem i.e. NURBS |
| 16:10.52 | brlcad | nods |
| 16:11.53 | madant | brlcad: hmm.. yeah it would be fun .. information visualization is always nice |
| 16:26.43 | *** join/#brlcad ``Erik___ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 16:30.31 | brlcad | dammit, sf.net is down right as I submit |
| 16:30.50 | brlcad | ~ping sourceforge.net |
| 16:30.51 | ibot | pong sourceforge.net |
| 16:34.30 | brlcad | there we go |
| 16:35.29 | d-lo | <PROTECTED> |
| 16:35.30 | ibot | pong sourceforge.net |
| 16:35.44 | d-lo | ~google |
| 16:35.45 | ibot | hmm... google is at http://www.yahoo.com |
| 16:35.55 | brlcad | ~d-lo is a BRL-CAD developer |
| 16:35.56 | ibot | brlcad: okay |
| 16:36.05 | brlcad | ~d-lo |
| 16:36.06 | ibot | hmm... d-lo is a BRL-CAD developer |
| 16:38.19 | dreeves | didn't mean to include that other stuff I forgot about messing around that |
| 16:41.52 | dreeves | actually only 3 files should have been in there |
| 16:43.15 | *** part/#brlcad ewilhelm (n=ewilhelm@pool-71-111-78-159.ptldor.dsl-w.verizon.net) |
| 16:47.00 | brlcad | dreeves: I know, it was obvious |
| 16:47.00 | brlcad | i wouldn't have even mentioned it save for the other issues |
| 16:47.00 | brlcad | all minor, but patch acceptance generally puts it in the submitter's hands to fix it so the issues are resolved earlier instead of later |
| 16:47.01 | brlcad | (as the goal is to give commit) |
| 16:49.06 | dreeves | absolutely yeah don't let me slide on anything I want comply no problem |
| 16:49.35 | starseeker | A bat hanging on to the space shuttle as it launches... awesome :-) |
| 16:49.43 | dreeves | I tried to follow the style but obviously hasn't been the style I have been follow as of late so habits and such |
| 16:50.26 | dreeves | So do I just re attach a new patch or is it a new submit altogether |
| 16:51.08 | dreeves | btw it is only 3 files |
| 16:53.13 | d-lo | Hrm, if a small peice of foam can cause a catastrophic loss of the orbiter.... i wonder what fate that bat has condemned them to? :/ |
| 16:54.41 | dreeves | I'm sure the "small" piece of foam was considerably larger than the bat |
| 16:55.45 | dreeves | was the brace style the only thing you noticed when reviewing the code? |
| 16:55.47 | starseeker | yeah, no one is worried that the bat will cause launcher damage |
| 16:56.35 | starseeker | wonders if there is a bat version of the Darwin award... |
| 16:56.51 | dreeves | However I pretty sure the bat didn't make it |
| 16:57.08 | d-lo | Dunno, sounds like the basis for Samuel Jacksons next movie: Bats on a Shuttle... |
| 16:59.13 | brlcad | dreeves: not a problem .. there are probably four distinct styles throughout the brl-cad sources -- just try to police new code and hit up files for consistency as they are worked on |
| 16:59.39 | brlcad | most of the files have issues, it'd takes many weeks of tedium to hit up everything (it can only partially be automated) |
| 17:00.13 | dreeves | ok no problem |
| 17:00.14 | brlcad | dreeves: braces was the only stylistic thing I noticed that mattered |
| 17:01.08 | brlcad | the other stylistic changes are not worth policing unless someone specifically wants to go on a rampage |
| 17:01.41 | dreeves | I was trying to follow the correct style but in my day job I use the other style so I will need to get the settings in my editor so I don't forget |
| 17:01.42 | brlcad | or is just egregiously annoying like spaces before commas |
| 17:01.50 | brlcad | nods |
| 17:01.56 | brlcad | I use the other style on a few other projects |
| 17:02.04 | dreeves | hey the 30 setting that should should have been 64 |
| 17:02.05 | brlcad | some people have religion on one vs the other |
| 17:02.20 | brlcad | to me, it's just more important that the code is consistent |
| 17:02.46 | dreeves | Yeah I'm not religious on that kind of stuff would rather spend my energy on more useful things |
| 17:02.54 | brlcad | minimally per-file consistent, ideally globally consistent (sans src/other) |
| 17:02.56 | dreeves | yes I agree |
| 17:03.54 | dreeves | that setting was in the bezier_2d_isect.c before but if I'm to pre allocate the buffers then the setting needs to come from extude.c |
| 17:05.48 | dreeves | I tried to think of a way to get rid of it all together but at the time I was tired (no sleep in 30+ hours) and I couldn't think of anything. So I gave in a moved the setting to extude.c and passed into bezier_2d_isect.c |
| 17:07.02 | dreeves | I was just messing around and wanted to see what it would like like if I changed the setting to 30 vs 64. Didn't make much of an impact on either. I'm sure it would with a more complex shape |
| 17:10.52 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 17:15.02 | brlcad | yeah, it sounds like the maximum number of intersects through the sketch |
| 17:15.11 | brlcad | just at a quick glance |
| 17:15.22 | brlcad | if that's true, even 64 is kinda sketchy (no pun intended) |
| 17:15.41 | brlcad | some simple grided sketch would blow out the limit |
| 17:19.33 | dreeves | no i don't think that is what that number is |
| 17:20.20 | dreeves | I think that is the number of times to subdivide the curve in order to resolve down to a single segment of the curve to find the particular intersection |
| 17:26.09 | *** join/#brlcad madant (n=madant@117.196.144.14) |
| 17:26.10 | brlcad | ah, hm |
| 17:26.33 | brlcad | then that sounds particularly asinine |
| 17:26.52 | brlcad | especially if it has a ton of control points |
| 17:27.08 | brlcad | unless that's between each pair of control points |
| 17:28.19 | brlcad | probably should be based adaptive based on the amount of curvature in a given piecewise region |
| 17:30.12 | dreeves | yeah checks the curvature |
| 17:31.01 | dreeves | it tries to subdivide to get down to little or no curvature but at some point it stops which the maxlevel setting |
| 17:33.18 | dreeves | let me restate |
| 17:34.53 | brlcad | aha.. so then after a given minimized curvature, it then performs MAXDEPTH samples of that piece |
| 17:34.57 | brlcad | that's not so bad then |
| 17:35.11 | brlcad | probably even overkill depending on that curvature setting |
| 17:35.36 | dreeves | exactly that is why I was playing around with the number a little |
| 17:36.09 | dreeves | no I misspoke |
| 17:36.19 | dreeves | I was saying exactly to the overkill part |
| 17:36.40 | dreeves | but the algorithm doesn't exactly work that way |
| 17:38.06 | dreeves | it divides the control polygon down to attempt to consider a single segment of the polygon but it also looks at curvature to make sure it is only considering a case where the ray will only cross that segment once |
| 17:38.40 | dreeves | if the curvature is not "flat" enough it will continue to subdivide |
| 17:40.26 | dreeves | however it gives on continuing to subdivide if it reaches the max subdivides |
| 17:41.30 | dreeves | the is actually no limit on how far it will subdivide |
| 17:41.56 | dreeves | it only consider the depth after it has gotten to a single segment of the control polygon |
| 17:42.42 | dreeves | I can imagine some situations that could cause it problems but I think they are pretty extreme |
| 17:44.43 | dreeves | If I right I think control polygons 2 to 32nd power is where you will see the algorithm start to have problems. Well maybe a few powers lower but in that area |
| 17:45.43 | dreeves | no actually 64th power |
| 17:53.33 | dreeves | Hope what I wrote makes since here reading backup I realize I'm dropping words... |
| 17:54.16 | dreeves | Of course I could be completely off track but that is what I think is going on |
| 18:01.14 | *** join/#brlcad ashish (i=d2d43dfb@gateway/web/ajax/mibbit.com/x-f77d495992c1e9eb) |
| 18:22.29 | *** join/#brlcad madant_ (n=madant@117.196.133.222) |
| 18:24.04 | brlcad | dreeves: you could toss in a zero-tolerance check on the polygon points -- if they're all within computation tolerance, halt |
| 18:43.47 | *** join/#brlcad BigATo1 (n=BigAToo@pool-96-230-124-87.sbndin.btas.verizon.net) |
| 18:56.57 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 19:09.54 | CIA-40 | BRL-CAD: 03bob1961 * r34056 10/brlcad/trunk/src/librt/shoot.c: Modified rt_res_pieces_clean() to skip uninitialized rt_piecestate structures. |
| 19:47.23 | *** join/#brlcad cad58 (n=c752f349@bz.bzflag.bz) |
| 19:58.55 | *** join/#brlcad andrecastelo (n=chatzill@201008160086.user.veloxzone.com.br) |
| 20:04.37 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 20:07.33 | *** join/#brlcad dreeves (n=c752f349@bz.bzflag.bz) |
| 20:09.27 | dreeves | brlcad had to go to the office after my comments so I didn't see what you wrote a response if anything |
| 20:30.39 | *** join/#brlcad kanzure (i=bryan@66.112.232.233) |
| 20:31.06 | kanzure | considers working on a project listed on http://brlcad.org/wiki/Google_Summer_of_Code/2009/Project_Ideas |
| 20:42.15 | *** join/#brlcad piksi (i=piksi@pi-xi.net) |
| 20:42.18 | *** join/#brlcad madant (n=madant@117.196.130.208) |
| 21:03.04 | brlcad | ah, dreeves left |
| 21:03.06 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-236-246.dclient.hispeed.ch) |
| 21:03.07 | brlcad | kanzure: glad to hear it! |
| 21:06.29 | kanzure | brlcad: Should I just submit a project proposal, or how does this work? |
| 21:10.57 | madant | congrats :) |
| 21:19.51 | madant | hmm.. and they have changed the timeline as brlcad predicted :D |
| 21:21.33 | brlcad | kanzure: discussion |
| 21:22.19 | brlcad | what do you want to work on? why? who are you? (the 2cent gist version) why do you want to work on brl-cad, what are your goals, etc |
| 21:22.34 | brlcad | madant: :) |
| 21:25.08 | madant | next 10 days are going to be fun on the channel and mailing list :) |
| 21:29.18 | madant | brlcad: gsoc blog says "larger student peer groups in each project" ;) |
| 21:41.43 | kanzure | hm, it's entirely possible that you guys don't remember me :) |
| 21:41.46 | kanzure | http://heybryan.org/om.html |
| 21:42.06 | kanzure | http://heybryan.org/~bbishop/docs/gears/gears.html |
| 21:42.43 | kanzure | interchangeable/intercompatible parts and automatic instruction generators, researcher here at the Automated Design Lab at UT Austin :-) |
| 21:43.45 | kanzure | so in particular I'd probably end up working on the parametric library or web thingy for design repository, in particular my background has been in open source hardware design packaging (much like "dot deb" and "dot rpm" files except, uh, for hardware) |
| 21:45.57 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-87.sbndin.btas.verizon.net) |
| 21:47.36 | kanzure | some stuff I've recently been doing (sadly, it's not with BRLCAD): http://heybryan.org/books/Manufacturing/pythonocc/2009-03-15_3.png |
| 21:50.23 | *** join/#brlcad samrose (n=samrose@oh-69-69-33-40.sta.embarqhsd.net) |
| 21:51.47 | brlcad | oh yeah, I guess I didn't announce it here yet :) |
| 21:51.51 | brlcad | we made it into gsoc 2009 |
| 21:52.11 | brlcad | hurrahs |
| 21:52.35 | kanzure | http://heybryan.org/bioreactor/membraneless_filtration/2009-03-18_spiral.jpg (warning: face) |
| 21:52.43 | kanzure | brlcad: remember my work on spirals? |
| 21:52.45 | kanzure | :) |
| 21:52.51 | kanzure | now this just needs to be tested in real life. |
| 21:53.02 | brlcad | <PROTECTED> |
| 21:53.13 | kanzure | DNS-wise? |
| 21:53.30 | brlcad | hah, yes |
| 21:53.35 | brlcad | resolves to 127.0.0.1 |
| 21:53.47 | _sushi_ | resolves to 127.0.0.1 too |
| 21:54.02 | kanzure | http://66.112.232.182/bioreactor/membraneless_filtration/2009-03-18_spiral.jpg (warning: face) |
| 21:54.05 | kanzure | try that? |
| 21:54.24 | brlcad | kanzure: and to answer your question, I did remember the name, just not the connection |
| 21:54.29 | kanzure | okay |
| 21:56.21 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 21:56.31 | brlcad | madant: hm, that's actually an interesting quote on the blog .. have to talk to lh about it |
| 21:57.52 | brlcad | bz's going to test almost the exact opposite mentoring-wise as our experience indicated that we needed fewer students in order to better engage them |
| 21:58.03 | madant | kanzure: what does pythonocc do ? |
| 21:58.04 | brlcad | probably just that there's a sweet spot that orgs have to find |
| 21:58.08 | kanzure | do mentoring organizations have a minimum team size? |
| 21:58.16 | brlcad | nope |
| 21:58.17 | kanzure | madant: pythonOCC == python bindings to OpenCASCADE |
| 21:58.20 | kanzure | http://pythonocc.org/ |
| 21:58.24 | madant | ah.. :) |
| 21:58.32 | kanzure | so I was just putting together pythonOCC + the HeeksCAD interface together |
| 21:58.35 | kanzure | since they both use wxWidgets |
| 21:59.43 | madant | k.. opencascade is pretty neat ;) |
| 22:00.03 | kanzure | but the API *sucks*. I mean, coming from the perspective of trying to figure out how to write a simpler wrapper for it, or something, it's just huge and hairy |
| 22:00.12 | brlcad | thinks they still fail the freeness test |
| 22:00.26 | brlcad | open yes, just not free |
| 22:00.33 | archivist | kanzure, author of HeeksCAD often is in #cam |
| 22:00.42 | kanzure | archivist: thank you for the heads up |
| 22:01.06 | madant | freeness maybe :) but not many CAE tools in open source scene otherwise right ? |
| 22:01.08 | kanzure | brlcad: apparently they are changing their licensing actually |
| 22:01.35 | brlcad | they've said that for a couple years |
| 22:01.39 | kanzure | oh :( |
| 22:01.58 | brlcad | and they did tweak it once about two years ago, as it was originally entirely ambiguous |
| 22:02.35 | madant | they had BRL-CAD in one of their CDs or something if i remember correctly ? |
| 22:02.45 | brlcad | did they? |
| 22:02.48 | brlcad | that'd surprise me |
| 22:02.50 | kanzure | why? |
| 22:02.56 | kanzure | I mean, why would they put it on? |
| 22:02.58 | brlcad | or at least be news to me |
| 22:03.21 | madant | let me see :) |
| 22:03.27 | kanzure | we were hoping that pythonocc would make it into gsoc, but that didn't happen this year |
| 22:03.37 | kanzure | but brlcad is a good alternative, heh |
| 22:03.47 | brlcad | I'm all for competition and collaboration, but that project has just smelled bad from the beginning |
| 22:05.12 | brlcad | seemed more of a failed commercial attempt that was dumped onto a website with an "Open" label slapped onto it in order to try to attract some business, then when that didn't work, they kept tweaking the license to try to actually open it up "just enough" to get some revenue through providing commercial API support |
| 22:05.13 | madant | ah maybe it was the CAELinux dvd :) |
| 22:05.21 | kanzure | the giant DVD library? :) |
| 22:06.01 | kanzure | ah, what I think I meant to say was that OpenCASCADE recently became "open" and "free" enough to warrant debian packaging and inclusion into the main repositories |
| 22:06.05 | brlcad | i could be completely wrong in that perception, but i was pretty excited to try and join our geometry engines several years back only to be sorely disappointed on many fronts |
| 22:06.09 | kanzure | (6.3.0 hit the repositories last week) |
| 22:06.27 | kanzure | brlcad: can you describe what happened on that front in particular? |
| 22:07.58 | brlcad | kanzure: well part of what I just mentioned, that their entire intentions haven't felt like they're with any actual regard or interest with F/OSS development of CAD |
| 22:08.02 | madant | hmmm opencascade in debian and not in non-free ? i remember somebody was trying to package salome and opencascade a year ago.. |
| 22:08.34 | kanzure | things that sound interesting: 1.3, 1.7, 1.10, 2.8 (from the wiki page) |
| 22:08.38 | brlcad | doing only the minimum they can get away with to conjure up business, not being open to the community at large |
| 22:08.47 | kanzure | brlcad: no, I mean the joining of the geometry engines :) |
| 22:08.54 | kanzure | sorry for the ambiguity |
| 22:08.59 | brlcad | I mean that too |
| 22:09.13 | kanzure | oh |
| 22:09.15 | brlcad | there's no technical discussion to be had if there are legal issues and project management issues |
| 22:09.28 | kanzure | were their headers weird or something? |
| 22:09.29 | kanzure | ah, I see. |
| 22:09.40 | madant | brlcad: news coming up at main page ;) ? |
| 22:10.17 | brlcad | their license originally was completely proprietary iirc, the only thing "open" about them was that you could get the source code (but you couldn't redistribute) and they had the word "Open" in their name |
| 22:10.29 | brlcad | madant: mailing list first, but yeah |
| 22:10.33 | brlcad | probably later today |
| 22:11.11 | kanzure | where is the brlcad-devel mailing list located? is it on the sf.net server? |
| 22:11.17 | brlcad | yes, sf |
| 22:11.58 | kanzure | http://lists.sourceforge.net/lists/listinfo/brlcad-devel |
| 22:11.59 | kanzure | aha |
| 22:13.58 | louipc | heh opennurbs seems kind of closed when it comes to the community too |
| 22:14.07 | Ralith | yay, gsoc! |
| 22:15.04 | madant | hey Ralith, howdy |
| 22:15.14 | Ralith | hullo |
| 22:15.31 | kanzure | louipc: isn't that the blender module? |
| 22:16.01 | Ralith | so I know we've got plenty of engs in here |
| 22:16.08 | Ralith | anyone have any thoughts on the hp50g calculator? |
| 22:16.42 | kanzure | huh, you guys were solving constraint satisfaction problems with graphs |
| 22:16.44 | Ralith | I discovered my ti-89's not talking with my computer anymore. |
| 22:16.47 | madant | has never used a graphing calculator :D |
| 22:16.57 | kanzure | has done some work on graph grammars for graph-based design automation. |
| 22:17.08 | kanzure | http://brlcad.org/wiki/Libpg_:_A_parametrics/constraint_library |
| 22:17.12 | louipc | kanzure: no that's the rhino 3d nurbs library |
| 22:17.14 | louipc | http://www.opennurbs.org/ |
| 22:17.31 | madant | kanzure: graphs .. well my initial idea was that bgl would be useful.. but now i think maybe not.. |
| 22:17.44 | kanzure | bgl? |
| 22:18.03 | madant | boost graph library |
| 22:18.10 | kanzure | so, our lab uses software called "GraphSynth" |
| 22:18.17 | kanzure | it's a graph grammar solver for engineering problems, more or less |
| 22:18.28 | madant | boost's hypergraph support the last time i checked was not that great.. |
| 22:18.29 | kanzure | one student is doing gear-based automated design and optimization, another is doing linkages, and another is doing product disassembly |
| 22:18.41 | louipc | kanzure: brl-cad requires opennurbs |
| 22:18.45 | kanzure | so it might be interesting to integrate the graph functionality into libpg |
| 22:19.15 | madant | kanzure: what exactly do u mean by graph functionality ? |
| 22:19.19 | archivist | hmm gears |
| 22:19.31 | kanzure | archivist: did you see the link? |
| 22:19.49 | kanzure | http://heybryan.org/~bbishop/docs/gears/gears.html |
| 22:20.10 | kanzure | madant: I mean the graphsynth classes for the representation of graphs, generating thousands of solutions for a given graph, and so on |
| 22:20.37 | kanzure | (just the other day we were generating a thousand 'design solutions' from a given 'specification graph' (these aren't the actual terribly convoluted names they have, but that's what they are)) |
| 22:20.51 | madant | :) |
| 22:21.06 | madant | just checking out the graphsynth page |
| 22:21.45 | kanzure | think of it as a search-and-replace system that goes through the entire tree of possible substitutions given a set of 'replace rules' (a "rule set") |
| 22:22.02 | louipc | those are some funky gears |
| 22:22.07 | kanzure | it's a hack to glxgears :) |
| 22:22.29 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 22:22.43 | kanzure | I was going to write a gear visualizer/CAD-generator with pythonocc |
| 22:22.49 | Ralith | there's a cool xscreensaver module that generates very (infinitely?) long serieses of properly interlocking gears |
| 22:22.54 | kanzure | but I haven't got around to that yet |
| 22:23.00 | madant | hmm. and the design is effectively a 'configuration' expressed in XML ? |
| 22:23.02 | kanzure | Ralith: oh? I've never seen that, is that in the standard X11 package? |
| 22:23.05 | kanzure | madant: yes |
| 22:23.08 | Ralith | no idea |
| 22:23.13 | Ralith | it might not even be on my system |
| 22:23.21 | archivist | glxgears |
| 22:23.23 | kanzure | Ralith: ah, maybe it's in the xscreensaver package (sorry, didn't read) |
| 22:23.24 | Ralith | I always set my screensavers to random, so I can't help beyond that |
| 22:23.29 | kanzure | glxgears doesn't do interlocking of infinitely many gears |
| 22:23.35 | Ralith | might even haev only been in the freebsd distrib |
| 22:23.42 | Ralith | yeah this is much more advanced than glxgears |
| 22:23.46 | Ralith | nicer looking models, too |
| 22:23.49 | kanzure | anyway, it sucks because it's not actual CAD |
| 22:23.55 | kanzure | it's just a cylinder and some OpenGL calls |
| 22:24.03 | kanzure | kinda useless for lab research :) |
| 22:24.12 | Ralith | I wouldn't think parametric gears would be very hard |
| 22:24.17 | kanzure | not at all |
| 22:24.17 | madant | kanzure: does graphsynth support hypergraphs ? |
| 22:24.31 | kanzure | madant: please excuse me, I'm not as well versed in hypergraphs as I should be |
| 22:24.36 | madant | nods |
| 22:24.38 | kanzure | is this where there are vertices with multiple edges? |
| 22:24.45 | Ralith | hm |
| 22:24.55 | Ralith | brlcad: does BRL-CAD have any sort of geargen tool? |
| 22:25.05 | bjorkintosh | geargen? gear generator? |
| 22:25.07 | Ralith | yeah |
| 22:25.08 | kanzure | yes |
| 22:25.13 | kanzure | madant: is that what a hypergraph is? |
| 22:25.14 | Ralith | okay, cool |
| 22:25.23 | kanzure | Ralith: no, I wasn't answering you |
| 22:25.26 | Ralith | oh |
| 22:25.45 | Ralith | I ask because we've got weird things like tire generators and fence generators but I don't recall ever seeing a gear generator |
| 22:25.45 | madant | kanzure: the hypergraph idea is basically that you can have edges between edges.. |
| 22:25.58 | bjorkintosh | fence generator? |
| 22:26.00 | bjorkintosh | whoa! |
| 22:26.03 | Ralith | chain link fence |
| 22:26.07 | bjorkintosh | is in white picket ... |
| 22:26.08 | bjorkintosh | oh okay. |
| 22:26.13 | kanzure | madant: blah? wha? |
| 22:26.13 | bjorkintosh | *as in. |
| 22:26.46 | kanzure | madant: http://en.wikipedia.org/wiki/Hypergraph |
| 22:26.48 | kanzure | "In mathematics, a hypergraph is a generalization of a graph, where edges can connect any number of vertices. " |
| 22:26.52 | kanzure | in which case, yes |
| 22:29.19 | louipc | hmm! those generators used to be prefixed with mk_ |
| 22:29.32 | louipc | now I don't know what the generators are blah |
| 22:29.48 | kanzure | just grep over the source for 'gear' :-) |
| 22:29.53 | kanzure | grep -H -I -R "gear" * |
| 22:30.05 | madant | kanzure: if you consider a constraint network.. it eventually has lets say a set of nodes( variables) and constraints( edges between two or moredependent variables) but constraints might depend on other constraints as well.. so you have hyperedges connecting two or more edges which can effectively be broken down into edges between many vertices.. |
| 22:30.31 | kanzure | I see |
| 22:30.56 | Ralith | kanzure: hehe |
| 22:30.59 | louipc | kanzure: that's not very efficient, and doesn't help those who only installed the binary |
| 22:31.06 | madant | consider a constraint which depends on two other constraints for instance .. |
| 22:31.11 | kanzure | madant: right |
| 22:31.27 | madant | so graphsynth supports hypergraphs ? |
| 22:32.47 | kanzure | the answer is complicated. yes in the sense that the constraint network can be represented, no in the sense that the way that you solve it is not by treating it as a hypergraph |
| 22:32.50 | kanzure | I don't know if that makes sense |
| 22:33.19 | kanzure | see, when a constraint network would be added into graphsynth, the "rules" would be called forth to solve a particular subset of the graph |
| 22:33.32 | kanzure | then it would be possible, say, to find the next part of the constraint network needs to be updated |
| 22:33.36 | kanzure | dependent on the last modification that was made |
| 22:33.53 | kanzure | which is essentially solving the same thing, no? |
| 22:34.20 | madant | looking at the grammar.. |
| 22:34.35 | kanzure | well that's the thing, the grammars are hand-crafted |
| 22:34.51 | kanzure | like I said, one researcher has made a grammar for gear generation, another for linkages (or is working on it), another for product disassembly |
| 22:35.22 | kanzure | (and there's a few others- one for how to tie a tie, electronics (filter circuits), and stuff I'm forgetting) |
| 22:35.42 | madant | kanzure: i meant the basic designGraph class |
| 22:36.29 | madant | what are the node classes ? |
| 22:36.48 | kanzure | vertices. |
| 22:36.58 | kanzure | what are you asking? the name of the node class is 'node' IIRC |
| 22:37.14 | madant | i mean they directly correlate with the variables right ? |
| 22:37.48 | kanzure | uhrm, sort of. each node has a list of labels, and it's possible for a node to only have one label, so in this case that label might be a variable related to the constraint expression, yeah |
| 22:38.11 | louipc | starseeker: should src/libged/tire.c be removed since it's already in src/shapes/tire.c? |
| 22:38.59 | madant | ah.. so designGraph is basically an implementation of a directed graph right ? but hypergraphs are not effectively reducible to directed graphs |
| 22:39.27 | kanzure | directed means that edges point in a certain direction |
| 22:39.33 | kanzure | but in this case, edges are bidirectional |
| 22:39.51 | kanzure | I mean, each node has a list of the edges that are connected to it |
| 22:40.32 | brlcad | oof, turn my head for just a few minutes.. |
| 22:40.45 | madant | :D |
| 22:43.17 | brlcad | louipc: mcneal & assoc. were very upfront from the very beginning that there was no support, no community, and a simple PD license, and open about the fact that their intent was more converters and that they have no intention of helping folks use it for analytic or modeling purposes .. big difference in intent and flexibility |
| 22:43.58 | madant | kanzure: consider this hypergraph ( vertices : A,B,C,D,E,F Edges/Constraints: A perp. B, Cperp. D, E parallel F if A perp. B and C perp. D else E perp. F) how would this be represented in graphsynth |
| 22:44.08 | madant | 6 variables and 3 constraints |
| 22:45.05 | kanzure | I would have to play around with possible representation methods :) |
| 22:45.14 | kanzure | one idea that comes to mind is using nodes for perpendicularity/parallelism |
| 22:45.16 | brlcad | kanzure: 404 on http://66.112.232.182/~bbishop/docs/gears/gears.html |
| 22:45.31 | kanzure | so if two nodes are connected by "parallel" or "perpendicular", then that's that. |
| 22:46.05 | brlcad | Ralith: don't think so, but pretty simple to create with the pattern tool .. something I did in a couple minutes a couple years ago here: http://brlcad.org/tmp/gear/ |
| 22:46.30 | brlcad | bjorkintosh: there's a picket fence generator too |
| 22:46.43 | kanzure | ah, you were the one who did /tmp/gear |
| 22:46.46 | Ralith | hm |
| 22:46.48 | kanzure | remembers seeing that a few weeks ago |
| 22:47.17 | Ralith | not the most gearlike, but I imagine that's not a limitation of the system |
| 22:47.23 | brlcad | louipc: ls src/shapes |
| 22:47.35 | madant | kanzure: just describe the new graph for me ? |
| 22:47.42 | bjorkintosh | haha |
| 22:47.46 | bjorkintosh | who put these things in there, brlcad? |
| 22:48.19 | brlcad | louipc: look at the implementation of src/shapes/tire.c .. ged_tire() |
| 22:48.26 | madant | kanzure: u mean two nodes and multiple edges between them ? |
| 22:49.06 | madant | kanzure: in that case? lets say the nodes are P(perpendicularity) and U ( parallel) .. how do u model the third constraint ? |
| 22:49.21 | kanzure | madant: what does the if/then statement signify? "if A per. B" does that mean "if A perp. B is possible" ? |
| 22:49.48 | brlcad | kanzure: /tmp/gear was a quick example for someone based on known curvature parameters, forget who though |
| 22:50.04 | madant | kanzure: if A perp. B is satisfied |
| 22:50.15 | kanzure | then that should be in the grammar rules |
| 22:50.28 | brlcad | bjorkintosh: various developers -- creating a procedural modeling tool that generates something is actually a great way to become familiar with the code base |
| 22:50.34 | kanzure | it would be a new rule: "if you see this graph structure, then make this modification" |
| 22:50.48 | bjorkintosh | you don't say. |
| 22:50.53 | starseeker | has considered making a gear generator, but coils were more manual labor for a usable result and less tractable to creation via tools like clone |
| 22:50.56 | kanzure | in particular it would be, using the model I suggested off the top of my head, "if you see A-perp-B (vertices: A, perp, B), then do blah blah blah" |
| 22:51.11 | kanzure | erm, sorry, vertices: A, perpSOME_ID_NUMBER, B |
| 22:51.21 | kanzure | the perpendicularity between the two is supposedly unique :-) |
| 22:51.26 | brlcad | so we often have new developers try to write an app that makes something (of their choice), they end up learning some of libbu, libbn, librt, libwdb and we end up with a simple tool that generates some shape procedurally usually |
| 22:51.30 | starseeker | gears will probably come later, but the variety is amazing in gears and much thought would be needed to create a sufficiently general framework |
| 22:51.34 | madant | kanzure: k :) |
| 22:51.42 | kanzure | starseeker: oh? |
| 22:51.51 | kanzure | starseeker: that's kind of the work that I'm supposed to be doing right now for the lab |
| 22:52.05 | kanzure | in particular, I'm also supposedly coming up with a way to display helical gears, worm gears, bevel gears, etc. etc. |
| 22:52.11 | starseeker | cooool :-) |
| 22:52.11 | Ralith | starseeker: isn't most of the variety just in the details of the tooth shape? |
| 22:52.27 | kanzure | and I get to ignore tooth shape (more or less)- which I know you guys are going to hate me for |
| 22:52.31 | starseeker | Ralith: tooth shape, tooth spacing, overall gear shape, gear interior... |
| 22:52.40 | brlcad | e.g., I wrote the chain link 'fence' tool probably a decade ago -- it comes in handy for generating scenes for something that would otherwise be very painstaking to model by hand (it generates a physically accurate chain link fence with all the bends and individual wires) |
| 22:52.42 | kanzure | madant: I think it can be useful for parametrics. I'll definitely talk it over with some labmates soon. |
| 22:53.13 | madant | kanzure: so effectively the constraint graph in itself does not represent the problem entirely ? |
| 22:53.23 | Ralith | starseeker: doesn't strike me as terribly hard to abstract. |
| 22:53.40 | brlcad | you probably have starseeker drooling now .. he's been talking about gears and coils for a while :) (and now has the latter mostly working) |
| 22:53.44 | kanzure | madant: maybe. I'm still not sure- why is there an if/then in your constraint specification? |
| 22:53.59 | starseeker | sticks tounge out at brlcad |
| 22:54.13 | kanzure | starseeker: you should definitely check out the code in the directory I keep linking to |
| 22:54.19 | madant | kanzure: it is a possible logical constraint right :) |
| 22:54.19 | kanzure | http://heybryan.org/~bbishop/docs/gears/ |
| 22:54.27 | starseeker | Ralith: It isn't hard to abstract - that's one of the reasons it's a good candidate for a tool |
| 22:54.33 | starseeker | looks |
| 22:54.53 | madant | since constraints effectively have two states : only constraints possible between them are in essence logical |
| 22:54.54 | kanzure | madant: can you give me an example of a situation where I inadvertedly used a logical constraint in a CAD app without perhaps knowing it? |
| 22:55.10 | starseeker | kanzure: Can't see it from here - I'll have to look later |
| 22:55.21 | kanzure | starseeker: blah, some of you are unable to load the pages, while others in this channel can |
| 22:55.24 | kanzure | wtf? |
| 22:55.57 | madant | kanzure: :) am not really sure if any CAD application supports it.. I mean i have only worked with CATIA and it doesn't.. |
| 22:56.08 | Ralith | starseeker: well, what did you mean by "much thought would be needed to create a sufficiently general framework"? |
| 22:56.09 | starseeker | Ralith: a lot of the work involved with a gear tool would be identifying what the standard methods are for specifying gear type, size, etc. and wiring up the logic to generate the proper geometry based on those numbers |
| 22:56.30 | kanzure | yay |
| 22:56.34 | Ralith | yeah, I imagine it would be mostly research |
| 22:56.35 | kanzure | starseeker: we should definitely collaborate on this |
| 22:56.35 | starseeker | for each gear type, there may be a whole sub-set of specifications to look at |
| 22:56.39 | madant | kanzure: but not sure if many CAD applications support it internally.. will have to think of a case :) |
| 22:56.41 | Ralith | it sounds ilke an interesting task, though |
| 22:56.46 | kanzure | Ralith: I'm working with somebody who has done most of that work |
| 22:56.49 | kanzure | that research work, I mean |
| 22:56.58 | Ralith | kanzure: cool; has he published his findings anywhere? |
| 22:57.03 | kanzure | paper in progress |
| 22:57.04 | kanzure | :) |
| 22:57.10 | starseeker | kanzure: It'll be a while before I can devote much time to it - I've got other more pressing tasks :-/ |
| 22:57.17 | Ralith | let me know when it's up |
| 22:57.19 | Ralith | I might just write this |
| 22:57.20 | madant | kanzure: how many people are working with parametrics and constraints at UT ? |
| 22:57.37 | kanzure | madant: I don't know anybody who is explicitly working on that problem. :( |
| 22:57.38 | kanzure | it's so sad |
| 22:57.49 | brlcad | kanzure: I believe unigraphics can get you into some situations where you use constraints implicitly |
| 22:57.51 | kanzure | I guess there's me. |
| 22:58.16 | brlcad | it's got a red-light/green-light to let you know if you're fully constrained or under/over too, interesting concept |
| 22:58.33 | starseeker | Ralith: then for each gear type, you have to think about precisely what geometry you want to use to represent it. For example, would it be better to use sketches for gear patterns that can be represented as extrusions, or should such gears be combinations of arbs and tgcs? |
| 22:58.43 | kanzure | yes, I've seen something like that in Solidworks re: red/green light for over/under constrained |
| 22:58.49 | starseeker | extrusions would do for a lot of types, but not all |
| 22:58.59 | madant | brlcad: i like the similar feature in catia sketcher.. where they show u overconstrained and underconstrained and correctly constrained elements in different colours |
| 22:59.06 | Ralith | yeah, I realized that |
| 22:59.09 | kanzure | starseeker: in my case, the generated CAD file would have to be dependent on the variables that the optimization engine is spitting out |
| 22:59.12 | Ralith | we can't twist extrusions yet, can we? |
| 22:59.14 | kanzure | so that kind of solves that problem eh? |
| 22:59.22 | kanzure | but makes for a perhaps overly constrained gear generator in the end of course :) |
| 22:59.36 | brlcad | has wanted similar lights for constraining once it's all working, but even now for overlap reporting |
| 22:59.55 | starseeker | kanzure: In part. You also want to be able to manually specify gears from the command line (or, better, from within MGED) using standard parameters |
| 23:00.00 | kanzure | right |
| 23:00.05 | kanzure | no argument there. |
| 23:00.16 | Ralith | some sort of extrude along a path describing rotation as well as direction; is there a name for that? |
| 23:00.20 | madant | ah.. so it is effectively : if ( constraint1 = true , constraint 2= true .... ) then constraints=true ;) hypegraph :D |
| 23:00.20 | kanzure | madant: so was your logic constraint spec an imaginary one? :) |
| 23:00.35 | starseeker | Ralith: sounds like sweep |
| 23:00.39 | Ralith | that's it |
| 23:00.44 | Ralith | we don't have that yet, right? |
| 23:00.47 | starseeker | right |
| 23:00.55 | Ralith | 'cuz that would make things easier. |
| 23:01.00 | starseeker | indeed |
| 23:01.02 | kanzure | madant: yeah, the solutions would be those graphs where "all constraints have been satisfied" (or eliminated, or completely replaced, or something) |
| 23:01.32 | madant | kanzure: yep :) |
| 23:01.41 | kanzure | what would BRLCAD do with multiple solutions to a constraints satisfaction problem anyway? |
| 23:01.46 | Ralith | in fact, I'm not sure how you'd represent those twisted gears with simple operations on primitives--though I'm no modeler. |
| 23:01.53 | kanzure | would it let the user pick from a list ? is that how this goes? |
| 23:02.07 | starseeker | twisted gears? like on oil rig drilling? |
| 23:02.13 | Ralith | I dunno about oil rigs |
| 23:02.13 | starseeker | yeah, those would be a problem |
| 23:02.15 | kanzure | helical gears? |
| 23:02.18 | madant | yeah the idea is to present the user with the range of options.. |
| 23:02.26 | Ralith | I saw these in a lathe's gearbox |
| 23:02.28 | madant | asking him for either further constraints or values |
| 23:02.48 | starseeker | runs through the primitives in his mind... |
| 23:02.54 | Ralith | imagine taking a normal gear with fine teeth, then twistingthe top and bottom half in opposite directions |
| 23:03.03 | Ralith | such that the teeth are no longer parallel to the axis |
| 23:03.12 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 23:03.16 | starseeker | Oh, that's less of a problem |
| 23:03.26 | Ralith | they're used to increase contact area between the gears |
| 23:03.38 | kanzure | madant: so I guess all that I need to do now is figure out how to make grammar rules for solving constraints problems |
| 23:03.48 | kanzure | and then get the professor to put up a real GPL license for graphsynth |
| 23:03.55 | kanzure | and then integrate the code and go from there :p |
| 23:04.38 | madant | kanzure: i will read up on graphsynth today .. is there any documentation other than http://www.me.utexas.edu/~adl/graphsynth/ |
| 23:05.43 | kanzure | not really. |
| 23:05.54 | kanzure | there's some related stuff here: heybryan.org/~bbishop/docs/repo/ |
| 23:06.04 | kanzure | some example graphs of designs: http://heybryan.org/~bbishop/docs/repo/2009-02-20_FS/ |
| 23:06.14 | starseeker | I was thinking of connections like those visible in page two of this patent: http://www.google.com/patents?id=9WEUAAAAEBAJ |
| 23:06.32 | kanzure | madant: this might be helpful, some powerpoints? http://heybryan.org/~bbishop/docs/repo/presentations/ |
| 23:06.37 | madant | kanzure: :( i don't have access to windows :P |
| 23:06.48 | Ralith | starseeker: those count as gears? |
| 23:06.59 | starseeker | It's remotely possible that some application of tgc subtractions could produce that sort of effect... |
| 23:07.12 | kanzure | madant: there should be some odf presentations there, and if not, don't worry- I don't have access to windows either :) |
| 23:07.16 | starseeker | Ralith: they can. It's called a twisted prism |
| 23:07.23 | Ralith | sounds... arcane. |
| 23:07.26 | Ralith | what're they used for? |
| 23:07.40 | starseeker | Lots of HP printer cartridges have used it |
| 23:07.49 | madant | nah.. i meant the actual graphsynth program |
| 23:07.52 | Ralith | I mean I can see in the drill application it would keep the connections tight |
| 23:07.57 | Ralith | but in gears? |
| 23:08.08 | starseeker | it has the advantage of the turning mechanism also pulling the component toward the socket |
| 23:08.10 | kanzure | madant: nope. |
| 23:08.26 | starseeker | Ralith: hang on, I'll see if I can find a picture |
| 23:08.29 | kanzure | btw, I've been able to compile it on monodevelop under linux |
| 23:09.12 | brlcad | kanzure: how long ago was dns changed? |
| 23:09.18 | brlcad | (on heybryan.org) |
| 23:09.21 | kanzure | brlcad: it wasn't! :) |
| 23:09.27 | kanzure | I mean, I've never set it to 127.0.0.1 |
| 23:09.34 | kanzure | and it hasn't been changed recently |
| 23:09.46 | brlcad | then you have a bad name server somewhere in there or an expired name or something.. |
| 23:09.57 | kanzure | hrm. |
| 23:10.01 | madant | hmm.. this is interesting : http://minion.sourceforge.net/ |
| 23:10.07 | kanzure | but then why doesn't the IP address work? |
| 23:10.27 | Ralith | heybryan.org works for me |
| 23:10.58 | madant | works for me too @opendns |
| 23:11.12 | kanzure | haha, somebody's using opendns? :) |
| 23:11.16 | Ralith | :P |
| 23:11.25 | Ralith | is using level3's servers |
| 23:11.32 | starseeker | Ralith: not ideal, but http://www.google.com/patents?id=dGyEAAAAEBAJ&pg=PA37&dq=twisted+prism+gear+helical&source=gbs_selected_pages&cad=1_1 |
| 23:11.32 | brlcad | kanzure: ah, there's your problem |
| 23:11.37 | brlcad | all four of your name servers are dead |
| 23:11.56 | kanzure | but then what about you being unable to use my IP to access the same content? |
| 23:12.08 | starseeker | Ralith: element 37a |
| 23:12.08 | kanzure | madant: so, minion spits out a list of solutions? |
| 23:12.13 | brlcad | looks like afraid.org lost their name |
| 23:12.22 | Ralith | starseeker: yeah, I saw... isn't that another interlock? |
| 23:12.32 | kanzure | http://minion.sourceforge.net/gsoc/index.html |
| 23:12.41 | starseeker | Ralith: It's a combination of interlock and driver |
| 23:12.43 | Ralith | or is 39a a matching gear |
| 23:12.55 | madant | not sure.. just came across it :) scalability seems to be one of their great aims ;) |
| 23:13.01 | starseeker | yes, 39a is the matching socket |
| 23:13.05 | Ralith | socket? |
| 23:13.13 | Ralith | still not a gear, then |
| 23:13.29 | starseeker | many of these gear types have helical components, but some of them get rotation only from that twisted prism |
| 23:13.36 | Ralith | well, either way, it's an interesting shape |
| 23:13.42 | kanzure | madant: it's weird, they seem to be about visualization of results? wtf |
| 23:13.45 | Ralith | and apparently one we can't model. |
| 23:14.18 | starseeker | I doubt it. I've been trying to envison some sort of tgc subtraction which could do it, but I doubt it |
| 23:14.46 | Ralith | would a sweep cover those? |
| 23:14.58 | starseeker | If sufficiently general, yes |
| 23:15.14 | Ralith | I'm guessing sweeps are pretty nontrivial to implement, then. |
| 23:15.23 | Ralith | seems very useful, though... |
| 23:15.42 | starseeker | yes and yes :-) |
| 23:16.03 | madant | kanzure: ? visualization |
| 23:16.08 | kanzure | in their gsoc page |
| 23:16.43 | madant | ah those are just their ideas page right :) |
| 23:18.00 | madant | hmm they have a solver independent modeling language too.. nice .. my idea for libpc is somewhat the same in the long run.. i mean multiple solvers for the same constraint network |
| 23:18.47 | starseeker | Well, enough tgc playing with an arb6 MIGHT produce something interesting, but I don't think it can do it |
| 23:18.54 | kanzure | shouldn't it just implicitly find all possible solutions, madant ? |
| 23:19.22 | madant | kanzure: i liked their work too a bit http://www.gecode.org/ |
| 23:20.16 | madant | kanzure: oh the mutliple solvers ? i was just thinking it might be possible that some solvers are better for some graphs / problems |
| 23:20.34 | madant | kanzure: i was not implying running a set of solvers for getting the complete set of solutions |
| 23:21.43 | kanzure | ah, better as in more efficient |
| 23:21.43 | kanzure | okay |
| 23:23.14 | madant | is diybio fun ;) ? |
| 23:23.18 | kanzure | very |
| 23:23.35 | kanzure | scroll down to the bottom of my homepage and I have a link to some recent work I've been doing with 'sharpie microfluidics' |
| 23:23.51 | kanzure | i.e. prototyping a "lab on a chip" with a sharpie and a few spare CDs using surface tension and the capillary force ;-) |
| 23:24.42 | brlcad | kanzure: huh, did minion make it? |
| 23:24.55 | brlcad | ah, no |
| 23:25.27 | brlcad | going to say, just having two ideas and being that domain-specific .. nearly impossible |
| 23:25.53 | madant | kanzure: can't find it :P link ? |
| 23:26.03 | brlcad | madant: that does look like an interesting project, though :) |
| 23:26.13 | kanzure | madant: http://groups.google.com/group/diybio/msg/1197606e3c3dc439 |
| 23:26.55 | kanzure | (there were 40 messages in that thread .. some of the more recent messages have been about prototyping microchannels via human hair + sharpie.. but anyway) |
| 23:27.03 | madant | brlcad: yeah.. i will check out their papers tomorrow .. er.. today ( 5 am here) .. |
| 23:27.06 | *** join/#brlcad ``Erik___ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) |
| 23:27.16 | brlcad | pretty bold performance claims |
| 23:27.17 | madant | should get going to try the Crossfit Murph |
| 23:27.33 | brlcad | not just an order.. orders* faster |
| 23:27.55 | brlcad | license is a non-starter though, maybe they'd consider changing it |
| 23:27.59 | madant | kanzure: see you around.. will definitely check out graphsynth today |
| 23:28.05 | kanzure | okay, neat :) |
| 23:28.13 | kanzure | mentions again that he's considering brlcad for gsoc |
| 23:28.14 | kanzure | heh |
| 23:28.18 | brlcad | heh |
| 23:28.20 | madant | brlcad: maybe.. most probably students or profs somewhere.. |
| 23:28.43 | brlcad | yeah, http://minion.sourceforge.net/people.html |
| 23:29.28 | madant | ok.. :) be back in an hour.. |
| 23:29.34 | brlcad | would be fantastic if they relicensed as lgpl or bsd |
| 23:29.40 | brlcad | cya madant |
| 23:48.01 | starseeker | hmm, this is as close to a twisted prism shape as I can come in a short trial: http://bzflag.bz/~starseeker/twisted.png |
| 23:48.07 | starseeker | not so good |
| 23:59.02 | brlcad | heck of a lot easier with brep :) |
| 23:59.10 | brlcad | but probably not as fast |
