| 00:27.06 | brlcad | starseeker: so curious about that SIZEOF_*_T suffix.. That symbol from autoconf land is SIZEOF_type where type is the uppercase form of the C type. The _T isn't really applicable to all sizeof() checks |
| 00:27.11 | brlcad | just happens to be the suffix for size_t and a few others we check for. |
| 00:27.35 | brlcad | I very well might have wanted to check sizeof(FILE) for example or some X type or something else in order to behave accordingly |
| 00:28.35 | brlcad | actually, one of the checks is supposed to be checking the sizeof(void*), which should be SIZEOF_VOIDP |
| 00:34.16 | brlcad | (and I do think we use that in one or more places) |
| 01:02.06 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 02:33.52 | *** join/#brlcad IriX64 (~kvirc@65.95.123.211) | |
| 03:15.35 | CIA-65 | BRL-CAD: 03phoenixyjll * r50649 10/brlcad/trunk/src/librt/primitives/extrude/extrude_brep.cpp: |
| 03:15.36 | CIA-65 | BRL-CAD: Changed the position of the sketch in extrude according to the parameters. |
| 03:15.36 | CIA-65 | BRL-CAD: Some comment is added to make it clear. |
| 03:37.09 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 03:39.31 | CIA-65 | BRL-CAD: 03phoenixyjll * r50650 10/brlcad/trunk/src/librt/primitives/ (revolve/revolve_brep.cpp sketch/sketch_brep.cpp): The old version creates a circle just on the xy plane. Now it's created on the sketch plane. |
| 03:43.51 | CIA-65 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3727 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 1 */ |
| 04:39.53 | *** join/#brlcad anuragmurty (~anurag@14.139.128.11) | |
| 06:35.50 | *** join/#brlcad ksuzee (~ksuzee91@46.149.82.166) | |
| 07:20.41 | anuragmurty | brlcad: hi |
| 08:03.15 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:22.28 | anuragmurty | d_rossberg:hi |
| 08:23.14 | anuragmurty | i wanted to enquire about voxelize |
| 08:24.18 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 08:55.08 | d_rossberg | anuragmurty: morning |
| 08:55.20 | anuragmurty | morning |
| 08:55.42 | anuragmurty | are you free right now? |
| 09:10.06 | d_rossberg | no, but don't hesitate to ask though ;) |
| 09:13.46 | anuragmurty | oh ok.. so i have been through two examples pointed out by brlcad(sean)... one is rtexample, the other is viewweight.. that does give me some hints on how to go about determining what functions will be useful for voxelization |
| 09:15.20 | *** join/#brlcad kane_ (~kane@e182053064.adsl.alicedsl.de) | |
| 09:16.49 | anuragmurty | there will be rt_hit, rt_miss that i have to modify according to needs.. but what parameters will i need for voxelization? an obvious one would be size of voxel/number of voxels in each dimension.. i just want to know if i am thinking along the right directions.. obviously things should get clearer after i go through g_qa which samples 3D geometry |
| 09:25.33 | d_rossberg | other parameters could be: rays per voxel, the percentage a voxel has to be filled to take it into account |
| 09:28.59 | d_rossberg | the algorithm of voxelization probanly involves calling rt_shootray from a grid of start points with grid size = voxel size |
| 09:29.28 | anuragmurty | ok.. i get it i think |
| 09:31.13 | anuragmurty | and then we can use the ray partitions of rays from different views to decide which voxels to take into account.. ? |
| 09:33.06 | anuragmurty | i mean using that to calculate volume of that rectangle filled and then deciding.. |
| 10:33.53 | d_rossberg | you don't need different views: e.g. voxel size 1, you hit a component at 17.2 and leave it at 17.8 => 60% of this voxel is filled |
| 10:34.54 | d_rossberg | to improve this you need more rays through this voxel |
| 10:40.06 | *** join/#brlcad kane_ (~kane@e182053064.adsl.alicedsl.de) | |
| 11:16.02 | *** join/#brlcad kane_ (~kane@e182051111.adsl.alicedsl.de) | |
| 11:30.35 | starseeker | hmm, cool: http://news.sciencemag.org/sciencenow/2012/05/return-of-the-vacuum-tube.html |
| 11:58.27 | *** join/#brlcad kane_ (~kane@e182051111.adsl.alicedsl.de) | |
| 12:05.07 | *** join/#brlcad kane_ (~kane@e182051111.adsl.alicedsl.de) | |
| 12:10.52 | *** join/#brlcad kane_ (~kane@e182051111.adsl.alicedsl.de) | |
| 12:12.42 | CIA-65 | BRL-CAD: 03d_rossberg * r50651 10/brlcad/trunk/src/conv/ (10 files in 2 dirs): a raw (simple ASCII bag of triangles) to g geometry converter |
| 13:22.32 | CIA-65 | BRL-CAD: 03d_rossberg * r50652 10/brlcad/trunk/ (4 files in 2 dirs): |
| 13:22.32 | CIA-65 | BRL-CAD: apply sourceforge parch 3527658 (libbn_refactor_tolerance.diff) from kane_: |
| 13:22.32 | CIA-65 | BRL-CAD: "refactor and manage libbn tolerance uses by providing an interface default |
| 13:22.32 | CIA-65 | BRL-CAD: (e.g., an init macro) and making everyone use that where it is hardcoded to |
| 13:22.32 | CIA-65 | BRL-CAD: 0.0005 presently" |
| 13:39.04 | d_rossberg | kane_: i've just realized that there is a BN_TOL_INIT() macro which could be used to initialize bn_tol with default values |
| 13:40.11 | d_rossberg | to initialize the struct to zero there is another BN_TOL_INIT_ZERO() macro |
| 13:49.48 | CIA-65 | BRL-CAD: 03Anuragmurty 07http://brlcad.org * r3728 10/wiki/User:Anuragmurty: /* community bonding period */ |
| 13:50.21 | *** join/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 14:40.31 | *** join/#brlcad kane__ (~kane@e182051111.adsl.alicedsl.de) | |
| 15:19.12 | brlcad | anuragmurty: thanks and welcome (again) |
| 15:20.50 | *** join/#brlcad Stattrav_ (~Stattrav@61.12.114.82) | |
| 15:26.20 | CIA-65 | BRL-CAD: 03starseeker * r50653 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_CheckFunctions.cmake): This should improve the behavior and robustness of the type checking macro in BRL-CAD. While we're at it, make the variable names automatic and deduced from the type itself. |
| 15:36.40 | *** part/#brlcad kane_ (~kane@e182051111.adsl.alicedsl.de) | |
| 15:44.36 | brlcad | anuragmurty: do you have a good idea what your next steps need to be? |
| 15:45.05 | brlcad | rather, a specific action to be taken next |
| 15:52.17 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 16:23.28 | CIA-65 | BRL-CAD: 03n_reed * r50654 10/brlcad/trunk/src/other/step/src/cleditor/ (STEPfile.cc STEPfile.h seeinfodefault.h): Apply changes from SCL git 4858af2 removing code supporting step files (N279 files) that pre-date ISO 10303-21:1994. |
| 16:27.10 | anuragmurty | brl-cad: hi! was gone for dinner |
| 16:27.37 | brlcad | pretty sure that's allowed ;) |
| 16:27.48 | anuragmurty | i was able to talk to daniel today |
| 16:28.10 | anuragmurty | rt_shootray for a grid |
| 16:28.13 | brlcad | irc isn't always instantaneous, meant to lurk just like you did, see messages when you get back, sometimes interactive othertimes not |
| 16:28.18 | brlcad | yeah, I read |
| 16:28.39 | anuragmurty | yes.. so thats what i plan to do.. |
| 16:28.51 | anuragmurty | will contact if i hit a roadblock |
| 16:29.18 | anuragmurty | right now i don't think a very basic program would differ much from rtexample |
| 16:29.32 | anuragmurty | maybe i am wrong.. but thats what i am tryin |
| 16:30.04 | brlcad | probably won't but that's exactly the sort of progress you should post daily to the patches tracker until you have commit |
| 16:30.09 | brlcad | and document in your dev log on the wiki |
| 16:30.16 | brlcad | even if it's just one sentence |
| 16:30.41 | brlcad | I'd suggest starting with something very basic, like firing one ray ala rtexample |
| 16:31.39 | anuragmurty | hmm.. got it.. will do that right now.. |
| 16:31.41 | brlcad | or maybe fire a ray down three axes |
| 16:31.51 | brlcad | that could be the second step |
| 16:32.16 | brlcad | that would effectively triple sample a single cell |
| 16:32.58 | anuragmurty | yes.. i will do that.. i had another doubt.. |
| 16:33.19 | anuragmurty | firing from 3 different views v. 3 from the same direction |
| 16:33.31 | anuragmurty | same view i mean.. which is better?? |
| 16:33.39 | brlcad | understand daniel's point, though -- you certainly don't need more than one |
| 16:34.13 | brlcad | 3 from the same direction means what? |
| 16:34.18 | anuragmurty | same view.. |
| 16:34.26 | brlcad | 3 from the same view means what? |
| 16:34.33 | brlcad | 3 what? |
| 16:34.36 | anuragmurty | rays |
| 16:34.43 | anuragmurty | i think i am messing something up |
| 16:34.45 | brlcad | why would you shoot 3 rays? |
| 16:34.54 | anuragmurty | yes i now realise |
| 16:34.57 | anuragmurty | sorry abt that |
| 16:35.07 | brlcad | no need to apologize |
| 16:35.35 | anuragmurty | ok.. thanks though.. dunno what i was thinking |
| 16:35.38 | anuragmurty | :-/ |
| 16:35.51 | brlcad | you might want to shoot multiple rays to sample a voxel cell, that would be why you might shoot N rays |
| 16:36.04 | brlcad | but certainly not the same ray, or you'll just get the same information three times |
| 16:36.27 | anuragmurty | exactly.. i think i meant something like no. of rays per voxel vs. smaller voxels |
| 16:36.28 | brlcad | rays are infinitely thin -- they give you a thickness |
| 16:36.48 | anuragmurty | but again.. i guess i will think first |
| 16:41.41 | brlcad | just make sure that thinking also involves discussion :) |
| 16:42.08 | anuragmurty | ok.. :) |
| 16:42.15 | brlcad | this isn't like doing homework -- you're expected to interact as we have a vested interest in what you're doing |
| 16:42.33 | brlcad | you're not getting graded, you're making something others will use |
| 16:42.48 | brlcad | so at a minimum, you need to discuss it because we need to understand what you're doing too |
| 16:43.41 | anuragmurty | i will ensure i do that.. |
| 16:45.01 | brlcad | so I think a good goal to have for a few weeks out is getting whatever technique working for shooting rays, and then getting that into a command in mged/archer |
| 16:45.39 | brlcad | from the discussion on the mailing list a couple days ago, it'll be good to include conversion to voxel form as part of our conversion.sh script so we can validate conversions |
| 16:46.07 | brlcad | which means creating a 'vol' object for a given input geometry |
| 16:47.23 | brlcad | just something to keep in mind, since the first steps are more oriented around learning the rt_shootray() interface |
| 16:48.18 | brlcad | you need to be able to shoot a grid at a minimum, so perhaps that's best to do first |
| 16:50.08 | anuragmurty | hmm.. i think i am sort of comfortable with the shootray function.. will try out the 3 different views first, then the grid should follow.. |
| 16:50.36 | anuragmurty | will look at the conversions after i am done with these |
| 16:51.19 | brlcad | definitely post your sources now and then after you shoot three views (then after a grid) .. those are good checkpoints |
| 16:51.58 | anuragmurty | ok.. it will be on my log.. |
| 16:52.13 | brlcad | hm? |
| 16:52.31 | anuragmurty | oh sources.. yes |
| 16:52.59 | anuragmurty | i will do that.. |
| 16:53.02 | brlcad | great |
| 16:53.19 | brlcad | both should be every day, doesn't even matter if you're done -- it's about communicating your effort and progress |
| 16:53.36 | brlcad | both being log and patch/commit |
| 16:54.05 | anuragmurty | ok.. |
| 16:54.15 | brlcad | if you have any feedback on patches already in the tracker, those should take priority because we want to get you reviewed and access granted |
| 16:54.18 | brlcad | so you can be more efficient |
| 16:54.37 | brlcad | it's also a lot easier to review commits than it is patches ;) |
| 16:54.59 | anuragmurty | :) |
| 16:55.58 | brlcad | so yeah, post very very small incremental steps as patches and respond to any feedback with updates -- getting commit set up is the #1 priority |
| 16:57.16 | anuragmurty | i will do that.. actually d_rossberg is reviewing the patch i sent.. some problems, but should be done soon.. |
| 17:01.10 | brlcad | excellent, I meant more in general |
| 17:01.22 | brlcad | and not just for you, that's all students that don't yet have commit access |
| 17:02.22 | brlcad | this is the first time several students didn't put in effort during bonding period to obtain commit, so we need to get that sorted out quickly |
| 17:02.43 | brlcad | should have been done a month ago.. :) |
| 17:25.51 | *** part/#brlcad anuragmurty (~anurag@14.139.128.12) | |
| 17:33.42 | *** join/#brlcad Stattrav_ (~Stattrav@61.12.114.82) | |
| 18:24.14 | CIA-65 | BRL-CAD: 03Crdueck 07http://brlcad.org * r3729 10/wiki/User:Crdueck/log: |
| 19:00.45 | CIA-65 | BRL-CAD: 03tbrowder2 * r50655 10/brlcad/trunk/src/libbu/test_vls.c: add new tests, some format tidying |
| 19:10.46 | *** join/#brlcad cristina (~quassel@188.24.79.30) | |
| 19:11.52 | *** join/#brlcad cristina (~quassel@unaffiliated/cristina) | |
| 19:16.34 | *** join/#brlcad cristina (~quassel@188.24.79.30) | |
| 19:16.51 | *** join/#brlcad cristina (~quassel@unaffiliated/cristina) | |
| 19:22.48 | CIA-65 | BRL-CAD: 03tbrowder2 * r50656 10/brlcad/trunk/src/libbu/vls.c: correct operator for combining flags |
| 19:24.40 | CIA-65 | BRL-CAD: 03tbrowder2 * r50657 10/brlcad/trunk/src/libbu/vls.c: reformat for ease of seeing boolean choices |
| 19:26.20 | CIA-65 | BRL-CAD: 03tbrowder2 * r50658 10/brlcad/trunk/src/libbu/vls.c: add another legitimate snprintf flag charcacter |
| 19:30.33 | CIA-65 | BRL-CAD: 03tbrowder2 * r50659 10/brlcad/trunk/src/libbu/vls.c: eliminate check for field type here (even though it's a hybrid length modifier) |
| 19:34.54 | CIA-65 | BRL-CAD: 03tbrowder2 * r50660 10/brlcad/trunk/src/libbu/vls.c: move all length modifier checks to end of format specifier parse, add comment to that effect |
| 19:38.26 | CIA-65 | BRL-CAD: 03tbrowder2 * r50661 10/brlcad/trunk/src/libbu/vls.c: correct position of comment |
| 19:48.02 | CIA-65 | BRL-CAD: 03tbrowder2 * r50662 10/brlcad/trunk/src/libbu/vls.c: reorder length mod defs, add new length group |
| 19:51.04 | CIA-65 | BRL-CAD: 03tbrowder2 * r50663 10/brlcad/trunk/src/libbu/vls.c: remove spurious spaces |
| 19:58.40 | CIA-65 | BRL-CAD: 03tbrowder2 * r50664 10/brlcad/trunk/src/libbu/vls.c: don't clear length flags for 'l' or 'h' UNTIL we check for doubling--this should fix the 32-bit failure |
| 20:45.22 | CIA-65 | BRL-CAD: 03tbrowder2 * r50665 10/brlcad/trunk/TODO: 32-bit vls failure fixed with rev 50664, confirmed on 32-bit Linux Mint LMDE |
| 20:48.53 | CIA-65 | BRL-CAD: 03tbrowder2 * r50666 10/brlcad/trunk/src/libbu/vls.c: reorder vars for ease of maintenance |
| 20:50.18 | CIA-65 | BRL-CAD: 03tbrowder2 * r50667 10/brlcad/trunk/src/libbu/vls.c: clarify comment |
| 20:53.24 | CIA-65 | BRL-CAD: 03tbrowder2 * r50668 10/brlcad/trunk/src/libbu/vls.c: align vars, correct spacing, clarify comment |
| 20:56.34 | CIA-65 | BRL-CAD: 03tbrowder2 * r50669 10/brlcad/trunk/src/libbu/vls.c: eliminate unnecessary check |
| 20:57.24 | CIA-65 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3730 10/wiki/User:Stattrav/GSoC2012_log: Updation of logs for day 24 |
| 20:59.15 | CIA-65 | BRL-CAD: 03tbrowder2 * r50670 10/brlcad/trunk/src/libbu/vls.c: add another valid char possibility |
| 21:03.58 | CIA-65 | BRL-CAD: 03tbrowder2 * r50671 10/brlcad/trunk/src/libbu/vls.c: expand comment for clarity |
| 21:06.28 | CIA-65 | BRL-CAD: 03tbrowder2 * r50672 10/brlcad/trunk/src/libbu/vls.c: ws |
| 21:09.52 | CIA-65 | BRL-CAD: 03tbrowder2 * r50673 10/brlcad/trunk/src/libbu/vls.c: style, ws |
| 21:10.58 | CIA-65 | BRL-CAD: 03tbrowder2 * r50674 10/brlcad/trunk/src/libbu/vls.c: typo in comment expansion |
| 21:18.57 | CIA-65 | BRL-CAD: 03tbrowder2 * r50675 10/brlcad/trunk/src/libbu/vls.c: use a var for clarity and ease of maintenance |
| 21:21.46 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 21:24.43 | CIA-65 | BRL-CAD: 03tbrowder2 * r50676 10/brlcad/trunk/src/libbu/vls.c: more idiomatic |
| 21:26.05 | CIA-65 | BRL-CAD: 03tbrowder2 * r50677 10/brlcad/trunk/src/libbu/vls.c: add comment |
| 21:30.34 | *** join/#brlcad kane__ (~kane@e182051111.adsl.alicedsl.de) | |
| 21:31.11 | CIA-65 | BRL-CAD: 03tbrowder2 * r50678 10/brlcad/trunk/src/libbu/vls.c: tidy one comment, move another |
| 21:31.31 | *** part/#brlcad kane__ (~kane@e182051111.adsl.alicedsl.de) | |
| 21:36.20 | CIA-65 | BRL-CAD: 03tbrowder2 * r50679 10/brlcad/trunk/src/libbu/vls.c: combine decl with initialization |
| 21:40.55 | CIA-65 | BRL-CAD: 03tbrowder2 * r50680 10/brlcad/trunk/src/libbu/vls.c: combine decl with initialization |
| 21:43.55 | CIA-65 | BRL-CAD: 03tbrowder2 * r50681 10/brlcad/trunk/src/libbu/vls.c: ws |
| 22:05.37 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@elvyn-248-109.halls.student.lut.ac.uk) | |
| 22:28.47 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) | |
| 22:35.00 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@elvyn-248-109.halls.student.lut.ac.uk) | |
| 22:45.28 | *** join/#brlcad cristina_ (~quassel@188.24.71.175) | |
| 22:57.30 | CIA-65 | BRL-CAD: 03n_reed * r50682 10/brlcad/trunk/src/other/step/src/ (15 files in 2 dirs): apply SCL git e72ca29; remove some superfluous boolean types and use std bool more often |