| 00:57.20 | starseeker | ``Erik: my take would be to focus on getting a working shader - integration into the build logic can come later |
| 00:57.35 | starseeker | for the moment, we could even assume an installed osl |
| 00:58.27 | starseeker | I'd probably have to cmakeify at least one or two deps - to the best of my knowledge tbb doesn't currently use CMake, for example |
| 01:05.49 | starseeker | idly wonders if imageio could sub for freeimage in ogre... |
| 01:05.54 | starseeker | openimageio rather |
| 03:47.58 | ``Erik | starseeker: the src/liboptical/sh_osl.c thing is what I meant, integrate it into our raytracing package. Not spend a lot of time writing shaders for it before... src/other with checks for system are after some basic integration |
| 07:03.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:23.03 | *** join/#brlcad Stattrav_ (~Stattrav@111.93.134.142) | |
| 10:52.48 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 12:55.19 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:42.19 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 14:14.02 | dloman_ | bangs head against keyboard..... doesn't wanna write a custom treewalker :( |
| 14:16.04 | ``Erik | why would you need to? we have too many already? |
| 14:17.03 | ``Erik | cinematics are dandy and all, but after half a dozen times, zomfg, give me a button to skip it, seriously |
| 14:17.26 | dloman_ | trying to make a tree walker that does two things: 1) keeps track of full path and 2) creates the appropriate bu_ext |
| 14:17.32 | dloman_ | i get 1 easy |
| 14:17.40 | dloman_ | but 2 keeps eluding me. |
| 14:18.16 | dloman_ | every different tree walker i've tried fails on 'badmagic' cause somehow, the directory* gets 'misaligned' with the db_i* |
| 14:18.24 | ``Erik | ooh, all the tree walkers are thinking prepped geometry, not disk... you MIGHT be able to create a memory image and do a wdb export into it, then have a magic bu_external |
| 14:18.30 | ``Erik | I think that might be what, um |
| 14:18.55 | ``Erik | bad magic probably means you're trying to use a bu_external as a .g file, which is not valid |
| 14:19.30 | ``Erik | g_transfer.c dude |
| 14:19.36 | dloman_ | hrm, dunno how. just calling bu_get_external() and feeding it a dbip and directory |
| 14:19.38 | ``Erik | your answers are there :D |
| 14:19.49 | dloman_ | kk, i've been all over search.c, keep.c paths.c |
| 14:19.53 | dloman_ | thanks, i'll check it. |
| 14:20.17 | ``Erik | src/gtools/g_transfer.c, brlcad mentioned it a while ago |
| 14:20.42 | dloman_ | okay, that's half the info i already know. |
| 14:20.55 | dloman_ | i can make valid bu_externals by simply looping thru the file. |
| 14:21.07 | dloman_ | and i can get a good set of full paths by tree walking. |
| 14:21.32 | dloman_ | now, i need to combine the two so I can do both in one pass over the file. |
| 14:21.37 | dloman_ | ..... that even possible? |
| 14:21.42 | ``Erik | a bu_external maps immediately to a single line of a .asc file |
| 14:21.58 | dloman_ | righto. |
| 14:22.00 | ``Erik | maybe the g2asc program will help you more |
| 14:22.02 | dloman_ | well, here's a question |
| 14:22.07 | ``Erik | since it has to do that by definition |
| 14:22.26 | dloman_ | is there a way to take a db object name and get its full path? |
| 14:23.29 | ``Erik | I'm questioning myself on the notion of what full path means in the BRL-CAD filesystem... I'm kinda thinking that there is no such thing as a path, it's imaginary :D or, rather, reconstituted based on relationships |
| 14:23.48 | ``Erik | the whole "flat namespace" has always bugged me a bit |
| 14:24.26 | ``Erik | using notation to denote a tree when everything sits at the same level and stacks metadata to denote associations... *shudder* |
| 14:24.38 | dloman_ | hrm. time to ponder and test code more. |
| 14:24.42 | ``Erik | denote note note denote note stop. morse dork. :D |
| 14:25.01 | dloman_ | backs away slowly. |
| 14:25.15 | ``Erik | I'm off today, man, cut me some slack |
| 14:25.33 | dloman_ | =D |
| 14:25.38 | ``Erik | I'm just saying that viewing it as a real 'path' may be problematic, it might not actually exist that way |
| 14:26.00 | ``Erik | it's more like a strange ORM in reality |
| 14:26.02 | dloman_ | that's why i'd like to be able to 'walk' the tree and verify the path. |
| 14:26.33 | dloman_ | aka, a user specifies they want a list of all child objects of /some/path/to/an/obj.r |
| 14:26.54 | dloman_ | where the actual .g file is named 'to' |
| 14:26.57 | ``Erik | yeah, and that's why I'm bugged, it has to be hand assembled from the entire soup |
| 14:27.11 | ``Erik | mebbe we'll do real pathing in v6 |
| 14:27.53 | ``Erik | you'd have to stop at 'to' and pull everything in it to construct the tree, the tree does not explicitely exist in the .g |
| 14:28.02 | ``Erik | it's assembled from name relationships at load time |
| 14:28.03 | dloman_ | exactly |
| 14:29.39 | ``Erik | gonna go swap laundry, the things you should probably be looking at are g2asc, libged tops, maybe pulling a loaded 'internal' tree and doing exports on each bit |
| 14:30.21 | dloman_ | thinking about giving up and chalking it to 'premature optimization' |
| 14:30.27 | dloman_ | and just doing in two passes |
| 14:30.36 | dloman_ | slower, yeah, but hellova lot less frustrating |
| 14:30.43 | ``Erik | good luck O.o :D *think* butler might be able to help, brlcad might, but he's otherwise occupied... |
| 14:30.55 | dloman_ | doody duty |
| 14:30.57 | ``Erik | for the muves guys, performance is not a concern |
| 14:30.58 | dloman_ | *snicker* |
| 14:31.07 | dloman_ | don't really care about them |
| 14:31.10 | ``Erik | dropped off their package on saturday, btw |
| 14:31.26 | dloman_ | im thinking of mged 2 or 3 performance. |
| 14:31.36 | ``Erik | they're the ones driving funding and deadlines... yeah, we want better, but if under teh gun, just gotta shut them up, right? |
| 14:31.46 | dloman_ | yuppers. |
| 14:31.58 | ``Erik | soo mebbe you should KISS |
| 14:32.31 | ``Erik | who knows, maybe the simple slow approach is adequate |
| 14:32.43 | dloman_ | yeah, i was just thinking that same thing. |
| 14:32.44 | dloman_ | heh |
| 14:35.12 | ``Erik | (yeah, you kinda already said it, I was agreeing) |
| 14:35.34 | dloman_ | i was focusing on the 'stupid' part, lol |
| 14:35.42 | dloman_ | my head hurts cause of this stuff. |
| 14:35.46 | dloman_ | i sooooooo can't read C |
| 14:35.47 | ``Erik | "keep it stupid, simple?" |
| 14:36.15 | ``Erik | heh, different paradigm than you're used to |
| 14:36.27 | dloman_ | that's Yodas version? |
| 14:36.52 | ``Erik | I thought I was a really good programmer when I went back to college, bitched like crazy when I had to learn new languages and design paradigms... |
| 14:37.15 | ``Erik | I think every new language and definitely every new paradigm has made me a much better programmer in all the languages I can use |
| 14:37.58 | dloman_ | hehehe, just reading thru www.ihas1337code.com makes me realize just how much i missed by not going to college for CS. |
| 14:38.23 | ``Erik | it twists your mind and makes you look at things differently... and then enlightenment :) |
| 14:40.12 | ``Erik | the, uh, monthly 'scrum', one of the points ed wanted to talk about was the future of GS and having you rotate to other stuff, drag you out of isolation and expose you to other stuff |
| 14:40.30 | dloman_ | that'd be nice |
| 14:40.48 | ``Erik | are you in the office? I know ed is in, he answered his phone a bit confused |
| 14:41.01 | dloman_ | yeah, im here. |
| 14:41.36 | ``Erik | well, there ya go :D walk over and mention it, I'd be willing to go on speakerphone since I poked the tiger |
| 14:42.12 | dloman_ | well, there's the issue of me being pissed that i can't make this thing work the way i want it to, as easily as it should be to implement. |
| 14:42.29 | dloman_ | im stubborn like that, an i really want this to be done. |
| 14:43.37 | ``Erik | dude, it's a whole bucketload of very specialized knowledge, the smart thing is to say "hey, this is hard" and get help... |
| 14:43.51 | dloman_ | that's why i have you :P |
| 14:44.02 | ``Erik | I mean, what'd you say if a coner tried to restart a reactor and refused to stop and say they didn't know what was going on? |
| 14:44.23 | ``Erik | getwhutahmean,verne? |
| 14:44.36 | dloman_ | to be fair, things have gotten a whole lot better since i stopped trying to hammer rocks into swords :) |
| 14:45.00 | dloman_ | well, in that case, i'd laugh, then leave the boat. power to him :) |
| 14:45.04 | dloman_ | but i know what you mean. |
| 14:45.15 | ``Erik | notes that he is not on the boat at the moment O:-) *duck* |
| 14:46.16 | ``Erik | sorry, couldn't resist that one.. Cliff Ed and I talked a bit about the needs, state, possibilities, etc of GS and ed felt that you and brlcad needed some insight, but it was time to stop and see what was what |
| 14:46.36 | dloman_ | right on |
| 14:47.00 | dloman_ | i'd like to get it to a point where i can say: Here, its working. Barely, but its working to reqs. |
| 14:47.16 | ``Erik | I think cliff and i did a big info dump that he grokked, but a little more data was needed for a good decision |
| 14:47.38 | ``Erik | it might be that the lithp version is close enough to their requirements that we can say "good 'nuff till next fy" |
| 14:48.06 | dloman_ | that's my fallback, so thanks for that :) |
| 14:48.24 | ``Erik | is cliff in? be social, man, our downfall is lack of communication |
| 14:48.42 | dloman_ | oh, we've talked a lot the last few weeks :) |
| 14:48.59 | dloman_ | ive tripled my understanding of the brlcad libs in a short time. |
| 14:49.26 | dloman_ | add in the fact that i am finally confident enough to say "No, using that lib is stupid" |
| 14:49.27 | ``Erik | talking and communication are not necessarily parallel, and ed feels in the dark a lot of the time |
| 14:50.22 | ``Erik | he's a good guy to talk to, I'd strongly recommend heading over, sitting down and chattering a bit |
| 14:50.36 | dloman_ | will do |
| 14:50.59 | ``Erik | and like I said, I'm off today, but if you feel the need to call up and throw me on speakerphone *shrug* I'm here |
| 14:52.45 | dloman_ | will do, thanks. |
| 15:03.46 | kunigami_ | does the blue ball seem to be using a phong shader? http://imageshack.us/photo/my-images/101/phong3.png/ |
| 15:07.41 | kunigami_ | in this other image is used the microfacet-beckmann shader, http://imageshack.us/photo/my-images/40/imager03.png/ but the specular highlighting is blue instead of white |
| 15:08.02 | ``Erik | kunigami_: yes, phone, but not radiosity or photon mapping, which the rest of the scene seems to be using... the granulatiry makes it look like a combination, almost |
| 15:08.06 | ``Erik | phong, even |
| 15:09.41 | ``Erik | looks like the difference is a specular saturation issue, and the latter kinda looks wrong on reflection issues |
| 15:15.35 | kunigami_ | but shouldn't the phong shader ball look like a snooker ball? |
| 15:15.52 | ``Erik | on pure phong, it'll be very smooth with maybe banding |
| 15:16.32 | ``Erik | if it's a photon map or radiosity type thing before, then the normal will be randomly permutated and you'll get the grainyness |
| 15:17.46 | ``Erik | it could also be that a material property is effecting the normal |
| 15:23.46 | kunigami_ | hmm ok! thanks |
| 15:24.53 | ``Erik | either way, I'd imagine it's a minor issued compared to the src/liboptical/sh_osl.c work... *shrug* just my opinion, you may want to email Daniel Rossberg about it to see his thoughts :) |
| 15:25.08 | ``Erik | he's the one listed as your mentor, right? |
| 15:29.22 | kunigami_ | yup, it's him. ok, I'll send an email to him. |
| 15:30.01 | kunigami_ | I think I already completed what I was expected to do on the bounding time (according to my final proposal) |
| 15:30.35 | kunigami_ | thus, I was trying to do make more complex things before proceeding. |
| 15:31.14 | kunigami_ | anyway, my next task was to understand brlcad shading system |
| 15:37.24 | ``Erik | if it helps, sh_toon.c is something I just recently started, it's a very trivial example |
| 15:37.59 | kanzure | beep boop |
| 15:38.16 | kanzure | i'm still working on my rewrite of esolid |
| 15:38.23 | kanzure | it's a lot of code |
| 15:38.28 | kanzure | there are no unit tests |
| 15:38.46 | kanzure | and there's maybe another 5k lines to write before it might be working |
| 15:38.47 | kanzure | what should i do? |
| 15:43.54 | ``Erik | esolid? I'm not aware of that, can you quickly summarize? |
| 15:48.48 | ``Erik | sorry, gotta run, I'll be on later |
| 15:49.19 | kanzure | nurbs-based boolean operations |
| 15:49.35 | kanzure | (well, trimmed bezier patches) |
| 16:20.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:09.15 | CIA-117 | BRL-CAD: 03davidloman * r44621 10/geomcore/trunk/ (7 files in 2 dirs): Clean up the IDataSource interface a tad. |
| 17:17.48 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 17:25.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.43) | |
| 17:25.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:46.32 | CIA-117 | BRL-CAD: 03davidloman * r44622 10/geomcore/trunk/src/GS/FileDataSource.cxx: Start work on getListing() |
| 18:00.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:10.30 | starseeker | ah, bugger - http://dev.crypt.co.za/coffee/wiki?name=Project+Status |
| 18:10.35 | starseeker | how'd I miss THAT? |
| 18:21.00 | starseeker | kanzure: did you get a license OK from the original devs? |
| 18:34.59 | starseeker | hmm... apparently tcl/tk switched to fossil?? |
| 18:42.39 | starseeker | ah, right - after that CVS business on SF |
| 18:49.55 | kanzure | starseeker: no didn't get a response from him |
| 18:53.40 | kanzure | why would i be rewriting if i had a permissive license to use the original code? |
| 19:41.56 | CIA-117 | BRL-CAD: 03starseeker * r44623 10/brlcad/trunk/src/other/togl/ (CMakeLists.txt src/CMakeLists.txt): Use LIB_DIR variable for install, so Windows gets things where it expects them. |
| 19:42.10 | starseeker | kanzure: oh, you're re-writing from SCRATCH? |
| 19:42.17 | starseeker | thought you were re-factoring |
| 19:42.52 | kanzure | heh |
| 19:43.00 | kanzure | yeah... i'm doing something dumb |
| 19:43.07 | kanzure | it's taking me forever and i can't really judge my progress along the way |
| 19:43.27 | kanzure | i mean, i sort of am able to - like i have two boxes that are generated and i'm somewhere in the middle of the intersection code |
| 19:43.39 | kanzure | but i don't really know if all of my implementation works the same or not |
| 19:46.42 | starseeker | kanzure: if esolid had test cases, you should at least be able to feed those to your code to see if the results are the same |
| 19:46.54 | kanzure | it has no test cases |
| 19:46.59 | starseeker | winces |
| 19:47.10 | starseeker | are you building off of the opennurbs libraries? |
| 19:47.10 | kanzure | it's roughly 20,000 lines of code |
| 19:47.11 | kanzure | with no tests |
| 19:47.38 | kanzure | no i'm just doing a vanilla implementation/port first using esolid's code base |
| 19:47.45 | kanzure | and then i'll rip out all of the custom crap |
| 19:47.55 | kanzure | and replace it with opennurbs/opengl/scipy/numpy/clapack |
| 19:48.17 | starseeker | um... be careful about that - if you're building off of esolid's code base that might be seen as a "derivative work" |
| 19:48.33 | kanzure | yes i've examined the legal implications thoroughly |
| 19:48.38 | kanzure | don't worry |
| 19:48.45 | starseeker | nods. |
| 19:49.26 | starseeker | might be worth trying to call him if email didn't work - once in a while a phone call will get through where email won't |
| 19:49.43 | kanzure | sure |
| 19:49.52 | kanzure | but honestly, if it doesn't have unit tests, it's not worth that much |
| 19:49.57 | kanzure | someone will have to do what i'm doing eventually anyway |
| 19:50.05 | starseeker | true |
| 19:51.42 | starseeker | q |
| 19:51.45 | starseeker | whoops |
| 20:06.14 | kanzure | so now i don't know what to do |
| 20:06.25 | kanzure | http://diyhpl.us/cgit/lolcad/plain/esolid/esolid.py |
| 20:07.52 | kanzure | write unit tests for the original code base, then re-write them for my own? |
| 20:08.10 | kanzure | keep trucking and weep at the end as i slowly/painfully try to figure out why results are different? |
| 20:08.40 | starseeker | kanzure: how different would unit tests be between your code and the original? |
| 20:08.51 | kanzure | well it's just 2x the amount of code |
| 20:09.07 | kanzure | but other than that the initial upfront figuring out "wtf" is a one-time cost |
| 20:09.53 | starseeker | kanzure: might be worth verifying the original behavior |
| 20:11.19 | kanzure | true.. i should really do it |
| 20:11.28 | kanzure | HOW do these people write this code without testing? |
| 20:12.21 | starseeker | may have figured the tests were too messy to release |
| 20:15.40 | CIA-117 | BRL-CAD: 03starseeker * r44624 10/brlcad/trunk/src/other/togl/CMakeLists.txt: whoops, typo. |
| 21:20.47 | *** join/#brlcad crazy_imp (~mj@a89-183-22-49.net-htp.de) | |
| 21:43.33 | *** join/#brlcad Ralith (~ralith@d142-058-174-188.wireless.sfu.ca) | |
| 22:47.46 | *** join/#brlcad Ralith (~ralith@d142-058-174-188.wireless.sfu.ca) | |
