| 00:17.40 | starseeker | brlcad: cool, I hadn't heard of the FLOSS weekly |
| 00:17.52 | Ralith | plugging is good. |
| 00:19.26 | starseeker | is curious if Ralith can write down his insights on what it would take to do shared context Qt/Ogre |
| 00:19.35 | starseeker | still wants to do that, somehow or other |
| 00:19.39 | Ralith | starseeker: did you already read the wiki entry? |
| 00:20.30 | Ralith | it wouldn't be hard, really |
| 00:21.05 | Ralith | just take things back to when the OgreScene approach was fully implemented, and add hello->show(); after the rest of the widget test code, and remove the resize call |
| 00:21.10 | Ralith | from main |
| 00:21.21 | Ralith | and if that doesn't work, try the same thing on the QtRenderListener approach |
| 00:21.35 | Ralith | and if that doesn't work, then I guess we're doing things this as best we can right now. |
| 00:21.41 | starseeker | nods |
| 00:33.20 | *** part/#brlcad jdoliner (n=jdoliner@68.51.75.169) |
| 00:44.21 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 00:59.20 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 01:07.48 | ``Erik | *pant* 80 pounds of empty boxes, paper bags, junkmail and newpapers prepped for recycling day |
| 01:09.03 | Ralith | starseeker: you gunna take a whack at it? |
| 01:57.42 | *** join/#brlcad stevegt_ (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 02:22.08 | ``Erik | ~seen madant |
| 02:22.09 | ibot | madant <i=cb7baf0f@gateway/web/freenode/x-a32eed164597bd06> was last seen on IRC in channel #brlcad, 12d 6h 15s ago, saying: 'nothing more disastrous than non-cooperative softwares ;)'. |
| 02:22.26 | ``Erik | ~seen homovulgaris |
| 02:22.27 | ibot | homovulgaris <n=d@117.196.131.215> was last seen on IRC in channel #brlcad, 338d 22h 29m 56s ago, saying: 'sean, on a scale of 1 to 10 how much trouble would one face when trying to make a .deb package for brlcad ?'. |
| 02:22.37 | ``Erik | hm. |
| 02:25.12 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 02:26.35 | *** join/#brlcad LarsG (n=lars@spnp207001.spnp.nus.edu.sg) |
| 02:26.44 | *** part/#brlcad LarsG (n=lars@spnp207001.spnp.nus.edu.sg) |
| 02:32.06 | ``Erik | oscilloscope spam, wow |
| 02:47.55 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 03:29.24 | *** join/#brlcad pacman87 (n=pacman87@pool-173-74-57-16.dllstx.fios.verizon.net) |
| 04:00.35 | starseeker | Ralith: probably at some point |
| 04:10.34 | Ralith | cool :) |
| 04:10.55 | Ralith | I'll try to code everything else such that it'll be easy to transition if you get it working |
| 05:44.42 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 07:17.16 | *** join/#brlcad IriX64 (n=WarLock@70.52.228.154) |
| 08:38.29 | CIA-30 | BRL-CAD: 03d_rossberg * r35148 10/brlcad/trunk/src/libbn/multipoly.c: |
| 08:38.30 | CIA-30 | BRL-CAD: replaced c99 idiom with c89 compatible one |
| 08:38.32 | CIA-30 | BRL-CAD: (all declarations have to be on top of a block) |
| 09:21.26 | *** join/#brlcad _clock_ (n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
| 09:53.51 | *** join/#brlcad mafm (n=mafm@83.42.152.74) |
| 10:14.32 | d-lo | ~seen d-lo |
| 10:14.33 | ibot | d-lo <n=claymore@bz.bzflag.bz> was last seen on IRC in channel #brlcad, 1s ago, saying: '~seen d-lo'. |
| 10:14.40 | d-lo | muwahaha |
| 10:14.48 | d-lo | mernin all! |
| 10:16.53 | ``Erik | yaegh |
| 10:17.08 | ``Erik | yargh, even |
| 10:17.11 | d-lo | whoa. up early or up late? |
| 10:17.42 | ``Erik | earlyish |
| 10:18.08 | ``Erik | been getting up at five something the last few weeks |
| 10:18.51 | d-lo | nice. |
| 11:56.16 | CIA-30 | BRL-CAD: 03erikgreenwald * r35149 10/brlcad/trunk/src/rt/viewweight.c: slightly more verbose logging if no density file is handy. |
| 11:59.52 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 12:47.48 | starseeker | winces as he now begins to understand some of the design considerations that may have driven the original design of opennurbs_ext |
| 12:47.48 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 12:49.02 | brlcad | ``Erik: you have a pine session going nuts |
| 12:58.18 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 13:05.09 | ``Erik | that machine gets gimpy with locks :/ I can't even start mutt due to mail locks going wonky |
| 13:07.30 | ``Erik | lame, sometimes we get .so.0 and sometimes .so.0.0 |
| 13:08.35 | brlcad | needs a -version-info 19:1 LDFLAGS in the makeifle.amd |
| 13:10.43 | ``Erik | hrm *shrug* fbsd6 gives .so.0 and fbsd7+ gives .so.0.0 on our core libs, supposedly |
| 13:11.12 | ``Erik | ah, wait, no, not our core |
| 13:11.15 | brlcad | hm, doesn't sound right |
| 13:11.17 | ``Erik | just the step stuff |
| 13:11.21 | brlcad | yeah, the new libs |
| 13:11.26 | ``Erik | http://people.freebsd.org/~amdmi3/brlcad-7.14.8.log |
| 13:11.26 | brlcad | none of them have -version-info |
| 13:12.53 | brlcad | with it, they should list better and the packing list can be fixed |
| 13:13.39 | ``Erik | yeah, editing now |
| 13:13.54 | ``Erik | but I blew away my macports stuff, so I gotta get that up enough to test |
| 13:15.43 | brlcad | probably shouldn't be 19:1 |
| 13:16.18 | brlcad | don't know what it "should" be without re-reading the libtool docs on verison-info and checking up on step's version |
| 14:29.54 | *** join/#brlcad BigAToo (n=BigAToo@69.95.46.65) |
| 15:16.20 | ``Erik | O.o http://www.alexa.com/siteinfo/brlcad.org |
| 15:18.47 | louipc | canada wins |
| 15:18.58 | louipc | ok not really |
| 15:20.42 | starseeker | brlcad: when will they post your interview? |
| 15:39.12 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 15:43.46 | *** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net) |
| 15:51.13 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 15:51.13 | *** join/#brlcad b0ef (n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT VICTIM] |
| 15:51.13 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 15:56.44 | *** join/#brlcad b0ef` (n=b0ef@084202026157.customer.alfanett.no) |
| 15:58.39 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 15:58.39 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 16:22.00 | CIA-30 | BRL-CAD: 03starseeker * r35150 10/brlcad/trunk/include/opennurbs_ext.h: BASegment isn't serving any purpose - remove it. |
| 16:33.38 | CIA-30 | BRL-CAD: 03starseeker * r35151 10/brlcad/trunk/include/opennurbs_ext.h: Don't use intersectedBy for a SubcurveBANode |
| 16:44.51 | CIA-30 | BRL-CAD: 03starseeker * r35152 10/brlcad/trunk/include/opennurbs_ext.h: Add a few comments, formatting. |
| 17:00.44 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 17:30.03 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 17:43.03 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 17:46.18 | jdoliner | indianlarry you around? |
| 17:49.06 | CIA-30 | BRL-CAD: 03starseeker * r35153 10/brlcad/trunk/ (4 files in 3 dirs): Merge BANode and SubcurveBANode classes into one BANode class |
| 18:00.03 | ``Erik | jabs indianlarry with a pointy stick |
| 18:00.24 | indianlarry | hey joe what's up |
| 18:04.10 | CIA-30 | BRL-CAD: 03starseeker * r35154 10/brlcad/trunk/include/opennurbs_ext.h: Move CurveTree class before BVNode definitions |
| 18:06.26 | jdoliner | hi |
| 18:07.20 | indianlarry | hey joe |
| 18:07.34 | jdoliner | and it seems that even the numerical solutions use some algebraic stuff |
| 18:08.57 | jdoliner | it seems they're needed for finding basepoints |
| 18:09.17 | indianlarry | basepoints? |
| 18:09.30 | jdoliner | yeah what I mean by that |
| 18:09.45 | jdoliner | is that if we want to march along the intersection |
| 18:10.08 | jdoliner | we need a place to start that's on the intersection |
| 18:10.11 | jdoliner | curve |
| 18:13.14 | jdoliner | So I've been looking through a couple of CAS implementations to see how they handle these sorts of things |
| 18:14.03 | indianlarry | what's in the algebra, do they subdivide into near flat pieces like the raytracing and then intersect planes for a starting point? |
| 18:14.53 | indianlarry | could use bounding box to see what parts of the surface a near |
| 18:15.01 | indianlarry | are near |
| 18:15.56 | jdoliner | no they use the high level stuff like Groebner bases to solve things |
| 18:16.48 | ``Erik | *yawn* |
| 18:17.12 | CIA-30 | BRL-CAD: 03erikgreenwald * r35155 10/brlcad/trunk/src/other/step/src/ (6 files in 6 dirs): chuck in some version info for installed libraries. Mimick BRL-CAD lib version (for now). |
| 18:18.17 | jdoliner | describe to me more how subdividing would work |
| 18:20.31 | indianlarry | for raytracing we currently subdivide each surface (in UV) until it is near flat |
| 18:22.21 | indianlarry | a 3D bounding box is computed for each near flat surface and put into a surface tree |
| 18:22.33 | jdoliner | okay |
| 18:22.52 | indianlarry | rays are first cast against the bounding boxes |
| 18:23.53 | indianlarry | for bounding boxes hit an iterative approach is used |
| 18:24.22 | indianlarry | two intersecting/perp planes are used to represent the ray |
| 18:25.09 | indianlarry | and an initial starting point in that sub-surfaces UV (possibly multiple start points) |
| 18:28.49 | indianlarry | given two bboxes from seperate surfaces overlap |
| 18:29.40 | indianlarry | use normals of each subsurface to setup walking direction |
| 18:30.14 | indianlarry | adjust normals as you walk |
| 18:33.09 | jdoliner | okay that makes sense |
| 18:33.17 | *** join/#brlcad docelic (n=docelic@78.134.205.236) |
| 18:33.21 | indianlarry | walk on each surface, plane of two normals along with the plane of from surface normals and a perp plane along their average |
| 18:33.38 | indianlarry | just thinkin out load |
| 18:33.41 | indianlarry | loud |
| 18:34.56 | jdoliner | so yeah if we have two surface's and a point on their intersection curve, then going iteratively from the point along the cross of the normals will keep us on the curve? |
| 18:35.12 | jdoliner | provided we take small steps |
| 18:35.32 | jdoliner | and our geometry is "nice" |
| 18:36.28 | indianlarry | that can be a problem |
| 18:37.02 | indianlarry | especially with boundary trims where the UV extent is the intersection |
| 18:37.42 | indianlarry | you will also need to check in/out of trim |
| 18:38.02 | indianlarry | unless you just start with untrimmed surfaces |
| 18:38.06 | indianlarry | your call |
| 18:38.25 | indianlarry | i'd start with the untrimmed surfaces ;^) |
| 18:39.39 | indianlarry | though wwe do have trim in/out closeness checking |
| 18:40.06 | jdoliner | do you mean by "the UV extent is the intersection" |
| 18:41.20 | jdoliner | what do you mean by the above? |
| 18:41.21 | jdoliner | whoops |
| 18:43.14 | jdoliner | also have we considered adding in some algebraic geometry functionality in brlcad? |
| 18:45.21 | CIA-30 | BRL-CAD: 03erikgreenwald * r35156 10/brlcad/trunk/src/librt/primitives/nmg/nmg_manif.c: fix some sign issues with the paint table? maybe? |
| 18:46.27 | indianlarry | the intersection between to surfaces can lie along one of the surfaces UV boundary |
| 18:47.19 | indianlarry | two |
| 18:48.03 | indianlarry | have to make sure the iterator doesn't step out of UV that's all |
| 18:48.29 | jdoliner | yeah that would be a problem |
| 18:49.37 | indianlarry | if your up to it try out the algebraic solution and if it looks a bit much we'll go back to iterative approach |
| 18:51.26 | jdoliner | k I like that idea |
| 18:52.06 | jdoliner | groebner bases and stuff can be really powerful |
| 18:52.46 | indianlarry | cool, look forward to seeing what you come up with |
| 18:53.25 | jdoliner | does this go in libbn you think? |
| 18:54.14 | ``Erik | dang that indianlarry is a slavedriver O.o |
| 18:55.22 | indianlarry | up to you, if you'd like to keep it in procdb while your testing i'm okay with it |
| 18:56.07 | jdoliner | also a question on etiquette because I haven't really done this before |
| 18:56.30 | jdoliner | I'm planning to draw heavily from an opensource library called CoCoa in my implementation |
| 18:56.39 | indianlarry | indianlarry looks for dictionary |
| 18:57.06 | ``Erik | jdoliner is out to confuse us mac weenies |
| 18:57.23 | jdoliner | I don't think we want to just include their library as external code, because a lot of it isn't going to be that useful |
| 18:58.12 | jdoliner | it's GPLed and all so I think this is okay |
| 18:58.30 | ``Erik | um, we're not gpl |
| 18:58.46 | ``Erik | we're bsd and a little lgpl, some of our consumers cannot abide by gpl |
| 18:58.58 | jdoliner | I see |
| 18:59.05 | ``Erik | (like, consumers that let us have paychecks) :) |
| 18:59.24 | jdoliner | ah that kind of consumer I see |
| 19:00.49 | jdoliner | so if we just "stole" the code and put it in our project, we would need that code to be gpled or our entire project. either way it doesn't seem like we can do that |
| 19:02.47 | indianlarry | it's not unheard of to get special author permission but that would have to be formalized |
| 19:03.13 | indianlarry | probably more trouble than worth |
| 19:04.07 | jdoliner | I see |
| 19:04.46 | indianlarry | erik pointed out that is especially hard with multiple authors as is typical in an open source gpl environment |
| 19:04.46 | jdoliner | k 2 questions then |
| 19:05.01 | jdoliner | yeah that would become difficult |
| 19:05.17 | jdoliner | that license would something have to be under for us not to have to worry at all |
| 19:05.36 | ``Erik | bsd, mit, apache, ... even lgpl |
| 19:05.58 | jdoliner | okay then that becomes and option, also how much borrowing will we get in trouble for? |
| 19:07.18 | ``Erik | if it's a license that permits it, as much as ya want as long as you abide |
| 19:07.55 | ``Erik | for a bsd style license, that just means you give credit where it's due |
| 19:07.56 | indianlarry | we don't want to borrow anything we shouldn't |
| 19:08.43 | ``Erik | but we have code that links to and are linked to by proprietary shtuff, so we cannot snarf gpl stuff :( |
| 19:09.34 | ``Erik | (we probably have a couple small executables that may be gpl, but the libraries and headers have to be clean) |
| 19:10.28 | ``Erik | (billy holiday to tool, my playlist is awesome) |
| 19:11.05 | jdoliner | okay sounds good |
| 19:11.18 | ``Erik | there's a little discussion in the HACKING file about license crap |
| 19:12.31 | jdoliner | I guess I just have a good reference to look at for stuff |
| 19:12.53 | jdoliner | oh well their code isn't actually such a good fit anyways :) |
| 19:13.44 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-9-142.dclient.hispeed.ch) |
| 19:15.10 | ``Erik | hm, gotta kinda be careful of doing that, the whole 'clean room' issue |
| 19:15.41 | ``Erik | (I wanna be a coder, not a lawyer, waahhhhh) |
| 19:17.50 | CIA-30 | BRL-CAD: 03starseeker * r35157 10/brlcad/trunk/ (5 files in 3 dirs): Merge BVNode and SubsurfaceBVNode classes into one BVNode class |
| 19:21.14 | jdoliner | well along those lines, this algorithm actually doesn't look all that though. I think I can probably just do it from scratch. |
| 19:21.54 | jdoliner | Perhaps this is Stallman's desired effect from the LGPL |
| 19:21.57 | jdoliner | and GPL |
| 19:24.12 | ``Erik | stallman is pushing a religion *shrug* |
| 19:50.32 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 19:56.29 | brlcad | cheers as he gets the big endian to chatter over serial |
| 19:56.58 | brlcad | starseeker: in a couple days I believe |
| 19:57.43 | brlcad | ``Erik: heh, I saw that stats site .. most interesting is that it thinks we could make about 8 bucks a day on ads, heh |
| 19:59.05 | brlcad | jdoliner: if you look at CAS, you're going to find computational geometry approaches, they kinda go hand in hand but aren't the only way to approach the problem (and often suffer massively in terms of performance) |
| 20:04.19 | brlcad | jdoliner: and yeah, GPL code is certainly out -- we're clean-scrubbed to LGPL or better so at best you can get someone to "explain to you" a technique used in some GPL code, but the code itself cannot be used |
| 20:05.31 | brlcad | but more to the point of the approach, I'd personally prefer keeping your work isolated in proc-db (could be a subdir for that matter) before injecting a bunch of computational geometry/algebra routines into libbn/librt until we know it works well, at least proof of concept |
| 20:06.29 | jdoliner | k I've gotten myself a nice Algebra folder setup in proc-db |
| 20:06.36 | brlcad | otherwise, to add directly to libbn/librt before it's known to be viable, that'd be worthy of a branch |
| 20:06.54 | jdoliner | do you think Groebner bases are prohibitively inefficient |
| 20:06.55 | jdoliner | ? |
| 20:07.06 | brlcad | I think they probably will be :) |
| 20:07.18 | jdoliner | rats |
| 20:07.46 | brlcad | most of the algebra-based approaches require stable numerics, with many/most falling back to fixed- or infinite-precision numerics in order for them to work |
| 20:08.09 | brlcad | which are anywhere from two to four orders of magnitude slower than other approaches |
| 20:08.16 | jdoliner | the numeric algorithms I've found still use algebra at the starting point though |
| 20:08.28 | brlcad | it's mostly how do you solve |
| 20:10.26 | brlcad | I mean you're more than welcome to give it a shot, but you should be rather cautious that it might mean you end up with squat in terms of useful code |
| 20:10.54 | brlcad | we need surface surface intersections to be fast slightly more than we need them to be exact :) |
| 20:11.18 | *** join/#brlcad stevegt_ (n=stevegt@cislunar.TerraLuna.Org) |
| 20:11.43 | jdoliner | K |
| 20:12.01 | jdoliner | well as you can see from my talk with IL |
| 20:12.19 | jdoliner | the simple approach of just marching the normal's cross seems pretty viable |
| 20:12.31 | jdoliner | it fails in some boundary cases |
| 20:12.59 | brlcad | the primary use is going to be for calculating booleans so we can go CSG+primitives -> CSG+NURBS -> untrimmed evaluated NURBS -> polygonal mesh -> triangle mesh |
| 20:13.34 | jdoliner | oh |
| 20:13.46 | jdoliner | okay so if a bit of inaccuracy creeps in it might be okay |
| 20:14.01 | brlcad | as long as it's controlled inaccuracy, sure |
| 20:14.13 | brlcad | it can't end up with non-solid geometry |
| 20:14.40 | jdoliner | yeah that's the apocalypse |
| 20:15.22 | jdoliner | okay well using the normal marching is pretty well setup already seeing as ON already has normal eval builtin. |
| 20:15.26 | brlcad | that's an axiomatic requirement, and it has to keep the same topological structure/manifolds (if was a 3-manifold when we started, it should be a 3-manifold regardless of the transformation) |
| 20:28.35 | CIA-30 | BRL-CAD: 03starseeker * r35158 10/brlcad/trunk/ (3 files in 3 dirs): Start preparing to move responsibility for Curve Tree generation and use to the Surface Tree builder, rather than calling it from brep.cpp. |
| 20:57.51 | ``Erik | ho hum |
| 22:48.34 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 23:02.27 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 23:26.59 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 23:53.19 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |