| 00:12.43 | *** join/#brlcad qux (944a2b81@gateway/web/freenode/ip.148.74.43.129) | |
| 01:40.00 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 01:55.57 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 01:58.34 | brlcad | starseeker: libpng change recently (last 3-4 weeks)? getting new failure on mac |
| 01:59.20 | brlcad | yeah, that collection is pretty insane ... so many gems in there I found |
| 01:59.44 | brlcad | old photos, lots of baltimore maps and drawings, letters, sheet music, ... |
| 03:17.01 | nmz787 | anyone in here know much about CAM? I am interested in getting my BRL-CAD designs out into the world, and have been thinking of how to implement a g-code exporter. I've seen the shell script that's out there, but it had too many dependencies and wasn't amenable to g-code optimization (i.e. if you're targeting a laser versus a traditional mill) |
| 04:01.05 | brlcad | nmz787: variety of thoughts on the matter |
| 04:01.34 | brlcad | the shell script method (projected polygonal tessellation) is an approach, but not a very good one at all for a variety of reasons (particularly for brl-cad models) |
| 04:03.22 | brlcad | another is to use export via stl or some other polygonal form and feed that to existing software -- also an approach riddled with issues less than ideal |
| 04:18.06 | brlcad | nmz787: better approach is to keep the models in implicit or parametric form and evaluate slices as needed |
| 04:21.17 | nmz787 | brlcad: yeah I've got the slicing-in-brlcad figured out. It is the edge-walking/stepping that I am not sure of... I guess some kind of ray shooting (but non-random aim) could be used ? |
| 04:21.32 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 04:21.35 | brlcad | this is an approach I had a summer student work on a few years ago: |
| 04:21.41 | brlcad | http://brlcad.org/~sean/tmp/g-gcode.patch |
| 04:21.48 | nmz787 | i've thought maybe slice in BRLCAD, then export to STL, then evaluate elsewhere |
| 04:22.01 | brlcad | basically shoots rays to sample layers through the geometry, outputs corresponding gcode directly |
| 04:22.04 | brlcad | simple program |
| 04:22.59 | brlcad | with that, you can shoot rays at whatever resolution your printer/laser/cutter supports so you will have perfect paths |
| 04:23.35 | nmz787 | any way to shoot rays via mged? |
| 04:23.41 | nmz787 | or another cmdline tool? |
| 04:23.46 | nmz787 | (existing binary)? |
| 04:23.57 | nmz787 | something I can hack with Python ;) |
| 04:23.58 | brlcad | certainly can shoot rays, sure |
| 04:24.13 | brlcad | nirt was made for exactly that purpose |
| 04:24.18 | nmz787 | that file seems easy enough to port |
| 04:24.20 | brlcad | can run inside or outside mged |
| 04:24.24 | brlcad | has a detailed manaul |
| 04:24.45 | nmz787 | ok, cool |
| 04:25.14 | brlcad | http://brlcad.org/w/images/f/fe/Interactive_Raytracing_-_The_nirt_Command.pdf |
| 04:27.49 | nmz787 | nice! timing is everything in this chatroom! |
| 04:28.12 | brlcad | nirt run outside of mged will be far more flexible for this kind of use |
| 04:30.03 | brlcad | someone doing something similar from inside mged was talked about on the list: https://sourceforge.net/p/brlcad/discussion/362509/thread/4ca04adb/?limit=25 |
| 04:30.14 | nmz787 | well so far I've been shoving python-crafted tcl strings to mged via subprocess... and recently used subprocess to also grab the output of the 'l' command for a make_bb temp-object |
| 04:30.19 | brlcad | but that will convert trivially to python outside mged |
| 04:30.27 | nmz787 | so I can interact/parse other commands similarly |
| 04:30.58 | brlcad | :) |
| 04:31.36 | brlcad | there is a difference in this instance in that mged has it's own view and state which gets passed to nirt when run from within mged |
| 04:31.56 | brlcad | e.g., it shoots at the objects you've drawn from the center of the current view, whatever that may be |
| 04:32.04 | brlcad | outside mged, you specify those things to nirt |
| 04:33.30 | brlcad | basic approach will be to create a nirt script file which tells it what point and direction to shoot ray(s) |
| 04:33.33 | nmz787 | btw I see you using osuosl in a screenshot, are you in OR? |
| 04:33.43 | nmz787 | (I prev guessed MD) |
| 04:33.51 | brlcad | MD |
| 04:34.33 | nmz787 | and the output is the intersection point? |
| 04:34.40 | nmz787 | (of a shoot event) |
| 04:34.53 | brlcad | output is customizable, but yes default is hit point and thickness |
| 04:35.13 | nmz787 | so it doesn't matter if I hit the same point from different viewpoints |
| 04:35.15 | brlcad | see the manual, there are a couple other installed output forms that will be more useful, more easily parsed |
| 04:35.39 | brlcad | inhit and outhit points in one of them, not just inhit and thickness |
| 04:35.56 | brlcad | nirt -L |
| 04:40.23 | nmz787 | hmm, i opened a spiral model (union of rpp) in nirt and used 's' from the starting menu |
| 04:40.35 | nmz787 | I got 3 point triplets |
| 04:40.57 | nmz787 | all from the same model-region |
| 04:41.07 | nmz787 | (region name) |
| 04:41.10 | brlcad | screenshot or output? |
| 04:41.18 | nmz787 | console output |
| 04:41.52 | nmz787 | http://paste.pound-python.org/show/BeGxlfcowYKdEEFiL8uZ/ |
| 04:42.02 | nmz787 | I catted a bit of the tcl script at the top |
| 04:43.01 | brlcad | ah, that looks right |
| 04:43.20 | brlcad | notice, you're shooting from 0,0,0 in the direction -1,0,0 |
| 04:43.34 | brlcad | i.e., from the center of the spiral, out |
| 04:43.39 | brlcad | so it hits it three times |
| 04:44.55 | brlcad | first time at -12 (exiting at -26), then at -47 (exiting at -53), then at -79 (exiting at -84) |
| 04:46.03 | brlcad | it might make more sense for you to open up the model in mged and run nirt and spin the view to understand what's going on |
| 04:46.15 | brlcad | it'll actually show you these segments visually inside mged |
| 04:47.54 | nmz787 | i'll do that now, all I can tell from your reply otherwise is that the X coord got subtracted from it LOS |
| 04:50.09 | brlcad | something like this is going on: http://paste.pound-python.org/show/BeGxlfcowYKdEEFiL8uZ |
| 04:50.23 | brlcad | oops, this: http://brlcad.org/~sean/tmp/nirt_spiral.png |
| 04:52.56 | nmz787 | this is what mged shows with "e spiral.r" : http://imgur.com/PKP2SfC |
| 04:52.57 | brlcad | default ray is useless, be intentional about your 'pnt' and 'dir' (from where and in what direction) |
| 04:53.09 | nmz787 | so apparently I haven't finished my spiral script! |
| 04:53.22 | brlcad | so it's hitting three of those boxes |
| 04:53.47 | brlcad | you can refire the same ray inside mged |
| 04:53.49 | nmz787 | one ray or three? |
| 04:53.56 | nmz787 | did the ray bounce? |
| 04:54.02 | brlcad | one ray |
| 04:54.02 | nmz787 | reflect? |
| 04:54.10 | brlcad | nope |
| 04:55.00 | brlcad | "center 0 0 0" in mged will set your view center point to the same as what nirt used outside of mged |
| 04:55.53 | brlcad | "view dir" to see what your view is, but I think view dir -1,0,0 may get you oriented right so you can just run "nirt" inside mged to get the same output |
| 04:56.22 | brlcad | if nirt hits anything, you can rotate the view and you'll see the segments of intersection as colored line segments |
| 04:57.28 | nmz787 | view doesn't seem to have dir |
| 04:57.33 | nmz787 | in mged |
| 04:57.47 | nmz787 | (release 7.24.0) |
| 04:58.59 | brlcad | ah, my mistake |
| 04:59.04 | brlcad | help view :) |
| 04:59.33 | nmz787 | anyway, I don't want to waste your time since I have to read the manual and such! you've given me a ton to go on for a while! |
| 04:59.41 | nmz787 | thanks! |
| 05:00.39 | brlcad | ah, fount it |
| 05:00.42 | brlcad | just run "front" |
| 05:00.47 | brlcad | that will face -1,0,0 |
| 05:03.42 | nmz787 | with that and then "nirt" , and "top" I see http://imgur.com/9gxZI07 |
| 05:03.49 | nmz787 | (and some zooming) |
| 05:04.09 | brlcad | there ya go, that's the three segments it hit |
| 05:04.31 | brlcad | center -47.1519 0.0000 0.0000 |
| 05:04.54 | nmz787 | it looks like the rightmost segment went through 4 distinct boxes |
| 05:04.57 | brlcad | or one of the other points nirt reported, and you'll see it's right there |
| 05:05.14 | nmz787 | the middle through 2, the leftmost through 1 |
| 05:05.16 | brlcad | yes, but you unioned them all together -- it's just one mass of material |
| 05:05.29 | nmz787 | ah |
| 05:05.47 | nmz787 | I do remember something about hiding those lines |
| 05:05.57 | brlcad | you even unioned the disparate boxes, but it knows when it leaves and enters different portions of something |
| 05:06.06 | brlcad | rtedge |
| 05:06.53 | nmz787 | hehe, well rtedge crashed mged |
| 05:07.00 | brlcad | wot? really? |
| 05:07.22 | nmz787 | well, it seems to have recovered |
| 05:07.35 | brlcad | you on debian? |
| 05:08.03 | brlcad | try "rtedge -F/dev/X" |
| 05:08.45 | nmz787 | ubuntu |
| 05:08.46 | brlcad | there's a bug on some platform that causes X11 to go haywire (black screen) until the raytrace finishes |
| 05:09.26 | brlcad | something screwy with opengl and/or direct render mode or X11 calls or .. dunno, haven't been able to diagnose, but I have heard it reported |
| 05:09.52 | nmz787 | that worked |
| 05:10.00 | brlcad | so something with opengl |
| 05:10.04 | brlcad | or direct rendering |
| 05:10.09 | nmz787 | here's the output of the plain command http://imgur.com/nnJJyHl |
| 05:11.29 | brlcad | yeah, bug in the opengl driver of some sort |
| 05:12.17 | *** join/#brlcad ofnlut_ (~ofnlut_@2601:143:8001:646d:701a:226:11ad:2011) | |
| 05:12.31 | nmz787 | hmm, so maybe I want to take a slice, then shoot rays at the slice cross-sectionally |
| 05:12.46 | nmz787 | so I only ever get one intersection |
| 05:13.21 | nmz787 | hrmm, this is a bigger problem than I imagined when I started thinking about it a month or so ago |
| 05:13.22 | brlcad | that's what that g-gcode.c program does |
| 05:13.39 | nmz787 | ah, mm |
| 05:14.21 | brlcad | basically shoots across a line of rays, then shoots the next line, then the next, etc.. outputting (very primitive) gcode instructions as it goes |
| 05:14.59 | brlcad | the cool part is that it's arbitrary resolution and independent of the geometry representation format |
| 05:15.46 | nmz787 | mmm, which is good for me, as I am working on MEMS devices (nanometers) that integrate into macro devices (millimeters or cm) |
| 05:15.49 | brlcad | this makes it far more robust than any polygonal method could possibly be |
| 05:15.54 | brlcad | and better quality unless you want to get into sub-resolution tessellation |
| 05:16.12 | nmz787 | not that I'd be exporting g-code from the two scales at the same time |
| 05:16.35 | nmz787 | smartly in-filling is what is kind of scaring me now! |
| 05:16.43 | nmz787 | but alas, I need to go consume food |
| 05:16.44 | brlcad | you'd probably have trouble getting a sub-resolution tessellation to complete successfully (and you might end up with TB size models) |
| 05:16.54 | *** part/#brlcad ofnlut_ (~ofnlut_@2601:143:8001:646d:701a:226:11ad:2011) | |
| 05:17.11 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:17.34 | nmz787 | thanks a lot brlcad ! you have given me plenty to work on and think about |
| 05:17.43 | brlcad | nods, glad to help! |
| 05:18.31 | brlcad | if you need an interim solution, you might check out "slic3r" -- it already does smart in-filling |
| 05:18.42 | brlcad | but it requires tessellated input (stl) |
| 05:18.59 | brlcad | which is a real pain to get brl-cad to export sometimes |
| 05:19.33 | brlcad | it has to evaluate all of the boolean expressions apriori, which is an unstable problem |
| 05:31.44 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:58.53 | Notify | 03BRL-CAD:brlcad * 67067 brlcad/trunk/src/librt/bundle.c: rework the rt_shootrays() logic to preallocate all rays at once, initialize them in a separate pass, and then dispatch them all at once. while more coherent, we're not going to see huge gains due to other stalling. however, this sets the stage so that we can dispatch these rays in parallel more easily. |
| 07:40.01 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 09:53.37 | *** join/#brlcad teepee` (bc5c2134@gateway/web/freenode/ip.188.92.33.52) | |
| 11:12.49 | *** join/#brlcad ofnlut_ (~ofnlut_@2601:143:8001:646d:691e:3aac:1af3:1256) | |
| 11:47.56 | *** join/#brlcad ofnlut_ (~ofnlut_@2601:143:8001:646d:5439:2d60:14b8:3ee8) | |
| 12:54.19 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 13:01.23 | *** join/#brlcad ``Erik_ (~erik@pool-100-16-40-20.bltmmd.fios.verizon.net) | |
| 13:10.35 | Notify | 03BRL-CAD:d_rossberg * 67068 brlcad/trunk/src/librt/bundle.c: looks like the standard setup of the gcc compiler (-Werror=c++-compat) requires an explicite cast here |
| 13:23.55 | starseeker | brlcad: yes, recent libpng change |
| 13:24.00 | starseeker | brlcad: what's the failure? |
| 13:28.46 | starseeker | (don't have a mac to test on anymore...) |
| 14:37.56 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 15:31.14 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 15:34.17 | brlcad | agua:.build morrison$ bin/rt |
| 15:34.18 | brlcad | dyld: Library not loaded: libpng16.16.dylib Referenced from: /Users/morrison/brlcad.trunk3/.build/bin/rt Reason: image not found |
| 15:34.20 | brlcad | Trace/BPT trap: 5 |
| 15:35.35 | brlcad | maybe something wrong during CMake |
| 15:36.42 | brlcad | cache says: |
| 15:36.53 | brlcad | PNG_FOUND:STRING=PNG-NOTFOUND |
| 15:36.55 | brlcad | yes also |
| 15:36.56 | brlcad | PNG_LIBRARY:STRING=/Users/morrison/Applications/lib/libpng.dylib |
| 15:37.53 | brlcad | and more confusing is another set of vars in the same cache further down: |
| 15:37.58 | brlcad | PNG_FOUND-ADVANCED:INTERNAL=1 |
| 15:38.19 | brlcad | PNG_LIBRARY-ADVANCED:INTERNAL=1 |
| 15:39.48 | brlcad | looks like the actual link line is using that locally detected version |
| 15:41.11 | brlcad | /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -msse3 -std=gnu89 -m64 -ggdb -Qunused-arguments -fstack-protector-all -pedantic -pedantic-errors -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation |
| 15:41.18 | brlcad | -Wno-c11-extensions -Werror -Wl,-search_paths_first -Wl,-headerpad_max_install_names -m64 -ggdb CMakeFiles/rt.dir/do.c.o CMakeFiles/rt.dir/main.c.o CMakeFiles/rt.dir/opt.c.o CMakeFiles/rt.dir/worker.c.o CMakeFiles/rt.dir/heatgraph.c.o CMakeFiles/rt.dir/scanline.c.o CMakeFiles/rt.dir/view.c.o -o ../../bin/rt ../../lib/libfb.20.0.1.dylib ../../lib/liboptical.20.0.1.dylib ../../lib/libicv.20.0.1.dylib -lm . |
| 15:41.24 | brlcad | ./../lib/libpkg.20.0.1.dylib ../../lib/librt.20.0.1.dylib ../../lib/libgdiam.dylib ../../lib/libvds.1.0.1.dylib ../../lib/libbrep.20.0.1.dylib ../../lib/libbg.20.0.1.dylib ../../lib/libopenNURBS.2012.10.245.dylib ../../lib/libp2t.1.0.1.dylib /usr/lib/libc.dylib /usr/lib/libz.dylib ../../lib/libtinycthread.dylib -framework tcl ../../lib/libbn.20.0.1.dylib ../../lib/libbu.20.0.1.dylib -ldl -lm ../../lib/liby2 |
| 15:41.30 | brlcad | 038.dylib /Users/morrison/Applications/lib/libpng.dylib -Wl,-rpath,/Users/morrison/brlcad.trunk3/.build/lib |
| 15:47.21 | brlcad | starseeker: so problem seems to be runtime rpath-related .. not finding the auto-detected lib it decided to compile against |
| 16:04.46 | brlcad | presumably something related to RPath_Setup.cmake ?? I'm at a loss here as setting the library path manually works, just not when recorded in the libs/binaries |
| 16:21.11 | brlcad | hmm, progress .. so looks like the cmake Find macro is either searching the PATH dirs, finding the lib relative to those paths, or finding the installed png_config but not using the LDFLAGS png_config says must be used |
| 16:25.53 | brlcad | manually linking with `png-config --ldflags` which is "-L/Users/morrison/Applications/lib -lpng16" vs the "/Users/morrison/Applications/lib/libpng.dylib" above, seems to work |
| 16:45.22 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 17:20.27 | *** join/#brlcad ickby (~stefan@x5d84d145.dyn.telefonica.de) | |
| 17:27.25 | *** join/#brlcad ickby (~stefan@x5d84d145.dyn.telefonica.de) | |
| 17:57.16 | Notify | 03BRL-CAD Wiki:Ickby freecad * 9530 /wiki/Google_Summer_of_Code/Project_Ideas: |
| 17:59.02 | Notify | 03BRL-CAD:d_rossberg * 67069 brlcad/trunk/src/conv/csg/CMakeLists.txt: this should help to solve the lemon issue here: explicitely initialize the lemon package |
| 18:25.20 | starseeker | brlcad: I'm not sure -lpng16 would pull libpng.dylib |
| 18:26.08 | Notify | 03BRL-CAD:d_rossberg * 67070 brlcad/trunk/src/conv/csg/csg_parser.lemon: reverting changes from revision 66191: I can't confirm a clean build with gcc 4.9.2 without these additions |
| 18:26.13 | starseeker | brlcad: if you're using the system libpng, I wouldn't have expected the recent changes to break that... |
| 18:26.34 | starseeker | curious |
| 18:27.15 | starseeker | wonder why PNG_FOUND was set to not-found if the LIBRARY was set. |
| 18:37.23 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) | |
| 18:40.05 | starseeker | brlcad: when you use the -lpng16 linking command, is it actually finding the dylib at /Users/morrison/Applications/lib/libpng.dylib or is it locating some other library? |
| 18:40.18 | starseeker | i.e. what does the binary end up with per otool? |
| 19:33.44 | Notify | 03BRL-CAD:starseeker * 67071 brlcad/trunk/src/bwish/CMakeLists.txt: These are local dirs, and need to come ahead of any system dirs contributed by the libs |
| 19:44.48 | Notify | 03BRL-CAD:starseeker * 67072 brlcad/trunk/src/other/tinycthread/tinycthread.h: Avoid clang Wdocumentation warnings |
| 21:23.54 | brlcad | starseeker: libpng.dylib is the first of a series of symlinks that ends up at libpng16.16.16.0.dylib |
| 21:24.08 | brlcad | all in that App lib dir |
| 21:31.34 | brlcad | something got mixed up in my testing, looks like the png-config ldflags *doesn |
| 21:31.44 | brlcad | *doesn't* actually fix it |
| 21:37.53 | brlcad | otool/ldd still just lists libpng16.16.dylib .. the problem is it either needs to embed the full rpath (which curiously I would have expected cmake's version to work) or the find script shouldn't have been nosing into PATH dirs without linking |
| 21:38.13 | brlcad | http://stackoverflow.com/questions/1937232/linking-to-a-dynamic-library-on-a-mac-with-full-path <-- seems to be related as renaming the link does work |
| 21:43.04 | *** join/#brlcad ickby (~stefan@x5d8457b8.dyn.telefonica.de) | |
| 21:54.59 | brlcad | I think I found the underlying cause ... libpng's build does not appaer to set a proper install_name in the dylib file |
| 21:56.41 | brlcad | so when it gets linked by something else (via full path or -lpng16), it embeds the wrong linkage that won't work without extra steps (set DYLD_LIBRARY_PATH, use install_name_tool) |
| 21:58.48 | starseeker | brlcad: sounds like a worthwhile patch to png |
| 21:59.08 | starseeker | brlcad: does the ENABLE_ALL version of the build work? |
| 21:59.20 | starseeker | I found a test machine here and it seemed to work for me... |
| 22:00.16 | brlcad | hadn't tried an enable all yet, but I would expect that to work |
| 22:01.24 | brlcad | it's probably a case of PNG needing what you added to our build from https://cmake.org/Wiki/CMake_RPATH_handling |
| 23:33.15 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) | |
