| 00:26.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 01:20.08 | *** join/#brlcad merzo (~merzo@139-2-133-95.pool.ukrtel.net) |
| 01:40.57 | starseeker | brlcad: I suspect there's some aspect to this that I'm not properly understanding - I scrubbed down librt's inclusion of bu.h and added the subheaders where needed - it does in fact compile, but trying to link anything with it results in a bunch of missing bu functions |
| 01:41.32 | starseeker | how is it compiling if it can't find the appropriate bu functions? |
| 02:09.08 | starseeker | added bu headers to all the libged files that included mater.h and didn't include bu.h - still complaining about bu_vls_trunk |
| 02:09.20 | starseeker | bu_vls_trunc rather |
| 02:23.17 | starseeker | ah, wait a minute |
| 02:35.09 | Notify | 03BRL-CAD:starseeker * 60054 (brlcad/trunk/include/bu/avs.h brlcad/trunk/include/bu/bitv.h and 20 others): Turns out the __BEGIN_DECLS and __END_DECLS statements really do matter. |
| 02:45.16 | brlcad | starseeker: it doesn't know that they're missing, assumes you're going to link in the symbol later |
| 02:46.15 | brlcad | the compiler only warns when the implicit default type (int) conflicts with how it's being used and most of the bu functions return an int |
| 03:23.07 | starseeker | nods - I needed the BEGIN_DECLS/END_DECLS wrappers. Didn't tidy them up initially, should have |
| 03:40.18 | brlcad | yeah, that demangles the name for C++ linkage |
| 03:45.54 | Notify | 03BRL-CAD Wiki:Sean * 6535 /wiki/Google_Summer_of_Code/Project_Ideas: /* Infrastructure */ |
| 03:49.31 | Notify | 03BRL-CAD Wiki:Sean * 6536 /wiki/Google_Summer_of_Code/Project_Ideas: /* Web Development */ |
| 03:54.08 | Notify | 03BRL-CAD Wiki:Sean * 6537 /wiki/Google_Summer_of_Code/Project_Ideas: /* Infrastructure */ PCL |
| 03:58.10 | Notify | 03BRL-CAD:starseeker * 60055 (brlcad/trunk/include/mater.h brlcad/trunk/include/nmg.h and 145 others): Get bu.h out of (most of) the toplevel include headers. Still a ton of individual files including bu.h, but it's a start. |
| 03:58.57 | Notify | 03BRL-CAD Wiki:Sean * 6538 /wiki/Google_Summer_of_Code/Project_Ideas: /* Infrastructure */ annotations |
| 04:58.25 | Notify | 03BRL-CAD:starseeker * 60056 (brlcad/trunk/src/librt/attributes.c brlcad/trunk/src/librt/bbox.c and 45 others): remove bu.h inclusions from librt. Right now these files are getting a lot of libbu from raytrace.h - when that header is broken out, it is likely that there will be more specific bu inclusions for most of these files. |
| 05:07.24 | Notify | 03BRL-CAD:starseeker * 60057 (brlcad/trunk/src/libged/adc.c brlcad/trunk/src/libged/analyze.c and 38 others): remove bu.h inclusions from libged files. Similar to librt - getting a lot from headers currently, but will boil down as they are broken up. |
| 05:16.02 | Notify | 03BRL-CAD:starseeker * 60058 (brlcad/trunk/src/adrt/isst_tcltk.c brlcad/trunk/src/adrt/librender/camera.c and 19 others): Remove bu.h inclusions from adrt. |
| 05:21.33 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 06:51.17 | Notify | 03BRL-CAD:brlcad * 60059 brlcad/trunk/include/bu/file.h: lost this include when moved interface to bu/ subdir. necessary for the dynamic loader symbols, used in liboptical and elsewhere. |
| 06:53.00 | *** join/#brlcad deepak (~chatzilla@202.164.53.117) |
| 06:53.09 | Notify | 03BRL-CAD:brlcad * 60060 brlcad/trunk/include/bio.h: stub in an empty setmode() call for non-windows platforms. this lets the code blend in seamlessly in the calling code while providing the functionality needed on windows. |
| 06:56.40 | Notify | 03BRL-CAD:brlcad * 60061 brlcad/trunk/src/librtserver/rtserver.c: missing bu/cv.h |
| 07:06.28 | *** join/#brlcad deepak (~chatzilla@202.164.53.117) |
| 07:07.02 | Notify | 03BRL-CAD:brlcad * 60062 brlcad/trunk/include/rtserver.h: there's a bu_vlb used in the interface here |
| 07:11.18 | Notify | 03BRL-CAD:brlcad * 60063 (brlcad/trunk/src/conv/asc/asc2pix.c brlcad/trunk/src/conv/asc/g2asc.c and 28 others): fix regression test breakage introduced in 60016 (can no longer introduce new _WIN32's) by eliminating all of the WIN32 blocks around setmode() calls. we can just make that function a no-op for now, but might consider a bu_setmode_binary() or similar if it causes confusion. for now, go with the simplest |
| 07:11.20 | Notify | solution. eliminates 30 of them. |
| 07:41.24 | Notify | 03BRL-CAD:brlcad * 60064 brlcad/trunk/regress/repository.sh: the platform symbol checks were not finding symbols that were at the start or end of lines and were apparently not checking for _WIN32 and _WIN64 at all. detecting our existing raises our count to an even 200 |
| 07:45.17 | Notify | 03BRL-CAD:brlcad * 60065 brlcad/trunk/src/conv/dxf/g-dxf.c: save all files, removed _WIN32 wrappage |
| 08:07.26 | *** join/#brlcad _zxq9_ (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) |
| 09:00.57 | *** join/#brlcad harmanpreet (~harman@198.199.108.236) |
| 09:00.57 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 09:12.52 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/session) |
| 09:12.52 | *** join/#brlcad witness___ (uid10044@gateway/web/irccloud.com/x-qcbejwnrfjcrylkt) |
| 11:29.58 | *** join/#brlcad teepee_ (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 11:40.10 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 11:52.56 | *** join/#brlcad ankesh11_ (sid8015@gateway/web/irccloud.com/x-myznsqzxfyjeghiu) |
| 11:56.54 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 11:58.00 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 12:06.47 | *** join/#brlcad yizhen_ (~yizhen@c-98-206-167-91.hsd1.il.comcast.net) |
| 12:33.09 | *** join/#brlcad ries (~ries@190.9.171.121) |
| 12:34.26 | Notify | 03BRL-CAD:n_reed * 60066 brlcad/trunk/src/libbrep/intersect.cpp: fix my less than correct comments |
| 13:42.31 | Notify | 03BRL-CAD:n_reed * 60067 brlcad/trunk/src/libbrep/intersect.cpp: move duplicated Subsurface subdivision code to separate function |
| 14:15.46 | *** join/#brlcad rotad (~user@unaffiliated/rotad) |
| 14:25.47 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 14:34.14 | *** join/#brlcad hoiji (~hoiji@117.201.93.118) |
| 14:36.38 | Notify | 03BRL-CAD:carlmoore * 60068 brlcad/trunk/src/libdm/dm-ogl.c: remove trailing blank/tab |
| 15:14.16 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:46.10 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:48.20 | Notify | 03BRL-CAD:n_reed * 60069 brlcad/trunk/src/libbrep/intersect.cpp: use suffix to distinguish surface A/B parameters instead of uv/st convention |
| 17:04.28 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 17:11.29 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 17:13.52 | *** join/#brlcad FreezingAlt (~FreezingC@135.0.41.14) |
| 17:19.00 | Notify | 03BRL-CAD:starseeker * 60070 (brlcad/trunk/include/dm/dm-ogl.h brlcad/trunk/include/dm/dm-osg.h and 16 others): Start setting up to allow setting a log file for display manager debugging output. |
| 17:32.33 | *** join/#brlcad teepee_ (5084559b@gateway/web/freenode/ip.80.132.85.155) |
| 18:24.18 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 18:41.47 | *** join/#brlcad javampire (~ncsaba@p4FF75642.dip0.t-ipconnect.de) |
| 19:28.33 | *** join/#brlcad FreezingAlt (~FreezingC@205.211.50.163) |
| 20:40.00 | *** join/#brlcad javampire (~ncsaba@p4FF75642.dip0.t-ipconnect.de) |
| 20:40.48 | javampire | anybody around experienced in libdm ? |
| 20:41.49 | javampire | I would like to try to wrap it from python-brlcad, and I wonder how much of setup-work I need to do before it could display anything |
| 20:42.32 | javampire | I'm not even sure I understand what it does at all - the documentation in dm.h is pretty thin |
| 20:43.02 | *** join/#brlcad KimK (~Kim__@ip24-255-223-153.ks.ks.cox.net) |
| 20:56.31 | *** join/#brlcad merzo (~merzo@139-2-133-95.pool.ukrtel.net) |
| 21:10.03 | javampire | after some code checking seems the better bet would be to wrap libged, and simply attach a display manager using that... |
| 21:21.47 | *** join/#brlcad ushoroh (~ushoroh@193.105.245.158) |
| 21:43.00 | javampire | ok, I managed to open a geometry file using libged in python, it was actually much easier than I thought - but I see now that the "mged_attach" function is not defined publicly in a header file |
| 21:43.48 | javampire | I guess it is still in the library so I probably will be able to call it if I insist, but I wonder what is the reason why it is not published ? |
| 21:44.27 | javampire | or perhaps I'm mistaken and it is really not in libged ? |
| 21:47.13 | brlcad | javampire: howdy |
| 21:47.36 | brlcad | javampire: we were just talking about libdm for the past couple hours ... heh |
| 21:47.48 | brlcad | I wouldn't suggest wrapping it just yet since we plan on changing it |
| 21:47.59 | brlcad | libged is where the money is at |
| 21:48.15 | javampire | brlcad: hi Sean |
| 21:48.16 | brlcad | that's basically 99% of our command API |
| 21:48.35 | javampire | yep, I see now, but I thought it's much harder to do the wrapping |
| 21:48.49 | javampire | there were so many functions in it that I missed the open call :-) |
| 21:49.00 | brlcad | it's probably the easiest lib we have :) |
| 21:49.12 | brlcad | they're nearly all ged_command(int ac, char *av[]); |
| 21:49.39 | brlcad | (they should all be that except for open/close ... some turds to clean up) |
| 21:49.44 | javampire | yes, but for me right now the most important thing would be to actually display something |
| 21:49.57 | brlcad | ahh, yes |
| 21:50.17 | javampire | so even if I need to rewrite it twice, I would prefer to do that |
| 21:50.33 | brlcad | well you could wrap the libdm bits for that, or wrap some more abstract "gimmie data" interface and display it yourself |
| 21:51.12 | brlcad | keep in mind that you can change our APIs if some change or improvement makes it easier for you to use it |
| 21:51.28 | brlcad | they aren't set in stone, so don't feel you have to work around something if you see a wart |
| 21:51.32 | brlcad | we can burn those suckers off |
| 21:51.58 | javampire | well I would have been real happy if the attach command would have worked :-) |
| 21:53.08 | javampire | but I could just do that directly in python I guess, and do whatever the attach command does |
| 21:53.19 | brlcad | attach isn't in libged, right? |
| 21:53.26 | javampire | well I think not |
| 21:53.34 | brlcad | pretty sure it's not |
| 21:53.47 | javampire | and it's likely because it would mean depending on dm |
| 21:53.51 | brlcad | interesting idea, but that is very "front-end" specific |
| 21:54.15 | brlcad | yeah, it's not supposed to be dependent upon dm .. it's a command library |
| 21:54.19 | javampire | well what is dm anyway ? |
| 21:54.30 | brlcad | display management library |
| 21:54.45 | javampire | it's the display where the wire-frames are shown, or something else ? |
| 21:54.59 | javampire | is it the menus too ? |
| 21:55.08 | javampire | it's hard to tell from the library code :-) |
| 21:55.17 | javampire | I mean from the headers |
| 21:55.18 | brlcad | manages the notion of a "display" which is usuallya window+graphics context, but can be any context including things like a network socket or a plot file |
| 21:55.31 | brlcad | not the menus |
| 21:55.35 | javampire | ok, but what is it doing ? |
| 21:55.38 | brlcad | just the graphics portions |
| 21:55.52 | javampire | so if I say Zip in ged, what will it do ? |
| 21:55.59 | brlcad | for mged, it's the black window where geometry is drawn |
| 21:56.04 | javampire | it needs an attached display I guess, and will clear it ? |
| 21:56.14 | brlcad | Zap |
| 21:56.22 | javampire | zap, sorry :-) |
| 21:56.25 | brlcad | zip won't do anything ;) |
| 21:56.56 | brlcad | libged does keep track of what needs to be drawn, the data being drawn |
| 21:57.02 | javampire | well that's exactly what I need currently, to select something using ged, then display it |
| 21:57.06 | brlcad | so you can "draw object" in libged |
| 21:57.26 | brlcad | and it'll load the geometry wireframes or polygons or whatever defined for draw |
| 21:57.46 | brlcad | the application (mged) then takes that data and tells libdm to draw it |
| 21:58.11 | javampire | ok, but libged is then not aware of the display manager at all ? |
| 21:58.16 | brlcad | so you could probably do something similar |
| 21:58.22 | brlcad | it's not supposed to be |
| 21:58.41 | javampire | ok, now I start to see how it works |
| 21:58.51 | brlcad | I believe one or two commands cheat and talk to libdm directly (e.g., "screenshot"), but they need to burn in hell |
| 21:58.59 | javampire | so libged is simply keeping a list of objects, and mged passes that on dm ? |
| 21:59.07 | brlcad | basically |
| 21:59.10 | javampire | aha |
| 21:59.34 | javampire | ok, so I would need to rewrite that part in python then, right ? |
| 21:59.58 | brlcad | yeah, I could see you doing something cool with a pygame context or something |
| 22:00.19 | javampire | hmm, I would need to check pygame for that |
| 22:00.22 | brlcad | in fact, you could try bypassing libdm for a first test |
| 22:00.31 | brlcad | just |
| 22:00.49 | brlcad | "draw sphere", pull the data out of the struct ged, and pass it to pygame (or whatever) |
| 22:00.57 | javampire | aha |
| 22:01.12 | brlcad | "pull the data out" might be oversimplifying |
| 22:01.26 | brlcad | it's been a while since I've seen where/how that is all currently stashed |
| 22:01.36 | javampire | ok, I will investigate what's easier, using libdm or some python lib... |
| 22:01.47 | brlcad | it was originally very simple with a clean design, but it grew and grew as commands got migrated |
| 22:02.10 | javampire | well I will start with attach.c and find the rest too :-) |
| 22:02.33 | brlcad | libdm is certainly not hard .. we have examples bound through Tcl, C, and Java |
| 22:02.57 | javampire | hmm, where should I look for the Java examples ? |
| 22:03.08 | javampire | that's something I will navigate easier |
| 22:03.21 | brlcad | knew you'd ask about that one |
| 22:03.26 | javampire | :-) |
| 22:03.28 | brlcad | can't share that one, not mine to share |
| 22:03.33 | javampire | ok |
| 22:03.46 | brlcad | but it does exist and was reportedly very easy (just a day or something) |
| 22:03.55 | javampire | ok |
| 22:04.50 | javampire | brlcad: thanks for the help, I think I have enough to do for the next week :-) |
| 22:05.16 | brlcad | haha, no problem |
| 22:05.24 | brlcad | love to hear the progress :) |
| 22:05.50 | javampire | well I hope it will actually be useful/used |
| 22:06.33 | javampire | I plan to implement that "sweep" thing, it is a nice challange :-) |
| 22:06.49 | brlcad | wow awesome |
| 22:06.53 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 22:07.35 | brlcad | let me know how i can help.. primitives are a specialty ;) |
| 22:07.42 | javampire | on the python side I will also do some experiments with constraint based geometry building - but that's a bit more complex in the sense it is not yet clear to me either how I want it to work :-) |
| 22:07.50 | brlcad | that's a doosey, but doable |
| 22:08.12 | brlcad | you could help work on implementing constraints in our core |
| 22:08.34 | brlcad | there's a fair bit written up in our todo file |
| 22:08.44 | javampire | well I have some initial thoughts (related the sweep) which on second thought are not enough, but I will come up with a complete specification including algorithms |
| 22:09.24 | javampire | related the constraints - I will want to do some actual geometry examples using it and that way refine the ideas |
| 22:09.43 | javampire | that's why python is better, I can easily write some throw-away code |
| 22:09.44 | brlcad | you could aleways cheat and tessellate a sweep parametrically on the fly (ala openscad/blender) |
| 22:10.01 | javampire | nope, I want it analytically solved |
| 22:10.10 | javampire | it must be possible |
| 22:10.15 | brlcad | implementing ray evaluation for sweep is whats hard |
| 22:10.45 | brlcad | at least iyou keep it in an implicit form |
| 22:10.57 | brlcad | s/iyou/if you/ |
| 22:10.59 | javampire | yes, I know, but if well defined then the ray can be projected as an analytical shape on the plane of the sketch |
| 22:11.10 | javampire | for each segment of the path |
| 22:11.23 | brlcad | assuming you only support sweeping sketches.. ;) |
| 22:11.41 | javampire | yes, but you can always reduce a shape to it's projection on a plane |
| 22:11.49 | javampire | then sweep that, and fix endings |
| 22:11.55 | brlcad | true.. yet another project! |
| 22:12.09 | teepee | just heard openscad and wonders now what sweep is |
| 22:12.32 | brlcad | sweeping a shape |
| 22:12.51 | javampire | anyway, the problem with 3D paths is that the orientation of the sketch related to the path is not well defined |
| 22:12.53 | *** join/#brlcad FreezingAlt (~FreezingC@135.0.41.14) |
| 22:13.07 | brlcad | basically a generalized extrusion along a path parametrically |
| 22:13.45 | javampire | the plane normal can always be well defined in terms of the path tangent, but then you can rotate the sketch around that normal and there's no "natural" default orientation |
| 22:13.52 | teepee | sounds a bit like the thing I'm thinking about https://github.com/openscad/openscad/wiki/OEP1%3A-Generalized-extrusion-module |
| 22:14.02 | brlcad | path in 3D that might twist and turn, shape might scale/rotate as its translated along the path |
| 22:14.16 | javampire | yes, but what is angle 0 ? |
| 22:14.20 | javampire | for the twist |
| 22:16.24 | javampire | for a 2D path it's easy, you take the angle 0 vector as the normal to the tangent in the plane of the path |
| 22:16.48 | javampire | but for a 3D path there's no natural 0 plane |
| 22:18.30 | javampire | also you can't reliably set one arbitrary plane or direction as reference, as the tangent could always just be parallel with that one |
| 22:18.50 | brlcad | could always take tangent to the path and treat the up vector as your basis |
| 22:19.02 | javampire | and what if the tangent show up ? |
| 22:19.16 | brlcad | then allow transformsa relative to that orientation |
| 22:19.54 | javampire | no, the tangent shows up, reference vector is up, now the sketch can again rotate around the up vector without a deterministic position |
| 22:21.02 | javampire | ok, it's somewhat hard to explain without drawing it |
| 22:21.19 | brlcad | could pick you next axis for that case |
| 22:21.30 | javampire | yes, but it's then all jumpy |
| 22:21.36 | brlcad | its the gimble lock problem |
| 22:21.49 | javampire | one point has the sketch in this orientation, the next one could have it all different |
| 22:23.09 | javampire | BTW, if the algorithm defines a good "Sweepable" interface, it doesn't need to be a sketch, could be any function |
| 22:23.30 | javampire | I only expect it will need to be a 2D structure |
| 22:23.40 | javampire | otherwise the algorithm gets too complex |
| 22:23.55 | brlcad | you're still starting with an object and a path, and transformations along that path (probably parametric) |
| 22:24.19 | javampire | hmm, I wouldn't do it that way |
| 22:24.22 | brlcad | so while you might not know your orientation at a given position directly, you can infer it from the starting point parametrically |
| 22:25.05 | brlcad | i.e., any 't' value along the path also feeds into your parametric deformation(s) |
| 22:25.24 | brlcad | so you can transform the object as described |
| 22:25.25 | javampire | I would project the ray on the sketch plane |
| 22:25.45 | javampire | considering the plane trajectory based on the path |
| 22:26.02 | javampire | I didn't do the math, but it should be some transformation of the ray based on the path |
| 22:26.35 | javampire | then intersect the transformed ray with the sketch |
| 22:26.39 | javampire | then transform back |
| 22:26.41 | brlcad | well, look forward to seeing what you come up with ;) |
| 22:27.14 | javampire | if I figure it out with this "twist" |
| 22:27.18 | brlcad | especially if it can handle scale/rotate (translate?) along the path |
| 22:27.30 | javampire | well it could |
| 22:27.42 | brlcad | rotate with 3D seems considerably harder |
| 22:27.53 | brlcad | presuming you allow more than planar rotation |
| 22:28.02 | javampire | not sure, the maths are similar |
| 22:28.15 | javampire | only it needs to be well defined |
| 22:28.54 | brlcad | extracting a brep from this is going to be a trick too :) |
| 22:29.03 | brlcad | polys, not so hard |
| 22:29.43 | brlcad | gotta run ttyl! |
| 22:30.52 | *** join/#brlcad javampire_ (~ncsaba@p4FF75642.dip0.t-ipconnect.de) |
| 22:31.08 | javampire_ | sorry, was disconnected |
| 22:31.34 | javampire_ | in any case, I think once the problem is well defined, it can be solved |
| 22:32.16 | javampire_ | the twist could be possibly defined based on some kind of continuity requirement |
| 22:32.34 | javampire_ | I will think about it, but it's for later |
| 22:33.06 | javampire_ | right now I want to get python-brlcad up with ged and dm... |
| 22:33.23 | javampire_ | ok, I'll leave now, late here - see you ! |
| 23:33.01 | ``Erik | http://cmorse.org/missiongen/ semi-random mission statement generator |
| 23:52.53 | Notify | 03BRL-CAD:starseeker * 60071 brlcad/trunk/src/libbu/fchmod.c: fchmod.c needs bu/str.h on Windows |