| 00:11.20 | starseeker | hmm: http://jreinhardt.github.io/BOLTS/index.html |
| 00:27.13 | brlcad | starseeker: and that's why we need to be better at modular import/export |
| 00:27.45 | brlcad | our shape module is probably already better, as is that gpl proc-db that someone wrote a few years ago |
| 00:45.42 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 02:06.01 | kanzure | where are dll files installed on windows for brlcad? |
| 02:06.23 | kanzure | starseeker: i dunno if you saw, but i emailed him some comments about why using freecad-python is a bad idea |
| 02:06.38 | kanzure | starseeker: because you have to load opencascade/freecad's ui first in order to use anything in there. or the dependency on openscad. |
| 02:06.58 | kanzure | i'm writing a few cython wrappers at the moment actually. which is why i'm pondering how to support the windows install path. :) |
| 02:54.35 | Notify | 03BRL-CAD:starseeker * 57523 brlcad/trunk/src/proc-db/CMakeLists.txt: Adapt the Ayam implementation of the Cobb NURBS sphere to OpenNURBS and BRL-CAD. Creates a sphere (right now, only a unit sphere) using six NURBS patches rather than a revolved arc. |
| 02:55.31 | brlcad | kanzure: I believe the dll's reside in the folder with the binaries (as is customary with most windows applications, especially those that avoid the registry) |
| 02:56.19 | brlcad | starseeker: eww.. :) |
| 02:56.44 | brlcad | actually, would be a nice option to 'make' -- that's right up there with 'ell1' |
| 02:56.48 | kanzure | brlcad: python packages have an install process where they can compile to link against libraries. so you can pass an absolute path or just the name of the library. i am not sure how this works on windows. doesn't make sense. |
| 02:57.16 | kanzure | i guess users can edit $PYTHONPATH to refer to the C:\brlcad\dlls\ path |
| 02:57.20 | brlcad | presumably just the name of the library uses an rpath |
| 02:57.22 | kanzure | i mean %PYTHONPATH% |
| 02:57.25 | starseeker | brlcad: ? wireframe's better... |
| 02:57.38 | starseeker | mainly wanted for testing |
| 02:57.59 | brlcad | wireframe could be changed for revolved breps |
| 02:58.08 | kanzure | huh? wouldn't a revolved arc also have a wireframe? |
| 02:58.15 | brlcad | I get it, just data-wise, it's a bit of a pig |
| 02:58.23 | starseeker | yeah, a half circle - doesn't do much for users |
| 02:58.32 | starseeker | brlcad: that's why it's not the default :-) |
| 02:58.41 | brlcad | no reason we couldn't draw revolved isolines |
| 02:59.08 | brlcad | we're not (yet) drawing interior face detail, that's all that's missing |
| 02:59.24 | brlcad | old bspline code even had that, trivial to do |
| 02:59.49 | starseeker | The cobb form can stay in the proc-db - I needed a simple, non-degenerate test case for the step-g/g-step work to isolate pullback failures from topological mistakes |
| 03:00.25 | brlcad | kanzure: we do have runtime routines for finding our resources, if it's of any help |
| 03:01.35 | starseeker | it's not truly right yet - each Face is self-contained, instead of properly sharing 3D edges, but not too bad for a couple hours |
| 03:01.41 | kanzure | unfortunately i think the issue i am messing around with at the moment is a non-brlcad issue (maybe) |
| 03:03.09 | starseeker | might be worth thinking about options to the brep command when converting primitives - there are a number of scenarios where I can see it being desirable to be able to select between various well known representations in the conversion process |
| 03:03.45 | starseeker | not sure what the command UI would look like though... brep -T cobb sph.s brep.s ? |
| 03:04.18 | kanzure | for example, cython needs to use the brlcad headers during compile-time (cython compiles a python wrapper library, it's a long story), and now i need to figure out how to do that in a way that will work if a user does "pip install brlcad" to download the bindings from the python package index. |
| 03:04.55 | kanzure | i suppose i could vendorize brlcad header files. but that wont work if the installed brlcad version differs. hrm.. |
| 03:05.04 | brlcad | kanzure: for example, running something like: file exists [ file join [ bu_brlcad_root lib ] "libbu.a" ] will return 0 or 1 if that file exists |
| 03:05.46 | kanzure | echo $bu_brlcad_root |
| 03:05.53 | kanzure | this does not seem to be defined (yes i have brlcad installed) |
| 03:06.10 | brlcad | echo? |
| 03:06.17 | brlcad | that's an mged command |
| 03:07.09 | kanzure | i am making bindings, which means i can't call into an mged instance |
| 03:07.37 | brlcad | but you could invoke mged to find the library (prior to it being loaded) |
| 03:07.48 | brlcad | akin to "which mged" |
| 03:07.50 | kanzure | interesting |
| 03:07.58 | brlcad | it'd be something like this in full: /usr/brlcad/rel-7.22.0/bin/mged -c test.g "file exists \[ file join \[ bu_brlcad_root lib \] \"libbu.a\" \]" |
| 03:08.19 | brlcad | on windows, you replace lib with bin (or search both, use the first found) |
| 03:08.22 | kanzure | btw maybe i should move up a level in the stack here, i forget if you are strongly opposed to not using swig? |
| 03:09.11 | brlcad | opposed to not using swig? not particularly opposed if it's a solution that works and someone maintains it |
| 03:09.28 | brlcad | if you get something working, that's better than nothing |
| 03:10.01 | kanzure | one other option- that is much less involved- is to use python + ctypes, which is a default library provided by python |
| 03:10.13 | brlcad | there's nothing inherintly better about swig except for consistency to other languages |
| 03:10.17 | kanzure | but it would require a shared library with C functions exposing all of brlcad's beautiful guts |
| 03:10.31 | kanzure | some of the brlcad shared libraries seem to work with ctypes just fine. but not all? |
| 03:10.47 | kanzure | yeah, i think that consistency is very valuable |
| 03:11.10 | brlcad | all of our core libraries are C APIs, it's only the nurbs portion that is not and that's an opaque type from librt's perspective |
| 03:11.23 | kanzure | oh really? |
| 03:11.38 | kanzure | so, exposing the nurbs stuff isn't super important since librt wraps it |
| 03:11.42 | kanzure | right? |
| 03:12.09 | brlcad | librt wraps it opaquely |
| 03:12.14 | Notify | 03BRL-CAD:phoenixyjll * 57524 brlcad/trunk/src/libbrep/boolean.cpp: Also check degree (order) and knots for NURBS surface equality. |
| 03:12.35 | brlcad | so IF you need opennurbs, you probably will need something non-opaque but that can be a separate binding |
| 03:12.45 | kanzure | i don't think i absolutely need opennurbs |
| 03:12.57 | kanzure | i'm willing to let brlcad do all of the interesting work |
| 03:13.07 | kanzure | and if someone wants direct access to opennurbs then they should just wrap opennurbs |
| 03:13.17 | brlcad | basically librt has a few functions that take an ON_Brep pointer ... but that is the entire extent of what it knows API-wise |
| 03:13.38 | kanzure | cool, well this makes my job way easier |
| 03:13.41 | brlcad | it's an empty struct type to C applications, it's a C++ class to everything else |
| 03:15.05 | kanzure | brlcad: which librt functions should i focus on first? i don't know the practical difference between db_create db_create_inmem db_close_client db_close etc. |
| 03:16.30 | brlcad | I'd actually suggest starting with libwdb |
| 03:16.43 | brlcad | it's a simple api just for creating geometry |
| 03:19.29 | brlcad | just a couple dozen functions |
| 03:20.23 | brlcad | simple example in C: http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/proc-db/wdb_example.c |
| 03:21.09 | brlcad | "brlman libwdb" for more functions or include/wdb.h to see the header |
| 03:22.05 | kanzure | cool, thank you |
| 03:22.25 | brlcad | another approach would be libged, which is basically most of mged's command set as argc/argv-style functions |
| 03:22.35 | brlcad | but libwdb would be a better proof-of-concept |
| 03:23.31 | brlcad | librt is the real workhorse that everything is built on, but there are hundreds of functions that interwork in complex ways |
| 03:23.49 | brlcad | wdb is the way to go ;) |
| 03:24.08 | brlcad | more examples: http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/proc-db/ and http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/shapes/ |
| 03:24.20 | kanzure | this is way easier than the adventure i was gearing up to do |
| 03:26.45 | kanzure | hmm tcl-dev didn't give me tcl.h |
| 03:27.26 | kanzure | ah it's tcl/tcl.h |
| 03:27.40 | brlcad | hm... it'd be really intersting to see what that wdb_example looks like as a simple python script |
| 03:29.29 | brlcad | note that our example uses our vmath.h macro header and we also define some basic types like vect_t and point_t, but note those are simple C types |
| 03:29.31 | kanzure | oh man, i should have listened to you sooner. i did librt and now i'm trying to find something in here to prove that it works. |
| 03:29.46 | kanzure | i dunno if anyone will be upset if i miss one or two macros |
| 03:29.46 | brlcad | in librt? |
| 03:29.49 | kanzure | yes |
| 03:30.18 | brlcad | ponders |
| 03:30.36 | kanzure | curve = librt.rt_curve() |
| 03:30.48 | kanzure | pokes his curve |
| 03:31.34 | kanzure | yeah okay i'll work on libwdb |
| 03:31.47 | kanzure | and then translate wdb_example.c to wdb_example.py |
| 03:31.52 | brlcad | maybe rt_prep_timer() and rt_get_timer() |
| 03:32.13 | brlcad | simple timing functions, first is void (void), so that'll be easy |
| 03:33.14 | brlcad | second takes a special string type of ours, but I believe you can pass NULL for both args |
| 03:33.27 | kanzure | i should have clarified that i am cheating and only did rtgeom.h |
| 03:33.32 | brlcad | return type is elapsed cpu seconds |
| 03:33.36 | brlcad | ahhhh |
| 03:33.59 | kanzure | i am using this generator but the final wrappers will probably be manual (this generated code makes zero sense) |
| 03:34.14 | brlcad | well, that's a problem - it doesn't declare any functions directly |
| 03:34.21 | kanzure | hm? |
| 03:34.23 | brlcad | does it pick up sub-headers? |
| 03:34.31 | kanzure | you mean included headers? |
| 03:34.35 | brlcad | rtgeom.h doesn't declare any functions, just a lot of types |
| 03:34.42 | brlcad | but it includes several headers that declare functions |
| 03:35.29 | kanzure | oh, maybe that explains why i only saw rt_geometry_related_structs |
| 03:35.30 | kanzure | right then |
| 03:35.31 | brlcad | bu.h is one of them, lots of simple bu functions you could call to show it's working |
| 03:35.51 | brlcad | could try calling bu_gettime() |
| 03:36.30 | brlcad | it returns an int64 for ms time since epoch, so call it twice, subtract, you got elapsed ms |
| 03:36.42 | kanzure | i don't seem to have a /usr/brlcad/libwdb.so |
| 03:36.46 | brlcad | or even more simple, bu_log("test\n"); |
| 03:37.12 | brlcad | probably because it's in the lib dir with the other libs? :) |
| 03:37.24 | brlcad | /usr/brlcad/lib/libwdb.so |
| 03:41.51 | kanzure | what is db_ident ? |
| 03:47.41 | kanzure | ah, lesson learned: favor absolute paths |
| 04:01.02 | kanzure | WARNING: Could not parse macro "#define BU_LIST_INIT |
| 04:01.24 | kanzure | hmm well this is going to make rewriting wdb_example.c a little bit more difficult |
| 04:02.59 | kanzure | can i just use bu_list_new() instead? |
| 04:05.09 | kanzure | and where is wdb_fopen defined? |
| 04:09.01 | kanzure | include/raytrace.h:RT_EXPORT extern struct rt_wdb *wdb_fopen(const char *filename); |
| 04:13.24 | kanzure | i've added "struct rt_wdb *wdb_fopen(const char *);" to include/wdb.h hope nobody hates me |
| 04:20.11 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 04:29.18 | brlcad | interesting, I wonder what about BU_LIST_INIT is causing it trouble |
| 04:29.32 | brlcad | yes, you don't need to call BU_LIST_INIT |
| 04:31.18 | brlcad | and that's fine about adding it .. that function doesn't belong in raytrace.h -- just nobody has bothered to move it from librt to libwdb |
| 04:31.26 | FLOSSrookie | What specifically does the brlcad developers expect to gain by moving the software to a new gui? Is there some functionality which cannot be created without it? |
| 04:31.28 | brlcad | there's a few functions like that which don't belong in librt |
| 04:31.38 | FLOSSrookie | "What specifically do ..."^ |
| 04:32.02 | brlcad | FLOSSrookie: depends what you mean by the new gui and which year |
| 04:32.15 | brlcad | development of a GUI is something that is passively worked over several years |
| 04:32.27 | brlcad | we have several other core activities that receive considerably more attention |
| 04:32.30 | FLOSSrookie | I recall a discussion of moving it to QT and it would be "a game like interface" |
| 04:33.02 | brlcad | oversimplifies it, but yes that is the long term direction |
| 04:33.24 | FLOSSrookie | brlcad: May I ask what is to be gained? |
| 04:33.25 | brlcad | though the emphasis is more on a thin client architecture, not so much on "qt" |
| 04:33.55 | brlcad | oof, that's a LONG discussion, but I can hit some of the highlights |
| 04:34.35 | brlcad | one of the biggest problems we have is one of complexity |
| 04:34.58 | brlcad | we have approximately 1000 "features" |
| 04:35.13 | brlcad | and that's probably a low estimate |
| 04:36.23 | brlcad | mged as it is currently designed presents maybe half of those features in a fairly unintuitive and often completely unlearnable manner |
| 04:37.50 | brlcad | of just the 400 or so features that are exposed to users in some usable useful way, the interface fails and presenting those features, making the system be discoverable, making it even be possible to find what you might be looking for |
| 04:38.26 | brlcad | our best users often learn by asking someone else that knew how to read the source code who could tell them the magic recipe |
| 04:38.45 | brlcad | these are predominantly usability interface failings |
| 04:39.48 | brlcad | improving our usability (across the board, not just our GUI) is an active area of focus for that and other reasons |
| 04:40.39 | brlcad | this highlights our overall project priorities in a greater context: http://brlcad.org/BRL-CAD_Priorities.png |
| 04:41.51 | brlcad | FLOSSrookie: does that answer your question? |
| 04:42.28 | FLOSSrookie | brlcad: Yes, it does. Thank you. Now I understand. :) |
| 04:45.07 | brlcad | I mean hell, we probably have everything one needs to implement a *command-line* scriptable version of Photoshop 1.0 ... but nobody would know that exploring mged (or care these days, there are far better tools) |
| 04:48.40 | FLOSSrookie | brlcad: On the geometry services part of that link it says "scriptable command framework." What scripting language will be used? |
| 04:48.40 | FLOSSrookie | brcad: So, if I start work on a project now will it still be usable in a future version? |
| 04:50.58 | brlcad | in rough order, our current development priorities are on 1) hybrid representation support (NURBS, Implicit to NURBS, NURBS CSG, NURBS tessellation, shaded displays, robust conversion, performance), 2) STEP import/export (robust conversion, robust facetization, faithful round-trip with commercial systems), 3) parametric constraints (geometry associations, parametric values, tangency, equations), and 4) GUI (usability, infrastructure work, ref |
| 04:51.54 | brlcad | somewhere in there performance work is implicit, getting our ray tracing engine and other processing-intensive bits leveraging memory coherency and gpgpu techniques for high performance desktop needs |
| 04:52.03 | kanzure | wm_hd.l = bu.bu_list() |
| 04:52.04 | kanzure | TypeError: incompatible types, struct_bu_list instance instead of struct_bu_list instance |
| 04:52.06 | brlcad | the wiki pages are woefully out of day |
| 04:52.07 | brlcad | date |
| 04:52.15 | kanzure | wdb.mk_addmember("box.s", bu.bu_list(), (ctypes.c_double * 16)(), ord("u")) |
| 04:52.16 | kanzure | mk_addmember() op=x6e6530c0 is bad |
| 04:52.33 | kanzure | (the ctypes thing there is just some stuff that will be fixed when i pretty up the wrapperlib) |
| 04:52.59 | kanzure | what does "is bad" mean? |
| 04:53.24 | brlcad | FLOSSrookie: the scripting engine is intended to support multiple scripting languages through a common binding layer, built on our libged command library, initially supporting Tcl, POSIX Shell (ksh), and probably Lisp or Python (or both) |
| 04:53.49 | brlcad | maybe perl if tom has his way |
| 04:55.04 | brlcad | FLOSSrookie: and yes, if you start now, it will be usable in a future version -- we take pride and have very tight controls in place on how fast we change things on users (and external developers) |
| 04:55.52 | brlcad | kanzure: heh, don't know about that TypeError ... maybe one is a pointer and one is not? |
| 04:56.26 | brlcad | the .l members are usually not pointers |
| 04:56.44 | FLOSSrookie | Okay, good. :) |
| 04:57.54 | brlcad | FLOSSrookie: are you looking to get into development, use, or both? |
| 05:02.47 | FLOSSrookie | It all depends. Right now I am on a steep learning curve. I was always good with computer from the end user perspective but just now peering into the development perspective of computing. |
| 05:02.47 | FLOSSrookie | I am learning much about programming languages and so forth and finally have a basic set which I think would be superb to learn. |
| 05:02.48 | FLOSSrookie | I think brlcad is very neat and I would like to be able to understand not only software engineering but CAD as well and then maybe follow through with an actual build of a model. Feel pretty good if I could accomplish such a thing. The challenge could be a very valuable educational tool. |
| 05:02.58 | FLOSSrookie | with computers^ |
| 05:06.28 | FLOSSrookie | And if there is a feature which I want in brlcad I will then put it in there. :) |
| 05:06.28 | *** join/#brlcad yukonbob (~bch@dsl081-162-155.sea1.dsl.speakeasy.net) | |
| 05:06.36 | yukonbob | hello #brlcad |
| 05:17.50 | kanzure | brlcad: struct_bu_list should be compatible between libwdb and libbu right? |
| 05:35.26 | brlcad | kanzure: I have no idea what "struct_bu_list" means |
| 05:35.40 | brlcad | is that our "struct bu_list" structure or a "struct bu_list *" pointer? |
| 05:36.10 | brlcad | I could see it easily being either |
| 05:36.24 | brlcad | or both even if it's a simple header parser |
| 05:36.28 | kanzure | it's not the pointer |
| 05:36.40 | kanzure | i think the problem is that i don't have the BU_LIST_INIT macro |
| 05:38.02 | brlcad | all of the wdb functions that take a struct bu_list take a pointer, but all of the struct members are non-pointers |
| 05:38.26 | kanzure | struct bu_list seems to have a struct bu_list *forw |
| 05:38.34 | brlcad | yep |
| 05:38.42 | kanzure | forw is a struct member |
| 05:38.46 | kanzure | and it looks like a pointer |
| 05:39.39 | brlcad | INIT is just ->forw = ->back = some_pointer; ->magic = special_32bit_number; |
| 05:40.02 | kanzure | magic is set to 0 at the moment. so i don't know if i am getting that actual magic number. |
| 05:40.10 | brlcad | 0 would be a problem |
| 05:40.33 | brlcad | that basically will tell the code it's unset/uninitialized/invalid |
| 05:40.44 | brlcad | anything using it will halt the application |
| 05:41.12 | brlcad | memory integrity checks are pervasive |
| 05:41.15 | kanzure | where is BU_LIST_HEAD_MAGIC defined? |
| 05:41.29 | brlcad | magic.h |
| 05:42.17 | brlcad | enwanders |
| 06:10.19 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 06:25.54 | FLOSSrookie | In the process of learning brlcad would it also be wise to learn a programming language with linear algebra features? Would it be useful when engineering? |
| 06:29.17 | FLOSSrookie | Like Octave? |
| 06:38.55 | kanzure | what does it mean if wmember.l.forw is always a different address :( |
| 06:39.00 | kanzure | i think this is bad |
| 06:59.57 | *** part/#brlcad greenride (~purplehaz@71.202.102.140) | |
| 07:00.39 | *** join/#brlcad vladbogo (~vlad@188.25.237.111) | |
| 07:09.33 | kanzure | brlcad: i am getting, "db_recurse(ball.s): matrix does not preserve axis perpendicularity. |
| 07:09.38 | kanzure | "bad matrix" |
| 07:17.03 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 07:57.55 | d_rossberg | vladbogo: did you already looked at Tcl_CreateEventSource()? |
| 08:02.49 | vladbogo | d_rossberg: no I haven't looked at Tcl_CreateEventSource |
| 08:06.13 | d_rossberg | it should be possible to hook in your dm_qt.dm_processEvents() into the TCL event loop with this function |
| 08:09.05 | vladbogo | I'll take a look and see what I can find. Thanks for the tip |
| 08:11.04 | vladbogo | I am currently trying to solve memory leaks |
| 08:43.34 | kanzure | i wonder if wdb_example.c is broken. that would explain a lot.. |
| 08:43.53 | kanzure | my .g file generated through python is correct, but the mk_comb result has a bad matrix. |
| 08:44.22 | kanzure | http://diyhpl.us/~bryan/irc/wdb_example.py |
| 09:20.22 | *** join/#brlcad vladbogo (~vlad@188.25.237.111) | |
| 09:20.22 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) | |
| 09:20.22 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) | |
| 09:32.59 | Notify | 03BRL-CAD:phoenixyjll * 57525 brlcad/trunk/src/libbrep/boolean.cpp: Improve inside/outside test for the cases with overlap surfaces. |
| 09:55.36 | Notify | 03BRL-CAD Wiki:Phoenix * 6115 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 13 */ |
| 10:07.15 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) | |
| 10:47.41 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) | |
| 11:35.16 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 13:10.05 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) | |
| 14:01.34 | *** join/#brlcad PrezKennedy (~DarkCalf@173.231.40.99) | |
| 14:48.04 | *** join/#brlcad kesha (~kesha@49.249.17.188) | |
| 14:50.32 | *** join/#brlcad PrezKennedy (~DarkCalf@173.231.40.99) | |
| 16:06.00 | brlcad | kanzure: just did a valgrind check and wdb_example is passing clean |
| 16:06.21 | kanzure | brlcad: thanks |
| 16:07.12 | kanzure | brlcad: i tried playing around with bu_list_new() and mk_pipe_init() as an alternative to BU_LIST_INIT() because those functions seemed to use the macros. |
| 16:07.48 | kanzure | brlcad: but no luck. the .g output of this script is valid and i can see a box and sphere in mged but "draw box_n_ball.r" gives me an error about a matrix being wrong. |
| 16:08.42 | brlcad | I saw that in your current example, calling mk_pipe_init() .. interesting :) |
| 16:09.04 | kanzure | i figured it was easier than rebuilding brlcad for the moment |
| 16:11.49 | brlcad | you list initialization looks fine |
| 16:11.52 | kanzure | brlcad: http://diyhpl.us/~bryan/irc/brlcad-python-ctypes-demo.zip |
| 16:12.57 | brlcad | a bad matrix indicates that a bad member is being added |
| 16:12.59 | kanzure | btw wdb_close was also not defined in wdb.h for some reason |
| 16:13.29 | kanzure | i'm pretty sure the problem is with how i'm passing around or defining wm_hd, wm_hd.l, etc. |
| 16:14.41 | kanzure | if you want to poke at this, open up a python console and do: import wdb, bu, rtgeom, ctypes |
| 16:15.55 | kanzure | the ctypes module provides some nifty things like ctypes.addressof() ctypes.byref() and there's also wdb.POINTER(wdb.struct_whatever)(struct_whatever_instance) |
| 16:16.52 | brlcad | I think wdb.mat_t() is the culprit |
| 16:17.13 | brlcad | presumably, that's creating a mat_t ... which is never initialized |
| 16:17.23 | brlcad | pass NULL |
| 16:17.39 | brlcad | (this is the third arg to mk_addmember) |
| 16:18.31 | brlcad | alternatively, you'll need to set that wdb.mat_t() to at least an identity matrix (a zero matrix would be invalid too) |
| 16:19.22 | brlcad | actuallly really nifty seeing libwdb and librt calls wrapped in python like that! |
| 16:24.04 | kanzure | holy hell you're right |
| 16:24.06 | kanzure | it works :) |
| 16:24.42 | kanzure | switch wdb.mat_t() to wdb.NULL then comment out line 3481 of wdb.py |
| 16:24.58 | kanzure | (note there's two wdb.mat_t() becaues of the two mk_addmember calls) |
| 16:26.48 | brlcad | awesome |
| 16:27.55 | kanzure | updated: http://diyhpl.us/~bryan/irc/brlcad-python-ctypes-demo.zip |
| 16:28.16 | Notify | 03BRL-CAD:brlcad * 57526 brlcad/trunk/TODO: review proc-db for promotion to src/shapes |
| 16:45.46 | Notify | 03BRL-CAD:brlcad * 57527 brlcad/trunk/src/util/dsp_add_t.cpp: more 'may be used unitialized' warnings due to try/catch block, reordered/separated for readability |
| 16:46.24 | brlcad | hm, can't get the dylib to load on mac |
| 16:49.16 | brlcad | ahh, crummy |
| 16:49.42 | brlcad | the python binary is 32-bit, so it won't load our 64-bit libraries |
| 16:51.46 | brlcad | hm, the plot thickens.. it's a universal binary so there's also a 64bit version, but it's somehow deciding to run the 32-bit one |
| 16:55.00 | brlcad | looks like it's trying now, segfaults |
| 16:58.16 | Notify | 03BRL-CAD:brlcad * 57528 brlcad/trunk/src/proc-db/CMakeLists.txt: mark which proc-db seem to be developmental test programs and which actually create some geometry, something potentially useful to a non-developer. don't install the development apps. |
| 16:58.19 | brlcad | awesome, that just might finally get us underneath the 400 app mark |
| 17:03.29 | *** join/#brlcad kesha_ (~kesha@49.249.8.110) | |
| 17:17.47 | kesha_ | brlcad: If I do rt some-obj in mged then it raytracing fails showing http://paste.kde.org/p446ae456/ , but if I do File>Raytrace>Raytrace, then the raytrace completes successfully. Why so ? |
| 17:24.32 | kesha_ | It happened with other model I tried. I think I have wrongly understood usage of rt |
| 17:24.51 | kesha_ | rt [options] [-- objects] |
| 17:50.06 | Notify | 03BRL-CAD:tbrowder2 * 57529 (brlcad/trunk/misc/auto-man-page/BIN_OPT_ARG_ANALYSIS.txt =================================================================== and 2978 others): add initial bin opt arg analysis per Sean's idea |
| 18:19.04 | Izak__ | brlcad: How do you think I can change the default orientation of the heart ? |
| 18:35.01 | Notify | 03BRL-CAD:tbrowder2 * 57530 brlcad/trunk/misc/auto-man-page/BIN_OPT_ARG_ANALYSIS.txt: rename section |
| 18:40.42 | ``Erik | "You can't remove this! It's a load-bearing hack!" |
| 18:44.08 | brlcad | kesha_: File->Raytrace is going to raytrace whatever is drawn, similar to just issuing the "rt" command inside mged without any object names |
| 18:44.24 | brlcad | whether either succeeds depends on what you tell it to raytrace |
| 18:44.39 | brlcad | I suggest running rt outside of mged until you're comfortable with what it all means |
| 18:45.06 | brlcad | use mged to explore the objects, e.g., mged -c file.g tops |
| 18:45.09 | brlcad | mged -c file.g ls |
| 18:45.15 | brlcad | rt file.g some_top_object |
| 18:45.29 | brlcad | rt file.g some_ls_object |
| 18:46.08 | brlcad | Izak__: you define the orientation with your equations in prep() and shot() |
| 18:46.28 | brlcad | Izak__: basically, you have your Y and your Z swapped |
| 18:46.52 | brlcad | (somewhere) |
| 18:47.20 | brlcad | more than likely, in the big polynomail expansion |
| 18:48.53 | Izak__ | So need to fix prep() and shot() ? |
| 19:02.12 | brlcad | Izak__: I don't know |
| 19:02.42 | brlcad | you have to find where you specified x/y/z, make sure they are right for +Z being up |
| 19:03.47 | brlcad | if you used this implicit equation, then that should be +Z is up correctly: http://mathworld.wolfram.com/HeartSurface.html |
| 19:03.57 | brlcad | rather, either of the two on that page |
| 19:05.02 | Izak__ | I think I know where the problem comes from |
| 19:05.03 | brlcad | get any of those coefficients wrong or flipped in sign, and it'll be flipped |
| 19:05.37 | Izak__ | True, I swapped Y and Z in the implicit equation |
| 19:06.21 | Izak__ | and 9/80Z^3 has to be 9/80Y^2 |
| 19:07.28 | Izak__ | fixing these |
| 19:17.44 | brlcad | should be -9/80Y^2Z^3 |
| 19:41.44 | Izak__ | O_ops: brlcad: Please can you give the 'rt' command you gave on Friday. |
| 19:43.10 | brlcad | ~lotgs |
| 19:43.12 | brlcad | ~logs |
| 19:43.12 | infobot | All conversations are logged to http://infobot.rikers.org/%23brlcad/ Lines starting with spaces are not logged. Logs are updated daily. |
| 19:43.41 | brlcad | running "/last rt" might help you |
| 19:44.33 | Izak__ | Okay thanks |
| 19:46.37 | brlcad | you should be an rt pro by now... :) |
| 19:47.49 | brlcad | i don't recall what it is we talked about five days ago, but then you're not being very specific |
| 20:08.31 | kanzure | brlcad: i'm confused, why were you trying on a mac? is it your main dev machine? |
| 20:37.02 | starseeker | brlcad: uh... did you delete brep_cobb? |
| 20:39.03 | Notify | 03BRL-CAD:starseeker * 57531 brlcad/trunk/src/proc-db/CMakeLists.txt: Add brep_cobb back in |
| 20:39.54 | Notify | 03BRL-CAD Wiki:Vladbogolin * 6116 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 13 */ |
| 20:44.09 | *** join/#brlcad mpictor (~mark@c-67-177-102-131.hsd1.in.comcast.net) | |
| 20:45.04 | brlcad | kanzure: I primarily due dev on mac, linux, and bsd, regularly switching between them all for various purposes and tools |
| 20:45.12 | brlcad | starseeker: not intentionally |
| 20:45.12 | kanzure | ah cool |
| 20:45.20 | kanzure | well, i'll try to get it working on mac osx |
| 20:45.23 | brlcad | s/due/do/ |
| 20:45.45 | kanzure | i need to submit a patch for wdb.h changes. do you guys accept git diff --patch output from the git-svn bridge? |
| 20:45.58 | brlcad | if it applies with patch -i -p0, sure |
| 20:46.19 | kanzure | oh wait, i have svn commit access. neat. |
| 20:46.24 | brlcad | or that ;) |
| 20:46.32 | brlcad | what'd you have to change? |
| 20:46.51 | kanzure | wdb_fopen wdb_close should be exposed through wdb.h |
| 20:47.00 | brlcad | ahh |
| 20:47.12 | brlcad | they're not because they're not (yet) technically in libwdb |
| 20:47.22 | brlcad | i.e., their function definition is actually in src/librt (boo hiss) |
| 20:47.25 | kanzure | but they get linked into libwdb? |
| 20:47.40 | brlcad | depends on the platform, how library dependencies are resolved |
| 20:47.45 | kanzure | "poorly" |
| 20:48.01 | brlcad | might be the reason the mac is crashing actually |
| 20:48.11 | kanzure | you will have to rebuild the bindings for mac |
| 20:48.16 | brlcad | checks nm |
| 20:48.23 | kanzure | i'm sorry i didn't make this easier, i'm planning on fixing things and making it cross-platform later today |
| 20:48.43 | brlcad | yep, not in there |
| 20:49.05 | kanzure | i didn't check if wdb_close was necessary anyway |
| 20:49.12 | brlcad | no worries, i knew it was proof of concept devmanship |
| 20:49.51 | brlcad | quick sed-replacement of all the /usr/brlcad/lib paths was easy enough |
| 20:50.09 | brlcad | had to replace .so with .dylib too, of course |
| 20:51.06 | kanzure | are you still getting a segfault ? |
| 20:51.37 | brlcad | haven't changed anything since I last tried, so I'd hope so :) |
| 20:56.36 | kanzure | so mac comes with a 32-bit version of python on a 64-bit system? |
| 21:02.17 | Ch3ck_ | brlcad: I just wish to clarify if the centrepoint of every object starts at 0,0,0 |
| 21:02.46 | Ch3ck_ | so if I could determine the centrepoint of the bounding box from then I could determine the translation which will be pulled |
| 21:09.09 | Notify | 03BRL-CAD:starseeker * 57532 brlcad/trunk/src/conv/step/g-step/CMakeLists.txt: Start figuring out what to do about combs. |
| 21:17.04 | Ch3ck_ | since i think every object originally starts at 0,0,0 |
| 21:17.37 | Ch3ck_ | before its being translated so I could easily get the translation after computing the centrepoint from the AABB |
| 21:29.58 | Notify | 03BRL-CAD:iiizzzaaakkk * 57533 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Correcting the implicit equation of the heart in rt_hrt_shot() |
| 21:30.43 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 6117 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Sept 09 - Sept 15 */ |
| 21:31.07 | Izak__ | brlcad : Getting better heart shape from rt. Will upload picture to logs. |
| 22:03.05 | Notify | 03BRL-CAD:carlmoore * 57534 (brlcad/trunk/TODO brlcad/trunk/doc/docbook/presentations/en/brlcad-app-devel.xml and 23 others): fix spelling; remove trailing blanks/tabs |
| 22:04.51 | brlcad | kanzure: it's a universal binary (meaning it has multiple compilations embedded into one binary) |
| 22:05.11 | brlcad | the default is /Library/Frameworks/Python.framework/Versions/Current/bin/python which is 32-bit only for some reason |
| 22:05.55 | brlcad | /usr/bin/python is universal, has 64-bit and invokes it correctly (but then segfaults) |
| 22:06.20 | brlcad | confirmed with: arch -x86_64 /usr/bin/python wdb_example.py |
| 22:06.30 | brlcad | which ensures which binary in the universal to run |
| 22:06.47 | kanzure | what about forcing 32-bit ? |
| 22:07.16 | brlcad | Ch3ck_: currently, the centerpoint of every object is not at 0,0,0 .. it's wherever it's defined |
| 22:07.38 | brlcad | kanzure: that would just be letting the /Library one run, but then it fails to load the .dylibs because they are incompatible |
| 22:08.04 | brlcad | our libs default to 64-bit on 64-bit-capable systems, so I'd have to recompile |
| 22:08.15 | brlcad | or we'd have to produce universal libs/bins |
| 22:08.51 | kanzure | i'd like to try to make this work without upstream changes in brlcad because then if anyone has a distribution with old brlcad it will still work (hopefully) |
| 22:09.23 | brlcad | Ch3ck_: but I think you have the right idea, that you would "move" an object such that it's bounding box center is at 0,0,0 |
| 22:09.40 | brlcad | Ch3ck_: it's just not right to "think every object originally starts at 0,0,0 .. it starts anywhere |
| 22:09.42 | kanzure | (i think the wdb_fopen issue can be tempfixed by pulling it in from the raytracer maybe) (but i'll still post a diff in a bit) |
| 22:10.14 | brlcad | yeah, that would definitely work, just by dloading librt in addition to libwdb |
| 22:18.07 | Ch3ck_ | brlcad, well i just wanted a way to be able to determine the translation from its original location using its AABBs centrepoint |
| 22:18.52 | Ch3ck_ | well based on its centrepoint how do I know its original centrepoint so as to extrapolate the translation? or is there another method to do this? |
| 22:31.38 | *** join/#brlcad kesha_ (~kesha@49.249.8.110) | |
| 22:46.22 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6118 /wiki/User:Izak/GSOC_2013_logs: /* September 9th to September 14th */ |
| 22:47.27 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6119 /wiki/User:Izak/GSOC_2013_logs: /* September 9th to September 14th */ |
| 22:48.08 | Izak__ | brlcad: ``Erik: Can yo watch the heart movie on this link http://brlcad.org/~Izak/Heart.mpg |
| 22:55.44 | kanzure | was the git-svn bridge reset? i don't see some of the old commit ids in the master branch. |
| 22:57.28 | Izak__ | s/yo/you |
| 23:07.14 | kanzure | 16:04 < jrayhawk> Yeah, the SVN URL changed. |
| 23:07.14 | kanzure | 16:05 < jrayhawk> which would qualify as a major change to the git-svn setup. |
| 23:07.14 | kanzure | 16:05 < jrayhawk> So all the hashes are going to be different as a result of the commit messages. |
| 23:07.21 | kanzure | 16:06 < jrayhawk> That could've been avoided if the git-svn setup had included just the revision and not the repository URL in the commit message. |
| 23:40.32 | Notify | 03BRL-CAD:iiizzzaaakkk * 57535 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Correcting rt_hrt_norm to reflect the right implicit heart equation |
| 23:50.17 | Notify | 03BRL-CAD:iiizzzaaakkk * 57536 brlcad/trunk/src/librt/primitives/hrt/hrt.c: More corrections to the implicit equation |
| 23:55.26 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
