IRC log for #brlcad on 20130815

01:04.39Notify03BRL-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.22Notify03BRL-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.28Notify03BRL-CAD:starseeker * 56849 brlcad/trunk/src/conv/step/ON_Brep.cpp: Cleanup, update comments
01:24.41starseekerphew, finally
02:16.33Notify03BRL-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.37starseekerbrlcad: we're up to date now
03:52.07*** join/#brlcad kesha_ (~kesha@14.139.122.114)
04:09.31brlcadstarseeker: I saw that, awesome.. will have to give our converter a test
06:43.18Notify03BRL-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.16zero_levelbrlcad , ``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.43Notify03BRL-CAD Wiki:IIIzzzaaakkk * 5981 /wiki/User:Izak/GSOC_2013_logs: /* August 12th to August 17th */
10:28.10Notify03BRL-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.33Notify03BRL-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.36Notify03BRL-CAD:phoenixyjll * 56854 brlcad/trunk/src/libbrep/boolean.cpp: It seems that div_t shadows a global declaration. Rename it to divT.
10:46.26brlcadzero_level: not off the top of my head, I'd just start by grepping the source tree for 'dpix'
10:46.40brlcadnot much uses or supports it
10:46.55brlcadI believe the ray tracer can output dpix with the right flags
10:47.13brlcadat least I think one of them can
10:57.02Notify03BRL-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.43Notify03BRL-CAD:mohitdaga * 56856 brlcad/trunk/src/libicv/dpix.c: Add dpix read function.
11:07.50Notify03BRL-CAD:mohitdaga * 56857 (brlcad/trunk/include/icv.h brlcad/trunk/src/libicv/fileformat.c): Add dpix read image to icv_read function.
11:08.40Notify03BRL-CAD:mohitdaga * 56858 (brlcad/trunk/src/libicv/dpix.c brlcad/trunk/src/libicv/fileformat.c): Trailing WS
11:08.56Notify03BRL-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.57Notify03BRL-CAD:tbrowder2 * 56860 brlcad/trunk/misc/auto-man-page/README.auto-man-page-handling: correct grammar; add reference to working example
11:18.08Notify03BRL-CAD:mohitdaga * 56861 brlcad/trunk/src/libicv/dpix.c: Clarify size variable.
11:23.02Notify03BRL-CAD:mohitdaga * 56862 brlcad/trunk/src/libicv/dpix.c: Add write function for dpix files.
11:24.12zero_levelbrlcad : Grepping the src code. :)
11:24.32zero_levelI wonder we dont have man page for dpix files, where as we have for bw,pix files.
11:39.48Notify03BRL-CAD:mohitdaga * 56863 brlcad/trunk/src/libicv/fileformat.c: Add dpix write option to icv_write.
11:40.29zero_levelbrlcad : after r56863. ICV Can read write dpix images. :)
11:41.46*** join/#brlcad harjot (~harjot@202.164.53.117)
12:38.02zero_levelbrlcad : I see only one utility using this. dpix-pix.
12:39.48zero_level``Erik ,brlcad : I would like you to see r56856. Is this type of normalization good for dpix format. ?
12:43.26zero_levelA feedback behind the strict condition will be nice.
12:43.43Notify03BRL-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``Erikerm, 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``Erikor, wait, bif->data is doubles now, hm
12:45.24``Erikmy 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.54Notify03BRL-CAD:phoenixyjll * 56865 brlcad/trunk/src/libbrep/boolean.cpp: Ignore UNSET IntersectPoints when maintaining the stack.
12:48.04``Erikmaybe 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.14zero_level``Erik : It does normalization.
13:02.24zero_levelIt doesnt create any garbage.
13:02.32zero_levelAlgorith used.
13:02.42zero_levelfind min and max values.
13:03.35zero_levelif (max>1.0 or min < 0.0) // strict condition .
13:04.18zero_levelthen for each data entry d, change d = (d-min)/max-min;
13:06.52Notify03BRL-CAD:mohitdaga * 56866 brlcad/trunk/src/libicv/dpix.c: Add comment for strict normalization. (Erik this should clarify)
13:08.15zero_level``Erik : I hope,I am able to understand you. :)
13:34.45Notify03BRL-CAD Wiki:Phoenix * 5982 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 9 */
13:44.13Notify03BRL-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``Erikzero_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``Erikyeah, 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.19Notify03BRL-CAD:mohitdaga * 56868 brlcad/trunk/src/libicv/dpix.c: Calling icv_normalize in dpix read.
14:14.23zero_levelok.
14:14.40zero_levelicv_normalize was intended for dpix read.
14:14.55zero_leveli didnt call it because i wanted to be 100 % sure.
14:15.23zero_levelspecial case is to avoid scaling or descaling of values.
14:15.48zero_levelfor eg let a image contain pixel values between (23-220)
14:16.44zero_levelthat is (0.9 - 0.86)
14:17.07zero_levelI dont want that these are forced to values between (0-1)
14:17.14zero_levelThus strict normalization.
14:17.28zero_level``Erik : I hope I made some sense here.
14:18.10zero_levelAlso the gensis of all these normalization stuff came from dpix-pix (a single resource in brlcad source code to understand dpix format)
14:19.10zero_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.34Notify03BRL-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.10Notify03BRL-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.36Notify03BRL-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.24Notify03BRL-CAD:tbrowder2 * 56872 brlcad/trunk/misc/auto-man-page/README.auto-man-page-handling: use correct format--no spaces allowed in keywords
17:10.28Ch3ck_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.16Ch3ck_looking at the code here http://pastebin.com/9ptu2tF9
17:17.09Ch3ck_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.05Notify03BRL-CAD Wiki:NyahCh3ck20 * 5983 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 12 August - 18 August */
17:58.06Notify03BRL-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.12ejnobrlcad: I've found the problem: this OpenCL implementation doesn't seem to support double-precision; it's using floats instead
18:04.40ejnoI assumed a CPU implementation would support doubles, but apparently not unless I'm mistaken
18:04.47brlcaddid you confirm that's the first change observed in the computation pipeline?
18:05.04ejnoyes, I get the same values when I change the RT code to use doubles
18:05.09ejnos/doubles/floats
18:06.49brlcadso changing that type makes no difference but when do the values diverge from the CPU calculations?  right away?
18:07.03brlcadeven single precision floating point should "predominantly" match
18:07.46brlcadthat'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.16ejnohere is the output: http://paste.kde.org/pc57af004/
18:11.05ejnoI mean, the rt values match the opencl values when rt uses floats instead of doubles
18:11.40ejnodouble support is optional in opencl, so I think that's the problem
18:20.17Izak_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.49ejnobrlcad: oh, ok. I will try other values
18:23.29ejnobrlcad: yes, they diverge right away
18:25.50Izak_``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.15ejnoI 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.01ejnowhat is the advantage of doubles over floats?
18:36.17ejnooh, they are faster on the CPU
18:36.45brlcadejno:do you have this in your code:
18:36.45brlcad#pragma OPENCL EXTENSION cl_khr_fp64 : enable
18:37.21brlcadbefore any double declarations in the code
18:38.05ejnoI just recently added that and it didn't seem to have an effect
18:38.11brlcadeven better, this block:
18:38.12brlcadhttp://www.bealto.com/gpu-fft2_real-type.html
18:38.28brlcadput a #error into each of those blocks to see if either extension is available
18:38.33ejnobecause I read that doubles were an optional builtin in opencl 1.2
18:38.49ejnook
18:39.32brlcad#ifdef cl_khr_fp64 #pragma OPENCL EXTENSION cl_khr_fp64 : enable
18:39.32brlcad#elif defined(cl_amd_fp64) #pragma OPENCL EXTENSION cl_amd_fp64 : enable
18:39.32brlcad#else #error "Double precision floating point not supported by OpenCL implementation."
18:39.36brlcad#endif
18:40.03ejnook, I will try that. I also put this in and didn't get the #error: http://stackoverflow.com/a/7004114
18:40.37brlcadokay excellent.. so it should have one of those two then
18:40.49brlcadnote that goes into the .cl file
18:41.22brlcadmay also need to be in the .c file, so perhaps just put it in a header and include it in both
18:41.32ejnooh, ok
18:42.01brlcadthe advantage is more precision before the numbers are meaningless
18:42.17brlcadin our output, notice the values diverage at 5 places after the decimal point
18:43.03brlcadsingle precision usually give about 7-8 digits of precision, so that fits your output
18:43.23brlcadwhat are ov and b?
18:44.13ejnoov is the vector from ray origin to center of the sphere
18:44.31ejnob is from the quadratic equation
18:44.56ejnothe dot product of the ray's direction and ov
18:45.24brlcader, ov is the ray origin?
18:46.04brlcadthat's coming straight from rt land, so that is a little surprising that they're instantly that divergent
18:46.42ejnoit's the vector from origin to sphere center
18:47.33ejnoov is calculated by the shot function
18:48.02brlcadoh, so what's the starting ray information?
18:48.10brlcadpoint and vector
18:48.25brlcadstruct ray * in the cpu version
18:50.57ejnoso if it differs at 5 decimal places, it is affecting the final pixel colors?
18:53.26ejnoI found how to query for double support in opencl 1.2 - it's in the host code; I'll try that
19:03.24Notify03BRL-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.45Notify03BRL-CAD:starseeker * 56875 brlcad/trunk/src/other/stepcode/src/cleditor/STEPfile.cc: Quote time stamp
19:09.57ejnoit indicates that double is supported
19:29.31Notify03BRL-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.39Izak_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.48Notify03BRL-CAD Wiki:IIIzzzaaakkk * 5984 /wiki/User:Izak/GSOC_2013_logs: /* August 12th to August 17th */
19:48.53brlcadejno: if double is supported, then those differences should not be there
19:49.50brlcadthat's 5 after the decimal plus 2 more before (in floating point, it'll be 1.3271881727181232e2 for example
19:50.03brlcadso that's the 7 digits of single-precision
19:50.08Notify03BRL-CAD Wiki:IIIzzzaaakkk * 5985 /wiki/User:Izak/GSOC_2013_logs: /* August 12th to August 17th */
19:51.19brlcadIzak_: prep is called during raytrace, so the "rt" command
19:56.43Notify03BRL-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.41Notify03BRL-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.57Izak_brlcad: Okay thanks
20:16.44Izak_brlcad: Are students allowed to attend the Google Summer of Code Mentor Summit?
20:17.16``ErikIzak_: mentor summit is for mentors, not students...
20:17.44``ErikI 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.23Izak_``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.20Notify03BRL-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.38Notify03BRL-CAD Wiki:NyahCh3ck20 * 5986 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 12 August - 18 August */
20:52.11Ch3ckstarseeker:  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.39Izak_screen -d
23:02.46Notify03BRL-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.

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.