| 00:38.45 | hcurtis | I am going back through fast4-g.c to look for clues to the answers to my questions. The variable region_list_len might be key in this equation. |
| 01:10.03 | hcurtis | Since I have determined that group_head is an important part of the solution, it would be a better idea to narrow my focus by learning more about it. I see that group_head is used with functions such as mk_addmember and mk_lfcomb. I will examine those. |
| 01:45.13 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 02:02.18 | *** join/#brlcad mpictor (~mark@c-68-58-38-45.hsd1.in.comcast.net) | |
| 02:10.12 | hcurtis | What does the w in the struct name wmember and the header name wdb.h mean? I looked for the answer but could not find it. |
| 03:11.44 | hcurtis | I am reading a pdf from the BRL-CAD Tutorial Series called Converting Geometry Between BRL-CAD and Other Formats. It has a section about FASTGEN-to-BRL-CAD conversion that might help me better understand the fast4-g task. |
| 03:30.40 | *** join/#brlcad infobot (~infobot@rikers.org) | |
| 03:30.40 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 2014 selections are announced! Thank you to all we got to work with. Remember that SOCIS is coming up right around the corner and you don't need a summer of code to get involved with open source. | |
| 04:15.58 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 04:38.02 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 06:08.01 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7318 /wiki/User:Hcurtis0010/GSoC2014/logs: /* Week 5 */ |
| 06:16.41 | Notify | 03BRL-CAD Wiki:Hcurtis0010 * 7319 /wiki/User:Hcurtis0010/GSoC2014/logs: /* Week 5 */ |
| 07:10.32 | Notify | 03BRL-CAD Wiki:14.98.17.66 * 7320 /wiki/User:Shainasabarwal/GSoC14/logs: /* Week 4 */ |
| 08:26.55 | *** join/#brlcad vladbogo (~vlad@195.216.218.10) | |
| 08:31.13 | *** join/#brlcad piyushparkash (~piyushpar@117.205.70.158) | |
| 08:41.11 | *** join/#brlcad albertcoder (~albertcod@101.214.178.123) | |
| 08:48.40 | *** join/#brlcad mihaineacsu (~mihaineac@109.166.129.226) | |
| 08:57.38 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 09:01.07 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7321 /wiki/User:Popescu.andrei1991/devlogs2014: /* Week 5 */ |
| 09:12.21 | *** join/#brlcad andrei_ (~IceChat77@188.26.187.205) | |
| 09:15.59 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 09:55.20 | *** join/#brlcad albertcoder (~albertcod@101.214.178.123) | |
| 10:24.48 | *** join/#brlcad piyushparkash (~piyushpar@59.91.252.52) | |
| 11:01.31 | *** join/#brlcad vladbogo (~vlad@195.216.218.10) | |
| 11:13.27 | *** join/#brlcad vladbogo (~vlad@195.216.218.10) | |
| 11:50.52 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) | |
| 13:11.11 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 13:13.51 | Notify | 03BRL-CAD Wiki:Vladbogolin * 7322 /wiki/User:Vladbogolin/GSoC2014/Logs: /* Week 5 */ |
| 13:21.16 | *** join/#brlcad caen23 (~caen23@92.83.166.162) | |
| 13:21.20 | *** join/#brlcad piyushparkash (~piyushpar@59.91.252.52) | |
| 13:29.51 | Notify | 03BRL-CAD:ejno * 61356 brlcad/trunk/src/conv/3dm/3dm-g.cpp: remove global variables |
| 13:33.55 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:34.38 | andrei_ | did anyone have time to look @ my patch? I'm not sure what to do with the Sketch implementation |
| 13:34.49 | ``Erik | CGI breakdown of 'game of thrones' (even if you don't watch the show, it's interesting to see how they composite things and do the modeling) http://youtu.be/i4GkA6rIPDc |
| 13:50.15 | d_rossberg | andrei_: i'm currently working on it |
| 13:50.28 | andrei_ | ah, cool, thanks ! :) |
| 13:57.29 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 14:11.44 | *** join/#brlcad albertcoder (~albertcod@49.138.156.1) | |
| 14:30.38 | *** join/#brlcad piyushparkash (~piyushpar@59.91.252.52) | |
| 15:04.53 | *** join/#brlcad piyushparkash (~piyushpar@59.91.252.52) | |
| 15:22.38 | andrei_ | Daniel: i've got one question |
| 15:22.56 | andrei_ | in bezier, there's control points array |
| 15:23.05 | andrei_ | but no size, how do you know how much to put in? |
| 15:24.31 | andrei_ | ah, nvm |
| 15:27.15 | d_rossberg | find the answer by yourself: include/rtgeom.h line 526 |
| 16:03.18 | raj12lnm | kanzure: can you guide me regarding binunif. |
| 16:03.42 | raj12lnm | First is it a relevant primitive to be wrapped ? |
| 16:04.19 | kanzure | i don't know :) |
| 16:05.12 | raj12lnm | If yes how shld it be wrapped? |
| 16:06.39 | kanzure | maybe instead of wrapping it, rewrite it in python |
| 16:06.53 | kanzure | not sure |
| 16:08.07 | raj12lnm | mged creates binunif by reading data from a file. |
| 16:09.27 | raj12lnm | kanzure: As far as I understand binunif is just a stream of data. |
| 16:09.43 | raj12lnm | Will have a utility in python ? |
| 16:10.38 | raj12lnm | What do you say ? |
| 16:10.44 | kanzure | yes, it might have utility |
| 16:11.36 | raj12lnm | Ok. kanzure: Then what shld be the process to be adapted. |
| 16:13.18 | kanzure | rt_mk_binunif requires a pointer to a wdb instance |
| 16:13.28 | kanzure | and minor_type |
| 16:13.35 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 16:13.50 | kanzure | i don't know what minor_type is, but it sounds like an extra typing layer on top of the existing types |
| 16:18.07 | *** join/#brlcad piyushparkash (~piyushpar@59.91.252.52) | |
| 16:18.59 | raj12lnm | kanzure: the minor type are 10 differebt types |
| 16:19.25 | raj12lnm | And binunif means binary uniform data. (As per I understood) |
| 16:20.31 | raj12lnm | And thus, the question if it makes sense to create a binary data (primitive) for python |
| 16:20.36 | raj12lnm | ? |
| 16:26.16 | *** join/#brlcad hcurtis (b82d188d@gateway/web/freenode/ip.184.45.24.141) | |
| 16:41.29 | hcurtis | I am working on the fast4g.c task. One interesting thing (to me at least) is that after last night's research, I now possess a better understanding of the difference between CSG and BREP. While FASTGEN4 is a BREP format, BRL-CAD relies more heavily on CSG. Fast4-g's purpose is to convert FASTGEN4 to BRL-CAD. |
| 16:41.41 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 16:41.56 | *** join/#brlcad cwstirk (~charlie@c-24-9-78-79.hsd1.co.comcast.net) | |
| 16:44.29 | hcurtis | I have tried hard to answer the following important questions for my task, but so far I have not been able to. I will continue researching them, but Sean has encouraged me to turn to the community for help more often. Does anyone know the answers to the questions below? |
| 16:44.53 | hcurtis | 1. How do I know when the heap memory allocated for the variable group_head needs to be resized? |
| 16:45.11 | hcurtis | 2. Once I have determined that, how do I know what new size it needs to be? |
| 16:45.40 | hcurtis | 3. Why does the group_head array in fast4-g's commit 56495 hold 11 elements in particular and not some other number of them? |
| 16:46.25 | andrei_ | the answer to the last question is that, most likely, it can never have over 11 elements |
| 16:46.37 | andrei_ | You shouldn't look for a value like "5, 3, 1, 4 or 7" |
| 16:47.08 | andrei_ | I mean, you should use a variable to figure out how large the array needs to be |
| 16:47.15 | hcurtis | Hi, andrei_. |
| 16:47.21 | andrei_ | because, if it wasn't like this, your task would've been "change 11 to the appropriate number" |
| 16:47.24 | andrei_ | Hello :) |
| 16:48.43 | andrei_ | this solution is not ellegant, but it works |
| 16:48.55 | andrei_ | dynamically allocate the array with 11 size(hardcoded) |
| 16:49.08 | andrei_ | then reallocate to the appropriate size(count how many elements you put in) |
| 16:50.40 | hcurtis | Thank you. |
| 17:00.39 | hcurtis | andrei_: I'm thinking about your response. When you say "dynamically allocate the array with 11 size(hardcoded)", are you saying I need to include a line of code like the following? |
| 17:01.13 | hcurtis | andrei_: struct wmember* somePointer = (struct wmember*) bu_malloc(sizeof(struct wmember*) * 11, "a string") |
| 17:01.48 | andrei_ | yes |
| 17:02.49 | hcurtis | Ok |
| 17:05.34 | hcurtis | andrei_: I appreciate your guidance. |
| 17:05.49 | hcurtis | By the way, I have written a new draft of my code to convert elements of BRL-CAD's fast4-g.c from stack allocated to dynamic. Any feedback is welcome. http://paste.lisp.org/+32AH |
| 17:07.09 | andrei_ | hmm |
| 17:07.37 | andrei_ | you need to change 213, group_head is still static (has [] ) |
| 17:07.46 | andrei_ | you ll need to change it to a memory pointer |
| 17:08.14 | andrei_ | also, you can't keep the 11 at 907, 2943 & 2944, you have to use a global variable(Sean might have a different opinion, but this ll help you understand) |
| 17:09.03 | andrei_ | group_head = (struct wmember *) bu_malloc( 11 * sizeof(struct wmember), "allocate heap memory for wmembers"); |
| 17:09.08 | andrei_ | you forgot to add the 11. |
| 17:09.19 | andrei_ | then, at realloc, you use the same group_head, not group_head2 |
| 17:10.17 | hcurtis | This code doesn't include the changes you suggested today. It is from earlier this week. |
| 17:10.25 | andrei_ | aah, ok |
| 17:13.28 | hcurtis | [13:09] <andrei_> then, at realloc, you use the same group_head, not group_head2 I thought when using realloc I needed to create a new variable because if the realloc fails, it will return null and overwrite the data in the original variable. |
| 17:14.29 | andrei_ | well, indeed, but you have to point it back to group_head |
| 17:14.53 | hcurtis | Ok |
| 17:18.04 | hcurtis | Well, at least one thing I can say is that I know more than when I started. |
| 17:18.46 | hcurtis | andrei_: Thanks again for all of your help. |
| 17:18.58 | andrei_ | hcurtis: no problem at all :) |
| 17:39.29 | *** join/#brlcad albertcoder (~albertcod@101.214.151.254) | |
| 18:03.11 | *** join/#brlcad cwstirk (~charlie@c-24-9-78-79.hsd1.co.comcast.net) | |
| 18:05.12 | Notify | 03BRL-CAD Wiki:Krajkreddy * 7323 /wiki/User:Krajkreddy/GSOC14/summary: /* Week 4 */ |
| 18:06.07 | Notify | 03BRL-CAD Wiki:Krajkreddy * 7324 /wiki/User:Krajkreddy/GSOC14/summary: Correct Week Numbering |
| 18:12.31 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 18:51.48 | hcurtis | I am working on another draft of my code to convert elements of BRL-CAD's fast4-g.c from stack allocated to dynamic. I will post it as soon as it's ready. |
| 19:12.32 | hcurtis | Here is the newest draft. http://paste.lisp.org/+32AW |
| 19:12.39 | clock | is it possioble to vandalize BRL-CAD |
| 19:13.02 | clock | by creating a scene with lot of transparent object where the raytracer hat to split the beam two every time it hits a surface |
| 19:13.13 | clock | driving the number of beams up exponentially and overloading the raytracer? |
| 19:18.24 | *** join/#brlcad piyushparkash (~piyushpar@59.91.252.52) | |
| 19:36.21 | *** join/#brlcad albertcoder (~albertcod@101.214.151.254) | |
| 19:46.32 | hcurtis | I read a little more in the document "Converting Geometry Between BRL-CAD and Other Formats", and now I am reading an article about the relationship between structs and pointers. I think that it will help me to better understand the parts of fast4-g.c that I am having trouble with. |
| 19:57.27 | Notify | 03BRL-CAD:ejno * 61357 brlcad/trunk/src/conv/3dm/3dm-g.cpp: cleanups |
| 20:45.01 | hcurtis | "It is often much cheaper in time and space to copy and dereference pointers than it is to copy and access the data to which the pointers point." This statement that I have just read is interesting to me because it sheds some light on why pointers are so valued in programming. |
| 21:22.54 | ankesh11 | brlcad: I tried adjusting to our color-scheme. Here's a screenshot. |
| 21:22.57 | ankesh11 | http://i.imgur.com/2dQgogz.png |
| 21:24.18 | ankesh11 | Also since the user-accounts are a bit of issue now, I will go do unique URLs for each uploaded file for now. |
| 21:32.30 | hcurtis | I had noticed that some devs would initialize pointers with NULL, and I wondered why. Now I know: |
| 21:33.36 | hcurtis | "Because the C language does not specify an implicit initialization for objects of automatic storage duration, care should often be taken to ensure that the address to which [a pointer] points is valid; this is why it is sometimes suggested that a pointer be explicitly initialized to the null pointer value, which is traditionally specified in C with the standardized macro NULL." |
| 21:39.30 | Notify | 03BRL-CAD Wiki:Albertcoder * 7325 /wiki/User:Albertcoder/GSoC2014/logs: /* Week 5 */ |
| 21:41.49 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) | |
| 22:07.28 | Notify | 03BRL-CAD Wiki:Ankeshanand * 7326 /wiki/User:Ankeshanand/GSoC14/logs: /* Week 5 */ |
| 22:08.18 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 22:08.26 | Notify | 03BRL-CAD Wiki:Ankeshanand * 7327 /wiki/User:Ankeshanand/GSoC14/logs: /* Week 5 */ |
