| 00:11.30 | starseeker | andromeda-galaxy: just so you know to keep an eye out for it, I've queued up a follow-on task for your script getting the transcribed PDF working with comgeom-g |
| 00:12.16 | starseeker | andromeda-galaxy: if you want to have a go at it, the follow-on task will be to figure out what's up with the arb imports (the getting wireframe but not raytrace thing) |
| 00:13.38 | starseeker | if you get everything working fully, we'll add the final, correct comgeom file to our sample db directory |
| 00:15.37 | *** join/#brlcad milamber (~devli_000@104-9-73-54.lightspeed.cicril.sbcglobal.net) | |
| 00:22.53 | starseeker | andromeda-galaxy: looks like that improvement wasn't enough: brlcad.org/~starseeker/arbn_crash.g |
| 00:24.00 | starseeker | src/other/libgdiam/gdiam.cpp:1345: bool CompareByAngle::operator()(point2d* const&, point2d* const&): Assertion `false' failed. |
| 00:27.55 | starseeker | andromeda-galaxy: it looks like the problem is CompareByAngle - I take it that was needed for the initial sorting to match the output? |
| 00:32.49 | andromeda-galaxy | starseeker: hmmm... I can look into it some more.. that was already there, I thought it was just how it sorted the points by x then y the way that it needed to for monotone chain... that's definitely something that we could replace with another function... |
| 00:33.17 | andromeda-galaxy | Sorry I didn't realize that for this task, but just getting it ``working'' with this example was a good bit of work... |
| 00:33.18 | starseeker | I'm not sure the monotone chain needs sorting |
| 00:33.35 | starseeker | andromeda-galaxy: sure - we can make another task if you want to go another round with it |
| 00:34.05 | starseeker | or if it does need sorting... I'll have to look at what I did in libbn |
| 00:34.59 | andromeda-galaxy | starseeker: it seems to, at least according to the geomalgorithms site |
| 00:35.29 | starseeker | OK - what I may have done was sort the points by first x values, then y |
| 00:35.46 | starseeker | that forms a polyline, which I think is one of the valid inputs to the monotone chain |
| 00:36.33 | andromeda-galaxy | right, I think that's what it says needs to be done... |
| 00:36.51 | starseeker | OK, it's coming back to me |
| 00:36.56 | andromeda-galaxy | writing a sort function for that and replacing it in |
| 00:37.21 | starseeker | yeah, the monotone chain can take a polyline, and I was thinking a polyline sort would be more robust than the CompareByAngle thing |
| 00:37.22 | andromeda-galaxy | the convex_hull algorithm shouldn't be too hard... would be fun for another task... |
| 00:37.41 | andromeda-galaxy | right... that makes sense |
| 00:37.50 | starseeker | you've already got the convex hull algorithm :-) |
| 00:38.06 | starseeker | now we just need to replace the sorting mechanism and hope it doesn't break anything else in gdiam |
| 00:38.28 | andromeda-galaxy | does anything else use CompareByAngle? |
| 00:38.45 | starseeker | doesn't look like it |
| 00:39.14 | starseeker | tries a quick hack |
| 00:42.13 | andromeda-galaxy | in that case, should be nice and easy to replace it without breaking other things... at least if it doesn't break chull, which it shouldn't |
| 00:42.48 | starseeker | nods - doesn't look like ProjPointSet::compute() is happy with the results |
| 00:42.51 | starseeker | blegh |
| 00:43.14 | andromeda-galaxy | hm... what happened? |
| 00:44.50 | starseeker | andromeda-galaxy: http://pastebin.mozilla.org/8101239http://pastebin.mozilla.org/8101239 |
| 00:45.42 | andromeda-galaxy | starseeker: changing the sort seems like it *shouldn't* change anything but the ordering, especially since the geomalgorithms page describes it using that sort... |
| 00:45.46 | andromeda-galaxy | that's odd... |
| 00:46.27 | andromeda-galaxy | hmm... fixing that probably will take some detective work through gdiam... I hope it doesn't require fully understanding the algorithm.... |
| 00:46.43 | starseeker | nods - at this point, I'll put it up to you - if you want tasks to keep digging at this we can do that, or we can take a wack at the GeometricTools code and see if does better |
| 00:47.42 | andromeda-galaxy | we might as well spend a little more time on gdiam since it might be more efficient... if we can't figure it out after that task, we can try out another one for GeometricTools... if you could upload the model you've been using to test the function, that would also be great! |
| 00:47.52 | andromeda-galaxy | the finishing-fixing-comgeom stuff also sounds interesting... |
| 00:48.23 | starseeker | brlcad.org/~starseeker/arbn_crash.g |
| 00:48.35 | starseeker | bb -o arbn.bot |
| 00:49.10 | andromeda-galaxy | great! |
| 00:49.37 | starseeker | doesn't really have a sense of how hard it would be to translate C++11 to libbn with a little C++ mixed in - probably not as bad as Fortran, but I don't know enough about C++11 to day |
| 00:49.41 | starseeker | s/day/say |
| 00:50.55 | andromeda-galaxy | true... I don't know too much either, but it would certainly be interesting to try |
| 00:51.51 | starseeker | a lot of it should map to libbn types (point2d, point3d, etc.) and we should have the 2d stuff pretty much in place, but there would definitely be some significant pieces |
| 00:52.48 | andromeda-galaxy | right... things like, say, C++11 closures/lambda functions would be a bit harder to translate into C89, but I don't know if it uses any of those |
| 00:53.45 | starseeker | I think this is most/all of the needed code: http://brlcad.org/~starseeker/GteMinimumVolumeBox3.tar.gz |
| 00:54.25 | starseeker | if we estimate it at ~1k lines per task, bearing in mind some if it should already be there, that's about 6-7 tasks |
| 00:55.40 | starseeker | for things like gaussian elimination, we'll have to make sure about row/column conventions and other fun stuff |
| 00:56.27 | andromeda-galaxy | indeed... |
| 00:56.46 | starseeker | gotta run - let me know if it looks like something you'd like to take a crack at. I suspect we're going to find that the gdiam code has too many sharp corners to easily be made into production grade code :-/ |
| 00:57.02 | andromeda-galaxy | sure :-) |
| 00:57.32 | *** join/#brlcad ignacio-mac (~IgnacioUy@unaffiliated/ignaciouy) | |
| 00:57.53 | starseeker | that's not to say the GeometricTools stuff is guaranteed, but at least they're current/active and making a tool set instead of a paper ;-) |
| 00:58.28 | *** join/#brlcad ignacio_ (~ignacio@r167-62-75-162.su-static.adinet.com.uy) | |
| 00:59.05 | *** join/#brlcad ignacio-mac (~ignacio@unaffiliated/ignaciouy) | |
| 00:59.20 | ignacio | ignacio-mac, you rock |
| 01:02.45 | ignacio-mac | ignacio, i know |
| 01:37.15 | Notify | 02GCI:mike_eirinberg * 5297186472460288 : Task Claimed - I would like to work on this task. |
| 01:46.52 | Notify | 02GCI:mike_eirinberg * 5297186472460288 : Claim Removed - The claim on this task has been removed, someone else can claim it now. |
| 01:48.52 | Notify | 02GCI:gjeet * 6359310477033472 : Re: Decision - Well Mongoose, I just noticed that you didn't do any other task. So in order to get a certificate you need to do some other task. As you lost claim... |
| 02:42.50 | maths22 | starseeker: I have a way to limit what it runs |
| 02:43.05 | maths22 | Where is the list of such tests> |
| 02:48.17 | maths22 | starseeker: http://pastebin.ubuntu.com/9593086/ |
| 02:48.37 | maths22 | Script for the dashboard (allows for revision information to be included and such. |
| 02:48.44 | maths22 | Still currently a work in progress |
| 03:16.39 | ``Erik | exactly why the bootstrapped cmake instead of system? (my gut feeling is that it's bandaid on a symptom instead of a fix) |
| 03:33.44 | starseeker | ``Erik: bootstrapped cmake works, system doesn't |
| 03:33.46 | starseeker | not sure why |
| 03:35.08 | starseeker | maths22: it's not an explicit list - it's built up as a set of dependicies to the check and regress custom targets |
| 03:35.31 | starseeker | maths22: I can build an explicit list if that's needed, but it's not being built at the moment |
| 05:01.29 | maths22 | starseeker: Can you point me to where they are defined? |
| 05:04.44 | *** join/#brlcad n_reed_ (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 05:04.53 | *** join/#brlcad tofu_ (~sean@66-118-151-70.static.sagonet.net) | |
| 05:09.54 | *** join/#brlcad chick_ (~capslock@41.205.22.41) | |
| 05:11.59 | *** join/#brlcad Vijfhoek (quassel@46.249.37.134) | |
| 05:21.19 | Notify | 02GCI:brlcad * 4956557716488192 : Task Assigned - This task has been assigned to PaxEuropaea. You have 100 hours to complete this task, good luck! |
| 05:24.25 | Notify | 02GCI:brlcad * 5860933276532736 : Task Closed - Congratulations, this task has been completed successfully. |
| 05:25.17 | Notify | 02GCI:brlcad * 5860933276532736 : unconfirmed - Andromeda Galaxy, On quick review, this looks good, but please run the patch by starseeker on IRC to make sure you got it working right if you... |
| 05:27.07 | Notify | 02GCI:o7p9bxbnyj * 5874710239772672 : Task Claimed - I would like to work on this task. |
| 05:31.18 | Notify | 02GCI:brlcad * 5900674122383360 : Task Closed - Congratulations, this task has been completed successfully. |
| 05:36.28 | Notify | 02GCI:brlcad * 5900674122383360 : needs more, but good effort - Marc, this is looking better. There are still a handful of issues that'll need to be fixed before this can be used, but it's a good... |
| 05:36.48 | Notify | 02GCI:brlcad * 5874710239772672 : Task Assigned - This task has been assigned to Andromeda Galaxy. You have 100 hours to complete this task, good luck! |
| 05:38.03 | Notify | 02GCI:brlcad * 5874710239772672 : important task - This is a very important task, so please take care and ask questions if any come up. Please contact me directly via e-mail if you can't get an... |
| 05:57.53 | Notify | 02GCI:ankitmukherjee * 6359310477033472 : None - I haven't done any of the other tasks due to final exams at school and a slew of other work. I was just confused as to why other "competitors" or... |
| 06:18.25 | *** join/#brlcad MarcTannous (5679c4d5@gateway/web/cgi-irc/kiwiirc.com/ip.86.121.196.213) | |
| 06:19.22 | MarcTannous | g'morning |
| 06:30.22 | Notify | 02GCI:smriti7545 * 5202849461960704 : Need more time - Sir please I need some more time to complete the task |
| 06:56.56 | maths22 | starseeker: http://brlcad.org/CDash/viewCoverage.php?buildid=7 |
| 06:58.03 | maths22 | tofu_: Take a look as well |
| 06:58.13 | maths22 | Current coverage report, submitted through ctest |
| 06:58.15 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) | |
| 06:58.23 | maths22 | I'm working on getting all this stuff integrated nicely |
| 07:01.44 | Notify | 03BRL-CAD:maths22 * 63802 brlcad/trunk/CTestConfig.cmake: added nightly time |
| 07:06.11 | *** join/#brlcad alisha (~alisha@115.184.126.110) | |
| 07:09.10 | *** join/#brlcad bugport (~bugport@91.103.85.100) | |
| 07:19.59 | Notify | 02GCI:tannousmarc * 5823454855036928 : Task Claimed - I would like to work on this task. |
| 07:25.16 | Notify | 02GCI:brlcad * 5823454855036928 : Task Assigned - This task has been assigned to Marc Tannous. You have 100 hours to complete this task, good luck! |
| 07:26.31 | Notify | 02GCI:tannousmarc * 5823454855036928 : Quick question - Sean, could you join IRC for a second? We were discussing about js canvas a few weeks ago about basic primitives in 2D with randomized... |
| 07:59.19 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.30.25) | |
| 08:11.06 | *** join/#brlcad YashM (~YashM@59.95.37.243) | |
| 08:29.10 | Notify | 02GCI:utkarshsingh341 * 5625032667561984 : Task Claimed - I would like to work on this task. |
| 08:29.21 | Notify | 02GCI:utkarshsingh341 * 5625032667561984 : Claim Removed - The claim on this task has been removed, someone else can claim it now. |
| 08:35.23 | Notify | 03BRL-CAD:d_rossberg * 63803 (rt^3/trunk/tests/coreInterface/halfspace.cpp rt^3/trunk/tests/coreInterface/primitives.cpp): no idea what was going on there: this code was tested but was definitely wrong too |
| 08:36.26 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 08:56.31 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) | |
| 09:29.16 | *** join/#brlcad AndroUser2 (~androirc@213.233.85.30) | |
| 09:30.33 | *** join/#brlcad AndroUser2 (~androirc@213.233.85.30) | |
| 09:36.57 | Notify | 02GCI:jatish * 5311760286351360 : Claim Removed - The claim on this task has been removed, someone else can claim it now. |
| 09:37.03 | Notify | 02GCI:jatish * 5311760286351360 : Task Claimed - I would like to work on this task. |
| 09:38.38 | Notify | 02GCI:rossberg * 5311760286351360 : Task Assigned - This task has been assigned to jatish. You have 100 hours to complete this task, good luck! |
| 09:46.21 | *** join/#brlcad AndroUser2 (~androirc@213.233.85.30) | |
| 09:59.14 | Notify | 02GCI:Melange * 5564670123442176 : Task Reopened - Melange has detected that the final deadline has passed and it has reopened the task. |
| 09:59.17 | *** join/#brlcad AndroUser2 (~androirc@213.233.85.30) | |
| 10:15.16 | Notify | 02GCI:gjeet * 5202849461960704 : Deadline extended - The deadline of the task has been extended with 2 days and 0 hours. |
| 10:20.23 | Notify | 02GCI:rohit_agarwal * 6349681697226752 : Ready for review - The work on this task is ready to be reviewed. |
| 10:21.15 | *** join/#brlcad bugport (~bugport@91.103.85.100) | |
| 10:23.22 | Notify | 02GCI:rohit_agarwal * 6349681697226752 : Link Shared - I uploaded the video on Google Drive and submitted the URL. I took the music from here- https://www.youtube.com/watch?v=-IBgbdEoBSo |
| 10:23.45 | *** join/#brlcad rohitagarwal (~Rohit@49.249.55.218) | |
| 10:33.01 | Notify | 02GCI:gjeet * 6359310477033472 : I am so sorry for inconvenience you faced - I am sorry from my heart that I couldn't get you extra time. Actually you didn't asked for time here on melange, so I... |
| 11:07.53 | *** join/#brlcad gjeet (3b5be853@gateway/web/cgi-irc/kiwiirc.com/ip.59.91.232.83) | |
| 11:09.53 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) | |
| 11:17.52 | *** join/#brlcad gjeet (3b5be853@gateway/web/cgi-irc/kiwiirc.com/ip.59.91.232.83) | |
| 11:21.42 | *** join/#brlcad smt (~smt@117.200.235.198) | |
| 11:25.21 | smt | hey! i just configured and built the code in vm debian(windows).Its src dir shows the various folders but in its sub-folders i am not able to access the .c files say libged dir, it doens't show analyze.c |
| 11:25.28 | smt | plz help!! |
| 11:32.13 | smt | ohk! got in the trunk folder :) |
| 11:37.44 | *** join/#brlcad rohitagarwal (~Rohit@49.249.53.96) | |
| 11:37.49 | starseeker | maths22: the macro logic for the check target starts around line 493 in the top level CMakeLists.txt file |
| 11:38.27 | starseeker | regress targets are handled in the regress/CMakeLists.txt file |
| 11:39.02 | starseeker | maths22: sweet coverage report! |
| 11:40.46 | *** join/#brlcad adityagulati (dce32db2@gateway/web/cgi-irc/kiwiirc.com/ip.220.227.45.178) | |
| 11:53.16 | *** part/#brlcad adityagulati (dce32db2@gateway/web/cgi-irc/kiwiirc.com/ip.220.227.45.178) | |
| 11:54.06 | *** join/#brlcad aditya (dce32db2@gateway/web/cgi-irc/kiwiirc.com/ip.220.227.45.178) | |
| 11:54.52 | *** join/#brlcad adityagulati (dce32db2@gateway/web/cgi-irc/kiwiirc.com/ip.220.227.45.178) | |
| 11:56.40 | Notify | 03BRL-CAD:starseeker * 63804 brlcad/trunk/src/other/libgdiam/gdiam.cpp: Apply gdiam patch from http://www.google-melange.com/gci/task/view/google/gci2014/5860933276532736 - successfully integrates the new algorithm |
| 11:56.40 | gcibot | Update gdiam oriented bounding box algorithm |
| 11:56.41 | gcibot | Status: Closed |
| 11:56.41 | gcibot | Mentor(s): Isaac Kamga, Dishank |
| 11:59.27 | *** join/#brlcad gjeet (3b5be853@gateway/web/cgi-irc/kiwiirc.com/ip.59.91.232.83) | |
| 12:27.28 | Notify | 02GCI:rossberg * 6349681697226752 : Nice video - I like it. Can you please tell us which font you have used and where the music came from (to check the licenses)? |
| 12:28.54 | Notify | 02GCI:rossberg * 6349681697226752 : Task Needs More Work - One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to... |
| 12:32.25 | Notify | 02GCI:rossberg * 6349681697226752 : Deadline extended - The deadline of the task has been extended with 1 days and 0 hours. |
| 12:39.14 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 13:26.19 | *** join/#brlcad adityagulati (dce32db2@gateway/web/cgi-irc/kiwiirc.com/ip.220.227.45.178) | |
| 13:44.13 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) | |
| 13:47.20 | *** join/#brlcad sofat (~sofat@223.225.207.47) | |
| 13:47.59 | sofat | maths22, hello |
| 13:49.42 | *** join/#brlcad sofat (~sofat@223.225.207.47) | |
| 13:57.49 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 13:58.13 | ignacio | Hi all, Good day ^_^ |
| 13:59.13 | sofat | hello |
| 14:07.07 | MarcTannous | sup ignacio |
| 14:08.53 | *** join/#brlcad gjeet (3b5be853@gateway/web/cgi-irc/kiwiirc.com/ip.59.91.232.83) | |
| 14:12.03 | *** join/#brlcad sofat_ (~sofat@223.225.220.155) | |
| 14:20.34 | *** join/#brlcad sofat_ (~sofat@223.225.220.155) | |
| 14:27.51 | *** join/#brlcad chick_ (~capslock@41.205.22.41) | |
| 14:34.39 | *** join/#brlcad sofat__ (~sofat@106.192.139.81) | |
| 15:09.37 | *** join/#brlcad adityagulati (dce32db2@gateway/web/cgi-irc/kiwiirc.com/ip.220.227.45.178) | |
| 15:10.15 | Notify | 02GCI:rohit_agarwal * 6349681697226752 : Correction - To be more specific I used Apple SD Gothic Neo and not AppleGothic. |
| 15:13.19 | Notify | 02GCI:adityagulati * 5863782450462720 : Ready for review - The work on this task is ready to be reviewed. |
| 15:16.55 | Notify | 02GCI:rossberg * 6349681697226752 : Task Closed - Congratulations, this task has been completed successfully. |
| 15:19.53 | Notify | 03BRL-CAD:starseeker * 63806 brlcad/trunk/src/librt/test_shape_recognition.cpp: Spot arbn shapes and start thinking about cylinders. |
| 15:39.51 | *** join/#brlcad YashM_ (~YashM@117.198.17.107) | |
| 15:42.07 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 15:44.28 | *** join/#brlcad chick_ (~capslock@41.205.22.41) | |
| 15:50.06 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.230.147) | |
| 15:52.41 | Notify | 02GCI:tannousmarc * 5823454855036928 : Ready for review - The work on this task is ready to be reviewed. |
| 15:52.51 | Notify | 02GCI:tannousmarc * 5823454855036928 : Lack of patch - Sorry for the lack of patch, I will not be able to access my Linux distro for a while, I just wrote the code in a Windows IDE, and explained... |
| 16:08.59 | Notify | 02GCI:rohit_agarwal * 5880415785058304 : Task Claimed - I would like to work on this task. |
| 16:22.07 | Notify | 02GCI:rossberg * 5880415785058304 : Task Assigned - This task has been assigned to Rohit Agarwal. You have 100 hours to complete this task, good luck! |
| 16:23.47 | Notify | 02GCI:camelia_mm * 4824199776436224 : Task Claimed - I would like to work on this task. |
| 16:36.16 | *** join/#brlcad albertcoder (~albertcod@202.164.45.204) | |
| 16:37.10 | Notify | 02GCI:mihaineacsu29 * 4824199776436224 : Task Assigned - This task has been assigned to camelia_mm. You have 100 hours to complete this task, good luck! |
| 16:47.45 | MarcTannous | Brlcad: Sean, did you get the chance to check this out http://codepen.io/marctannous/pen/xbOBGP ? |
| 16:50.52 | brlcad | MarcTannous: yeah, that looks like a start -- is that manually drawing the base shapes? |
| 16:51.41 | brlcad | did you try to do booleans? |
| 16:51.55 | MarcTannous | Not sure what you mean by manually drawing |
| 16:52.07 | MarcTannous | They are easly generated in js |
| 16:52.10 | MarcTannous | easily* |
| 16:52.53 | MarcTannous | Booleans are kinda hard to do ( the whole suite of operations such as xor ) |
| 16:53.03 | MarcTannous | Because you'd have to "merge" paths |
| 16:53.42 | MarcTannous | This way, sometimes the shapes are added one to another due to the randomness of the whole thing and the frequency of creation being super super high |
| 16:56.36 | brlcad | hm, maybe what you're seeing is different than what I'm seeing... |
| 16:56.46 | Notify | 02GCI:rohit_agarwal * 6349681697226752 : Information - I used AppleGothic as font of the first heading and Gill Sans for the rest of the video. The link to the music is... |
| 16:56.48 | brlcad | I see outlines (just the outlines, not filled) |
| 16:57.02 | MarcTannous | yeah, and they sometimes get merged ( the shapes ) |
| 16:57.06 | MarcTannous | and just float around as a whole |
| 16:57.16 | MarcTannous | until their so called "life |
| 16:57.17 | brlcad | basically circles, triangles, and squares flying out randomly with their outline colors changing very rapidly |
| 16:57.18 | MarcTannous | expires |
| 16:57.21 | MarcTannous | yeah |
| 16:57.49 | MarcTannous | Flying out and eventually dying when their "life" gets too high in order to nto cause lag after 10 seconds or so |
| 16:58.03 | MarcTannous | they can be filled pretty easily but I don't think it would look that good |
| 16:58.31 | brlcad | if they're solid filled the same color, that's effectively a boolean union |
| 16:58.40 | brlcad | s/effectively// |
| 16:59.03 | MarcTannous | that's right |
| 16:59.07 | MarcTannous | Yeah, that would be easy to do |
| 17:00.31 | brlcad | then might look interesting to issue the shapes in pairs, vary the sizes and rotations of the shapes per pairing for variety |
| 17:01.03 | brlcad | that might be interesting enough for a starter |
| 17:01.12 | MarcTannous | will work on that in my downtime |
| 17:01.31 | brlcad | I'll create a set of tasks so you get credit for all this ;) |
| 17:01.49 | MarcTannous | have been working a lot on motion animations lately in CSS http://codepen.io/collection/nZMbrW/ while waiting for tasks to be reviewed, the js canvas thing is on my to do list tho |
| 17:01.53 | Notify | 02GCI:rohit_agarwal * 6349681697226752 : Ready for review - The work on this task is ready to be reviewed. |
| 17:02.24 | MarcTannous | By the way, I've submitted a .cpp file for my unit test and "wrote" the rest of the patch file in the comment as I cannot use my linux partition for a while ( probably until tomorrow ) and therefore can't svn diff on windows |
| 17:02.29 | MarcTannous | hope that's okay |
| 17:04.09 | brlcad | likes http://codepen.io/marctannous/pen/yyJwBe |
| 17:04.44 | MarcTannous | oh that's actually the weirdest thing ever. Those are two rectangles spinning around |
| 17:05.02 | brlcad | MarcTannous: so you do realize that you can get a full dev environment set up on Windows (including Subversion)? |
| 17:05.13 | MarcTannous | both of them only having colored the top and bottom sides, the other two being transparent, while giving the whole rectangle a border-radius of 50% ( pretty much a circle ) |
| 17:05.32 | MarcTannous | brlcad: Yeah, but that would be pretty pointless since I have it already in a working condition on Ubuntu |
| 17:05.44 | MarcTannous | And it would take me probably less time to fix ubuntu than to install it on windows too |
| 17:05.47 | brlcad | not pointless if you can't make proper patch files |
| 17:06.03 | Notify | 03BRL-CAD:ejno * 63807 brlcad/trunk/src/libged/simulate/physics_world.cpp: remove use of btMotionState and simplify initialization code; the problem is either with positioning or bounding boxes |
| 17:06.09 | brlcad | it's 10x more work to try to manually apply changes .. that's why patch files exist |
| 17:06.16 | MarcTannous | I could've wrote the patch file by hand |
| 17:06.33 | MarcTannous | If that's an issue |
| 17:09.09 | brlcad | from the reviewer's perspective, it's a question of whether it can be applied quickly, flawlessly, independently and have it just work |
| 17:10.01 | MarcTannous | how are .patches applied? |
| 17:10.01 | brlcad | for someone's first-time submission, it can be pretty lenient, but like I mentioned ... you're level of expertise and participation are greatly heightened, so expectations will continue to increase :) |
| 17:10.10 | brlcad | patch -p0 < your_file |
| 17:10.13 | MarcTannous | ow |
| 17:10.17 | MarcTannous | well that's easy |
| 17:10.51 | MarcTannous | If it not being a patch is a big issue, just submit some feedback on the code and I'll create the patch first thing tomorrow, after I get ubuntu working properly |
| 17:11.07 | brlcad | that should apply without fail, compile, and work to whatever extent intended |
| 17:11.13 | brlcad | if that doesn't work, something's wrong with the patch ;) |
| 17:11.58 | brlcad | i also noticed your last couple patches also still had changes from other tasks mixed in (unit testing of sphere iirc) |
| 17:12.44 | MarcTannous | I removed the changes from previous tasks in the final submission of the task iirc |
| 17:13.02 | MarcTannous | they are all in the same directory and automatically get added when I ask svn to patch my modifications |
| 17:13.03 | brlcad | it's not a "big issue", but it is an issue and it does make reviews take 10x more effort (a review that could've literally taken 30 seconds might end up taking a few minutes) |
| 17:13.28 | MarcTannous | how should I go about a situation like: |
| 17:13.41 | brlcad | the one I closed 12 or so hours ago had other mods included still |
| 17:14.04 | MarcTannous | I have a root directory. It has two folders, A and B. A has 2 modified files, but I only want to submit a patch with 1 of them, and I also want to include the modified files from B. |
| 17:14.11 | MarcTannous | How should I create the patch? |
| 17:14.21 | MarcTannous | svn diff the whole root and then manually delete stuff that's extra? |
| 17:14.42 | brlcad | svn diff path/to/A/file1 path/to/B > mypatch |
| 17:15.03 | MarcTannous | ow |
| 17:15.06 | MarcTannous | that's easy |
| 17:15.21 | MarcTannous | did not know you can add stuff together |
| 17:15.22 | brlcad | you definitely can/should just read and edit the patch if needed |
| 17:15.35 | brlcad | so long as you don't break the format (it uses the context lines) |
| 17:15.57 | brlcad | where you'll still run into problems are when you make two different changes to the same file |
| 17:16.28 | MarcTannous | can't I just choose which modified line to add to a patch? |
| 17:16.29 | brlcad | in that case, you'll want to either manually edit the patch file or keep separate checkouts/directories when changes are going to overlap |
| 17:16.41 | MarcTannous | saw it indicates the index of lines changing |
| 17:16.49 | brlcad | or keep patch sets yourself even .. I do that a lot |
| 17:17.35 | brlcad | e.g., make change #1, svn patch > change_1.patch, svn revert -R . to undo the changes, make change #2, svn patch > change_2.patch, etc |
| 17:18.14 | brlcad | then I can svn revert any time, re-apply a given patch, test it, work on it some more, improve it, create a new version, revert, work on something else, etc |
| 17:18.30 | brlcad | if they're big complicated changes, a separate checkout directory is often better though |
| 17:18.48 | MarcTannous | why do you guys use svn instead of git tho? |
| 17:19.37 | brlcad | variety of reasons and an involved discussion |
| 17:19.58 | brlcad | but basically we want centralized cooperation amongst core devs |
| 17:20.11 | brlcad | which svn implicitly requires without any action |
| 17:20.25 | brlcad | you can kind of do that with git, but it's optional and not enforceable |
| 17:20.56 | MarcTannous | centralized cooperation = patch logs? |
| 17:21.13 | brlcad | heck no, patches are for external new contributors |
| 17:21.45 | brlcad | contributors gain commit access when they demonstrate competency with our dev infrastructure |
| 17:22.39 | *** join/#brlcad albertcoder (~albertcod@202.164.45.204) | |
| 17:22.40 | brlcad | sending a patch is basically equivalent to a pull requests |
| 17:22.53 | brlcad | (in fact under the hood it's exactly that) |
| 17:23.56 | brlcad | if you used a tool/website/interface like github that sends pull request notifications for you, it would be identical with subversion |
| 17:24.09 | brlcad | git != github |
| 17:26.00 | MarcTannous | On my last coding task you mentioned something about my code not being exactly on-point |
| 17:26.05 | MarcTannous | As in it was still flawed |
| 17:26.14 | MarcTannous | Does my latest task still have these issues? |
| 17:27.29 | andromeda-galaxy | brlcad: for http://www.google-melange.com/gci/task/view/google/gci2014/5874710239772672, I noticed that rtshot seems to try to determine whether to use rt_raybundle_maker() or rt_gen_circular_grid() by looking at the values of the given options (specifically -c); do you have a specific interface in mind for how it should determine when to use rt_gen_conic? (sorry to interrupt...) |
| 17:28.46 | brlcad | MarcTannous: I haven't seen your latest task yet |
| 17:29.11 | MarcTannous | brlcad: when you find some time to check it : http://www.google-melange.com/gci/task/view/google/gci2014/5823454855036928 |
| 17:29.11 | gcibot | Write CoreInterface unit test #5 |
| 17:29.12 | gcibot | Status: NeedsReview (3 days 17 hrs 55 min) |
| 17:29.12 | gcibot | Mentor(s): Mandeep Kaur, Ishwerdas |
| 17:30.00 | brlcad | andromeda-galaxy: no interface in mind -- anything sensible should be fine |
| 17:30.51 | brlcad | all of the bundling interface can/should change for consistency |
| 17:31.03 | brlcad | circular_grid sounds an aweful lot like a cone for example |
| 17:31.07 | andromeda-galaxy | right... |
| 17:31.12 | brlcad | in which case, what's the difference with a conic |
| 17:31.32 | brlcad | or maybe they should be one in the same with another parameter that talks about an angle |
| 17:31.56 | andromeda-galaxy | that makes sense... what does gen_circular_grid() do for an angle right now? |
| 17:32.06 | brlcad | it doesn't |
| 17:33.04 | brlcad | we can create an API design task to sort out exactly what that API should look like if you want to work on making it clean |
| 17:33.27 | brlcad | that is a very important task to get working well, correctly, and cleanly |
| 17:33.39 | brlcad | whipping it into shape is worthwhile |
| 17:34.06 | andromeda-galaxy | Makes sense... right now, I'm just a little confused as to the exact difference between gen_conic() and gen_circular_grid() --- |
| 17:36.18 | andromeda-galaxy | it seems like gen_ellipticial_grid() should be effectively creating a cone of rays with a divergence angle in the x and y directions specified by avec/bvec... (so rt_gen_circular_grid() does the same thing but with the divergence angle calculated from radius) |
| 17:41.00 | andromeda-galaxy | brlcad: also, I'm a little confused as to the difference between rt_shootrays() and rt_shootray_bundle()... |
| 17:43.35 | andromeda-galaxy | ohh... is it that rt_gen_*_grid() make it all happen in a x/y grid, whereas rt_gen_conic() should sample in (non-spiraling, so not like rt_raybundle_maker()) ``rings'' around the center ray? |
| 17:52.32 | brlcad | andromeda-galaxy: perhaps the first step is to sketch a diagram of what all the existing functions do |
| 17:53.08 | brlcad | it very well could be that one of the existing functions already does what this task calls for given the right parameters |
| 17:53.14 | brlcad | it that's the case, your job is very simple |
| 17:53.55 | brlcad | will add a diagram task, maybe create it ascii art so it can become documentation as a doxygen comment with the function declaration |
| 17:53.58 | andromeda-galaxy | brlcad: is there any disadvantage to using something like an option '-B <bundle_type>' for rtshot? overall, that seems like it would allow extending the set of bundles that rtshot can create more easily.... it could always fall back to attempting to determine which type to use based on other options as well --- the problem with the current approach is that it seems to me that -n, -c, and -R all kind of make sense f |
| 17:54.57 | brlcad | your message was truncated off at "kind of make sense f" |
| 17:55.09 | andromeda-galaxy | oh sorry... let me resend the stuff after that |
| 17:55.19 | andromeda-galaxy | or conic... |
| 17:55.29 | andromeda-galaxy | (apparently, it was just barely over the limit) |
| 17:56.15 | brlcad | sure a bundle type sounds great |
| 17:56.26 | andromeda-galaxy | I think that I can tell the difference between what's already there and conic, since I believe that conic should create non-spiraling rings... |
| 17:56.31 | brlcad | to me, this is all about creating a general interface that lets one specify a pattern |
| 17:57.16 | andromeda-galaxy | right... then we can add more bundle (pattern) types to rt, and rtshot -B <bundle_type> selects the kind of pattern... then the rest of the pattern-specific options are passed through to that function, and then it shoots the rays... |
| 17:57.39 | brlcad | that pattern may be circular, spiraling, rectangular; orthogonal or divergent or convergent; and with some params to specify density/pattern |
| 17:57.47 | andromeda-galaxy | just curious, where did the name 'rt_raybundle_maker()' come from? it's kind of generic... |
| 17:58.03 | brlcad | all these names can be changed |
| 17:58.09 | brlcad | almost certainly named on a whim |
| 17:58.17 | andromeda-galaxy | ahh... |
| 17:58.18 | brlcad | by different devs at different types |
| 17:58.35 | brlcad | maybe even completely ignorant of the existing API |
| 17:58.42 | brlcad | so there may be some redudancy |
| 17:58.49 | andromeda-galaxy | alos, is rt_shootrays() or rt_shootray_bundle() preferred? rt_raybundle_maker uses one of them and rt_gen_*_grid uses the other... |
| 17:58.51 | brlcad | if you see room for consolidation/improvement, let me know ... |
| 17:59.00 | brlcad | it would be good to see a summary of where this api is all at |
| 17:59.19 | andromeda-galaxy | luckily, I don't think there's too much redundancy... part of having a good standard interface for patterns would probably be to have a good naming convention for them though. |
| 17:59.24 | brlcad | I believe rt_shootrays() is the more new/modern/flexible interface |
| 17:59.56 | brlcad | conceptually rt_shootrays() and rt_shootray_bundle() do the exact same thing |
| 18:00.02 | brlcad | they shoot a set of rays |
| 18:00.09 | brlcad | so that to me says they're redundant |
| 18:00.31 | andromeda-galaxy | right.... soo new code should use rt_shootrays()? |
| 18:00.32 | brlcad | the fact that they work on different containers/data is kind of irrelevant to API design |
| 18:01.00 | andromeda-galaxy | they do seem to be redundant... above, I was just talking about the pattern generation code in mkbundle.c, the pattern types all seem fairly different... |
| 18:02.36 | andromeda-galaxy | so for this task, I should 1) write rt_gen_conic to correctly populate the xrays struct given parameters like divergence angle, number of rings, number of rays per ring and 2) set up something in rtshot like the aforementined -B <bundle_type> that makes rtshot construct a conic pattern and then shoot it? |
| 18:11.14 | brlcad | yeah, I mean API design, there are differences in the patterns and I think that's part why there are multiple versions |
| 18:11.33 | brlcad | the second dev didn't see the pattern they liked and they didn't like the name, so they implemented a different one |
| 18:11.51 | brlcad | and now we need to consolidate |
| 18:12.46 | andromeda-galaxy | for rt_shootrays/rt_shootray_bundle? |
| 18:13.27 | Notify | 02GCI:Melange * 4531831353376768 : Task Reopened - Melange has detected that the final deadline has passed and it has reopened the task. |
| 18:13.52 | andromeda-galaxy | if rt_shootrays() is supposed to be better, moving to it and remeoving rt_shootray_bundle() shouldn't be too hard... rt_shootray_bundle() seems to only be used by rtshot |
| 18:14.35 | Notify | 03BRL-CAD:starseeker * 63808 brlcad/trunk/src/librt/test_shape_recognition.cpp: Make a stab at spotting cylinders. |
| 18:24.36 | brlcad | andromeda-galaxy: possibly, would have to look at how those two functions differ ... why did two devs come up with two different approaches, which is better, etc |
| 18:25.06 | brlcad | the name rt_shootrays() is better ... whether the args and data being passed is better remains to be seen |
| 18:25.31 | brlcad | if you can provide a summary analysis of the functions, that would be helpful |
| 18:26.12 | andromeda-galaxy | ah... okay |
| 18:26.31 | andromeda-galaxy | brlcad: I've been trying to look at them now... rt_shootrays() is a lot simpler than rt_shootray_bundle() |
| 18:27.48 | andromeda-galaxy | it looks like rt_shootray_bundle() does a bunch of calculations with the model rpp, as opposed to rt_shootrays() which just calls rt_shootray() repeatedly |
| 18:28.31 | andromeda-galaxy | rt_shootray_bundle() basically reimplements all the stuff that rt_shootray() does, whereas rt_shootrays() calls rt_shootray() |
| 18:30.47 | andromeda-galaxy | for now, I'll use rt_shootrays() in rtshot... just checking, is my above assessment of the task generally correct? |
| 18:31.57 | brlcad | yes |
| 18:32.46 | andromeda-galaxy | great! I'll start working on writing rt_gen_conic() now, then add the -B option to rtshot |
| 18:32.48 | brlcad | just remember that this is a hot task, so it can easily expand to a dozen or more other tasks if that's what it takes to get it cleaned up and provably working well |
| 18:33.15 | brlcad | we don't just want this done -- we want to use this (really soon) |
| 18:33.20 | brlcad | and for real analysis work |
| 18:33.39 | brlcad | so it must be correct to some level of certainty |
| 18:34.09 | andromeda-galaxy | okay, I'll try to make sure it's correct... I'll test it out on various models in rtshot etc. etc. as well |
| 18:34.22 | andromeda-galaxy | doing more tasks to get the rest of the APIs cleaned up would be nice |
| 18:45.29 | andromeda-galaxy | by the way, is there a preferred mechanism for applications to switch behavior based on string arguments (e.g. one of if/strcmp chain, bu_hashtable, etc.)? |
| 18:53.44 | *** join/#brlcad winghouchan (~winghouch@2.123.10.10) | |
| 18:54.43 | winghouchan | brlcad: Are there any definitive plans for the website at the moment? |
| 18:59.11 | brlcad | winghouchan: what do you mean? there are lots of definitive plans, and at least three different website domains involved :) |
| 18:59.25 | brlcad | so "yes" |
| 18:59.58 | brlcad | and no, they can't be quickly simply summarized other than "make it all work well together, look great, and be easy to use" |
| 19:01.09 | winghouchan | In my opinion the current tasks for the site are too fragmented |
| 19:01.23 | MarcTannous | Well the website is pretty big |
| 19:01.47 | MarcTannous | A normal website design process should take anywhere between 40 and 200-300 hours of manwork |
| 19:01.53 | MarcTannous | depending on size |
| 19:02.01 | MarcTannous | And that's of an experienced web dev/designer |
| 19:02.14 | MarcTannous | Just my 2 cents |
| 19:02.28 | winghouchan | I was looking at the work done by others and for most people who have completed more than one website task their work is not that cohesive |
| 19:03.13 | winghouchan | MarcTannous: I agree |
| 19:04.24 | winghouchan | To make the process of building the site more cohesive would it be better to set tasks for each stage of the process? |
| 19:04.45 | MarcTannous | oh my god I should design a BRL-CAD CSS loader |
| 19:05.50 | winghouchan | For example: Task 1: Research, Wireframe and Design |
| 19:06.00 | winghouchan | Task 2.x: Build the site |
| 19:06.15 | winghouchan | Task 2 could be divided into each of the pages |
| 19:06.50 | winghouchan | Task 3: QA, Research, Iterate and Improve |
| 19:08.13 | andromeda-galaxy | brlcad: it looks like the other bundle makaing functions all create rays with the same direction but different start points dispersed around a center ray; am I correct in believing that the proposed gen_conic() should create rays starting at the same point but with different directions? |
| 19:11.05 | winghouchan | Not sure if it's too late to work my suggestion though since a lot of work has already been put in but hopefully a solution can be found through discussion |
| 19:14.59 | winghouchan | With more streamlined tasks the success of completing the site is more measurable and a clear goal is set. The current plan is not obvious for people doing website related tasks |
| 19:41.25 | brlcad | winghouchan: I don't disagree but there are also a lot of different reasons for GCI tasks too -- some are purely to give students a chance to learn, others are an opportunity to test out design ideas (that we may or may not have thought about), others are towards project objectives |
| 19:41.48 | brlcad | and everyone's skills are all over the map, so yeah, it's GOING to be a mess ;) |
| 19:42.29 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 19:42.36 | brlcad | the best you can do it try to ensure your work is consistent with your interests and that'll hopefully be interesting to us so we can incorporate the different design elements |
| 19:42.55 | brlcad | andromeda-galaxy: bingo, exactly |
| 19:43.00 | andromeda-galaxy | brlcad: great! |
| 19:43.04 | brlcad | that's the divergent aspect |
| 19:43.13 | brlcad | they're parallel, divergent, or convergent |
| 19:43.19 | andromeda-galaxy | brlcad: I'm working on rotating the direction properly... |
| 19:43.31 | brlcad | (e.g., starting from a grid and converging towards a point would be another possibility) |
| 19:43.35 | andromeda-galaxy | makes sense |
| 19:43.41 | brlcad | andromeda-galaxy: there is logic for exactly this already in src/rt |
| 19:43.45 | andromeda-galaxy | where? |
| 19:44.23 | brlcad | find where perspective rays are fired |
| 19:44.29 | andromeda-galaxy | hmm. okay, one sec |
| 19:45.14 | andromeda-galaxy | basically, what I'd been planning to do (for example, for the outermost ring) --- rotate by the necessary angle of divergence around an axis orthogonal to the given direction (to get some point on that ring) and then rotate around that ring by the necessary angle for each point |
| 19:45.41 | andromeda-galaxy | rotating arouond the orthogonal vector is fairly easy because you can just basically add a vector with length radius in the correct direction... |
| 19:46.34 | andromeda-galaxy | where are perspective rays fired? I'm unfortunately still more familiar with libbn/libbu/librt than with src/rt |
| 19:52.24 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 19:52.53 | brlcad | andromeda-galaxy: what you describe isn't far off but there are a couple issues |
| 19:53.01 | brlcad | the pattern has to be balanced, for example |
| 19:53.27 | andromeda-galaxy | I assumed that it would be balanced because it's moving in equal increments between rings and between points within a ring... |
| 19:53.29 | brlcad | so you either want to still shoot a grid -- in a conic/circular pattern but sampling the center of grid cells) |
| 19:53.49 | brlcad | or determine what a given ring needs to have to ensure they're evenly spaced |
| 19:54.23 | andromeda-galaxy | because if rays_per_ring is passed in, just rotate through each time by M_2PI/rays_per_ring, right? |
| 19:55.46 | andromeda-galaxy | then you can decompose that rotation into adding two vectors that are orthogonal to the original ray with a little trigonometry... |
| 20:00.11 | brlcad | the shape of the pattern being useful is one of density |
| 20:00.26 | brlcad | there are a variety of sampling patterns with different properties |
| 20:00.39 | brlcad | you could shoot a grid like this, for example: http://people.sc.fsu.edu/~jburkardt/c_src/ellipse_grid/ellipse_grid_test01.png |
| 20:00.51 | brlcad | or you could shoot in polar like this: http://www.mathworks.com/help/examples/matlab/CompareExtrapolationOfCoarselyAndFinelySampledScatteredDExample_01.png |
| 20:01.23 | winghouchan | brlcad: Okei thank you! |
| 20:01.25 | brlcad | the latter is not desirable as-is because that's not a regular pattern, but then one could obviously adjust it to be regular (possibly) |
| 20:01.42 | andromeda-galaxy | hmmm |
| 20:02.12 | andromeda-galaxy | the second one is what I'd originally had in mind |
| 20:02.13 | brlcad | you could even do a random sampling and (with the right kind of random number generator) be able to guarantee regular sampling |
| 20:02.20 | brlcad | whereas pure random is not reguarl |
| 20:02.54 | andromeda-galaxy | the advantage of the second pattern you mentioned is that every point in the outermost ring is exactly on the edge of the cone |
| 20:03.33 | brlcad | sure |
| 20:03.35 | andromeda-galaxy | which is why I'd been considering it |
| 20:03.54 | brlcad | and the disadvantage is that you have to adjust the sampling as you approach the interior to maintain a given point density |
| 20:04.24 | andromeda-galaxy | right... you'd have to do some fun stuff to correctly adjust rays_per_ring on each ring as a function of ring # |
| 20:04.36 | brlcad | think about the chord distance between neighboring points on the outermost ring -- that distance should be upheld everywhere |
| 20:05.02 | brlcad | you wouldn't want to sample the center point N times, for example |
| 20:05.08 | andromeda-galaxy | the first one is nice for regularity... as for using a random number generator with normalization, that'd probably be the most difficult possibility since we don't have (as far as I now) any random number generater that can do that... |
| 20:05.16 | andromeda-galaxy | *know |
| 20:05.17 | brlcad | same holds for halfradius where you don't need/want to sample 2x |
| 20:05.42 | brlcad | we have random number generators that will do the right thing |
| 20:05.53 | brlcad | but we don't want that one as a first cut on this |
| 20:06.03 | brlcad | just that it's one of several possible sampling approaches |
| 20:06.12 | andromeda-galaxy | ahhh |
| 20:06.58 | andromeda-galaxy | okay.. I can try to do either the regularized polar or the cartesian approach, I don't really have a preference... do you think that one would be significantly more useful than the other? |
| 20:10.11 | brlcad | regular grid, staggered grid, random regular, random irregular, radial regular, radial irregular, spiral regular, spiral irregular, etc |
| 20:10.21 | brlcad | (just thinking through options)_ |
| 20:11.17 | andromeda-galaxy | indeed... now I'm really not sure which would be best for a first stab at it... |
| 20:11.23 | brlcad | the easiest is probably going to be to shoot a regular grid as that's probably what rt_gen_circular does now and you could mimic it closely |
| 20:11.29 | brlcad | you just have a different ray starting point |
| 20:11.42 | *** join/#brlcad albertcoder (~albertcod@202.164.45.204) | |
| 20:11.51 | brlcad | maybe, I forget what the different existing patterns look like |
| 20:12.05 | andromeda-galaxy | basically, doing that is doing exactly what rt_gen_circular_grid does except modifying dir instead of pt, I believe |
| 20:12.10 | brlcad | start there, create a visualization of the existing patterns |
| 20:12.34 | andromeda-galaxy | except that dir has to be unitized (at least according to the header file) |
| 20:13.35 | andromeda-galaxy | how would you create a visualization of the patterns? just write some code that runs rt_gen_* and then turns it into some other representation (like very thin cylinders in a .g file or gnuplot graphs, for example)? |
| 20:13.54 | brlcad | any way you want |
| 20:14.10 | brlcad | we want to see what they look like |
| 20:15.03 | andromeda-galaxy | right... would that be part of the submission for this task? |
| 20:15.11 | andromeda-galaxy | I can think of a couple of fun ways to do that |
| 20:15.20 | brlcad | there are options to RT where it will export 3D plot data (line segments) of the rays fired, and there are tools to look at plot data in 2d or 3d, so you could use that |
| 20:15.50 | andromeda-galaxy | aha! that would work... |
| 20:15.57 | brlcad | I'd make another task to visualize it so you'd come back to this task afterwards/next |
| 20:16.21 | andromeda-galaxy | ahh... okay |
| 20:16.41 | brlcad | once visualized, lets make the "final product" a simple ascii art depiction of the pattern annotated with the generator args |
| 20:16.49 | andromeda-galaxy | makes sense |
| 20:16.49 | brlcad | so an image and a text file |
| 20:17.15 | brlcad | how many routines are there? three? |
| 20:17.19 | andromeda-galaxy | I think so |
| 20:17.30 | andromeda-galaxy | but rt_gen_circular_grid is just a special case of rt_gen_elliptical grid |
| 20:17.43 | brlcad | so it'll be easy ;) |
| 20:18.14 | andromeda-galaxy | the ascii art might end up just being basically a projection of the ray hits onto a surface... |
| 20:19.02 | andromeda-galaxy | it probably would be... even doing the uniform grid approach for rt_gen_conic() would be quite interesting though, since I'd have to confirm that the grid stays uniform as the ray lengths change |
| 20:20.05 | andromeda-galaxy | so should I stop working on this one for now, until we have that one ready? |
| 20:21.02 | Notify | 02GCI:aa2014 * 4531831353376768 : Task Claimed - I would like to work on this task. |
| 20:21.47 | Notify | 02GCI:aa2014 * 4531831353376768 : Claim Removed - The claim on this task has been removed, someone else can claim it now. |
| 20:22.19 | brlcad | andromeda-galaxy: I don't see it as stopping, it's just working another aspect of this project ;) |
| 20:22.36 | andromeda-galaxy | brlcad: indeed, I just meant e.g. unclaim this task, work on something else until then |
| 20:22.44 | brlcad | like I said, I could probably come up with a dozen tasks in this area that'd take you through the next couple weeks |
| 20:22.55 | andromeda-galaxy | that would be nice ;-) |
| 20:23.00 | MarcTannous | brlcad: did you get a chance to check out my code? ( sorry for intrerrupting your discussion ) |
| 20:23.44 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.30.25) | |
| 20:24.01 | andromeda-galaxy | brlcad: so until you have a chance to put those ones up, I'll find something else to do... maybe some of those CoreInterface tasks... |
| 20:24.03 | brlcad | andromeda-galaxy: don't worry about the claim/unclaim ... the task to vis will get added probably tonight along with a few others and you can unclaim/claim/reclaim then ... |
| 20:24.19 | brlcad | definitely wouldn't want you to jump to a diff task "waiting"! |
| 20:24.27 | andromeda-galaxy | brlcad: great! in that case, I won't |
| 20:24.48 | andromeda-galaxy | just wanted to check since sometimes the task batches don't go up for a while... |
| 20:24.57 | brlcad | yeah, don't work something else if this is at all interesting .. just keep going and they'll get credited |
| 20:25.02 | andromeda-galaxy | I'll just start working on the vis now so I have it ready when you put it up |
| 20:25.10 | brlcad | great |
| 20:25.29 | brlcad | MarcTannous: I'm not in review position at the moment or I would |
| 20:25.41 | brlcad | MarcTannous: in discussion position if you have questions ;) |
| 20:26.07 | andromeda-galaxy | but in general, you think that I should waait until after the vis is done and and we've had a chance to look at the results from it to work on gen_conic(), right? |
| 20:26.28 | MarcTannous | brlcad: well I'd like to suggest some tasks revolving either around BRLCAD::Objects or Vector3Ds |
| 20:27.11 | MarcTannous | brlcad: These are both heavily used in rt^3 and could use some operators to make the code easier to read/implement |
| 20:27.26 | brlcad | andromeda-galaxy: yes, I think that's in order ... |
| 20:27.30 | MarcTannous | brlcad: such as overflowing operators or adding some basic comparation functions. |
| 20:28.24 | brlcad | MarcTannous: hm, those sound like great questions for d_rossberg as that's his domain |
| 20:28.47 | brlcad | he did comment in one of the tasks why there were limited facilities |
| 20:28.47 | MarcTannous | he mentioned BRLCAD::objects comparators a few days ago IIRC |
| 20:28.47 | andromeda-galaxy | brlcad: sure, then I'll take a look at doing the visualization and see if it brings up anything that makes one sampling approach look particularly good |
| 20:28.52 | MarcTannous | but he said it would be pretty ahrd to implement |
| 20:29.10 | brlcad | "pretty hard" makes for poor gci tasks :) |
| 20:29.19 | brlcad | especially if rossberg says they're hard :) |
| 20:29.35 | brlcad | andromeda-galaxy: great |
| 20:29.38 | MarcTannous | maybe a beginner task for overflowing the == operator on Vector3Ds? |
| 20:29.59 | MarcTannous | it's a static function with 4 lines of code that I ahve to write in all my unit tests |
| 20:30.05 | brlcad | andromeda-galaxy: grided is always a safe bet -- the question is really whether there's already something shooting a regular or irregular circular pattern, precedence |
| 20:30.42 | starseeker | andromeda-galaxy: I'll hold off on putting up GeometricTools tasks if you're going to tackle the pattern raytracing - that's the more useful of the two |
| 20:30.47 | brlcad | MarcTannous: oh you mean to create a mini set of math helper routines just for the unit testing? |
| 20:31.04 | MarcTannous | I think it would help with other parts of the code too, not just unit testing |
| 20:31.17 | MarcTannous | addition of Vector 3Ds, substraction, checking for equality etc |
| 20:31.19 | MarcTannous | basic stuff |
| 20:31.26 | brlcad | well the other parts of the code aren't test code, so the considerations change in a big way :) |
| 20:31.41 | MarcTannous | a global library that would include all these |
| 20:31.45 | MarcTannous | and be included where needed |
| 20:31.52 | MarcTannous | is that big? |
| 20:31.52 | brlcad | most of that already exists in brl-cad's basic math library (C API) |
| 20:32.08 | MarcTannous | ow |
| 20:32.08 | brlcad | so we definitely wouldn't want to duplicate everything |
| 20:32.21 | brlcad | and double our maintenance burden |
| 20:32.45 | brlcad | not to mention questions about validity (proving routines are correct is a LOT of work) and interoperability |
| 20:33.05 | brlcad | that's why daniel mentioned he left that up to the calling application, so you can use different math libraries and MOOSE doesn't need to know or care |
| 20:33.20 | brlcad | not impossible, but I think there are lower fruit to get picked first |
| 20:33.58 | brlcad | e.g., if the problem is four lines of code getting replicated, refactoring rules would dictate just putting those four lines into a utility file local to the tests so they're only defined once |
| 20:33.58 | MarcTannous | okay then, thought it wouldn't alter the "whole" so much |
| 20:34.26 | MarcTannous | but it would be pretty neat to have operators on Vector3Ds defined as to avoid those huge ifs in unit tests |
| 20:37.49 | brlcad | andromeda-galaxy: useful reading: http://wiki.povray.org/content/Reference:Camera |
| 20:38.11 | brlcad | MarcTannous: I suggest asking daniel about that |
| 20:40.12 | andromeda-galaxy | brlcad: pov-ray? |
| 20:40.47 | andromeda-galaxy | I might be looking at the wrong output for this... I was trying to look at the plot3 output from rtshot with R_DEBUG&RDEBUG_PLOTRAY set |
| 20:43.22 | brlcad | andromeda-galaxy: yeah, pov-ray's docs on cameras are very similar as you're basically setting up a type of camera |
| 20:43.39 | *** join/#brlcad ColloquyUser (~caen23@92.81.191.161) | |
| 20:43.46 | andromeda-galaxy | oh, you mean for the parameters to rtshot? |
| 20:43.58 | brlcad | (the camera is what defines the ray orientations) |
| 20:44.24 | andromeda-galaxy | ahh... |
| 20:44.28 | brlcad | so I just mean in general, in terms of thinking about what the API should look like, what options where should/shouldn't be |
| 20:44.38 | brlcad | s/where/there/ |
| 20:45.02 | andromeda-galaxy | rtshot -p 0 0 0 -d 1 0 0 -X 80000000 -c 10 -n 3 -R 30 |
| 20:45.15 | andromeda-galaxy | oh sorry, that was the wrong thing |
| 20:45.19 | andromeda-galaxy | right |
| 20:46.02 | andromeda-galaxy | that makes sense.. .right now for the visualization I'm trying to make rtshot shoot a bundle, but the above command doesn't seem to be working... it appears to only be shooting one ray for some reason |
| 20:46.05 | Notify | 02GCI:iamhasana * 4531831353376768 : Task Claimed - I would like to work on this task. |
| 20:49.46 | brlcad | andromeda-galaxy: don't know, never run that command ... but I do know it was working at some point; might have gotten broken during some maintenance |
| 20:50.41 | andromeda-galaxy | hmm... okay, still looking into it... if it doesn't start working soon, I'll just write a little application that calls gen_* and then outputs the rays in some nice text format |
| 20:51.15 | andromeda-galaxy | many of the povray camera options seem to have to do with the projection that the camera should use... |
| 20:53.30 | andromeda-galaxy | brlcad: which is kind of interesting... most of the options there seem to really make sense as options to the various ray-pattern-generators, each of which would need their own options, rather than for shooting individual rays. The different kinds of perspectives are also kind of interesting, it seems like at least some of them could be implemented as their own pattern generators |
| 20:53.40 | andromeda-galaxy | (sorry if that cut off, I can't tell for sure if it did or not) |
| 20:54.26 | Notify | 02GCI:iamhasana * 4531831353376768 : Claim Removed - The claim on this task has been removed, someone else can claim it now. |
| 20:54.28 | brlcad | didn't cut off and that's why I mentioned the url; rather deceivingly relevant |
| 20:54.35 | andromeda-galaxy | ahh |
| 20:55.33 | brlcad | gotta run, ttyl! |
| 20:55.35 | andromeda-galaxy | it *seems* relevant but most of it is related to the whole-scene based stuff... it would also be kind of fun to think about ray pattern generators that take geometry as an input option and then use it as part of the generation... |
| 20:55.42 | Notify | 02GCI:iamhasana * 4531831353376768 : Task Claimed - I would like to work on this task. |
| 20:55.44 | andromeda-galaxy | sure :-) |
| 20:55.50 | brlcad | andromeda-galaxy: *bingo* |
| 20:56.02 | brlcad | this is part of a larger issue, creating patterns of replicated geometry |
| 20:56.18 | brlcad | where here the geometry is a simple oriented line/ray |
| 20:56.24 | brlcad | but could in theory be any geometry |
| 20:56.45 | brlcad | and you might want a linear, circular, or rectangular pattern based on a parameterization |
| 20:58.01 | andromeda-galaxy | ah, that makes sense... hopefully this will help get there |
| 20:59.18 | brlcad | btw, the -X 0x80000000 should work... redirect stdout to a file.plot3 |
| 20:59.36 | andromeda-galaxy | that seems to be working, it just only seems to be shooting one ray for some reason... |
| 21:00.13 | brlcad | ah |
| 21:00.19 | Notify | 02GCI:iamhasana * 4531831353376768 : None - Do you know how to submit your designs ? |
| 21:00.40 | brlcad | someone was messing around in there earlier specifically on the bundle shooter and might have broken it |
| 21:01.03 | andromeda-galaxy | makes sense... I'm pretty sure it's calling rt_shootray_bundle() |
| 21:01.49 | andromeda-galaxy | the code for rt_shootray_bundle() looks suspiciously similar to that foor rt_shootray(), that's one reason to favor rt_shootrays() at leasat |
| 21:11.50 | MarcTannous | good night guys |
| 21:26.41 | brlcad | cya MarcTannous ! |
| 21:39.42 | starseeker | well, phooey arbn doesn't do concave shapes |
| 21:42.52 | brlcad | nope, it's a union of half-spaces by definition |
| 21:43.09 | brlcad | er, the intersection rather |
| 21:43.30 | starseeker | crud was hoping to use than instead of NMG |
| 21:43.32 | starseeker | oh well |
| 21:44.30 | brlcad | could take it as an opportunity to fix+merge the nmgreorg branch! that'd help reduce the mess greatly |
| 21:44.45 | starseeker | heh. More concerned with the raytracing performance, actually |
| 21:45.34 | starseeker | NMG (IIRC) is still slow |
| 21:45.49 | starseeker | still wants to replace the NMG ray intersection with BoT intersection under the hood |
| 21:46.12 | brlcad | reduces model->region->shell->loops->edges->vertics to just shell->loops->edges->vertices which will help with that some |
| 21:46.26 | brlcad | doesn't have to go as deep and not nearly as big API |
| 21:46.50 | starseeker | nods - big job though and basically a distraction from my main objective |
| 21:47.15 | brlcad | NMG speed up about 25% just by using pooling ... most of the rest is just simple linear algorithms scanning over all pairings |
| 21:47.53 | starseeker | still - we should in principle be able to convert it to BoTs on the fly and do NMG almost exactly as fast as BoT |
| 21:47.56 | brlcad | it's not a distraction if you need a polygonal container... |
| 21:48.07 | brlcad | unless you're bob :) |
| 21:48.13 | maths22 | brlcad: did you see the CDash coverage stuff? |
| 21:48.27 | brlcad | maths22: nope, at least I don't think so |
| 21:48.49 | brlcad | going nmg->bot isn't a problem ... pretty sure that works now pretty well |
| 21:49.01 | brlcad | using it for ray tracing would be good obviously |
| 21:49.19 | brlcad | the time you were talking about didn't sound like a ray tracing performance issue |
| 21:49.22 | brlcad | but construction |
| 21:49.40 | maths22 | brlcad: http://brlcad.org/CDash/viewCoverage.php?buildid=7 |
| 21:50.18 | brlcad | maths22: that's awesome! |
| 21:50.27 | brlcad | does it stay up-to-date? |
| 21:51.15 | brlcad | wonders if that's counting the tests in the regress directory |
| 21:51.17 | brlcad | and benchmark |
| 21:52.20 | maths22 | brlcad: regress is included; benchmark isn |
| 21:52.36 | maths22 | isn´t |
| 21:52.50 | maths22 | brlcad: would having it update once a week be reasonable? |
| 21:52.50 | starseeker | brlcad: what I wanted to do was toss a bunch of plane equations into arbn and get back a primitive. That's out unless I use the convex hull approach and construct a boolean tree of arbns, which has its attractions... |
| 21:53.47 | starseeker | I went from nmg faces to brep faces for the primitive->brep work, I'm sure I can go the other way for this... but it's a lot of explicit vertex/edge/loop/etc. mucking I was hoping I could dodge |
| 21:54.31 | starseeker | especially if going to NMG also gives a slow raytrace - was thinking arbn might be both more compact and faster |
| 21:56.07 | starseeker | it's even conceivable that the arbn tree approach might let me reduce some shapes down to simple arb combinations |
| 21:58.07 | brlcad | maths22: includes the unit tests? I forget the target name starseeker created to just run them but basically "make test" runs everything (except make benchmark) |
| 21:58.24 | brlcad | would be good to run all three test types for coverage reporting since they're more reflective |
| 21:58.36 | brlcad | starseeker: what was the name of that new target? |
| 21:58.58 | brlcad | starseeker: boolean tree of arbns... that is interesting! |
| 21:59.33 | starseeker | make check? |
| 21:59.49 | brlcad | and for what it's worth, I'd be a little surprised if arbn ended up faster than nmg for an object with the same face count |
| 22:00.00 | brlcad | yeah, check, that's the one -- thanks |
| 22:00.25 | starseeker | maybe not faster, but possibly more compact... |
| 22:00.32 | brlcad | maths22: so yeah, test and benchmark or regress and check and benchmark :) |
| 22:00.36 | maths22 | brlcad: It does the equivalent of make test |
| 22:00.52 | starseeker | might be worth some experimentation, but first I need to get *something* working, good bad or indifferent |
| 22:01.08 | brlcad | definitely more compact |
| 22:01.11 | brlcad | (arbn) |
| 22:01.18 | starseeker | test includes some things that are known not to be working, like flawfinder and rtwizard |
| 22:02.09 | starseeker | flawfinder in particular would be a job to get working... not sure about the others |
| 22:02.27 | maths22 | starseeker: we can exclude with a regex |
| 22:02.44 | starseeker | that's basically what regress and check do automatically |
| 22:02.58 | starseeker | if it's easier to do it in the CDash setup that's cool too - whatever works |
| 22:05.33 | maths22 | I just need a single regex that excludes everything we want to exclude (or includes everything we want to include) |
| 22:06.52 | brlcad | pretty cool to see all the libbu results ... including the coverage across the unit tests themselves |
| 22:07.02 | brlcad | that in theory exist to provide full coverage ;) |
| 22:07.41 | brlcad | dives into more reporting |
| 22:07.56 | maths22 | brlcad: I also could use a regex of files to exclude from coverage testing |
| 22:08.01 | maths22 | ex src/other |
| 22:11.19 | maths22 | starseeker: would it be reasonable to add benchmark to make test? |
| 22:11.37 | Notify | 03BRL-CAD:ejno * 63809 (brlcad/trunk/src/libged/simulate/collision.cpp brlcad/trunk/src/libged/simulate/collision.hpp and 4 others): compile the collision algorithm from simrt.c |
| 22:14.58 | starseeker | maths22: I think it's possible, if brlcad doesn't mind |
| 22:15.37 | starseeker | does some thought experiments and concludes that arbn boolean trees aren't such a hot idea |
| 22:17.37 | starseeker | maths22: the regex match would be something like not matching ^regress- or label matching "Regression" |
| 22:17.55 | starseeker | the "active" regression tests have a label Regression |
| 22:20.32 | starseeker | maybe we could explicitly disable tests with a NOT_WORKING label and do ctest -LE NOT_WORKING ? |
| 22:24.11 | starseeker | tries that... |
| 23:09.57 | Notify | 02GCI:rexey29 * 5269456200663040 : Task Claimed - I would like to work on this task. |
| 23:19.47 | Notify | 02GCI:Melange * 4938019295461376 : Task Reopened - Melange has detected that the final deadline has passed and it has reopened the task. |
| 23:22.31 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 23:30.31 | Notify | 03BRL-CAD:starseeker * 63810 brlcad/trunk/regress/CMakeLists.txt: add a label to disabled tests so ctest -LE NOT_WORKING will function |
| 23:32.45 | Notify | 02GCI:judebirch * 5857438834098176 : Redone - Sorry for the mistake, I've done the entire logo again. |
| 23:51.05 | Notify | 02GCI:mihaineacsu29 * 4531831353376768 : Task Assigned - This task has been assigned to Hasan Ahmad. You have 100 hours to complete this task, good luck! |
| 23:52.41 | Notify | 03BRL-CAD:starseeker * 63811 brlcad/trunk/src/libbrep/shape_recognition.cpp: Need to use tolerancing on the surface checks - eventaully this will become a parameter. |
| 23:52.44 | Notify | 02GCI:mihaineacsu29 * 5269456200663040 : Task Assigned - This task has been assigned to Rexey. You have 100 hours to complete this task, good luck! |
| 23:54.25 | Notify | 03BRL-CAD:starseeker * 63812 brlcad/trunk/src/librt/test_shape_recognition.cpp: Start thinking about how to handle the planar case. nmg is the catch-all solution, but also the least beneficial when it comes to compact data storage. |
