| 01:04.39 | Notify | 03BRL-CAD:starseeker * 56847 brlcad/trunk/src/conv/step/ON_Brep.cpp: Get at the SdaiPath inside of the SdaiEdge_loop - adding the edges to THAT edge list appears to work. Horribly unintuitive on the part of SdaiEdge_loop - what's the point of exposing _edge_list at all? - but at least it seems to function. |
| 01:08.22 | Notify | 03BRL-CAD:starseeker * 56848 brlcad/trunk/src/other/stepcode/src/fedex_plus/classes.c: Back out r56838 - not the correct approach, from the looks of things. |
| 01:24.28 | Notify | 03BRL-CAD:starseeker * 56849 brlcad/trunk/src/conv/step/ON_Brep.cpp: Cleanup, update comments |
| 01:24.41 | starseeker | phew, finally |
| 02:16.33 | Notify | 03BRL-CAD:starseeker * 56850 (brlcad/trunk/src/other/stepcode/CMakeLists.txt brlcad/trunk/src/other/stepcode/data/CMakeLists.txt and 58 others): Update stepcode to commit da3fe4543f86047a176a2f899d1c485a6ab8f9e8 from the primary repository - merges changes for diamond inheritance, incorporates BRL-CAD changes, etc. |
| 02:24.37 | starseeker | brlcad: we're up to date now |
| 03:52.07 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 04:09.31 | brlcad | starseeker: I saw that, awesome.. will have to give our converter a test |
| 06:43.18 | Notify | 03BRL-CAD:phoenixyjll * 56851 brlcad/trunk/src/libbrep/boolean.cpp: Deal with ccx_overlap. And treat points on boundary the same as they are outside. |
| 08:42.33 | *** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net) | |
| 08:43.16 | zero_level | brlcad , ``Erik : Can u guide me to some source where dpix files are generated. ? |
| 09:50.59 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 10:22.43 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5981 /wiki/User:Izak/GSOC_2013_logs: /* August 12th to August 17th */ |
| 10:28.10 | Notify | 03BRL-CAD:phoenixyjll * 56852 brlcad/trunk/src/libbrep/boolean.cpp: Implement get_subcurve_inside_faces(), because the intersection curve of SSI is the whole surface, and we need to get the part inside the trimmed face's outer loop. |
| 10:33.33 | Notify | 03BRL-CAD:mohitdaga * 56853 brlcad/trunk/src/libicv/CMakeLists.txt: Add dpix.c in libicv. This file will contain routines to read and write images in dpix format. Also added normalize function which will be used to normalize the value in image |
| 10:37.36 | Notify | 03BRL-CAD:phoenixyjll * 56854 brlcad/trunk/src/libbrep/boolean.cpp: It seems that div_t shadows a global declaration. Rename it to divT. |
| 10:46.26 | brlcad | zero_level: not off the top of my head, I'd just start by grepping the source tree for 'dpix' |
| 10:46.40 | brlcad | not much uses or supports it |
| 10:46.55 | brlcad | I believe the ray tracer can output dpix with the right flags |
| 10:47.13 | brlcad | at least I think one of them can |
| 10:57.02 | Notify | 03BRL-CAD:mohitdaga * 56855 brlcad/trunk/src/libicv/dpix.c: Make a more strong condition in normalization regarding the data enteries. Now this function normalizes only when the data entries are out of order. |
| 10:59.43 | Notify | 03BRL-CAD:mohitdaga * 56856 brlcad/trunk/src/libicv/dpix.c: Add dpix read function. |
| 11:07.50 | Notify | 03BRL-CAD:mohitdaga * 56857 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/fileformat.c): Add dpix read image to icv_read function. |
| 11:08.40 | Notify | 03BRL-CAD:mohitdaga * 56858 (brlcad/trunk/src/libicv/dpix.c brlcad/trunk/src/libicv/fileformat.c): Trailing WS |
| 11:08.56 | Notify | 03BRL-CAD:tbrowder2 * 56859 brlcad/trunk/misc/auto-man-page/README.auto-man-page-handling: tighten format rules a bit |
| 11:10.06 | *** join/#brlcad harjot (~harjot@202.164.53.117) | |
| 11:14.57 | Notify | 03BRL-CAD:tbrowder2 * 56860 brlcad/trunk/misc/auto-man-page/README.auto-man-page-handling: correct grammar; add reference to working example |
| 11:18.08 | Notify | 03BRL-CAD:mohitdaga * 56861 brlcad/trunk/src/libicv/dpix.c: Clarify size variable. |
| 11:23.02 | Notify | 03BRL-CAD:mohitdaga * 56862 brlcad/trunk/src/libicv/dpix.c: Add write function for dpix files. |
| 11:24.12 | zero_level | brlcad : Grepping the src code. :) |
| 11:24.32 | zero_level | I wonder we dont have man page for dpix files, where as we have for bw,pix files. |
| 11:39.48 | Notify | 03BRL-CAD:mohitdaga * 56863 brlcad/trunk/src/libicv/fileformat.c: Add dpix write option to icv_write. |
| 11:40.29 | zero_level | brlcad : after r56863. ICV Can read write dpix images. :) |
| 11:41.46 | *** join/#brlcad harjot (~harjot@202.164.53.117) | |
| 12:38.02 | zero_level | brlcad : I see only one utility using this. dpix-pix. |
| 12:39.48 | zero_level | ``Erik ,brlcad : I would like you to see r56856. Is this type of normalization good for dpix format. ? |
| 12:43.26 | zero_level | A feedback behind the strict condition will be nice. |
| 12:43.43 | Notify | 03BRL-CAD:phoenixyjll * 56864 brlcad/trunk/src/libbrep/boolean.cpp: Error handling in get_subcurve_inside_faces(): sub_curve() may return a NULL pointer. |
| 12:44.16 | ``Erik | erm, it doesn't seem to do any normalization at all, and looks like it'd probably generate a garbage image by blindly packing data from a double array into a uchar8 array? |
| 12:44.32 | ``Erik | or, wait, bif->data is doubles now, hm |
| 12:45.24 | ``Erik | my gut feeling is that accessing bif->data directly is prone to bugs, the hope is to encapsulate the data field so it can be altered in the future with minimal effort |
| 12:45.54 | Notify | 03BRL-CAD:phoenixyjll * 56865 brlcad/trunk/src/libbrep/boolean.cpp: Ignore UNSET IntersectPoints when maintaining the stack. |
| 12:48.04 | ``Erik | maybe use a buffer of width*height*3*sizeof(double) size, then have a function to write the data in? (either by pixel, by scanline or by buffer) |
| 13:02.14 | zero_level | ``Erik : It does normalization. |
| 13:02.24 | zero_level | It doesnt create any garbage. |
| 13:02.32 | zero_level | Algorith used. |
| 13:02.42 | zero_level | find min and max values. |
| 13:03.35 | zero_level | if (max>1.0 or min < 0.0) // strict condition . |
| 13:04.18 | zero_level | then for each data entry d, change d = (d-min)/max-min; |
| 13:06.52 | Notify | 03BRL-CAD:mohitdaga * 56866 brlcad/trunk/src/libicv/dpix.c: Add comment for strict normalization. (Erik this should clarify) |
| 13:08.15 | zero_level | ``Erik : I hope,I am able to understand you. :) |
| 13:34.45 | Notify | 03BRL-CAD Wiki:Phoenix * 5982 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 9 */ |
| 13:44.13 | Notify | 03BRL-CAD:carlmoore * 56867 (brlcad/trunk/misc/auto-man-page/README.auto-man-page-handling brlcad/trunk/sh/shtool brlcad/trunk/src/conv/step/ON_Brep.cpp): remove trailing blanks/tabs, and fix spelling |
| 14:06.59 | ``Erik | zero_level: I was looking at the diff for 56856, that itself doesn't contain the normalize routine or a call to it, let me look a bit more :) |
| 14:10.53 | ``Erik | yeah, the icv_normalize() looks reasonable... but I don't see where it's called... I'm also not sure why the special cases to avoid normalization would be there? |
| 14:14.19 | Notify | 03BRL-CAD:mohitdaga * 56868 brlcad/trunk/src/libicv/dpix.c: Calling icv_normalize in dpix read. |
| 14:14.23 | zero_level | ok. |
| 14:14.40 | zero_level | icv_normalize was intended for dpix read. |
| 14:14.55 | zero_level | i didnt call it because i wanted to be 100 % sure. |
| 14:15.23 | zero_level | special case is to avoid scaling or descaling of values. |
| 14:15.48 | zero_level | for eg let a image contain pixel values between (23-220) |
| 14:16.44 | zero_level | that is (0.9 - 0.86) |
| 14:17.07 | zero_level | I dont want that these are forced to values between (0-1) |
| 14:17.14 | zero_level | Thus strict normalization. |
| 14:17.28 | zero_level | ``Erik : I hope I made some sense here. |
| 14:18.10 | zero_level | Also the gensis of all these normalization stuff came from dpix-pix (a single resource in brlcad source code to understand dpix format) |
| 14:19.10 | zero_level | ``Erik : by the look of util/dpix-pix.c it turns out that dpix files can contain any values in [a,b] where a<b are two double values. |
| 14:32.51 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 14:40.34 | Notify | 03BRL-CAD:starseeker * 56869 brlcad/trunk/src/conv/step/ON_Brep.cpp: Add faces to STEP output. |
| 15:00.04 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 15:20.10 | Notify | 03BRL-CAD:starseeker * 56870 brlcad/trunk/src/conv/step/ON_Brep.cpp: Start working on the top level structures needed for a valid step file. |
| 16:11.36 | Notify | 03BRL-CAD:n_reed * 56871 (brlcad/trunk/src/conv/step/BRLCADWrapper.cpp brlcad/trunk/src/conv/step/step-g.cpp): Fix valgrind branch-on-uninitialized-value warning. Since step-g called BRLCADWrapper::Close even if no database was loaded, db_close would get a garbage pointer causing a bomb. |
| 16:50.24 | Notify | 03BRL-CAD:tbrowder2 * 56872 brlcad/trunk/misc/auto-man-page/README.auto-man-page-handling: use correct format--no spaces allowed in keywords |
| 17:10.28 | Ch3ck_ | starseeker: corrected patch 223, works perfectly now. also seen that patch 226 has been accepted but not in source code. However looking at the bn_poly_synthetic_divsion() test, the seg fault actually comes from the poly_synthetic division routine itself |
| 17:15.16 | Ch3ck_ | looking at the code here http://pastebin.com/9ptu2tF9 |
| 17:17.09 | Ch3ck_ | i actually think its as the result of the quo->cf[n+divisor] part which i think may have an error case of n + divisor > dgr+1 which causes the seg fault still working on it. |
| 17:23.05 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5983 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 12 August - 18 August */ |
| 17:58.06 | Notify | 03BRL-CAD:ejno * 56873 (brlcad/branches/opencl/src/librt/primitives/sph/sph.c brlcad/branches/opencl/src/librt/primitives/sph/sph_shot.cl): benchmark script; print debugging values |
| 18:01.48 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 18:04.12 | ejno | brlcad: I've found the problem: this OpenCL implementation doesn't seem to support double-precision; it's using floats instead |
| 18:04.40 | ejno | I assumed a CPU implementation would support doubles, but apparently not unless I'm mistaken |
| 18:04.47 | brlcad | did you confirm that's the first change observed in the computation pipeline? |
| 18:05.04 | ejno | yes, I get the same values when I change the RT code to use doubles |
| 18:05.09 | ejno | s/doubles/floats |
| 18:06.49 | brlcad | so changing that type makes no difference but when do the values diverge from the CPU calculations? right away? |
| 18:07.03 | brlcad | even single precision floating point should "predominantly" match |
| 18:07.46 | brlcad | that's 7 decimal places out, more than our calculation tolerance, so in theory one should still be able to obtain perfectly matching results at least a large portion of the time |
| 18:10.16 | ejno | here is the output: http://paste.kde.org/pc57af004/ |
| 18:11.05 | ejno | I mean, the rt values match the opencl values when rt uses floats instead of doubles |
| 18:11.40 | ejno | double support is optional in opencl, so I think that's the problem |
| 18:20.17 | Izak_ | brlcad: Is there an mged/archer command to test rt_hrt_prep() routine just as the l command tests the rt_hrt_describe() ? |
| 18:22.49 | ejno | brlcad: oh, ok. I will try other values |
| 18:23.29 | ejno | brlcad: yes, they diverge right away |
| 18:25.50 | Izak_ | ``Erik: Is there an mged/archer command to test rt_hrt_prep() routine just as the l command tests the rt_hrt_describe() ? |
| 18:34.15 | ejno | I mean, not the same final pixel values, but the same debug value printings. So, if it's below the calculation tolerance then it's not the problem |
| 18:35.01 | ejno | what is the advantage of doubles over floats? |
| 18:36.17 | ejno | oh, they are faster on the CPU |
| 18:36.45 | brlcad | ejno:do you have this in your code: |
| 18:36.45 | brlcad | #pragma OPENCL EXTENSION cl_khr_fp64 : enable |
| 18:37.21 | brlcad | before any double declarations in the code |
| 18:38.05 | ejno | I just recently added that and it didn't seem to have an effect |
| 18:38.11 | brlcad | even better, this block: |
| 18:38.12 | brlcad | http://www.bealto.com/gpu-fft2_real-type.html |
| 18:38.28 | brlcad | put a #error into each of those blocks to see if either extension is available |
| 18:38.33 | ejno | because I read that doubles were an optional builtin in opencl 1.2 |
| 18:38.49 | ejno | ok |
| 18:39.32 | brlcad | #ifdef cl_khr_fp64 #pragma OPENCL EXTENSION cl_khr_fp64 : enable |
| 18:39.32 | brlcad | #elif defined(cl_amd_fp64) #pragma OPENCL EXTENSION cl_amd_fp64 : enable |
| 18:39.32 | brlcad | #else #error "Double precision floating point not supported by OpenCL implementation." |
| 18:39.36 | brlcad | #endif |
| 18:40.03 | ejno | ok, I will try that. I also put this in and didn't get the #error: http://stackoverflow.com/a/7004114 |
| 18:40.37 | brlcad | okay excellent.. so it should have one of those two then |
| 18:40.49 | brlcad | note that goes into the .cl file |
| 18:41.22 | brlcad | may also need to be in the .c file, so perhaps just put it in a header and include it in both |
| 18:41.32 | ejno | oh, ok |
| 18:42.01 | brlcad | the advantage is more precision before the numbers are meaningless |
| 18:42.17 | brlcad | in our output, notice the values diverage at 5 places after the decimal point |
| 18:43.03 | brlcad | single precision usually give about 7-8 digits of precision, so that fits your output |
| 18:43.23 | brlcad | what are ov and b? |
| 18:44.13 | ejno | ov is the vector from ray origin to center of the sphere |
| 18:44.31 | ejno | b is from the quadratic equation |
| 18:44.56 | ejno | the dot product of the ray's direction and ov |
| 18:45.24 | brlcad | er, ov is the ray origin? |
| 18:46.04 | brlcad | that's coming straight from rt land, so that is a little surprising that they're instantly that divergent |
| 18:46.42 | ejno | it's the vector from origin to sphere center |
| 18:47.33 | ejno | ov is calculated by the shot function |
| 18:48.02 | brlcad | oh, so what's the starting ray information? |
| 18:48.10 | brlcad | point and vector |
| 18:48.25 | brlcad | struct ray * in the cpu version |
| 18:50.57 | ejno | so if it differs at 5 decimal places, it is affecting the final pixel colors? |
| 18:53.26 | ejno | I found how to query for double support in opencl 1.2 - it's in the host code; I'll try that |
| 19:03.24 | Notify | 03BRL-CAD:starseeker * 56874 (brlcad/trunk/src/conv/step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step.cpp): populate header, assign empty names to unnamed objects. |
| 19:03.45 | Notify | 03BRL-CAD:starseeker * 56875 brlcad/trunk/src/other/stepcode/src/cleditor/STEPfile.cc: Quote time stamp |
| 19:09.57 | ejno | it indicates that double is supported |
| 19:29.31 | Notify | 03BRL-CAD:iiizzzaaakkk * 56876 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Added rt_hrt_ifree() to Free the storage associated with the rt_db_internal version of this |
| 19:31.39 | Izak_ | brlcad:``Erik: Is there an mged/archer command to test rt_hrt_prep() routine just as the l command tests the rt_xx_describe() ? |
| 19:38.48 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5984 /wiki/User:Izak/GSOC_2013_logs: /* August 12th to August 17th */ |
| 19:48.53 | brlcad | ejno: if double is supported, then those differences should not be there |
| 19:49.50 | brlcad | that's 5 after the decimal plus 2 more before (in floating point, it'll be 1.3271881727181232e2 for example |
| 19:50.03 | brlcad | so that's the 7 digits of single-precision |
| 19:50.08 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5985 /wiki/User:Izak/GSOC_2013_logs: /* August 12th to August 17th */ |
| 19:51.19 | brlcad | Izak_: prep is called during raytrace, so the "rt" command |
| 19:56.43 | Notify | 03BRL-CAD:starseeker * 56877 brlcad/trunk/src/conv/step/ON_Brep.cpp: Set some values - need to study these more carefully to be sure the mappings are the ones that should be there... |
| 19:58.41 | Notify | 03BRL-CAD:carlmoore * 56878 brlcad/trunk/src/conv/jack/g-jack.c: alert the user of writing of files (at this time, only '.fig' file is mentioned explicitly |
| 20:04.57 | Izak_ | brlcad: Okay thanks |
| 20:16.44 | Izak_ | brlcad: Are students allowed to attend the Google Summer of Code Mentor Summit? |
| 20:17.16 | ``Erik | Izak_: mentor summit is for mentors, not students... |
| 20:17.44 | ``Erik | I don't believe mged or archer have a way to exercise just prep, but 'rt' will call prep during the gettrees phase, before the first ray is fired... |
| 20:20.23 | Izak_ | ``Erik: i just got selected for the Doc Camp summit in Mountain View and i am asked if I would like to attend the Mentor Summit |
| 20:24.43 | *** join/#brlcad mpictor (~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505) | |
| 20:44.20 | Notify | 03BRL-CAD:carlmoore * 56879 brlcad/trunk/src/conv/g-nff.c: add h? options; delete P because it was unused (ncpu set to 1) |
| 20:50.38 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5986 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 12 August - 18 August */ |
| 20:52.11 | Ch3ck | starseeker: please apply tickets 223 and 225 will finish fixing 225 tommorow |
| 20:53.35 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 20:55.39 | Izak_ | screen -d |
| 23:02.46 | Notify | 03BRL-CAD:starseeker * 56880 brlcad/trunk/src/conv/step/ON_Brep.cpp: Finally got a working creation and writing of a complex type - now just need to figure out how to manipulate the individual pieces. |