| 03:25.39 | brlcad | starseeker: color wasn't a mistake, that was the point .. that it could be cmyk or rgb or hsv or some other color space color definition |
| 03:46.46 | starseeker | brlcad: but programatically, particularly for backwards compatibility, it's been a real pain |
| 03:52.57 | starseeker | in particular, if I remember correctly, if we don't write out the rgb attribute we break older BRL-CAD releases' support for color |
| 05:08.20 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) | |
| 06:17.17 | *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-ayrsklsxgmfwsuqh) | |
| 06:55.40 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 08:00.54 | *** join/#brlcad Izak (~Izak@195.24.220.16) | |
| 08:04.12 | Notify | 03BRL-CAD:phoenixyjll * 56942 brlcad/trunk/src/libbrep/boolean.cpp: Add basic support of connectivity graph. And build connectivity graphs for the original structure. |
| 08:17.20 | Notify | 03BRL-CAD:phoenixyjll * 56943 brlcad/trunk/src/libbrep/boolean.cpp: Error handling. |
| 08:22.21 | Notify | 03BRL-CAD:iiizzzaaakkk * 56944 brlcad/trunk/src/libbn/tests/bn_poly_synthetic_div.c: Corrected spelling of polynomial in bn_poly_synthetic_div.c |
| 08:39.40 | Notify | 03BRL-CAD:phoenixyjll * 56945 brlcad/trunk/src/libbrep/boolean.cpp: Fix two tiny bugs in build_connectivity_graph(), and print the graph if the debug flag is set. |
| 08:44.07 | Notify | 03BRL-CAD:phoenixyjll * 56946 brlcad/trunk/src/libbrep/boolean.cpp: Remove trailing ws. |
| 09:05.03 | Notify | 03BRL-CAD Wiki:Phoenix * 6001 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 9 */ |
| 09:43.23 | Notify | 03BRL-CAD:iiizzzaaakkk * 56947 brlcad/trunk/src/librt/primitives/hrt/hrt.c: rt_hrt_free() and rt_hrt_params() functions |
| 10:05.10 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6002 /wiki/User:Izak/GSOC_2013_logs: /* August 19th to August 24th */ |
| 10:51.22 | Izak_ | screen -d 1218 |
| 10:52.29 | Ch3ck | starseeker: I've fixed tickets 226 as Sean requested, I've fixed the changes with the previous patches and uploaded to 231. Would all patches to be reviewed and closed.;) |
| 11:20.40 | Notify | 03BRL-CAD:tbrowder2 * 56948 brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: style |
| 11:38.53 | Notify | 03BRL-CAD:tbrowder2 * 56949 brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: style |
| 11:49.00 | Notify | 03BRL-CAD:tbrowder2 * 56950 (brlcad/trunk/src/librt/primitives/dsp/dsp.c brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c): added FIXME where gcc 4.8.1 reports error upon release build |
| 11:52.07 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b102:6fca:0:12:8531:5301) | |
| 12:40.10 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) | |
| 12:41.23 | *** join/#brlcad hickoryknoll (~hickorykn@66-118-151-70.static.sagonet.net) | |
| 13:17.36 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) | |
| 14:07.49 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 14:08.09 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 14:08.09 | *** join/#brlcad ejno (~ejno@66-118-151-70.static.sagonet.net) | |
| 14:08.10 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) | |
| 14:08.20 | *** join/#brlcad hickoryknoll (~hickorykn@66-118-151-70.static.sagonet.net) | |
| 14:08.35 | *** join/#brlcad Izak_ (~Izak@66-118-151-70.static.sagonet.net) | |
| 14:08.35 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) | |
| 14:08.36 | *** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net) | |
| 14:09.17 | *** join/#brlcad maths22 (~gcimaths@66-118-151-70.static.sagonet.net) | |
| 14:09.28 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) | |
| 14:13.34 | brlcad | and as I send the e-mail, sagonet comes back to life |
| 14:14.01 | brlcad | ejno: try compiling with all enabled (see INSTALL) |
| 14:14.11 | brlcad | so that it doesn't try to use the system tcl/tk |
| 14:14.26 | ejno | ok |
| 14:14.58 | brlcad | or feel free to fix that 8.6 build error ;) |
| 14:16.06 | ejno | brlcad: I got disconnected - I think I missed part of your response |
| 14:16.53 | ejno | ok, I will try if I have time |
| 14:17.40 | brlcad | ejno: I explained in an e-mail, the server's ISP had a brief outage |
| 14:17.58 | ejno | ok |
| 14:18.26 | brlcad | don't worry about the error .. it's a bug in tcl 8.6's header |
| 14:19.01 | brlcad | if you build with bundled libs enabled, that error will go away |
| 14:19.09 | ejno | ok |
| 14:23.49 | *** join/#brlcad luca79 (~luca@89.249.207.188) | |
| 14:34.03 | brlcad | hello luca79 |
| 14:42.21 | brlcad | ``Erik: notify, she dead |
| 14:44.40 | ejno | brlcad: do you know where the OpenCL libraries are? |
| 15:06.20 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) | |
| 15:06.42 | Notify | 03BRL-CAD:brlcad * 56951 brlcad/trunk/src/conv/step/ON_Brep.cpp: use our considerably more precise DEG2RAD constant, no explanation needed. need common.h before system headers. |
| 15:06.46 | Notify | 03BRL-CAD:brlcad * 56952 brlcad/trunk/src/conv/step/ON_Brep.cpp: ws and comma cleanup |
| 15:06.48 | Notify | 03BRL-CAD:carlmoore * 56953 (brlcad/trunk/src/libbn/tests/bn_poly_synthetic_div.c brlcad/trunk/src/librt/primitives/hrt/hrt.c): fix spellings, remove trailing blanks/tabs |
| 15:06.50 | Notify | 03BRL-CAD:brlcad * 56954 brlcad/trunk/src/conv/step/ON_Brep.cpp: inject some visual cues to help my own understanding |
| 15:06.53 | Notify | 03BRL-CAD:brlcad * 56955 brlcad/trunk/src/conv/step/ON_Brep.cpp: fit comments for external readers |
| 15:20.01 | brlcad | ejno: they should be in /usr/local |
| 15:20.18 | Notify | 03BRL-CAD:brlcad * 56956 (brlcad/trunk/src/conv/dbupgrade.c brlcad/trunk/src/conv/enf-g.c and 5 others): ws |
| 15:21.04 | brlcad | yeah, /usr/local/include/CL |
| 15:21.13 | ``Erik | https://github.com/erikg/cl-cia/commit/fa8418386a50d8c77d70470f4cd7a598b22c07ba will kick the next time the bot thread restarts (after I push '0' in slime when it pings out or when I restart the vm), hopefully that'll address the bot "mia after disconnect" issue |
| 15:22.59 | brlcad | woot |
| 15:23.00 | ejno | brlcad: I mean the binaries |
| 15:23.23 | brlcad | ejno: good question, I see the port only installed the headers |
| 15:23.43 | hickoryknoll | brlcad: why does "gcc -c -I ../../include/ gcode.c" give me "fatal error: tcl.h: no such file or directory" |
| 15:23.56 | hickoryknoll | having trouble remembering all of our previous lesson |
| 15:24.12 | brlcad | ejno: found a cpu driver... looking for non-cpu driver |
| 15:24.24 | ejno | brlcad: ok, thank you |
| 15:28.54 | brlcad | ejno: installed the cpu version -lOpenCL, but will keep looking |
| 15:29.05 | brlcad | let me know what devices it says are available |
| 15:29.21 | brlcad | hickoryknoll: because tcl.h is not in ../../include |
| 15:30.05 | brlcad | if you're going to compile real library-using code by hand, not just simple proc-db stuff, you'll need to specify a couple paths |
| 15:30.37 | brlcad | -I../../src/other/tcl/generic |
| 15:30.41 | brlcad | or find all the places it exists: find ../.. -name tcl.h |
| 15:32.06 | hickoryknoll | okay thanks |
| 16:02.49 | ejno | brlcad: OpenCL isn't linking with the c++ library: /usr/local/lib/libOpenCL.so: undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11' |
| 16:05.38 | ejno | oh, maybe I need to tell cmake to link with the c++ library |
| 16:12.08 | hickoryknoll | brlcad: and why does this half not work either? "~/Applications/brlcad/src/rt$ gcc -L ../../build/lib/ -lrt -lbu -lwdb gcode.o" it seems to recognize none of the brlcad functions |
| 16:16.44 | ejno | brlcad: this is failing too: g++ test.cpp -L/usr/local/lib -lOpenCL |
| 16:20.53 | brlcad | ejno: yeah, sounds like it -- try adding -lstdc++ to the link line |
| 16:21.15 | brlcad | (probably can add ";stdc++" to the list of libs needing linking) |
| 16:21.29 | brlcad | hickoryknoll: ordering matters |
| 16:22.17 | brlcad | symbols are resolved in the order they are described, so you want gcode.o first (since nearly everything is referenced), and then include the libs to resolve those references |
| 16:22.39 | hickoryknoll | ohhh! |
| 16:22.45 | hickoryknoll | that makes sense now |
| 16:22.54 | brlcad | ejno: where's your test? |
| 16:23.13 | ejno | brlcad: this fails too: g++ test.cpp -L/usr/local/lib -lOpenCL -lstdc++ |
| 16:23.29 | ejno | brlcad: ~/t |
| 16:23.52 | brlcad | yeah, you don't need -lstdc++ with g++ |
| 16:25.47 | ejno | is it an incompatible libstdc++? |
| 16:37.28 | hickoryknoll | brlcad: it worked, than stopped working and gave me this "error while loading shared libraries: librt.so.20: cannot open shared object file: No such file or directory" I don't think any code changes could account for it. What happened? |
| 16:46.46 | brlcad | ejno: possibly, but that doesn't make much sense |
| 16:46.53 | brlcad | libOpenCL was just compiled |
| 16:47.26 | brlcad | hickoryknoll: that's a runtime library error |
| 16:47.51 | brlcad | when a program is run, the libraries are located and loaded |
| 16:48.07 | brlcad | it's saying it cannot find the librt library that you specified (via -lrt) |
| 16:48.39 | brlcad | you can tell it where to find the library at runtime in addition to compile time with the -rpath=/runtime/path linker option |
| 16:49.26 | brlcad | if you use BRL-CAD's cmake build system, this is all should be done for you automatically just by telling it what files to compile |
| 16:50.19 | hickoryknoll | I'll try that now. Although I had issues when trying to do that before |
| 16:51.16 | brlcad | good time to sort them out ;) |
| 16:51.18 | brlcad | I presume you have a fresh checkout? |
| 16:51.25 | hickoryknoll | yeah |
| 16:51.30 | brlcad | what kind of checkout is it? |
| 16:51.33 | brlcad | svn info . |
| 16:51.38 | brlcad | what's the url? |
| 16:52.12 | hickoryknoll | URL: https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk |
| 16:52.18 | brlcad | okay cool |
| 16:52.32 | brlcad | so first step is to put your source file into the src/proc-db dir |
| 16:52.46 | hickoryknoll | really? not conv? |
| 16:53.00 | brlcad | right, sorry |
| 16:53.38 | hickoryknoll | okay. it actually has been in rt |
| 16:54.49 | brlcad | in face, probably easiest to follow the examples of the subdir converters, create a src/conv/gcode |
| 16:55.23 | brlcad | put your file in there, then you'll need to 1) update src/conv/CMakeLists.txt and 2) add your own src/conv/gcode/CMakeLists.txt |
| 16:56.13 | hickoryknoll | if I just put it in conv, all I need to do is add an BRLCAD_ADDEXEC" to the Cmake file right? |
| 16:56.35 | brlcad | even if you put it in a subdir, that's almost all you need to do |
| 16:56.50 | hickoryknoll | okay |
| 16:57.07 | hickoryknoll | But what's the point if I only have one file? |
| 16:57.08 | brlcad | I see this exporter really expanding, so a subdir will probably make the most long-term sense |
| 16:57.14 | hickoryknoll | oh |
| 16:57.21 | brlcad | different ways to fill the interior, for example |
| 16:57.41 | brlcad | could be hundreds of lines of code to write out a honeycomb pattern .. that'd be best separated from the main app logic |
| 16:57.46 | hickoryknoll | yeah. It definitely has the potential to get huge |
| 16:57.47 | brlcad | along with the dozen other ways |
| 17:02.40 | Notify | 03BRL-CAD:brlcad * 56957 brlcad/trunk/regress/repository.sh: previous common.h check only tested to make sure common.h came first in the file if it's included at all. new check also makes sure that common.h is included if there are any system headers included first since common.h should come first. currently disabled since there are several files that need to be fixed. |
| 17:08.09 | brlcad | ejno: the error is not your fault .. looks like something wonky with the gcc 4.6 that was recently installed (``Erik) |
| 17:08.13 | brlcad | g++ test.cpp -L/usr/local/lib/gcc46 -L/usr/local/lib -lOpenCL -rpath=/usr/local/lib/gcc46 |
| 17:08.18 | brlcad | that works |
| 17:09.36 | ejno | brlcad: ok, thanks |
| 17:09.56 | brlcad | ah, it's a path problem.. "gcc" and "g++" are still 4.2.1 so it couldn't find the libs that compiled libOpenCL |
| 17:10.28 | brlcad | if you had used gcc46 it would have worked |
| 17:10.37 | ejno | ok |
| 17:12.31 | brlcad | hickoryknoll: lemme know when you get the cmakefile stuff set up and I can look it over |
| 17:15.51 | hickoryknoll | File Edit Options Buffers Tools Help |
| 17:15.51 | hickoryknoll | set(GCODE_INCLUDE_DIRS ${BU_INCLUDE_DIRS} ${RT_INCLUDE_DIRS} ${WDB_INCLUDE_DIRS} ) |
| 17:15.51 | hickoryknoll | set(ggcode_SRCS g-gcode.c ) |
| 17:15.51 | hickoryknoll | BRLCAD_ADDEXEC(g-gcode "${ggcode_SRCS}" "libwdb;librt;libbu" NOSTRICT) |
| 17:15.53 | hickoryknoll | # Local Variables: |
| 17:16.49 | brlcad | looks good on the surface -- does it work? |
| 17:17.49 | brlcad | looks like the raw format is the closest example |
| 17:19.03 | *** join/#brlcad hickoryknoll (~hickorykn@66-118-151-70.static.sagonet.net) | |
| 17:20.04 | brlcad | not using screen? |
| 17:20.27 | hickoryknoll | am using screen, did something odd in screen |
| 17:21.18 | brlcad | ah |
| 17:21.35 | brlcad | you learned how to create new contexts? |
| 17:21.44 | hickoryknoll | new contexts? |
| 17:21.49 | brlcad | ctrl-a c |
| 17:22.10 | brlcad | ctrl-a n and ctrl-a p to go to the next/previous |
| 17:22.14 | hickoryknoll | already knew that, did something else. |
| 17:22.30 | hickoryknoll | I think I just ended the context that was running irc |
| 17:22.46 | brlcad | ah, fun :) |
| 17:22.54 | brlcad | ctrl-a k will do that ;) |
| 17:23.03 | *** join/#brlcad ralph (408663e6@gateway/web/freenode/ip.64.134.99.230) | |
| 17:23.07 | brlcad | hi ralph |
| 17:23.11 | *** part/#brlcad ralph (408663e6@gateway/web/freenode/ip.64.134.99.230) | |
| 17:23.17 | brlcad | by ralph |
| 17:23.29 | hickoryknoll | probably that |
| 17:24.01 | hickoryknoll | did you see the CMake thingy |
| 17:25.05 | brlcad | you mean the pasting? |
| 17:25.18 | brlcad | I'd replied with this: |
| 17:25.18 | brlcad | 13:16 < brlcad> looks good on the surface -- does it work? |
| 17:25.18 | brlcad | 13:17 < brlcad> looks like the raw format is the closest example |
| 17:25.45 | hickoryknoll | getting to the does it work. And that is the one I used as a template |
| 17:26.10 | brlcad | forgot that most of them don't even bother with a sub-CMakeLists.txt file |
| 17:26.22 | brlcad | but it's still fine to have |
| 17:26.37 | brlcad | more modular |
| 17:27.12 | hickoryknoll | I just run cmake now in a new build directory? |
| 17:29.16 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) | |
| 17:34.07 | ``Erik | ponders some process russian roulette to see if any irc sessions go... ps ax | awk '{print $1}' | rand | head -n 1 | xargs sudo kill -9 |
| 17:34.42 | ``Erik | watches himself get removed from wheel :D *duck* |
| 17:35.51 | starseeker | brlcad: I'm probably going to be breaking ON_Brep.cpp up into separate files along the line of the importer, which should help comprehensibility |
| 17:36.22 | starseeker | the "context" stuff is almost certainly per-step-file for us, not per-brep |
| 17:37.14 | starseeker | so that'll be it's on bit |
| 17:37.42 | starseeker | then I'll need per-primitive logic as well |
| 17:38.56 | brlcad | hickoryknoll: yes, just build like you normally would -- if you run "cmake ...." first, you'll be able to just specify "make g-gcode" |
| 17:39.17 | brlcad | but since you added new cmake logic, you need to run cmake at least once |
| 17:40.32 | brlcad | starseeker: would it make sense to put them in separate dirs or can they substantially share code? |
| 17:41.06 | brlcad | or better put, could they be separated into separate dirs without duplicating any files or having cmake logic reference the other dir |
| 17:56.41 | hickoryknoll | it couldn't find common.h. |
| 17:56.51 | hickoryknoll | What do I need to include for it to find it? |
| 17:58.54 | ejno | there are no GPU devices detected, and the CPU implementation doesn't support double-precision |
| 17:59.30 | starseeker | brlcad: you mean the importer and exporter? |
| 17:59.53 | starseeker | possibly |
| 18:00.33 | starseeker | not really sure yet - still too early in the game |
| 18:07.52 | *** join/#brlcad whyesse (~quassel@109.160.230.186) | |
| 18:15.03 | *** join/#brlcad caen23 (~caen23@92.81.163.217) | |
| 18:29.54 | brlcad | hickoryknoll: it's in the top level include/ |
| 18:30.13 | brlcad | and what couldn't find it -- your cmake changes? |
| 18:30.56 | brlcad | hickoryknoll: note the include_directories() line in the raw CMakelists.txt file example |
| 18:33.40 | Notify | 03BRL-CAD:brlcad * 56958 brlcad/trunk/regress/repository.sh: stub in initial support for exempting files that intentionally should not be including common.h |
| 18:34.22 | Notify | 03BRL-CAD:brlcad * 56959 brlcad/trunk/src/adrt/slave/tienet_slave.c: missing common.h |
| 18:34.24 | hickoryknoll | brlcad: where does it specify include/ ? |
| 18:37.53 | Notify | 03BRL-CAD:brlcad * 56960 (brlcad/trunk/src/external/Unigraphics/log.h brlcad/trunk/src/external/Unigraphics/ug_misc.c): stdlib.h instead of malloc.h and include common.h |
| 18:38.57 | *** join/#brlcad vladbogo (~vladbogo@188.25.238.69) | |
| 18:40.30 | Notify | 03BRL-CAD:brlcad * 56961 (brlcad/trunk/src/conv/iges/brlcad_brep.cpp brlcad/trunk/src/conv/step/BSplineSurface.h and 6 others): common.h should be included before any system headers |
| 18:42.42 | Notify | 03BRL-CAD:brlcad * 56962 (brlcad/trunk/src/conv/step/CartesianPoint.h brlcad/trunk/src/conv/step/STEPEntity.h): Point.h is not a system header; remove unnecessary doxycomment |
| 18:46.31 | *** join/#brlcad kesha_ (~kesha@49.249.17.31) | |
| 18:47.35 | Notify | 03BRL-CAD:brlcad * 56963 brlcad/trunk/regress/repository.sh: apparently just two more to exempt from needing common.h |
| 18:49.19 | brlcad | hickoryknoll: that is probably embedded via BU_INCLUDE_DIRS (or either of the other two) |
| 18:49.30 | hickoryknoll | yeah I found it |
| 18:51.02 | Notify | 03BRL-CAD:brlcad * 56964 (brlcad/trunk/src/proc-db/mkbuilding.c brlcad/trunk/src/proc-db/mkbuilding.h): headers should be self-contained. include common.h before the system headers, then the main file doesn't need to know it needed to do that. |
| 18:51.43 | Notify | 03BRL-CAD:brlcad * 56965 (brlcad/trunk/src/liboptical/constantpool.h brlcad/trunk/src/liboptical/liboslrend.h and 5 others): must include common.h before all system headers for portability. |
| 18:52.43 | ejno | brlcad: I think this is a problem with FreeOCL: http://paste.kde.org/p57fecc22/ |
| 18:56.06 | Notify | 03BRL-CAD:brlcad * 56966 brlcad/trunk/src/libged/simulate/simutils.h: include common.h |
| 18:58.37 | Notify | 03BRL-CAD:brlcad * 56967 brlcad/trunk/regress/repository.sh: all files now passing the expanded common.h header checks, so turn error-matching on |
| 19:03.22 | whyesse | how would you go about modelling something like this with brl-cad? http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/2D_to_3D_Extrusion#Twist |
| 19:03.56 | brlcad | ejno: indeed, try again now |
| 19:04.23 | whyesse | sort of a rotating extrusion? |
| 19:05.06 | brlcad | whyesse: yeah, that's a tricky one |
| 19:06.10 | brlcad | a generalized sweep operation would normally do it (which we don't implement), though the notion of extruding with a twist parameter is interesting |
| 19:06.28 | whyesse | I was hoping maybe there's a different way of doing it |
| 19:06.53 | brlcad | there are, depending on what you need specifically |
| 19:07.21 | whyesse | I saw it used for this: http://www.thingiverse.com/thing:53451 |
| 19:07.39 | ejno | brlcad: thank you. There are new errors: http://paste.kde.org/pde8c2b0b/ |
| 19:07.45 | whyesse | I think to make herringbone gear teeth |
| 19:08.43 | brlcad | whyesse: here's one method used for things like threading on bolts: http://ronja.twibright.com/3d/ |
| 19:10.41 | brlcad | whyesse: that's really cool (the gear) |
| 19:11.02 | whyesse | yeah |
| 19:11.47 | brlcad | I'm pretty sure that shape is possible... |
| 19:13.01 | brlcad | those are basically cylinders with grooves cut out |
| 19:13.26 | whyesse | ah |
| 19:14.10 | brlcad | hm, wonder if 90 degree sections of a torus rotated up the column would do the trick? |
| 19:15.02 | brlcad | hickoryknoll: now that looks like something fun and practical to print, I think that just might be a good g-gcode test case if I can model something up quick :) |
| 19:16.37 | brlcad | tries |
| 19:20.01 | Notify | 03BRL-CAD:n_reed * 56968 (brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp brlcad/trunk/src/conv/step/STEPWrapper.cpp and 4 others): address some step-g related leaks identified by valgrind |
| 19:22.04 | whyesse | brlcad: how difficult would adding a twist feature be? |
| 19:23.20 | whyesse | brlcad: assuming I'm ok with code but completely new to brl-cad |
| 19:24.05 | brlcad | whyesse: conceptually, not that hard ... mathematically, not sure |
| 19:25.20 | brlcad | whyesse: hm, it might be crazy easy even mathematically the more I think about it |
| 19:26.30 | whyesse | ok |
| 19:26.47 | brlcad | if you want to give it a try: src/librt/primitives/extrude/ is where extrusions are defined |
| 19:26.57 | brlcad | pretty much all right there in extrude.c |
| 19:28.26 | brlcad | each object type (like extrude) is defined by a set of callback functions .. the critical ones affected by adding twist are going to be rt_extrude_shot(), rt_extrude_plot(), and rt_extrude_tess() so that it renders, shows wireframe, and can be converted to polygons correctly |
| 19:30.30 | whyesse | can primitives be defined externally? |
| 19:31.01 | brlcad | what do you mean? |
| 19:31.40 | whyesse | by an application using librt, or are they always compiled in |
| 19:32.27 | brlcad | you can always define your own procedural geometry (and we provide several examples of this), but those are built on top of the fundamental primitives |
| 19:32.40 | brlcad | they're the basic building blocks understood throughout the system |
| 19:33.00 | brlcad | so the answer is probably "no" |
| 19:33.07 | whyesse | ok |
| 19:33.29 | whyesse | needs to try compiling brl-cad, then. which would probably be a good idea anyway |
| 19:34.22 | brlcad | ah, yeah :) |
| 19:34.27 | brlcad | ~cadsvn |
| 19:34.28 | infobot | To obtain BRL-CAD from Subversion: svn checkout https://svn.code.sourceforge.net/p/brlcad/code/brlcad/trunk brlcad |
| 19:35.38 | whyesse | thanks |
| 19:36.57 | brlcad | I've considered implementing a fully generalized primitive that is defined by some parametric equation, but that wouldn't even help you with this kind of problem |
| 19:37.43 | brlcad | maybe some primitive defined by a scripting language definition (or opencl) |
| 19:38.12 | brlcad | otherwise, the only means might be to make each primitive self-register at run-time as plugins and you could define your own new primitive as a (compiled) plug in |
| 19:38.32 | brlcad | whyesse: what were you hoping for? |
| 19:39.14 | whyesse | making a copy of the extrude, and then modifying that |
| 19:39.20 | brlcad | n_reed: why #if !defined(__WIN32__) ? |
| 19:39.59 | whyesse | would probably be easier for me to compile just that |
| 19:40.16 | brlcad | whyesse: intriguing notion, would language matter? |
| 19:40.27 | whyesse | language? |
| 19:40.27 | n_reed | because that's the test a few lines before that causes the memory to be allocated |
| 19:41.07 | brlcad | there's generally so much work involved in implementing a new primitive that it's never been an issue .. |
| 19:42.03 | brlcad | and we wouldn't want to end up with multiple extrusion methods, it'd probably end up an extension of the existing |
| 19:42.16 | brlcad | n_reed: ah, humph |
| 19:45.51 | *** join/#brlcad whyesse (~quassel@109.160.230.186) | |
| 19:49.09 | n_reed | iirc that's typical of stepcode. instead of using wrapper macros/functions, windows/non-windows code is just mixed together w/ conditionals |
| 19:49.18 | n_reed | i'm not about to fix all of them |
| 19:52.59 | Notify | 03BRL-CAD:brlcad * 56969 brlcad/trunk/src/mged/chgview.c: the message is wrong, can only scale uniformly |
| 19:59.51 | whyesse | I'm trying to generate brl-cad databases from python, wrapping functions in the C api with cython. should I be just generating mged commands? |
| 20:03.52 | Notify | 03BRL-CAD:carlmoore * 56970 brlcad/trunk/src/conv/g-nff.c: remove a pair of braces, and also remove duplicate output going to stderr -- do you understand the latter change? |
| 20:07.28 | brlcad | whyesse: it depends how much functionality you'd like to have access to, but wrapping mged commands will give you the most high-level syntax to work with |
| 20:08.10 | brlcad | whyesse: wrapping src/libged will get you 95% of mged's command functionality in C API form |
| 20:08.11 | whyesse | ok |
| 20:08.21 | whyesse | thanks |
| 20:08.58 | brlcad | wrapping mged obviously gets you 100% but then has a little bit of processor invocation overhead |
| 20:09.38 | brlcad | I presume you've seen the shell and perl examples: http://brlcad.org/wiki/Main_page#Tutorials |
| 20:09.43 | whyesse | nope |
| 20:09.54 | brlcad | ah, check out SGI_Cube and Spiral |
| 20:10.33 | whyesse | I saw someone output mged from python somewhere |
| 20:10.35 | whyesse | ok |
| 20:11.19 | brlcad | the latter is particularly relevant to that gear, but some modifications would be needed to create geometry at the same density as you spiral outward/upward |
| 20:18.14 | brlcad | ejno: yeah, so FreeOCL sucks... |
| 20:19.02 | brlcad | there are some changes I could try, but need to be able to test your compile .. where is your build dir or how can I otherwise reproduce that error? |
| 20:19.36 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6003 /wiki/User:Izak/GSOC_2013_logs: /* August 19th to August 24th */ |
| 20:19.40 | brlcad | it's all simple stuff until the nested-name-identifier error |
| 20:21.47 | ejno | brlcad: cd /home/ejno/brlcad-opencl/build; make -j8 rt && ./bin/rt -Ftest.pix sflake.g depth0.r depth1.r depth2.r depth3.r |
| 20:22.27 | ejno | also, I can try setting up OpenCL on my laptop if you want |
| 20:23.28 | brlcad | ejno: what OS are you running there? |
| 20:24.06 | ejno | Arch Linux. I have it mostly working but the rt window and output pix are entirely black currently, not sure why |
| 20:24.26 | brlcad | is the regular rt window also black? |
| 20:25.06 | ejno | I was going to try that but haven't yet |
| 20:25.11 | brlcad | try -F/dev/Xl |
| 20:25.22 | brlcad | that should rule out ogl |
| 20:25.47 | ejno | ok, I |
| 20:26.28 | brlcad | note that you can run rt -otest.pix -F/dev/Xl to both write to file and display a window if you need that |
| 20:27.15 | ejno | ok, I'll be able to do that in about 10 minutes |
| 20:27.20 | *** join/#brlcad mpictor (~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505) | |
| 20:29.04 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 6004 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 19 August - 25 August */ |
| 20:34.26 | Notify | 03BRL-CAD:vladbogo * 56971 (brlcad/trunk/src/mged/attach.c brlcad/trunk/src/tclscripts/mged/openw.tcl): Added the Qt display manager as a option to the Modes>Display Manager in mged's menu. |
| 20:37.39 | brlcad | heh, nicely done ... crashing gdb |
| 20:43.09 | Notify | 03BRL-CAD Wiki:Vladbogolin * 6005 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 9 */ |
| 20:43.32 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6006 /wiki/User:Izak/GSOC_2013_logs: /* August 12th to August 17th */ |
| 20:44.15 | Notify | 03BRL-CAD Wiki:Vladbogolin * 0 /wiki/File:Mged1.png: |
| 20:45.28 | Notify | 03BRL-CAD Wiki:Vladbogolin * 6008 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 10 */ |
| 20:52.30 | mpictor | anyone on here familiar with setlocale()? the man page makes it sound like it always defaults to "C" on Linux, but I haven't found anything about its behavior on windows |
| 20:53.46 | mpictor | I need to force exppp (in stepcode) to always print numbers with the formatting specified in 10303-11 |
| 21:01.10 | starseeker | hmm - we just had a problem like that crop up |
| 21:03.10 | brlcad | Qt was setting the users locale causing some of our hard-coded constant values (e.g., 3.0 vs 3,0) to fail |
| 21:04.14 | brlcad | mpictor: C is the default locale |
| 21:04.32 | mpictor | heh I actually found mention of qt doing that when I was googling |
| 21:04.36 | brlcad | but application codes can set whatever they like too |
| 21:04.50 | mpictor | brlcad: is it the default on all systems in all countries? |
| 21:05.00 | brlcad | it's a default for posix C, yes |
| 21:05.12 | brlcad | it's a global libc state |
| 21:05.15 | mpictor | what about windows and osx? |
| 21:06.04 | brlcad | language-wise, it's that way everywhere something claims to be posix compliant |
| 21:06.18 | mpictor | ok |
| 21:06.24 | brlcad | it's defined by stdc, so it's that way everywhere as far as I know, but ... application code can just as well set it to something else |
| 21:06.37 | brlcad | and even default application frameworks can (and some do) set something else |
| 21:07.10 | brlcad | we ran into with a Qt application, Qt itself set the locale to something else just by using Qt |
| 21:07.30 | brlcad | and MFC or OSX framework could just as well do the same thing |
| 21:08.02 | mpictor | this is in exppp, so qt/mfc/etc shouldn't affect it |
| 21:08.32 | mpictor | unless someone writes a gui that uses exppp... |
| 21:08.35 | brlcad | so you either rely on the calling application to set the locale() back to C before calling into sdai/stepcode or you forcibly set/reset it *everywhere* you possibly call a std C function that reads/writes numbers |
| 21:08.44 | brlcad | read, write, scanf, printf, .... all of them |
| 21:09.07 | brlcad | right, that's my point -- you don't know or have control of the calling application |
| 21:09.47 | brlcad | and stepcode is pretty much useless without embedding it into an app ;) |
| 21:09.59 | mpictor | oh, I was thinking I could do it once and not worry again. guess I could just check if it isn't C and exit with an error... |
| 21:10.26 | brlcad | so you either document the expectation/requirement, or hope some init() function is sufficient to setlocale("C"), or forcibly set it everywhere it might be needed |
| 21:10.40 | brlcad | you don't need to exit |
| 21:10.55 | brlcad | you can get the current locale, set C, and return to caller locale just fine |
| 21:11.34 | brlcad | or just set it and forget it but then that's not much different than just documenting the assumption of C |
| 21:12.29 | mpictor | If I set C each time, I need to modify every function that could use printf/scanf/etc with a number |
| 21:13.26 | mpictor | *every function that is accessible from outside the library |
| 21:23.01 | Notify | 03BRL-CAD:iiizzzaaakkk * 56972 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Fixing spelling |
| 21:29.24 | brlcad | yep |
| 21:29.55 | brlcad | half-punting sounds like a good balance |
| 21:30.17 | brlcad | if there's an init-location where almost certainly any call will be going through, set the locale to C |
| 21:30.25 | brlcad | then put it in the docs |
| 21:51.31 | Notify | 03BRL-CAD:carlmoore * 56973 brlcad/trunk/src/conv/nmg/g-nmg.c: remove 2 sets of braces, remove : from P in opt string, and implement h? |
| 22:01.53 | Notify | 03BRL-CAD:ejno * 56974 (brlcad/branches/opencl/src/librt/primitives/sph/sph.c brlcad/branches/opencl/src/librt/primitives/sph/sph_shot.cl): check for double-precision support; start of hypersampling; other changes |
| 22:06.02 | *** join/#brlcad whyesse (~quassel@109.160.230.186) | |
| 23:38.47 | brlcad | ejno: any luck confirming double-precision support? |
| 23:39.25 | brlcad | should make the code print either a compile-time or run-time notice whether single or double precision is being used so we can make sure comparisons take into consideration |