| 00:13.24 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 00:25.47 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 01:19.15 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 01:23.50 | starseeker | cool: http://www.cacr.caltech.edu/~sean/projects/stlib/html/cpt/cpt_driver3.html |
| 01:24.13 | starseeker | or maybe more to the point https://bitbucket.org/seanmauch/stlib/src/32f7fcef834fc174ca86cd9a58eab6725d8cedb5/src/cpt/?at=default |
| 01:33.55 | starseeker | wonders if this might have applications in brep tessellation... http://www.cacr.caltech.edu/~sean/projects/stlib/html/geom/examples_geom_mesh_subspace.html |
| 01:36.19 | starseeker | http://www.cacr.caltech.edu/~sean/projects/stlib/html/geom/geom_shape.html |
| 01:39.39 | starseeker | http://www.cacr.caltech.edu/~sean/projects/stlib/html/ |
| 01:40.04 | starseeker | very friendly license |
| 02:13.37 | kanzure | here's a poorly constructed zip of a opennurbs swig wrapper (generating python bindings), http://diyhpl.us/~bryan/irc/opennurbs/brlcad-opennurbs2.zip |
| 02:21.28 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 04:42.34 | Notify | 03BRL-CAD:brlcad * 61595 (brlcad/trunk/NEWS brlcad/trunk/src/librt/primitives/bot/bot.c): fixed a crash running the ged 'get' command. if you ran bot_merge to merge a smoothed bot with an unsmooted bot, you'd get a bot with no face normals but with face normals requested. was using the wrong counter in the structure. |
| 04:54.17 | Notify | 03BRL-CAD:brlcad * 61596 brlcad/trunk/src/librt/primitives/bot/bot.c: couple other instance where we are using the wrong variable when iterating over the faces_normal array. need to use num_face_normals count. |
| 05:07.19 | *** join/#brlcad oana_ (~elf11@109.97.186.121) |
| 06:32.43 | Notify | 03BRL-CAD Wiki:Mihaineacsu * 7459 /wiki/User:Mihaineacsu/SoCIS2014/Logs: /* Week 5 */ |
| 06:35.22 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 07:49.40 | *** join/#brlcad pandrei (~pandrei@188.25.173.201) |
| 08:03.10 | pandrei | brlcad: Daniel's asked me to learn what's the purpose of "tie" in rt_bot_internal |
| 08:03.55 | pandrei | I ve gone through code and my understanding is that it's used to keep raytrace intersections information |
| 08:04.48 | pandrei | but in bot.c there's not much done with it |
| 08:05.04 | pandrei | it's just checked for validity(!NULL) and freed |
| 08:05.20 | pandrei | how should I handle/represent that in my class design? |
| 09:11.34 | raj12lnm | hi all. |
| 09:12.27 | raj12lnm | brlcad : libbrep is an interesting case. |
| 09:12.36 | raj12lnm | brlcad : Its all c++ code. |
| 09:13.29 | *** join/#brlcad javampire (~ncsaba@p4FF72308.dip0.t-ipconnect.de) |
| 09:13.34 | raj12lnm | and lack of "__cplusplus" only puts in dummy structures in the librep.so library file. |
| 09:13.46 | raj12lnm | javampire : what I time to join ;) |
| 09:15.20 | javampire | raj12lnm: I'm also curious how the C and C++ code works together - I have very little experience with C and no experience at all with C++ |
| 09:25.23 | raj12lnm | brlcad, javampire : In brep it is interesting to note that, libbrep.so contains only the dummy structures which are produced when __cpluscplus is lacking. |
| 09:26.23 | javampire | raj12lnm: how did you get to this conclusion ? |
| 09:26.46 | raj12lnm | brlcad : Also when plugged they are believed to work for example in libged/brep.c where a lot of functions are called related to brep |
| 09:27.24 | javampire | the .so file contains machine code, the structures are only a meaning attached to it |
| 09:28.04 | javampire | that's why you can cast pointers to whatever you want, which will attach meaning to a bunch of bytes |
| 09:36.17 | raj12lnm | javampire : ".so" I think are library files (where they can be statically linked to other parts of code) |
| 09:37.13 | javampire | yes, but the library contains no structures, but machine code which can be called using the declared functions as entry points |
| 09:37.23 | raj12lnm | now in that dynamicaly linkable file when we wrapp into python-brlcad the bindings show only the dummy structures and no definitions of any function. |
| 09:37.42 | javampire | and those functions operate on structures which are just a bunch of bytes, which you provide them as parameter |
| 09:38.04 | javampire | that's the low level working of it |
| 09:38.48 | javampire | now to be able to write code which actually can use those functions, you need the header files which define the structure of those bunches of bytes and gives a meaning to the parameters |
| 09:39.27 | javampire | and the problem is that the header file wrapped by python-brlcad is a dummy one which doesn't give the right meaning to the brep structures |
| 09:39.54 | javampire | but the .so file nevertheless will expect and work with the right structures :-) |
| 09:41.09 | javampire | I think we should for the moment read up on how C and C++ interoperate |
| 09:41.18 | javampire | see these: |
| 09:41.19 | javampire | http://yosefk.com/c++fqa/mixing.html |
| 09:41.27 | javampire | http://www.devx.com/cplus/Article/34999 |
| 10:12.10 | ``Erik | pandrei: there're two bot raytracing engines, the old one lives in the src/librt/primitives/bot/ stuff, the experimental one in src/adrt/ (as libtie)... the tie field is the data for when the experimental one is triggered (using the LIBRT_BOT_MINTIE environment variable or rt_bot_mintie C variable) |
| 10:42.13 | raj12lnm | javampire : Why do you think was the reason behind choosing c++ for brep ? Does it achieve anything specific ? |
| 10:42.25 | raj12lnm | I think If we try to understand that it might help us find answers to our issues.. |
| 10:43.39 | javampire | OpenNurbs is written in C++: http://www.rhino3d.com/opennurbs |
| 10:46.40 | raj12lnm | ok. |
| 11:22.00 | Notify | 03BRL-CAD:brlcad * 61597 brlcad/trunk/src/librt/primitives/brep/brep.cpp: quellage, unused var computing whether we're at a singularity |
| 11:23.05 | starseeker | makes note to self - once we decide on a bu API supporting long options, see if http://optionparser.sourceforge.net/index.html would be a better backend than tclap... |
| 11:24.06 | starseeker | pretty new arrival on the command line parsing stage |
| 11:43.16 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 11:56.57 | andrei_ | ``Erik: from what I see in bot.c there no specific operation performed on the tie field |
| 11:58.10 | andrei_ | there's* |
| 13:49.58 | *** join/#brlcad albertcoder (~albertcod@101.208.48.193) |
| 14:24.13 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:57.30 | *** join/#brlcad ishwerdas (~ishwerdas@117.199.108.190) |
| 15:12.55 | javampire | raj12lnm, kanzure: this might be interesting to interface to the open-nurbs C++ classes: http://www.boost.org/doc/libs/1_55_0/libs/python/doc/ |
| 15:14.43 | javampire | this thread is also interesting mentioning many options: stackoverflow.com/questions/145270/calling-c-c-from-python |
| 15:19.24 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 15:20.23 | Notify | 03BRL-CAD Wiki:Inderpreet * 7460 /wiki/User:Inderpreet/GSoC14/logs: /* Week 6 */ |
| 15:20.47 | javampire | I spent quite some time by now figuring out how to wrap C++ code in python, and I got to the conclusion that it is nearly impossible to wrap straight C++ in a portable way |
| 15:21.07 | *** join/#brlcad ishwerdas (~ishwerdas@117.199.108.190) |
| 15:22.21 | javampire | it will be much easier to wrap C struct versions of the C++ classes, and extern "C" wrappers for functions |
| 15:23.38 | javampire | raj12lnm: so the question for open-nurbs is if the necessary classes/functions are already wrapped for BRL-CAD usage in extern "C" + struct ? |
| 15:24.07 | javampire | please figure that out from the brep examples ! |
| 15:24.43 | javampire | if there is such a straight C interface, figure out a way to wrap it |
| 15:25.25 | javampire | if not, then I would say the best option is to add such C wrapping code to BRL-CAD, and then use that from python |
| 16:34.09 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 16:38.53 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:40.05 | *** join/#brlcad albertcoder (~albertcod@101.215.96.236) |
| 17:02.09 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 17:11.36 | *** join/#brlcad albertcoder (~albertcod@101.208.161.36) |
| 17:35.41 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 18:01.29 | *** part/#brlcad ishwerdas (~ishwerdas@117.199.108.190) |
| 18:49.25 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:22.00 | *** join/#brlcad albertcoder (~albertcod@101.208.161.36) |
| 19:48.18 | *** join/#brlcad piyushparkash (~piyushpar@117.205.75.118) |
| 20:01.52 | *** join/#brlcad pandrei (~pandrei@188.25.27.120) |
| 20:02.05 | andrei_ | hello ! |
| 20:08.18 | ``Erik | andrei_: bot.c has some logic to call bottie_* functions which use the tie field |
| 20:15.28 | andrei_ | I know that may not be related to you but |
| 20:15.47 | andrei_ | which of the engines(experimental or old one) should be used in the geometry API |
| 20:16.14 | andrei_ | from what you've said, I understand that what I need to do is |
| 20:16.27 | andrei_ | to provide methods that internally call the functions you mentioned |
| 20:19.38 | ``Erik | the geometry API should probably just default to the ... default... |
| 20:22.19 | ``Erik | the tie pointer in the rt_bot_internal struct is intended as a 'private' member and is encapsulated by the library, thus the "here be dragons" comment on the void* |
| 20:24.31 | *** join/#brlcad piyushparkash (~piyushpar@117.205.66.21) |
| 20:28.15 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) |
| 20:29.21 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:48.09 | *** join/#brlcad mihaineacsu (~mihaineac@92.81.149.0) |
| 21:11.32 | *** join/#brlcad infobot (~infobot@rikers.org) |
| 21:11.32 | *** 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. |
| 21:17.13 | andrei_ | there's something I don't understand about |
| 21:17.27 | andrei_ | rt_bot internal. fastf_t *vertices;/**< @brief array of floats for |
| 21:17.27 | andrei_ | <PROTECTED> |
| 21:17.27 | andrei_ | <PROTECTED> |
| 21:17.35 | andrei_ | how can vertices be floats, shouldn't they be points? |
| 21:19.10 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7461 /wiki/User:Popescu.andrei1991/devlogs2014: /* Week 7 */ |
| 21:20.28 | *** join/#brlcad albertcoder (~albertcod@101.220.155.34) |
| 21:35.49 | andrei_ | brlcad: I haven't forgotten about that wiki page |
| 21:36.00 | andrei_ | should I write a preliminary phase or discuss with you |
| 21:36.02 | andrei_ | beforehand? |
| 21:44.18 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7462 /wiki/Extrude: added Extrude Image |
| 21:45.05 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 0 /wiki/File:Extrude_example.png: |
| 21:45.55 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7464 /wiki/Extrude: |
| 21:47.14 | andrei_ | can anyone help me with using a file on the wiki |
| 21:47.16 | andrei_ | I get Error creating thumbnail: /usr/bin/convert: not found |
| 21:47.20 | andrei_ | when I uploaded it |
| 21:55.02 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7465 /wiki/Extrude: |
| 21:55.04 | Notify | 03BRL-CAD Wiki:Albertcoder * 7466 /wiki/User:Albertcoder/GSoC2014/logs: /* Week 7 */ |
| 21:56.24 | ``Erik | andrei_: a point is just 3 floats (fastf_t in this case, which is usually a double)... x,y,z |
| 21:56.44 | andrei_ | well, yeah but |
| 21:57.02 | andrei_ | vertices [num_vertices*3] |
| 21:57.13 | andrei_ | this means that it's a vector of .. point coordinates? |
| 21:57.22 | andrei_ | like |
| 21:57.33 | andrei_ | x1,y1,z1,x2,y2,z2 |
| 22:00.37 | ``Erik | yup |
| 22:00.50 | ``Erik | try the upload thing now, I just fixed the path in the wiki config script (I hope) |
| 22:03.00 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7467 /wiki/Extrude: |
| 22:03.09 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7468 /wiki/Extrude: |
| 22:03.12 | andrei_ | ``Erik: it works now, thank you ! |
| 22:03.18 | ``Erik | np |
| 22:22.33 | andrei_ | what is rpp as solid type |
| 22:28.30 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7469 /wiki/Extrude: |
| 22:29.07 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7470 /wiki/Extrude: |
| 22:29.30 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7471 /wiki/Extrude: |
| 22:35.48 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7472 /wiki/User:Popescu.andrei1991/devlogs2014: /* Week 7 */ |
| 22:36.56 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7473 /wiki/Extrude: |
| 22:37.18 | Notify | 03BRL-CAD Wiki:Popescu.andrei1991 * 7474 /wiki/Extrude: fixed missing mged> prompt |