| 01:05.57 | *** join/#brlcad poolio_ (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 01:38.42 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 03:46.29 | *** join/#brlcad poolio_ (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 03:51.04 | *** join/#brlcad poolio_ (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 04:39.38 | CIA-4 | BRL-CAD: 03johnranderson * 10brlcad/src/gtools/g_diff.c: |
| 04:39.38 | CIA-4 | BRL-CAD: Added calls to wdb_create_command() since it had been removed from wdb_obj_init(). |
| 04:39.38 | CIA-4 | BRL-CAD: Also fixed a small bug where -f option would miss differences. |
| 04:48.53 | CIA-4 | BRL-CAD: 03johnranderson * 10brlcad/src/ (7 files in 6 dirs): |
| 04:48.53 | CIA-4 | BRL-CAD: Eliminated more instances of direct access of interp->result (not allowed |
| 04:48.53 | CIA-4 | BRL-CAD: since tcl 8.0) |
| 05:16.49 | brlcad | woot |
| 05:18.38 | yukonbob | brlcad: BRL-CAD heavily uses [incr tcl], right? |
| 05:19.10 | brlcad | mged and rtwizard heavily use incrTcl |
| 05:19.17 | brlcad | and archer iirc |
| 05:19.29 | yukonbob | =) -- what I mean is sit idly by --- hopefully I'll be able to contribute some useful code sometime :) |
| 05:19.30 | brlcad | i.e. the gui tools do, but not the rest |
| 05:19.36 | yukonbob | ah... |
| 05:19.52 | yukonbob | but the 7.10 is dependent on the (still beta) tcl 8.5, right? |
| 05:20.17 | brlcad | there are hundreds of "processing tools" that work in a unix fashion (can be chained together, perform rather isolated tasks, command-driven, etc) |
| 05:20.29 | brlcad | right |
| 05:21.00 | brlcad | 8.4 can be made to work, but there are about a dozen lines of code that would need to be back-updated |
| 05:21.18 | brlcad | s/back-updated/patched/ |
| 05:21.29 | yukonbob | is there a changelog 7.8->7.10? |
| 05:21.53 | brlcad | 8.5 is needed for the tk aqua fixes on os x though among a few other significant fixes |
| 05:22.23 | brlcad | yes, see the NEWS file for user-visible changes or the ChangeLog for all commits release-to-release |
| 05:22.41 | brlcad | speaking of the news file... |
| 05:23.04 | yukonbob | brlcad: 8.5 gets it's own native OO, iirc, kinda bases on Xotcl and snit... that's why I was asking about [incr tcl]... |
| 05:23.21 | yukonbob | /bases/based/ |
| 05:25.03 | brlcad | hm, I've not seen anything related to that actually |
| 05:25.10 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/TODO: |
| 05:25.10 | CIA-4 | BRL-CAD: john fixed the units command, woot. it was an issue with interp->result being |
| 05:25.10 | CIA-4 | BRL-CAD: used where apparently it was an object instead of a string. this apparently |
| 05:25.10 | CIA-4 | BRL-CAD: only now biting us, probably due to the 8.5 upgrade, though tcl.h says to stop |
| 05:25.10 | CIA-4 | BRL-CAD: using it since 8.0 |
| 05:25.16 | brlcad | i know tk picked up that entire theming package |
| 05:26.21 | brlcad | and a couple of the core tcl guys still work on incr tcl so it's quite far from dead (i'm on their commits and tracker lists) |
| 05:29.26 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/NEWS: |
| 05:29.26 | CIA-4 | BRL-CAD: john fixed the units command, woot. it was an issue with interp->result being |
| 05:29.26 | CIA-4 | BRL-CAD: used where apparently it was an object instead of a string. this apparently |
| 05:29.26 | CIA-4 | BRL-CAD: only now biting us, probably due to the 8.5 upgrade, though tcl.h says to stop |
| 05:29.26 | CIA-4 | BRL-CAD: using it since 8.0 |
| 06:11.42 | *** join/#brlcad Laniakea (i=clock@217-162-204-122.dclient.hispeed.ch) | |
| 06:15.02 | *** join/#brlcad tofu (n=sean@bz.bzflag.bz) | |
| 06:18.23 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 06:21.14 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/helplib.tcl: can get/set with units command |
| 06:23.21 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 06:31.33 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/NEWS: john fixed a g_diff bug where -f option missed differences -- now only calls atof the values actually seem to be numbers. |
| 06:44.16 | *** join/#brlcad ak__ (n=ak@ll-81-222-164-251.awanti.ru) | |
| 06:51.29 | yukonbob | brlcad: you on? |
| 07:16.33 | *** join/#brlcad yukonbob_ (n=bch@whthyt247-240.northwestel.net) | |
| 07:18.11 | *** join/#brlcad Laniakea (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:11.24 | *** join/#brlcad ak__ (n=ak@ll-81-222-164-251.awanti.ru) | |
| 08:16.48 | *** join/#brlcad ak__ (n=ak@ll-81-222-164-251.awanti.ru) | |
| 08:54.13 | *** join/#brlcad cad72 (n=5b0bd657@bz.bzflag.bz) | |
| 10:33.55 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 11:02.02 | *** join/#brlcad akreal (n=ak@87.249.56.197) | |
| 11:50.09 | *** join/#brlcad docelic (n=docelic@212.91.116.101) | |
| 12:22.50 | *** join/#brlcad cris (n=cris@200.223.157.187) | |
| 12:24.11 | cris | hi, I am an AutoCAD user, and I'm searching for a CAD "4 Linux". Please, what do you know about BRL-CAD? is it a good CAD? is it good for civil engiinering projects ? |
| 12:28.34 | Laniakea | cris: it's not good for CE because it doesn't have dimensions blueprint anything |
| 12:29.27 | Laniakea | cris: look at Qcad but that's 2D only |
| 12:29.32 | cris | Laniakea, hum... :-( ok, thank you. but, do you know a CAD for Linux? |
| 12:29.57 | Laniakea | I know just BRL-CAD and Qcad |
| 12:30.05 | Laniakea | I doubt there is a 3D cad with blueprints and arrows |
| 12:30.27 | Laniakea | I use BRL-CAD and Qcad on my mechanics project |
| 12:30.43 | cris | yes, I know QCad, but I dont like it, it isn't like autocad ... :-) |
| 12:30.44 | Laniakea | what is CE? Is it building houses? Or making machines? |
| 12:31.04 | cris | Laniakea -> CE = civil engennering |
| 12:31.24 | Laniakea | what is it? |
| 12:34.45 | cris | Laniakea -> I'm asking for a cad 4 linux to work with civil engennering |
| 12:36.04 | cris | Laniakea -> please, forget the last speak , CE = building houses |
| 12:39.47 | cris | Laniakea -> thank you |
| 12:48.53 | Laniakea | oh houses |
| 12:49.01 | Laniakea | no I never did houses, only mechanical stuff |
| 12:53.38 | ``Erik | heh, we could model the geometry, and I think we just got hte ability to convert to nastran for FAE type activities, and we have an approximation of edge drawing, and we can even do 2d overlay stuff... but there's no "measurement" tool to generate dimension info |
| 12:57.20 | Laniakea | ``Erik: I just don't care about dims - I am happy that I am getting at least what I am getting from BRL-CAD :) |
| 12:59.40 | ``Erik | just noting where it falls short : |
| 12:59.41 | ``Erik | :) |
| 12:59.51 | ``Erik | sure as hell ain't gonna do shit about it right now, I'm on vacation :D |
| 13:06.38 | archivist | after his holiday of course |
| 13:06.50 | poolio | anyone know if brlcad is going to be back today? |
| 13:12.40 | ``Erik | he seems to be back every day, is it something that someone else can help with? O.o |
| 13:19.55 | poolio | ``Erik: Maybe, I'm starting work today and have a steady stream of questions :P |
| 13:25.58 | poolio | Most of them I'm able to answer myself if I spend the itme, it just would be a lot faster with someone who knew the codebase |
| 13:31.48 | ``Erik | some others of us have some familiarity :) |
| 13:32.07 | poolio | Yeah but I didn't want to interrupt you :) |
| 13:32.27 | ``Erik | aight, but if it's a 5 second thing *shrug* I'll help where I can |
| 13:33.33 | poolio | ``Erik: I'm mainly trying to get how to go about converting a CSG shape into voxel data. So at the moment I'm trying to understand how to get a bounding box |
| 13:34.18 | ``Erik | uhm, after you prep geometry, there's bounding box and bounding sphere information |
| 13:34.41 | poolio | Yeah I see that, but I don't need all the other rt stuff |
| 13:34.50 | brlcad | yeah, he's around |
| 13:35.02 | poolio | Like I'm looking at g_qa.c and it looks like rt_prep_parallel does all the grunt work |
| 13:35.06 | poolio | brlcad: morning :) |
| 13:36.09 | ``Erik | g_qa, heh |
| 13:36.16 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-092-241.pools.arcor-ip.net) | |
| 13:37.47 | poolio | Also. it appears make_bb in mged doesn't actually make the correct bounding box |
| 13:38.06 | poolio | Or more likely, I'm doing it wrong |
| 13:38.11 | brlcad | how so ? |
| 13:38.43 | brlcad | it's AABB, not an OBB |
| 13:39.28 | poolio | Ah oops, the issue was that I hadn't updated the framebuffer |
| 13:39.36 | poolio | d'oh |
| 13:54.15 | poolio | brlcad: Do you think it's an OK starting point if I just took g_qa and stripped it down to what i needed and worked off that code base for the csg --> voxel-like form? |
| 13:54.55 | brlcad | yeah, that's viable |
| 13:55.54 | brlcad | note, though, what part this actually is -- voxelization is one aspect of your fitness function |
| 13:58.31 | poolio | and the aabb is also needed for generation of the initial population |
| 13:58.58 | poolio | along with eliminating invalid mutations |
| 13:59.24 | brlcad | sure, though does g_qa help with getting the aabb? |
| 14:00.03 | poolio | brlcad: No, but it shows me how to do all the prepping I need to do in order to get it |
| 14:00.55 | poolio | Although I think I'd have to try to eliminate rt_prep and do something at a more lower level as the fitness function is going to be the main bottleneck of the GA |
| 14:08.27 | poolio | Oh man, I'm going to have to touch up on semaphores with all this multiple cpu stuff :P |
| 14:14.04 | brlcad | that's actually one of the nice aspects of g_qa is that it's already fully multithreaded |
| 14:15.06 | brlcad | librt's multithreading stuff isn't too complicated, you grab a semaphore to protect your data accesses, then release it when you're done |
| 14:17.30 | brlcad | those routines are being run in parallel via that bu_parallel routine, which says to call plane_worker() for N threads (ncpu) |
| 14:18.02 | poolio | brlcad: Yeah I got that :) |
| 14:19.04 | poolio | I'm trying to understand plane_worker and don't see why you shoot all the rays in the first row, but then every other in the next row |
| 14:22.10 | brlcad | ah, that's a particular aspect of g_qa .. it's a refinement grid |
| 14:22.26 | brlcad | since the model isn't changing.. it's shooting a grid that is more and more refined |
| 14:22.31 | poolio | So meaning the grid spacing is decreeased and refined |
| 14:22.34 | poolio | yeah |
| 14:22.36 | brlcad | right |
| 14:22.44 | brlcad | so it doesn't need to reshoot the spacings it already shot at |
| 14:22.58 | brlcad | big performance savings |
| 14:23.00 | poolio | Ans so because it halves the size each time you can eliminate re-shooting every other one? |
| 14:23.08 | brlcad | right |
| 14:23.15 | poolio | Ah ok, thanks |
| 14:23.43 | brlcad | not sure if that will be any use to you since the models will be different every iteration |
| 14:23.53 | brlcad | but shooting the grid certainly will be |
| 14:24.27 | poolio | Well it will be useful in the brief time you generate the voxel data for the original unchanging model |
| 14:26.13 | brlcad | ah, true |
| 14:26.25 | brlcad | shooting a 4x4, then a 8x8, ... |
| 14:26.47 | poolio | but I'd have to modify it to not do that optimization for all the other thousands (millions?) of times it runs on the population |
| 14:27.34 | brlcad | right, they're just going to shoot at a given resolution for a given iteration |
| 14:27.51 | brlcad | and you could then progressively refine that resolution as the fitness gets better |
| 14:28.13 | poolio | I remember you were talking a little while ago about when shooting the rays I'll want to do a "slingshot" type thing to get a vector of the ray and all the points it passes through. does g_qa implement that? |
| 14:34.38 | poolio | one region = one ray? |
| 14:40.46 | *** join/#brlcad thing0 (n=ric@203-59-121-145.dyn.iinet.net.au) | |
| 14:41.03 | thing0 | hey allll |
| 14:49.27 | brlcad | howdy thing0 |
| 14:49.45 | thing0 | hey brlcad |
| 14:49.50 | thing0 | how you doing? |
| 14:49.58 | brlcad | poolio: not sure what you mean by slingshot |
| 14:50.11 | brlcad | it does do shoot-through rays |
| 14:50.17 | poolio | brlcad: Firing a ray and having it return a vector |
| 14:50.19 | poolio | yeah that :) |
| 14:50.27 | poolio | I don't know why the word slingshot came to mind |
| 14:50.34 | thing0 | brlcad: did you see my discussion with ``elite01 yesterday? |
| 14:51.04 | brlcad | thing0: probably |
| 14:51.16 | thing0 | hehe |
| 14:51.18 | brlcad | whether it meant anything to me that I'd remember is a different question ;) |
| 14:51.24 | thing0 | the bit about http://www.ode.org/ |
| 14:51.33 | thing0 | BRLCAD should connect with this |
| 14:51.35 | thing0 | ;) |
| 14:51.38 | brlcad | hm, i might have missed that |
| 14:51.51 | brlcad | yeah, ode's been "on the list" |
| 14:51.59 | thing0 | ahh ok |
| 14:52.36 | brlcad | thing0: http://my.brlcad.org/~sean/ideas.html .. "Material Properties" section, third bullet |
| 14:53.01 | poolio | somehow I feel like what I'm doing isn't very useful ;) |
| 15:00.06 | poolio | brlcad: Is there some sort of example with shoot-through rays? I'm having some issues trying to understand all of rt_shootray() |
| 15:01.19 | thing0 | brlcad: I dunno if Alias still has that format anymore |
| 15:01.27 | thing0 | being bought by Autodesk and all |
| 15:03.08 | brlcad | poolio: are you kidding? if this works, it will be amazingly useful |
| 15:04.26 | brlcad | being able to go from mesh and/or voxel explicit representations to an implicit and/or boundary representation is very useful |
| 15:05.04 | ``Erik | that's some heavy stuff |
| 15:05.15 | ``Erik | 3d version of computer image recognition, yo |
| 15:05.49 | brlcad | it's a means to heal geometry, compress representations, reduce data, recognize patterns, .. any one of those alone are worthwhile |
| 15:07.19 | ``Erik | and advancing the science of that is doctorate worthy shtuff, I'd imagine :) |
| 15:08.20 | poolio | brlcad: Key words _"if this works"_ |
| 15:10.04 | brlcad | even if you implement the approach fully/correctly and it turns out to be a disaster, that's still good research |
| 15:10.34 | brlcad | finding out that a technique doesn't work well is just as useful as one that works well |
| 15:10.59 | brlcad | that said, given the results seen to date, I actually expect this will work very well for some models |
| 15:11.29 | brlcad | implementing the approach fully/correctly is the trick, and the brunt of the hard work ;) |
| 15:12.57 | poolio | eh, first I have to understand the basics of 3d shapes, then i might have a chance |
| 15:14.14 | poolio | Could you gie me a hand understanding some of this terminology? |
| 15:14.50 | brlcad | ~hand poolio |
| 15:14.56 | poolio | hoorah. |
| 15:15.08 | brlcad | hrm, no literal for that one, shucks |
| 15:15.12 | poolio | So a partition in the contex of a ray is the segment of the ray that intersected a solid? |
| 15:15.22 | poolio | hah |
| 15:16.25 | brlcad | ~hand $who is <action> gives $who a hand, then promptly chops it off |
| 15:16.25 | ibot | brlcad: okay |
| 15:16.30 | brlcad | ~hand poolio |
| 15:16.31 | ibot | ACTION gives brlcad a hand, then promptly chops it off |
| 15:16.36 | brlcad | heh, oops |
| 15:16.56 | poolio | dangling modifier too |
| 15:19.32 | thing0 | hehe |
| 15:21.24 | brlcad | ~no, hand $target is <action> gives $target a hand, then promptly chops it off |
| 15:22.19 | brlcad | hm |
| 15:22.24 | brlcad | ~hand pooolio |
| 15:22.24 | ibot | ACTION gives pooolio a hand, then promptly chops it off |
| 15:22.32 | brlcad | good enough |
| 15:22.32 | poolio | thanks. |
| 15:22.44 | thing0 | ~hand thing0 |
| 15:22.45 | ibot | ACTION gives thing0 a hand, then promptly chops it off |
| 15:22.51 | thing0 | yay! |
| 15:23.12 | brlcad | ~whaleslap thing0 |
| 15:23.12 | ibot | ACTION beats thing0 upside and over the head with a freakishly huge killer whale named Hugh |
| 15:23.24 | brlcad | a classic |
| 15:23.48 | thing0 | nice |
| 15:24.44 | poolio | brlcad: so rt_shootray() passes to hit/miss a circularly linked list of "partitions" where each partition represents a segment of the ray vector where it intersected a solid? |
| 15:25.50 | thing0 | sleep now me |
| 15:26.11 | poolio | thing0: what time is it? |
| 15:26.19 | thing0 | 2326 |
| 15:26.52 | poolio | wow. 12 hours ahead of me. across the globe---> |
| 15:27.33 | thing0 | yeah |
| 15:27.55 | thing0 | 36 hours and I'll be on a plane |
| 15:28.05 | thing0 | to a place with limited net access |
| 15:28.06 | thing0 | so yeah |
| 15:28.16 | thing0 | If I am not here for like 3 weeks |
| 15:28.16 | poolio | enjoy? |
| 15:28.23 | thing0 | you'll know why |
| 15:28.28 | thing0 | yeah it will be awesome |
| 15:28.42 | thing0 | I'll be able to work less hours and get paid more |
| 15:28.43 | thing0 | hehe |
| 15:29.05 | thing0 | but |
| 15:29.06 | thing0 | yeah |
| 15:29.09 | thing0 | got my lapto |
| 15:29.13 | thing0 | got some movies |
| 15:29.19 | thing0 | got ut2004 |
| 15:29.19 | poolio | funf un |
| 15:29.26 | poolio | good times |
| 15:29.27 | thing0 | autodesk inventor |
| 15:29.31 | thing0 | yeah |
| 15:29.45 | thing0 | but |
| 15:29.51 | thing0 | I get one week off when I get back |
| 15:29.54 | thing0 | so that'll be good |
| 15:29.59 | thing0 | alrighty guys |
| 15:30.04 | thing0 | i'll cya later |
| 15:30.13 | thing0 | hopefully decent enough connection down there |
| 15:30.20 | thing0 | otherwise 3 weeks |
| 15:30.21 | thing0 | hehe |
| 15:30.23 | thing0 | have fun |
| 15:30.25 | thing0 | bye |
| 15:30.35 | brlcad | wooo |
| 15:30.37 | poolio | cya, have fun. |
| 15:30.39 | brlcad | cya thing0 |
| 15:30.59 | brlcad | ~bed thing0 |
| 15:31.00 | ibot | ACTION tucks thing0 into a warm bed. |
| 15:31.09 | poolio | brlcad: What matrix math is VJOIN1? |
| 15:31.38 | brlcad | see include/vmath.h |
| 15:32.38 | brlcad | VJOIN1(A,B,c,D) is A = B + cD |
| 15:33.10 | brlcad | where A, B, and D are vectores, c is a constant |
| 15:33.17 | poolio | I saw that, the thing is I don't quite get what it meant in terms of the code. |
| 15:33.37 | brlcad | basically joins to vectors, scaling one of the vectors |
| 15:33.41 | brlcad | s/to/two/ |
| 15:34.17 | brlcad | ah, in terms of the code it's even easier |
| 15:34.20 | poolio | Ah I think I see what it's doing. Calculating the point where the ray entered and exited a certain partition |
| 15:34.38 | brlcad | yep |
| 15:35.03 | brlcad | a ray fired from a given point, in a given direction, with a hit along some distance |
| 15:35.03 | poolio | geez, I need to start using my brain more |
| 15:35.15 | brlcad | VJOIN1 basically gives you that hit point |
| 15:35.46 | poolio | Any suggestions on how to store the ray data? should I just store the linked list of parititons? |
| 15:36.07 | brlcad | B:[a ray fired from a given point], D:[in a given direction], with c:[a hit along some distance] |
| 15:36.11 | brlcad | just to clarify ;) |
| 15:36.23 | poolio | Yes yes, thank you |
| 15:36.49 | brlcad | no suggestions, whatever works for you |
| 15:37.07 | poolio | I think I might just not store it at all |
| 15:37.11 | brlcad | linked list of partitions should be lightweight enough, maybe store them as an array of linked list |
| 15:37.42 | brlcad | 2d array of segments.. basically a list per grid line |
| 15:37.46 | poolio | Meaning I calculate the fitness of a given model one ray at a time |
| 15:38.14 | poolio | That way the need to store the data is eliminated |
| 15:38.53 | brlcad | that could work |
| 15:39.47 | poolio | Because for debugging I'd have the original model(in real life this would theoretically just be voxel data), and the proposed GA model, so I don't really need the rt stuff as I can just check it in mged |
| 15:42.13 | poolio | But on the downside it'd mean I'd have to write a separate function to shoot rays at the original model |
| 15:42.38 | poolio | Although that could be a benefit |
| 15:42.41 | poolio | ah many things to think about :) |
| 15:43.40 | brlcad | i'd think you want to shoot at the original model |
| 15:43.56 | brlcad | that way you can convert arbitrary models to proposed csg solutions |
| 15:44.33 | brlcad | so your same algorithm will work on a volumetric model, or a polygonal model, or even another CSG model |
| 15:45.51 | poolio | Well yes I want to shoot at the original model, I was just thinking how you could have the same function to shoot rays at the original and the models, but I think it's better seperate, as you have said, so that if you want to work with other data it's easy to implement |
| 15:45.53 | brlcad | that's what I meant about starting with something like a simple CSG sphere as your input model .. you'd raytrace that to stash your list of segments .. then kick off the GA, evaluating via ray-tracing and comparing rays to those stashed |
| 15:46.04 | poolio | Yes exactly :) |
| 15:46.06 | brlcad | ideally, you'll get back a model that is almost exact |
| 15:46.57 | poolio | The one thing I'm kind of concerned about is that the way I'd evaluate the fitenss -- ray by ray -- would make a shifted but identical model be completely unfit |
| 15:47.13 | brlcad | the ray-tracer simply returns segment lists and doesn't care if it's shooting at voxels or triangles or primitives, makes it a nice encapsulation layer |
| 15:47.30 | poolio | yeah, librt++ |
| 15:47.33 | brlcad | yes, well position is just as important as shape |
| 15:47.37 | brlcad | so that model is unfit |
| 15:47.57 | brlcad | likewise for orientation |
| 15:48.06 | poolio | yeah |
| 15:48.42 | brlcad | which is why your genotype really will probably need to be a CSG tree solution (which has operators, matrices, and primitive nodes) |
| 15:49.29 | poolio | and what does the term "region" mean in terms of a ray? the area that the ray has passed through? |
| 15:50.01 | poolio | brlcad: Yeah, I was looking at the tree.c stuff. I'd definitely try to have the genome be something along those lines |
| 15:50.56 | brlcad | another research paper for you to look over in your copious spare time: http://my.brlcad.org/~sean/trunkpacking2005.pdf |
| 15:51.23 | brlcad | it's a much more advanced paper, but is even closer in methodology to what you're trying to do |
| 15:51.31 | brlcad | and its results were spectacular |
| 15:51.49 | poolio | cool |
| 15:52.07 | brlcad | you could throw simmulated annealing into yours down the road maybe, but I wouldn't worry about that part for now ;) |
| 15:52.19 | poolio | eeeek. |
| 15:52.23 | brlcad | similarly, if the math gets too deep, just shelve it |
| 15:53.27 | brlcad | they basically solved the same problem you were solving but with just one primitive, didn't allow overlap, but did allow arbitrary orientation -- and they fit an input shape tightly |
| 15:53.46 | brlcad | better than a human could even, using a GA/SA approach |
| 15:54.33 | brlcad | they won best paper just a couple years ago at the ACM SPM conference |
| 15:54.40 | poolio | ah cool. |
| 15:55.02 | poolio | The thing I'm worried about with CSG is the boolean operators...I think that could cause some substantial problems/increase in problem space |
| 15:55.18 | brlcad | which is why you're starting without operators :) |
| 15:55.23 | poolio | jah. |
| 15:55.53 | brlcad | it does substantially increase the space, but then that's what GAs are notorious for searching for solutions over |
| 15:56.26 | brlcad | it's just a matter of how many evolutions, and is your convergence a local minima |
| 15:56.45 | brlcad | getting stuck on a local minima is generally a problem (and where SA helps save the day) |
| 15:57.07 | poolio | I'll have to read up on SAs if I get that far, I know absolutely nil about them at this point |
| 15:57.19 | brlcad | they're probably way beyond the scope of this |
| 15:57.50 | poolio | is brl-cad conform to c89 or can I use // comments? |
| 15:58.15 | brlcad | http://en.wikipedia.org/wiki/Simulated_annealing |
| 15:58.33 | poolio | brlcad: I know where to go to look for SA info, I just don't want to write now :D |
| 15:58.42 | brlcad | k, good man ;) |
| 15:58.51 | poolio | *right |
| 15:58.57 | poolio | geez. all the code is frying my brain |
| 15:59.34 | *** join/#brlcad Elperion (n=Bary@p548768AB.dip.t-dialin.net) | |
| 15:59.35 | brlcad | you can probably use // comments for this |
| 15:59.50 | poolio | as it's not really ever going to be integrated into the main codebase |
| 15:59.56 | brlcad | but i'd still try to minimize their use |
| 16:00.12 | brlcad | no, it will be integrated .. you'll be working off the main codebase even |
| 16:00.23 | poolio | oh woah |
| 16:00.31 | brlcad | there's just plans to move up to c99 at year's end when we kick over to subversion |
| 16:00.36 | poolio | speaking of which, is there anywhere in particular you want me to move stuff to? |
| 16:00.45 | poolio | but for now... cvs? |
| 16:00.50 | brlcad | yes, cvs |
| 16:01.25 | brlcad | there's // in the code base now .. so I'm sure the compile will fail in some c89 environments |
| 16:02.27 | brlcad | mipspro is one of the last remaining vestiges, though, so i'm not too concerned with it being c99 |
| 16:02.42 | *** join/#brlcad cadguy (n=cadguy@c-67-166-125-250.hsd1.ut.comcast.net) | |
| 16:03.11 | brlcad | hello cadguy |
| 16:03.23 | brlcad | how's youtall? |
| 16:08.51 | cadguy | Whacked out. |
| 16:09.14 | cadguy | Exterminator arrives in a few hours. I've got to finish clearing part of the house for them to do their work. |
| 16:09.36 | brlcad | heh |
| 16:09.53 | brlcad | can't be great if the status begins with an exterminator |
| 16:10.37 | brlcad | how's the course(s)? |
| 16:11.08 | brlcad | lots of folks asking how you all have been doing |
| 16:11.58 | cadguy | Doing better since we got THOR going realtime. |
| 16:12.05 | brlcad | Ralf Muuss sends his regards |
| 16:12.09 | cadguy | Un, make that "interactive" |
| 16:12.19 | brlcad | had lunch with him, chuck, bob, carol last week |
| 16:12.35 | cadguy | Got a nice note from him. Working on a reasonable response amidst the office move today. |
| 16:13.02 | cadguy | Ah, good. So you were in on the lunch. Rolf mentioned it. He really enjoyed it. |
| 16:13.26 | brlcad | sorry, rolf, can't seem to remember that spelling for some reason |
| 16:13.37 | cadguy | np |
| 16:14.11 | cadguy | Anyone check out the video I sent? |
| 16:14.52 | brlcad | oh yeah |
| 16:15.01 | brlcad | talked about it for quite a while |
| 16:15.11 | brlcad | the bit about being from MS was funny |
| 16:15.41 | *** join/#brlcad thing0 (n=ric@203-59-121-145.dyn.iinet.net.au) | |
| 16:16.32 | cadguy | Yeah, that was funny. I was actually thinking about the THOR vid. |
| 16:18.27 | brlcad | ooh |
| 16:18.31 | brlcad | when'd you send it? |
| 16:19.15 | cadguy | Hmmm. Friday or saturday. It's in my account on Xon. |
| 16:19.19 | brlcad | i've not checked e-mail since wednesday .. a trend likely to only continue with the plans to shut things down |
| 16:19.22 | cadguy | Friday I think. |
| 16:19.25 | brlcad | k |
| 16:19.44 | cadguy | Shut things down? You mean *nix or the "great scrub" |
| 16:25.41 | poolio | Is there some sort of builtin function to compare rays? |
| 16:27.20 | cadguy | What do you mean by "compare rays"? |
| 16:27.22 | brlcad | hm, not that I'm aware of |
| 16:31.39 | brlcad | poolio: you're going to have to write that one, and it's very much tailored to what you're doing .. amount matching and amount not matching |
| 16:32.17 | brlcad | cadguy: he means comparing two shotlines against two different models, how similar are the results (e.g. for comparing two models) |
| 16:34.16 | poolio | that's gonna be a slight pain. |
| 16:34.19 | poolio | I think I might do that today |
| 16:36.01 | poolio | I'm thinking project both rays onto another ray and do something like a reverse boolean intersection, the union of the differences |
| 16:38.26 | brlcad | you'll get back evaluated segments, you don't have to do the csg evaluation on the shotlines |
| 16:38.29 | brlcad | it's done for you |
| 16:39.13 | brlcad | so you're really just comparing two segment lists |
| 16:39.19 | poolio | I know that, but I'm talking about doing that on two different shotlines |
| 16:39.42 | poolio | well yes, but to compare them isn't really straightforward |
| 16:40.01 | brlcad | not too horrible, a couple for loops ;) |
| 16:40.29 | brlcad | could even do it with just one methinks |
| 16:41.26 | brlcad | merge the two lists into just one list of entry and exit points .. count your entries and exits and you'll know where they overlap or where there's a miss |
| 16:42.02 | poolio | Ah yeah. smart. |
| 16:44.41 | brlcad | poolio: more documentation to read probably worth your time is to read the librt manpage |
| 16:44.58 | brlcad | it talks about partitions, segments, shooting rays, the application structure, etc |
| 16:45.11 | poolio | sounds helpful :) |
| 16:45.40 | brlcad | as well as the first two links on http://brlcad.org/example_app.php |
| 17:30.44 | poolio | woah brlcad, sudden realization |
| 17:30.50 | poolio | translation is irrelevant |
| 17:31.03 | brlcad | relative translation isn't |
| 17:31.11 | brlcad | but global, yeah |
| 17:31.28 | brlcad | as is scale |
| 17:31.28 | poolio | what do you mean relative translation? as in translation of different shapes within the model's tree? |
| 17:32.15 | poolio | yeah true |
| 17:32.21 | brlcad | e.g. the translation of two spheres being unioned together .. their position relative to each other matters a lot, but where they're positioned in 3-space won't necessarily if you set up matching grids |
| 17:32.48 | poolio | yeah because i'm using AABB they will be the same wherever they are (globally) |
| 17:33.20 | brlcad | so long as you shoot adaptive to the scale/position of the AABB, and not global size (like fixed 1mm grid) |
| 17:33.41 | poolio | yeah |
| 17:34.46 | poolio | so in terms of randomly creating a population, you don't care where it is, you just want all the shapes to intersect an arbitrary bounding box |
| 17:35.44 | poolio | well maybe not arbitrary, maybe the first shape in the hierarchy or something |
| 17:57.40 | *** join/#brlcad Laniakea (i=clock@217-162-207-165.dclient.hispeed.ch) | |
| 18:28.11 | poolio | ah nooooo. nothing like segfaults. |
| 18:33.31 | ``Erik | I'd much rather have a sig11 than a logic bug :) |
| 18:33.42 | ``Erik | gdb and efence make seggies and bus faults easy to track |
| 18:33.49 | poolio | I found the issue |
| 18:35.13 | poolio | Is there a way to copy the partition passed to a_hit ? |
| 18:35.17 | poolio | memcpy? |
| 18:38.03 | ``Erik | um, that'd be a way, but there're pointers that may be deallocated, soooo if you're expecting it to be there out of scope (like if you're threaded), it could be very bad |
| 18:38.16 | poolio | Yeah, I am :( |
| 18:38.36 | ``Erik | I don't recall seeing any kinda partition copy function... might be a good patch unless brlcad can think of an alternative |
| 18:38.36 | poolio | Basically I'm trying to store a partition from a previous ray that I know will have been already calculated, and then compare that ray to future rays |
| 18:39.08 | poolio | Well an alternative for me would be to copy the values that I need into a different data structure |
| 18:39.11 | poolio | which might be smarter anyway |
| 18:39.16 | ``Erik | (now the region pointers should exist until you free the rtip, ... but *shrug*) |
| 18:40.16 | *** join/#brlcad cadguy (n=cadguy@c-67-166-125-250.hsd1.ut.comcast.net) | |
| 18:49.46 | *** join/#brlcad irt (n=cadguy@c-67-166-125-250.hsd1.ut.comcast.net) | |
| 18:59.08 | poolio | brlcad: any way to duplicate a partititon? I'm trying to test out my ray comparison function |
| 19:08.13 | *** join/#brlcad jimmyz (n=asd@host81-129-128-152.range81-129.btcentralplus.com) | |
| 19:08.34 | brlcad | poolio: hmm, pretty simple to iterate over it and manually create a copy, but .. i'm not sure you even need to do that |
| 19:09.12 | brlcad | i believe for a given ray-trace application that the partition lists may be all stored in the application structure |
| 19:13.45 | poolio | brlcad: is it the "a_FINAL_Part_hdp" ? |
| 19:15.15 | brlcad | I think |
| 19:15.28 | brlcad | it's been a long while since I looked ath what is stashed in there |
| 19:15.31 | poolio | and the index values are the # ray / total rays? |
| 19:15.42 | brlcad | index values? |
| 19:15.50 | brlcad | it's a bu_list |
| 19:15.57 | poolio | of parititions? |
| 19:17.01 | brlcad | yeah |
| 19:17.40 | brlcad | bu_lists are "inverted" .. you add bu_list as the first element to any structure and it gives you a linked list of that structure |
| 19:18.25 | poolio | yeah I was just reading the bu.h header about them because I'll probably use one to store the data |
| 19:18.36 | poolio | but if I can figure out the a_final_part_hdp stuff than there's no need in duplicating it |
| 19:18.53 | brlcad | that's why a_Final_Part_hdp is a "head pointer", you can iterate over head pointers like: for( BU_LIST_FOR( pp, partition, (struct bu_list *)PartHeadp ) ) { ... } |
| 19:19.39 | brlcad | in your comparison function, have it print out the contents of the application pointer's a_Final_Part_hdp using a for loop like that |
| 19:19.46 | poolio | yeah, g_qa used BU_LISTs for storing region groups |
| 19:20.08 | poolio | well, I'm just going to print out the total linear difference |
| 19:20.09 | brlcad | bu_lists are used everywhere |
| 19:20.44 | brlcad | ratio of right to wrong |
| 19:21.06 | brlcad | weighted by absolute length perhaps |
| 19:22.34 | poolio | well yeah, this is mainly to see if the comparison is working, not the finalized part of the fitness function |
| 19:24.53 | brlcad | whadayaknow .. there is a macro for copying partitions, RT_DUP_PT |
| 19:25.55 | poolio | hoorah. |
| 19:25.55 | brlcad | include/raytrace.h has the details |
| 19:25.56 | poolio | thanks |
| 19:26.20 | brlcad | but like I said, I'm really not sure you even need to |
| 19:27.44 | poolio | also -- shouldn't a_Final_Part_hdp be a linked list of linked lists(partitions for each ray)? |
| 19:29.55 | *** join/#brlcad Elperion (n=Bary@p548768AB.dip.t-dialin.net) [NETSPLIT VICTIM] | |
| 19:29.55 | *** join/#brlcad akreal (n=ak@87.249.56.197) [NETSPLIT VICTIM] | |
| 19:29.55 | *** join/#brlcad archivist (n=archivis@host217-35-76-52.in-addr.btopenworld.com) [NETSPLIT VICTIM] | |
| 19:31.13 | poolio | need to what? |
| 19:31.13 | *** join/#brlcad akreal (n=ak@87.249.56.197) | |
| 19:31.14 | *** join/#brlcad jack- (i=jack@83.137.193.141) [NETSPLIT VICTIM] | |
| 19:31.16 | brlcad | a_Final might just be the last ray .. would have to debug/test to see |
| 19:33.34 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-092-241.pools.arcor-ip.net) [NETSPLIT VICTIM] | |
| 19:34.11 | poolio | brlcad: I might just abandon the pursuit of doing all the ray comparison in hit() and move it to plane_worker where the individual rays are shot |
| 19:35.32 | poolio | and just pass back an array of pt_inhit and pt_outhits |
| 19:35.52 | brlcad | should/could work either way ;) |
| 19:35.58 | brlcad | whatever works out easiest for ya |
| 19:36.33 | poolio | yeah I suppose. It's just segfaulting cause of memory issues and I think half the issue was I started coding before I understood the data structures |
| 19:38.24 | *** join/#brlcad jimmyz (n=asd@host81-129-128-152.range81-129.btcentralplus.com) [NETSPLIT VICTIM] | |
| 19:38.24 | *** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT VICTIM] | |
| 19:38.28 | poolio | ALso, it seems like there is a lot of overhead for features I don't need in librt. Is it worth rewriting a lot of code and trying to get it faster or should I just try to get it working first? |
| 19:46.16 | brlcad | try to get it working first |
| 19:53.06 | akreal | hello brlcad! |
| 19:53.20 | brlcad | howdy akreal |
| 19:55.04 | akreal | i'm a student and i hope to do some cad practice with BRL-CAD, maybe you remember me ;) |
| 19:55.14 | akreal | are there any jobs now? |
| 19:57.09 | brlcad | akreal: I certainly remember your nick, though not so much what we were talkinga bout |
| 19:58.00 | akreal | brlcad: yes, it is so |
| 19:58.47 | brlcad | so what have you been up to? |
| 20:04.19 | akreal | you said the most interesting question was BREP objects, i've got math book with some formulas about it, but i'm not sure that i'm able to put them to BRL-CAD code |
| 20:04.43 | akreal | i'm a looser in production C-coding |
| 20:06.11 | brlcad | you saw the ideas page? |
| 20:07.14 | akreal | yes, i read it some times |
| 20:08.00 | brlcad | anything catch your interest? |
| 20:08.10 | *** join/#brlcad poolio_ (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 20:08.13 | brlcad | it's had a few items added since too, though nothing small |
| 20:11.48 | akreal | could you give me URL? i can't find it |
| 20:14.31 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/conv/iges/brlcad.hpp: remove hard-coded output filename |
| 20:15.29 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/conv/iges/brlcad_brep.cpp: remove hard-coded output filename |
| 20:16.45 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/conv/iges/nmain.cpp: pass output file on command line and remove hard-coded output file |
| 20:17.16 | brlcad | akreal: http://my.brlcad.org/~sean/ideas.html |
| 20:18.46 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/librt/g_brep.cpp: sort the hits (need to look into this further); remove some debugging output |
| 20:20.38 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/other/openNURBS/opennurbs.h: add some stupid simple debugging capability to openNURBS |
| 20:21.42 | brlcad | ttk, that's the new theming stuff I couldn't remember |
| 20:23.09 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/other/openNURBS/ (opennurbs_nurbscurve.h opennurbs_nurbscurve.cpp): fix NumIntersectionsWith to properly override virtual method from ON_Curve |
| 20:24.12 | poolio | brlcad: I've utterly failed at merging two strings of numbers. :P |
| 20:24.33 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/other/openNURBS/ (opennurbs_curve.cpp opennurbs_bezier.cpp): add some debugging statements; trying to find out why the trimming is not working properly |
| 20:25.49 | brlcad | poolio: hehe |
| 20:26.13 | poolio | All the logic checks out in my brain, but the code segfaults. |
| 20:27.43 | brlcad | where does it segfault? |
| 20:27.55 | brlcad | don't fear the gdb ;) |
| 20:28.11 | poolio | yeah yeah. i'm more of a fan of printf debugging though |
| 20:29.07 | brlcad | that's one of the best habits to break ;) |
| 20:29.41 | brlcad | becoming intimately familiar with your debugger will save you days of your life, though |
| 20:38.38 | akreal | brlcad: i checked the ideas list and saw it'd growed. geometry processing is interested me most, and volume (etc.) routins looks for me more suitable than others |
| 20:39.26 | akreal | its's because i understand what's it about... but maybe you could suggest smth better for newbe? |
| 20:39.58 | brlcad | it's really hard to say without knowing what you're capable of, what your experience is |
| 20:40.25 | brlcad | maybe try working on a little patch or two, or fix a bug.. see how far you get |
| 20:40.50 | *** join/#brlcad poolio_ (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 20:41.27 | akreal | fixing bug looks like nice thing to start |
| 20:42.00 | akreal | i know it helps a lot to get into the codebase :) |
| 21:38.23 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 21:38.30 | *** join/#brlcad cadguy (n=cadguy@c-67-166-125-250.hsd1.ut.comcast.net) | |
| 21:56.26 | *** join/#brlcad jimmyz (n=asd@host81-129-128-152.range81-129.btcentralplus.com) | |
| 22:18.38 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 22:25.43 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: report the directory when we can't find configure.ac |
| 22:59.40 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 23:37.27 | *** join/#brlcad poolio_ (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) | |
| 23:43.32 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |