| 00:13.55 | *** join/#brlcad pgzkipnwellsklws (~armin@dslb-088-066-157-191.088.066.pools.vodafone-ip.de) | |
| 00:19.23 | *** join/#brlcad infobot (~infobot@rikers.org) | |
| 00:19.23 | *** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;) | |
| 01:28.28 | *** join/#brlcad yorik (~yorik@2804:431:f720:f6ac:290:f5ff:fedc:3bb2) | |
| 02:07.10 | *** join/#brlcad louipc_ (~louipc@archlinux/fellow/louipc) | |
| 02:36.46 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-eengafheskakcykv) | |
| 05:02.57 | *** part/#brlcad ignacio (ignacio@fedora/sugar/ignacio) | |
| 05:26.05 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:26.55 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:27.40 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:28.32 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:29.17 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:30.07 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:30.53 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:31.43 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 06:30.09 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 06:43.54 | *** join/#brlcad chenzhe (~smuxi@d66-222-134-161.abhsia.telus.net) | |
| 07:05.12 | *** join/#brlcad DaRock1 (~Thunderbi@mail.unitedinsong.com.au) | |
| 07:23.44 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 07:38.45 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 08:03.47 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 08:18.18 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 08:23.49 | *** join/#brlcad merzo (~merzo@user-94-45-58-139.skif.com.ua) | |
| 08:28.31 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) | |
| 10:39.29 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 11:25.34 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-peuegugvujnrorma) | |
| 11:32.03 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 11:53.36 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 12:06.56 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:21.38 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 12:22.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:23.42 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:24.27 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:25.17 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:26.02 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:26.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:27.40 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:04.42 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 13:36.40 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:50.36 | *** join/#brlcad mdtwenty[m] (mdtwentyma@gateway/shell/matrix.org/x-uyltizopgikldkkn) | |
| 14:05.33 | *** join/#brlcad mdtwenty[m] (mdtwentyma@gateway/shell/matrix.org/x-iwpdlhgermucyhhk) | |
| 14:53.15 | *** join/#brlcad yorik (~yorik@2804:431:f720:f6ac:290:f5ff:fedc:3bb2) | |
| 16:24.23 | *** join/#brlcad d_rossberg (~rossberg@104.225.5.10) | |
| 17:24.30 | d_rossberg | gabbar1947: any additional questions? |
| 17:25.18 | gabbar1947 | whats with the annot vs ant, mentioned by you |
| 17:25.19 | gabbar1947 | ? |
| 17:28.16 | gabbar1947 | I had mentioned in the mail, that there occurs a segmentation fault as soon as I inititalize anip->ant.count to any number in typein.c(annot_in()). Any idea as to why this happens |
| 17:48.02 | d_rossberg | in include/rt/primitives/annot.h you use sometines _annot_ and sometimes _ant_ |
| 17:48.32 | d_rossberg | however, it looks like you mean the internal list when you use ant |
| 17:51.37 | gabbar1947 | yes ant is the list |
| 17:51.54 | gabbar1947 | annot is only referred in the case of internal object |
| 17:52.07 | d_rossberg | then it's ok |
| 17:55.18 | gabbar1947 | For the plot() function, we need to get the coordinates in the 3D space. For that I think we need the current plane of the screen (i.e. the unit vectors describing the plane of the screen). I had a look at the bview struct and was trying to proceed further.... Is there any other way to do this ? |
| 17:58.56 | d_rossberg | and for the segmentation fault i would need to see your code |
| 18:00.18 | d_rossberg | for the plat() function: did you got my mail i wrote today? |
| 18:00.34 | gabbar1947 | Oh yess, just went through your mail ! |
| 18:01.04 | gabbar1947 | But still I think we will need the screen plane coordinates ? |
| 18:02.09 | d_rossberg | you will need to know the "pixels per inch", but the displymanager should know about it |
| 18:03.23 | d_rossberg | and the drawing functions in libdm draw directly to the screen (in pixels) |
| 18:04.27 | d_rossberg | and, why do you call your patchfile .c |
| 18:05.10 | gabbar1947 | haha ! sorry, was into .c files since the morning. I'll update |
| 18:06.27 | d_rossberg | wait .. |
| 18:06.38 | d_rossberg | it should be " |
| 18:07.01 | d_rossberg | Copyright (c) 2017" |
| 18:07.14 | gabbar1947 | okay |
| 18:07.28 | d_rossberg | the files where created this year |
| 18:13.43 | d_rossberg | that's all i can see for now |
| 18:13.50 | gabbar1947 | This is what I was talking about. This is a snippet from the l_seg part of the sketch plot function. Here we have u_vec and v_vec that define the sketch plane, hence we can map the 2D coords to the 3D space. But in the case of annotations the plane of the screen is always the annotation plane, so we'll be needing the screen plane vectors, i suppose... |
| 18:13.50 | gabbar1947 | VJOIN2(pt, V, sketch_ip->verts[lsg->start][0], u_vec, sketch_ip->verts[lsg->start][1], v_vec); |
| 18:13.50 | gabbar1947 | <PROTECTED> |
| 18:13.50 | gabbar1947 | <PROTECTED> |
| 18:13.50 | gabbar1947 | <PROTECTED> |
| 18:16.15 | d_rossberg | ~pastebin |
| 18:16.15 | infobot | methinks pastebin is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few: http://pastebin.ca, http://channels.debian.net/paste, http://paste.lisp.org, http://bin.cakephp.org/; or install pastebinit with yum or aptitude. |
| 18:16.59 | d_rossberg | forget the sketch here |
| 18:17.55 | d_rossberg | write the lines in an unmodified x-y plane and flag it as the display plane |
| 18:18.14 | d_rossberg | then the display manager should know how to handle it |
| 18:19.07 | d_rossberg | i.e. RT_ADD_VLIST(vhead, pt, BN_VLIST_DISPLAY_LINE_MOVE); |
| 18:20.07 | gabbar1947 | Okay! will proceed accordingly. And one more thing, annotations always remain in the plane of screen, irrespective of the user rotating the entire model. I don't think the display manager will handle this thing, we'll have to handle it. is it? |
| 18:22.15 | d_rossberg | of course the dm can handle this, and furthermore, only the displaymanager can handle this |
| 18:23.32 | d_rossberg | if we would rely on the existing structures the dm could shift, rotate, and zoom it around |
| 18:23.57 | gabbar1947 | Okay so for now, the priority is to add all the elements to the vlist and we need to define some functions in bn/vlist.h for its accomplishment. On it ! |
| 18:25.29 | d_rossberg | the hard part (but i don't think it's too hard) is to handle them in the displaymanagers |
| 18:25.57 | d_rossberg | adding them to bn_vlist should be easy ;) |
| 18:27.05 | gabbar1947 | So, we'll have to handle them for all display managers? |
| 18:27.15 | d_rossberg | jep |
| 18:31.54 | gabbar1947 | :) |
| 18:33.57 | gabbar1947 | and regarding the seg fault, I've checked the import/export functions, there seem to be no issue with those. Do have a look if you get time, by the time I'll dive into vlist.h ! |
| 18:37.13 | d_rossberg | regarding the seg fault: the is no anip->ant.count in the typein.c i got |
| 18:38.21 | gabbar1947 | It was commented previously, then we decided to remove the comments. Hence the line got removed |
| 18:38.47 | gabbar1947 | just ( anip->ant.count = 1) |
| 18:42.24 | d_rossberg | why not anip->ant.count = 0 ? |
| 18:43.09 | d_rossberg | otherwise you had to allocate an rt_ant |
| 18:45.16 | gabbar1947 | there seems to be no error with 0, but I was trying to include a line_seg, hence 1. |
| 18:45.17 | gabbar1947 | <PROTECTED> |
| 19:06.59 | d_rossberg | no, there isn't |
| 19:09.38 | d_rossberg | you need to allocate memory for a pointer in segment, a line_seg, and write the address of the line segment memory to segment[0] |
| 19:10.07 | gabbar1947 | I did that, still this issue persisted |
| 19:11.16 | d_rossberg | then: show me your code ;) |
| 19:11.24 | gabbar1947 | You can see this in the previous revisions of annot.c patch |
| 19:11.49 | gabbar1947 | Wait, I'll have a look a look again, and get back to you |
| 19:16.52 | d_rossberg | gabbar1947, i'll review, and hopefully commit, your patch tomorrow |
| 19:17.59 | d_rossberg | and "look at a previous version and comment some (the right!) lines out" is a bad approach ;) |
| 19:18.10 | d_rossberg | simply show me your code |
| 19:20.12 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 19:22.22 | *** join/#brlcad DaRock (~Thunderbi@mail.unitedinsong.com.au) | |