| 00:16.09 | CIA-61 | BRL-CAD: 03bhinesley * r44907 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Some tests I was running regarding a bug in the ls command were accidently included in the last commit. Reverting |
| 00:27.28 | *** join/#brlcad crazy_imp (~mj@89.182.141.229) |
| 04:06.21 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 07:11.34 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) |
| 07:11.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 07:20.41 | *** join/#brlcad yiyus (1242712427@je.je.je) |
| 09:03.02 | *** join/#brlcad CIA-12 (~CIA@cia.atheme.org) |
| 09:37.53 | *** join/#brlcad CIA-49 (~CIA@cia.atheme.org) |
| 10:55.26 | CIA-49 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2918 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ |
| 11:46.58 | CIA-49 | BRL-CAD: 03brlcad * r44908 10/brlcad/trunk/doc/deprecation.txt: little more aggressive multiline matching even though it still will skip function pointer arguments |
| 12:18.04 | CIA-49 | BRL-CAD: 03brlcad * r44909 10/brlcad/trunk/ (65 files in 27 dirs): the days of supporting pre-ansi C compilers are long past. remove the BU_EXTERN() wrapper macro as a minimally impacting change. functions should be fully descriptive per ansi with type qualified parameter lists. |
| 12:25.14 | brlcad | has wanted to do that for more than 10 years! |
| 12:34.27 | CIA-49 | BRL-CAD: 03kunigami * r44910 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl_rt2.c): Added a simple c osl raytracer to call functions from osl_render. it does not leak memory |
| 12:36.19 | CIA-49 | BRL-CAD: 03kunigami * r44911 10/brlcad/trunk/src/liboptical/osl_rt.cpp: Changed osl_rt (cpp version) to use the wrapper functions instead of the class methods directly. it does not leak memory |
| 12:37.40 | CIA-49 | BRL-CAD: 03kunigami * r44912 10/brlcad/trunk/src/liboptical/sh_osl.c: Changed sh_osl so that the reference to OSLRenderer is stored in shader_specifics. It does leak memory :( |
| 12:51.18 | CIA-49 | BRL-CAD: 03brlcad * r44913 10/brlcad/trunk/misc/batch-indent-region.el: don't mess with the backslashes |
| 13:24.03 | CIA-49 | BRL-CAD: 03brlcad * r44914 10/brlcad/trunk/include/ (15 files): ws indent cleanup after BU_EXTERN removal |
| 13:24.22 | CIA-49 | BRL-CAD: 03brlcad * r44915 10/brlcad/trunk/regress/testlib.c: ws indent cleanup |
| 13:35.33 | kunigami | actually osl_rt2.c leaks memory too |
| 13:53.34 | brlcad | do you know why? :) |
| 13:55.51 | CIA-49 | BRL-CAD: 03brlcad * r44916 10/brlcad/trunk/include/tclcad.h: gah, remove the commas |
| 14:57.01 | kunigami | I know "where" :) it's on an open image io function called "OpenImageIO::v0::ustring::make_unique". It's probably that the raytracer is not freeing it. Unfortunately it has a lot of calling in between, including some LLVM code |
| 14:57.21 | kunigami | I'll have to dig further |
| 15:06.06 | kunigami | ouch, this leaking occurs also in osl code, namely the testshade application. |
| 15:17.02 | starseeker | kunigami: has the osl list been of any help with stuff like this? |
| 15:41.38 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) |
| 15:41.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 15:43.21 | kunigami | hmm, I've once asked by the usage and they did not answered me. But I didn't ask about the code. I'll check if is not a silly mistake and then send an email them. |
| 15:47.03 | *** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net) |
| 16:09.53 | kunigami | When I run with valgrind, rt finishes without crashing. This image: http://dl.dropbox.com/u/1399996/GSoC/WeirdRendering.png is a render of a scene where the floor has an osl yellow shader. Note the weird black strips on it |
| 16:15.53 | starseeker | kunigami: so does that image consitute the first ever BRL-CAD + OSL raytrace image? |
| 16:16.02 | kunigami | yes :) |
| 16:16.31 | starseeker | those black lines might be scan lines that never completed (if there were memory issues or something... you say it crashes without valgrind?) |
| 16:17.34 | kunigami | starseeker: yup |
| 16:18.04 | starseeker | I'd work on the crash first |
| 16:19.13 | kunigami | here is the gdb backtrace: http://pastebin.mozilla.org/1248665 |
| 16:28.03 | kunigami | Could that be an issue with multiple threads? |
| 16:50.38 | *** join/#brlcad merzo (~merzo@50-140-132-95.pool.ukrtel.net) |
| 16:54.37 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) |
| 16:54.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 16:59.14 | *** join/#brlcad merzo (~merzo@50-140-132-95.pool.ukrtel.net) |
| 17:23.57 | brlcad | woot, another logo submission |
| 17:25.24 | brlcad | kunigami: fwiw, OSL is pretty much a one-man show |
| 17:25.50 | brlcad | unfortunately he's not particularly interested in providing support (help) unless you find a bug or write patches, but it's good that you've been talking on the list anyways |
| 17:26.17 | kunigami | I had that impression too. Larry Gritz seems to be ahead of both OSL and OIIO |
| 17:26.29 | brlcad | nods |
| 17:26.43 | brlcad | nice guy, but not a lot of time |
| 17:27.13 | brlcad | kunigami: run rt -P1 and you won't get thread contention |
| 17:27.23 | brlcad | that image is fantastic progress, though :) |
| 17:27.32 | brlcad | worth posting to your log |
| 17:34.25 | bhinesley | what does the debug flag do besides change the install directory? |
| 17:34.28 | bhinesley | oops |
| 17:34.41 | bhinesley | ignore that... accidentally sent history |
| 17:39.40 | bhinesley | brlcad: We talked about a libged command registry a few days ago. Did you have any particulars in mind with regard to how you'd like the registry to work? |
| 17:45.30 | brlcad | definitely, started working on the interface over the weekend |
| 17:45.54 | bhinesley | oh, did you commit anything? |
| 17:52.24 | kunigami | running with rt -P1 stops the crashing! (actually I had tried with -P1 before, but I did "./rt example.g scene.c -P1" and just discovered that the order matters >.<) |
| 17:52.34 | kunigami | the strips are still there though |
| 18:31.16 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 18:50.22 | brlcad | kunigami: so two separate issues -- the strips are probably not threading related then and the crashing may be |
| 18:50.34 | brlcad | P1 just means use one processor |
| 18:51.42 | kunigami | yup. I'll check if it's not the case that the OSLRenderer is returning black pixels (I don't believe so) |
| 18:51.49 | CIA-49 | BRL-CAD: 03brlcad * r44917 10/brlcad/trunk/include/fb.h: common comes before all system headers |
| 18:51.59 | CIA-49 | BRL-CAD: 03brlcad * r44918 10/brlcad/trunk/include/ged.h: common comes before all system headers |
| 18:56.27 | CIA-49 | BRL-CAD: 03brlcad * r44919 10/brlcad/trunk/src/rt/viewg3.c: comment ws indent style cleanup |
| 18:59.00 | brlcad | yeah, not likely |
| 18:59.31 | brlcad | osl wouldn't know about a scanline |
| 18:59.45 | brlcad | undoubtedly something in sh_osl.c |
| 19:16.37 | kunigami | It was actually OSLRenderer that was returning the black points :) The random erand48 depends on the y-coordinate :P |
| 19:19.09 | kunigami | I'm not sure how we'll deal with the recursion. |
| 19:19.57 | kunigami | OSLRenderer finds a multiplier, generates a new ray and recurse |
| 19:20.12 | kunigami | the problems is that not all objects are using osl_shaders |
| 19:21.02 | kunigami | OSLRender would have to return this multiplier back to brlcad system |
| 19:27.15 | kunigami | but how to deal with reflection and refraction? |
| 19:53.38 | kunigami | - |
| 19:54.15 | kunigami | should I use "struct bu_vls" instead of "char *"? |
| 19:54.49 | brlcad | that's pretty interesting |
| 19:56.54 | CIA-49 | BRL-CAD: 03r_weiss * r44920 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 19:56.54 | CIA-49 | BRL-CAD: Made additional corrections to logic in functions 'nmg_booltree_evaluate' and |
| 19:56.54 | CIA-49 | BRL-CAD: 'nmg_boolean' within file 'nmg_bool.c'. This fix stops the error 'nmg_boolean() |
| 19:56.54 | CIA-49 | BRL-CAD: result of nmg_booltree_evaluate() isn't tp' which occurs occasionally when |
| 19:56.55 | CIA-49 | BRL-CAD: performing nmg boolean operations such as when using the mged 'facetize' |
| 19:56.55 | CIA-49 | BRL-CAD: command. This change also allows boolean operations to return a null result |
| 19:56.56 | CIA-49 | BRL-CAD: without failing. |
| 19:57.06 | brlcad | those are (sometimes) shader properties, so it'd be the shader shooting any new rays needed (via librt) .. user might write some interesting osl shader that requires thousands of new rays to get generated for each pixel |
| 19:57.57 | brlcad | kunigami: vls vs char* => "it depends" |
| 19:58.20 | brlcad | if you need a dynamic string in C, vls is the way to go |
| 19:58.26 | brlcad | if you're in c++, just use a std::string |
| 19:59.16 | brlcad | if you're just storing a name or label and there's no need for the string to be variable in size, then a char[] might be appropriate |
| 19:59.43 | brlcad | when in doubt, vls |
| 20:00.06 | kunigami | I'd like to add a parameter to sh_osl so that the user can specify which osl shader to use |
| 20:00.16 | kunigami | I think vls is better then |
| 20:04.14 | brlcad | what about embedding an actual osl shader? |
| 20:15.34 | kunigami | do you mean independent from rt? |
| 20:26.27 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 20:26.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) |
| 20:36.09 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 21:04.49 | brlcad | kunigami: I mean embedding new shader descriptions, like this: https://github.com/fohr/openshadinglanguage/blob/testrender/src/shaders/matte.osl |
| 21:05.42 | brlcad | so you could define new shaders and new shader behavior at runtime or at least without recompiling brl-cad |
| 21:05.52 | brlcad | (or osl) |
| 21:21.59 | CIA-49 | BRL-CAD: 03starseeker * r44921 10/brlcad/trunk/src/rt/viewg3.c: fix C comment formatting |
| 21:24.32 | starseeker | bhinesley: I'm getting a problem with Archer |
| 21:24.46 | bhinesley | what's that? |
| 21:24.59 | starseeker | bhinesley: when I launch archer and open a .g file with the File->Open menu option, I can't raytrace the result |
| 21:25.29 | starseeker | when I launch archer and supply the .g file name from the command line (e.g. ./bin/archer m35.g) I can raytrace it |
| 21:25.46 | bhinesley | I'll take a look |
| 21:25.57 | starseeker | thanks |
| 21:30.52 | starseeker | I think it has to do with the path that is being passed to rt |
| 21:31.56 | starseeker | I'm seeing : |
| 21:32.00 | starseeker | opendb /home/user/brlcad/brlcad-build//home/user/brlcad/brlcad-build/share/brlcad/7.20.1/db/m35.g~ |
| 21:33.10 | starseeker | when I specify from the command line I get: |
| 21:33.13 | starseeker | opendb /home/user/brlcad/brlcad-build/share/brlcad/7.20.1/db/m35.g~ |
| 21:41.54 | bhinesley | hm, I'm getting the same (wrong) result no matter how I open the .g file |
| 21:43.48 | starseeker | bhinesley: could that be a consequence of your recent changes? |
| 21:44.03 | bhinesley | I'm not seeing how... they're minor/straightforward |
| 21:49.18 | bhinesley | yeah, it's definitely not that |
| 21:49.49 | starseeker | hrm |
| 21:54.45 | bhinesley | Okay, it runs for me when I am in the directory of the .g file. If I give it a full path it fails even from the command line. |
| 22:12.24 | starseeker | bhinesley: weird... this must be some kind of recent change, it worked just a little while ago... |
| 22:13.12 | bhinesley | starseeker: yeah, I've looked through recent svn logs on related files but haven't found anything interesting yet |
| 22:42.42 | starseeker | bhinesley: yeah, me either |
| 22:53.34 | bhinesley | starseeker: well, you're right about it being a recent change. I updated to r44873, which was 4 days ago, and it works fine. |
