| 00:42.19 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 05:30.15 | Notify | 03BRL-CAD:brlcad * 57439 NIL: Begin a new branch intended to sit as an intermediary between unstable trunk development and STABLE point releases. As a release window nears, trunk will be merged to this new branch, documented, tested, fixed/reverted, stabilized, and finally merged to STABLE when complete. for now, intentionally using just this one branch (not one per release). Here's a pictorial view:trunk |
| 05:30.17 | Notify | -o-o-o-o-o--o-o--o-o--o-o--o--o--o-o--...\ \ \ \RELEASE \ \ o---o-o-o------o-o---...\ \ / \ \STABLE o---o---o-----------o--------o-...\ \ \ \ \tags o o o o o |
| 05:33.55 | brlcad | yep, looks just like that |
| 05:36.16 | n_reed | I can see the plaintext in gmail - I think it's a good diagram, very helpful |
| 05:47.23 | *** join/#brlcad caen23 (~caen23@92.81.182.233) |
| 05:47.56 | *** join/#brlcad kesha (~kesha@49.249.0.140) |
| 05:59.13 | Notify | 03BRL-CAD:phoenixyjll * 57440 brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Flip the face if necessary. |
| 06:15.37 | Notify | 03BRL-CAD:phoenixyjll * 57441 brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: It seem that FilpFace() has no effect... Change vnormal directly. |
| 06:36.55 | *** join/#brlcad kesha_ (~kesha@49.249.8.239) |
| 07:10.41 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 07:23.11 | *** join/#brlcad kesha__ (~kesha@49.202.238.197) |
| 08:16.09 | Notify | 03BRL-CAD:phoenixyjll * 57442 brlcad/trunk/src/libbrep/boolean.cpp: Don't append to intersect[] directly, because the pointers in pts_on_curves[] may be invalid if the capacity of intersect[] is enlarged. And use ON_ClassArray instead of dynamic allocated pointers. |
| 08:35.36 | kesha__ | Hello brlcad |
| 08:36.02 | kesha__ | I tried with some more geometry conversions. Still some queries .. |
| 08:37.05 | kesha__ | Many a times, when I do export, some objects are exported correctly, but it shows a message of segmentation fault(core dumped) and stops (almost 40-50% of those I tried) |
| 08:37.15 | kesha__ | The material property disappears after conversion. The mater and color related information is lost after conversion. |
| 08:37.38 | kesha__ | I tried from http://brlcad.org/private/geometry/ |
| 08:37.50 | kesha__ | http://brlcad.org/private/geometry/3dm_Geometry/ |
| 08:38.46 | kesha__ | I also installed freecad. |
| 08:39.56 | kesha__ | Whenever you are free, can you please walk me through 1 or 2 examples of *perfect 3D model importing* ? |
| 09:09.33 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 09:50.23 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) |
| 11:15.43 | Notify | 03BRL-CAD Wiki:Phoenix * 6089 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 12 */ |
| 12:21.57 | Notify | 03BRL-CAD:tbrowder2 * 57443 brlcad/trunk/src/util/dsp_add_t.cpp: initial implementation of tclap arg parsing |
| 12:54.05 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) |
| 12:55.04 | Izak__ | brlcad: My research indicates that only numerical analysis methods can find the roots for the sextic equation in rt_hrt_shot |
| 12:58.08 | ``Erik | sooooo, slap together a quick newtonian solver or regula falsi or something :D |
| 12:59.28 | Izak__ | Erik: A Newtonian solver? The issue with that is determining the first root in the first place |
| 13:00.41 | brlcad | Izak__: did you actually try a sextic with our solver? what did it do? |
| 13:01.20 | Izak__ | I did not do that because bn_sextic... was not implemented yet |
| 13:02.27 | Izak__ | I consulted 2 mathematicians on the sextic equation and they said we can only approximate the roots. A solution in radicals is inadmissible |
| 13:06.40 | brlcad | so...for a week you've been reading papers and talking to people |
| 13:07.07 | brlcad | without doing a quick compile to demonstrate how the existing solver behaves? |
| 13:07.42 | brlcad | bn doesn't have support for sextic, but that's not the solver |
| 13:08.10 | Izak__ | I was ill too. |
| 13:08.40 | Izak__ | I had to go to hospital for my left eye |
| 13:08.49 | brlcad | I saw that in your log |
| 13:08.57 | brlcad | that was basically a week ago too :) |
| 13:09.42 | Izak__ | I dont understand what you mean by a quick compile |
| 13:10.05 | ``Erik | librt/roots.c has an iterative polynomial root solver that looks like it might do arbitrary order polynomials |
| 13:10.34 | brlcad | the whole point of increasing the limit in bn.h from 4 to 6 was to try and see what it does |
| 13:10.44 | brlcad | we talked about this two or even three weeks ago |
| 13:11.02 | brlcad | first to compile with just the poly limit increased, make sure everything behaves |
| 13:11.19 | brlcad | then to try a sixth order in our solver |
| 13:11.54 | ``Erik | wonders if the iterative poly solver should be moved from librt to libbn |
| 13:12.32 | brlcad | extending src/util/roots_example.c with a sixth order was the next step, not investigating ways to implement a sixth order solver |
| 13:12.38 | Izak__ | For the compilation with the poly limit increased, I did that |
| 13:13.07 | Izak__ | later on saw that Mohit at also committed it |
| 13:13.23 | brlcad | that was just the 10 minute first piece to a long discussion on how to proceed |
| 13:13.42 | brlcad | ``Erik: yeah, it should but is waiting on another patch and some data types before getting migrated |
| 13:14.05 | brlcad | the coefficients are in the wrong order, that needs to be fixed (we have a patch) |
| 13:14.39 | brlcad | Izak__: right, editing 4/6 and compiling was not a big deal -- the point was to run the tests and confirm |
| 13:14.42 | brlcad | then change the example |
| 13:15.29 | Izak__ | brlcad: I am sorry if I didnt get your instuctions right the first time but you should understand i was ill at the time |
| 13:16.27 | brlcad | I get that you were ill, glad that you're better |
| 13:16.35 | brlcad | but this was more of a communication problem |
| 13:17.54 | brlcad | this should have been discussed here and on the mailing list on the 22nd/23rd |
| 13:20.29 | brlcad | Izak__: okay so lets move forward, I'd just ask that you please take a more active invovlement in communicating progress and activity beyond your logs |
| 13:21.10 | brlcad | especially when activity takes a major turn away from coding, towards having to do research |
| 13:22.58 | Izak__ | I just couldn't progress with the coding without looking into solving the sextic equation |
| 13:23.11 | brlcad | I could have told you about the problems solving general sextic equations long before you talked to your math teachers, knew this issue before your proposal was even accepted |
| 13:23.46 | Izak__ | mathematician Tito tested the sextic in rt_hrt_shot and it coulnt be solved in radicals , that is, precise solutions |
| 13:24.33 | Izak__ | So he said only numerical algorithms could be used to approximate this. |
| 13:25.08 | Izak__ | These mathematicians were not prompt to reply me too so that is why it took a while |
| 13:25.14 | brlcad | and guess what, our solver is a numerical algorithm |
| 13:25.25 | Izak__ | what |
| 13:25.42 | Izak__ | roots.c ? |
| 13:26.05 | brlcad | again, this is why this is frustrating, none of this is new information and is a discussion that should have happened (really months ago) |
| 13:26.32 | Izak__ | months ago ? brlcad: common |
| 13:27.07 | brlcad | yes, because this really is at the heart (no pun intended) of implementing your primitive, it's the central piece that is the major unknown |
| 13:27.29 | brlcad | implementing all of the other callbacks are pointless if shot() cannot be resolved, so in a way, it should have been first |
| 13:27.37 | brlcad | which means this discussion would have been first |
| 13:27.45 | brlcad | not a critical issue, though, lots has been learned |
| 13:28.04 | brlcad | the issue was just once you finally got to the hard part, you disappeared instead of discussing it |
| 13:28.21 | brlcad | this was well known to be THE defining problem of implementing this particular primitive |
| 13:28.39 | Izak__ | I was told that as concerns shot I am the expert |
| 13:28.42 | brlcad | the goal and plan was never to implement a sextic solver even if ours is determined to be inadequate |
| 13:29.38 | Izak__ | So i had the impression that solving rt_hrt_shot was my responsibility alone |
| 13:30.43 | brlcad | you're basically saying that your mentors have no business .. mentoring you? |
| 13:31.06 | Izak__ | No that's not what I am saying |
| 13:31.14 | brlcad | it's certainly your responsibility to try and implement it as best possible, but that's not in a vacuum |
| 13:31.19 | brlcad | communication is expected |
| 13:31.39 | Izak__ | The thing is I asked Erik:and he said I was the expert for rt_hrt_shot |
| 13:32.19 | brlcad | sure, as far as the code is concerned, nobody knows that code right now better than you |
| 13:32.41 | Izak__ | even you and Erik ? |
| 13:33.09 | ``Erik | we haven't written any of it, we didn't design it, we just occasionally glance at it to make sure it's not completely wrong... |
| 13:33.12 | brlcad | we may understand the bigger picture better, what you're doing and why, how it fits in |
| 13:33.15 | brlcad | but you wrote it |
| 13:33.30 | brlcad | still, what's the point? |
| 13:33.42 | Izak__ | yes i did and I take responsibility for that |
| 13:34.34 | brlcad | http://brlcad.org/~Izak/rt_shot_test.png is a dead link, btw |
| 13:34.43 | ``Erik | I grok that there's a 6th order polynomial to define the trace line of the shape, but I don't know which coefficient causes which changes in the surface (I do know we have code to estimate roots of nth order polynomials and fast code for 3rd and 4th order) |
| 13:36.12 | ``Erik | for the hrt_shot() bit, you're the expert, but it'll use other bits of code where you're not the expert *shrug* :) |
| 13:36.37 | Izak__ | Okay i get it. |
| 13:38.17 | brlcad | Izak__: let me frame this another way -- I don't think you have the time or background to implement a sixth order solver in the time remaining, and I would have told you that a month ago even had I thought you'd try going down that route |
| 13:38.32 | brlcad | and that's not intended to be offensive |
| 13:38.40 | brlcad | it's a very hard problem |
| 13:39.04 | brlcad | that could have been a gsoc proposal all by itself |
| 13:39.57 | brlcad | that's why it was/is necessary to determine how the existing solver behaves, and if it doesn't work, we need to document that and THEN discuss what to do about it |
| 13:40.11 | brlcad | make sense? |
| 13:41.21 | Izak__ | So I need to test if the root solver actulally solves sextics |
| 13:42.35 | brlcad | not any sextic |
| 13:43.03 | brlcad | your specific sextic, which is a dramatically different question |
| 13:44.07 | Izak__ | So should I use the equation in rt_hrt_shot ? |
| 13:44.08 | brlcad | ours numerical method is based around an assertion that there is at least some surface correllation with stability in the second order derivatives |
| 13:44.19 | brlcad | your shape predominantly does have stable second order derivatives |
| 13:45.31 | brlcad | so it'll either blow up dirty fast and give crap, or it'll give 90% good probably screwing up on the top lobes, or 100% adequate |
| 13:45.49 | Izak__ | So how am i supposed to do that |
| 13:45.55 | brlcad | assuming you decomposed that massive equation perfectly .. yes ;) |
| 13:46.09 | brlcad | i'm hard-pressed to believe there's not a typo in there somewhere ;) |
| 13:46.29 | brlcad | all it takes is one missing '-' and it'll all go to hell |
| 13:48.49 | Izak__ | brlcad: Are you saying I should re check the coefficients of the equation |
| 13:49.08 | brlcad | how: edit src/util/roots_example.c, add your polynomial, and query a specific root -- ideally one that you are certain has roots |
| 13:49.25 | brlcad | if you've not already done that, *absolutely* |
| 13:49.37 | brlcad | or even express it in two forms |
| 13:50.24 | Izak__ | like in the torus ? |
| 13:51.21 | brlcad | mmm, no |
| 13:51.26 | brlcad | like in rt_tgc_shot() |
| 13:51.54 | brlcad | see the comment on 741 |
| 13:52.39 | brlcad | like that where it's expressed in unexpanded math terms and in theory is identical, just slower |
| 13:55.00 | brlcad | don't sweat it if you can't describe it that way, but if you can, that would be a great validation that there's not a simple typo |
| 13:56.26 | brlcad | so you then test the solver via roots_example.c just to see what it does, then let shot() get called and see what image results, how many "failed to converge" messages are given, or what else happened |
| 13:56.32 | brlcad | s/happened/happens/ |
| 13:57.42 | Izak__ | ok |
| 13:58.24 | Notify | 03BRL-CAD:starseeker * 57444 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Get NURBS form of rev surface for export. |
| 13:58.42 | brlcad | know that it "probably" won't work, but we got to at least see what it does |
| 13:59.00 | brlcad | there's >1% chance that it'll just work too ;) |
| 14:20.21 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b102:9b5f:0:4a:bf99:2901) |
| 14:50.43 | Izak_ | f |
| 16:13.45 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 16:21.16 | *** join/#brlcad kesha__ (~kesha@49.249.17.228) |
| 16:39.42 | *** join/#brlcad Izak (~Izak@195.24.220.16) |
| 17:15.01 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) |
| 17:15.32 | Izak__ | brlcad: i have built the sextic polynomial again |
| 17:15.40 | Izak__ | like in the tgc shot |
| 17:16.22 | Izak__ | I have tested in the archer/mged interface and it keeps saying raytrace failed and rt_hrt_plot not implemented yet |
| 17:16.40 | Izak__ | Does the image depend on rt_hrt_plot ? |
| 17:20.02 | Izak__ | Erik: brlcad : please take a look at http://paste.kde.org/p639981da/ . I built the sextic equation gradually like in rt_tgc_shot() |
| 17:31.01 | brlcad | Izak__: don't plot it |
| 17:31.31 | brlcad | running the "draw" command depends on plot() being implemented |
| 17:31.45 | Izak__ | I ran the rt command instead |
| 17:31.57 | brlcad | you don't need to draw it, or you could draw a point or a line or set of lines or something simple |
| 17:32.19 | brlcad | rt run from within mged uses what is "draw"n by default |
| 17:32.26 | Izak__ | I created a heart shape and ran 'rt' on it |
| 17:32.29 | brlcad | so if you can't draw it, you can't run rt |
| 17:32.36 | brlcad | but you can run rt from outside mged |
| 17:32.40 | Izak__ | I am editing roots_example.c now |
| 17:32.47 | brlcad | that's good |
| 17:32.57 | brlcad | that's really the next step I think, before running the trace |
| 17:33.13 | brlcad | just to make sure the evaluator doesn't crash or run off into an infinite loop |
| 17:33.40 | brlcad | whether it solves a root will entirely depend on the ray you use (try to hit it dead on center) |
| 17:33.51 | brlcad | (where it's most "flat") |
| 17:34.22 | Izak__ | ok Just wanted to check that my coefficients were correct |
| 17:34.22 | Izak__ | have you looked at the code on kde paste ? |
| 17:35.18 | Izak__ | How should I hit the center say? |
| 17:37.49 | brlcad | Izak__: yes, the paste is certainly easier to read than the other form |
| 17:38.06 | brlcad | whether it's right or not, is not something I'm going to see just glancing through the file |
| 17:38.31 | Izak__ | okay I justb wanted you to appreciate the method |
| 17:38.32 | brlcad | I don't see anything obviously wrong, but it's not like I'm going to notice a missing minus sign in 200 lines of math code :) |
| 17:38.45 | Izak__ | :) |
| 17:39.54 | brlcad | so if you call bn_pr_poly() on that paste 'S' polynomial and the one current committed, are they identical? |
| 17:41.14 | brlcad | that's really the validation going for -- reducing the liklihood that there's a typo |
| 17:42.30 | brlcad | so if something isn't working, we know it's more likely the solver or initial math than it being a typo |
| 17:43.12 | Izak__ | I really took time to work through this one with accuracy and I checked again you know |
| 17:44.00 | brlcad | I don't doubt that you did |
| 17:44.42 | brlcad | if they're the same, it's a confirmation validation |
| 17:45.00 | brlcad | if they're different, then likely something wrong in the expanded/fast version, but worth checking into |
| 17:47.05 | brlcad | you can test putting them both into roots_example, and see if calling bn_pr_poly() prints the same |
| 18:01.20 | Izak__ | brlcad :It means I will have to choose arbitrary values for dprime and pprime right ? |
| 18:04.53 | Izak__ | Or did you mean I should test at the center (0,0,0) ? |
| 18:23.00 | Notify | 03BRL-CAD:tbrowder2 * 57445 brlcad/trunk/src/util/dsp_add_t.cpp: initial subclass experiment |
| 18:29.51 | brlcad | Izak__: it depends on the primitive parameters |
| 18:30.05 | brlcad | so no, not arbitrary values for dprime/pprime |
| 18:30.33 | brlcad | carefully selected values that should (hopefully) result in a stable evaluation |
| 18:31.03 | Notify | 03BRL-CAD:brlcad * 57446 brlcad/trunk/src/util/dsp_add_t.cpp: since it's all within a try/catch block now, count is used potentially uninitialized |
| 19:00.45 | Izak__ | brlcad: Have just compiled roots_example.c, how do I test to see its values generated |
| 19:00.45 | Izak__ | ? |
| 19:13.14 | brlcad | you run it |
| 19:16.22 | Izak__ | does the regular make compile it or do i have to usee gcc |
| 19:21.38 | Izak__ | brlcad: This is what I get http://paste.kde.org/p1c0cf23a/ |
| 19:22.01 | Izak__ | when I complie given the command in the roots_example.c comment |
| 19:24.03 | brlcad | it's integrated into the build system, you should not need to build it by hand |
| 19:24.48 | brlcad | you certainly can fix those errors, but it's easier to just run make && bin/roots_example |
| 19:31.21 | Izak__ | brlcad: System says there is no file called roots_example |
| 19:36.49 | brlcad | Izak__: where are your source and build directories located? |
| 19:37.54 | Izak__ | My source is in /home/Izak/Code/ and build in /home/Izak/Code/brlcad-build/bin/ |
| 19:38.02 | brlcad | went through this same discussion with Ch3ck, where were you? :) |
| 19:39.46 | Izak__ | I was surely doing sth else at the time |
| 19:40.07 | brlcad | bin/ is not your build dir, that would be probably /home/Izak/Code/brlcad-build/ |
| 19:40.27 | brlcad | how are you compiling? |
| 19:41.29 | Izak__ | I dont understand ? |
| 19:41.32 | brlcad | what commands are you running |
| 19:41.42 | brlcad | walk me through what exactly you are typing |
| 19:42.02 | brlcad | or show me a log or something |
| 19:42.14 | Izak__ | cmake ../brlcad -DCMAKE_BUILD_TYPE=Debug |
| 19:42.17 | Izak__ | make |
| 19:42.26 | Izak__ | make benchmark |
| 19:42.30 | Izak__ | make install |
| 19:42.50 | brlcad | okay, and no errors on any of those? |
| 19:43.00 | Izak__ | in the /home/Izak/Code/brlcad-build/ directory |
| 19:43.07 | brlcad | nods, good |
| 19:43.09 | Izak__ | No errors |
| 19:44.01 | brlcad | ah, i bet i know the problem |
| 19:44.17 | brlcad | yeah, that's it |
| 19:44.50 | brlcad | if you look in brlcad/src/util/CMakeLists.txt, you'll see that roots_example is marked NO_INSTALL |
| 19:45.04 | brlcad | which means ... *drumroll* don't put it into the bin directory |
| 19:45.11 | brlcad | so this: |
| 19:45.26 | brlcad | ~/brlcad-build/src/util/roots_example |
| 19:46.25 | brlcad | the binary is left in the build subdir since it's just for testing |
| 19:46.36 | brlcad | it used to be in bin/ |
| 19:56.33 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6090 /wiki/User:Izak/GSOC_2013_logs: /* August 26th to August 31st */ |
| 20:00.25 | Izak__ | Need to do some debugging |
| 20:52.55 | Notify | 03BRL-CAD Wiki:Vladbogolin * 6091 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 12 */ |
| 21:01.40 | *** join/#brlcad mpictor (~mark@2601:d:b280:3d4:d63d:7eff:fe2d:2505) |
| 21:12.03 | Notify | 03BRL-CAD:brlcad * 57447 (brlcad/branches/RELEASE/AUTHORS brlcad/branches/RELEASE/BUGS and 899 others): merge trunk from r55755 through r57446 into the release branch, beginning preparations and testing for release 7.24.2 |
| 21:46.52 | Notify | 03BRL-CAD:jordisayol * 57448 brlcad/trunk/misc/debian/changelog: update debian changelog |
| 22:07.52 | Notify | 03BRL-CAD:starseeker * 57449 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Work on figuring out how to properly export a rational curve |
| 22:19.11 | Notify | 03BRL-CAD:tbrowder2 * 57450 brlcad/trunk/src/util/dsp_add_t.cpp: add more of TCLAP code to customize |
| 22:31.05 | Notify | 03BRL-CAD:starseeker * 57451 brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: Add ability to print specific 3D curve info |
| 22:32.59 | Notify | 03BRL-CAD:starseeker * 57452 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Multiplicity (at a minimum) isn't right. |
| 22:44.12 | Notify | 03BRL-CAD:tbrowder2 * 57453 brlcad/trunk/src/util/dsp_add_t.cpp: eliminate showing '--' or '--version' args |
| 23:09.44 | Notify | 03BRL-CAD:tbrowder2 * 57454 brlcad/trunk/src/util/dsp_add_t.cpp: demo '?' arg when we have no long help (same as '-h') |
| 23:17.43 | Notify | 03BRL-CAD:tbrowder2 * 57455 brlcad/trunk/src/util/dsp_add_t.cpp: TCLAP takes care of no-arg situation |
| 23:28.37 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
