| 00:11.46 | CIA-22 | BRL-CAD: 03pacman87 * r31851 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: upgrade revolve's wireframe to show lines added to close open sketches |
| 00:30.14 | *** join/#brlcad jonored (n=jonored@c-24-34-212-39.hsd1.ma.comcast.net) |
| 00:35.51 | *** join/#brlcad prasad1 (n=psilva@static-70-108-244-218.res.east.verizon.net) |
| 00:54.31 | jonored | So, I've been trying for a while and not managing to work out how to invoke an external editor on a temporary file and read the revised file back with tcl in mged... I seem to have it either manage reading the file back, or invoking vim, not both. It seems like nothing after the external command gets run. Am I misunderstanding exec / is there a wait command I should be using? |
| 00:57.38 | pacman87 | ...bash doesnt do so well parsing mged commands :( |
| 00:59.26 | jonored | ...? I'm using open, puts, etc. to write to a file in /tmp, then "exec xterm -e vim <tempfile>", then trying to read it back in the same way I wrote it... |
| 01:00.15 | pacman87 | jonored: can you use g2asc and asc2g instead? |
| 01:02.01 | jonored | I'm trying to write myself a command similar to ted for attributes. |
| 01:06.20 | pacman87 | wireframes look good for (-) sided sketches, (-1,-1) to (1,1) : https://webspace.utexas.edu/trv82/www/rev_wf07.png |
| 01:06.44 | pacman87 | shot() still needs logic work |
| 01:21.14 | CIA-22 | BRL-CAD: 03pacman87 * r31852 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: rearrange plot() to avoid a second calloc(), and remember to free allocated memory |
| 01:27.53 | pacman87 | wishes his first programming class wasn't in java - bad memory management habits |
| 01:29.42 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 02:30.12 | *** join/#brlcad jonored (n=jonored@c-24-34-212-39.hsd1.ma.comcast.net) |
| 02:58.54 | CIA-22 | BRL-CAD: 03andrecastelo * r31853 10/brlcad/trunk/src/librt/namegen.c: Moved declarations to the beginning of the parse_obj_name() function. |
| 03:00.41 | CIA-22 | BRL-CAD: 03andrecastelo * r31854 10/brlcad/trunk/misc/win32-msvc9/librt/librt.vcproj: Added librt/namegen.c to the MSVC 9 build. |
| 03:12.42 | *** join/#brlcad andre|away_ (n=chatzill@189.71.12.88) |
| 03:40.32 | *** part/#brlcad jonored (n=jonored@c-24-34-212-39.hsd1.ma.comcast.net) |
| 03:48.47 | *** join/#brlcad Ralith (n=chatzill@216.162.199.202) |
| 03:56.12 | *** join/#brlcad Ralith (n=chatzill@216.162.199.202) |
| 03:58.13 | *** join/#brlcad starseeker_ (n=CY@c-68-33-217-173.hsd1.md.comcast.net) |
| 03:58.20 | starseeker_ | scowls at comcast |
| 03:59.32 | poolio | starseeker_: I was out for ~6hours today |
| 03:59.50 | starseeker_ | It doesn't like my ssh connection to bz |
| 04:00.12 | starseeker_ | slow, and keeps getting reset - wonder if they're doing some *ahem* traffic management |
| 04:01.12 | Axman6 | didn't the FCC just get pissed at comcast for doing that? |
| 04:01.27 | Ralith | yep |
| 04:01.31 | Ralith | starseeker_: they do that for me, too :/ |
| 04:02.23 | starseeker_ | grr |
| 04:04.46 | starseeker_ | wants verizon fios... |
| 04:05.24 | poolio | Hmm, I might have to hack mged's WM_NAME |
| 04:05.26 | poolio | It's making my WM unhappy |
| 04:07.16 | poolio | Ah there we go....Toplevel worked. |
| 04:07.30 | poolio | starseeker_: Isn't FIOS similarly priced to comcast? |
| 04:08.35 | Ralith | poolio: not available most places |
| 04:10.19 | starseeker_ | dunno. Doubt this particular apartment would support it - it was hard enough to get cable here |
| 04:38.55 | andre|away_ | hey starseeker_, i added librt/namegen.c to the msvc9 build, is there a problem? |
| 04:39.37 | starseeker_ | uh, that's not ready |
| 04:39.43 | starseeker_ | or functional |
| 04:40.24 | starseeker_ | I'd recommend ignoring it until something actually uses it |
| 04:41.00 | andre|away_ | hm sounds better |
| 05:07.34 | CIA-22 | BRL-CAD: 03andrecastelo * r31855 10/brlcad/trunk/misc/win32-msvc9/librt/librt.vcproj: Removed namegen.c from librt.vcproj until it's used by something. |
| 05:49.34 | *** join/#brlcad clock_ (n=clock@217-162-111-228.dclient.hispeed.ch) |
| 06:06.03 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) |
| 06:25.37 | *** join/#brlcad PrezKennedy (n=Matthew@whitecalf.net) |
| 07:00.58 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) |
| 07:04.08 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) |
| 08:36.40 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 09:12.25 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 09:13.21 | mafm | hi |
| 09:58.26 | brlcad | howdy mafm |
| 10:00.33 | mafm | happier than usual |
| 10:00.40 | mafm | now I must devote to my fans \o/ |
| 10:01.20 | brlcad | hehe |
| 10:01.41 | *** mode/#brlcad [+o brlcad] by ChanServ |
| 10:03.23 | mafm | sending a patch of 1043 lines... |
| 10:03.39 | CIA-22 | BRL-CAD: 03mafm * r31856 10/rt^3/trunk/src/g3d/ (7 files): |
| 10:03.39 | CIA-22 | BRL-CAD: Many pending commits due to SourceForge downtime, cannot be separated now: |
| 10:03.39 | CIA-22 | BRL-CAD: Important increase in functionality of CameraMode base class to allow for the |
| 10:03.39 | CIA-22 | BRL-CAD: now more complex derived camera modes, including managing their own input |
| 10:03.39 | CIA-22 | BRL-CAD: bindings; implemented Blender camera mode including mouse drag mode for free |
| 10:03.42 | CIA-22 | BRL-CAD: camera rotations; fixed parts of input handling which were still immature |
| 10:03.44 | CIA-22 | BRL-CAD: (traping events when they shouldn't, etc). |
| 10:04.12 | mafm | done. |
| 10:04.25 | brlcad | bets some separation could have occurred, but good enough |
| 10:04.43 | mafm | btw, what happened with the feedback of middle term evaluation? |
| 10:05.16 | brlcad | i'm going down the list, some have happened, some still to go |
| 10:05.49 | mafm | hmm, it's because it was intermixed: the application main input handlers inject cameramanager with input, then it feed the active camera mode; which has also the new camera modes; etc |
| 10:12.30 | mafm | and mostly I didn't bother because probably the code is to be changed massively anyway :D |
| 10:19.30 | brlcad | hence the good enough |
| 10:20.09 | brlcad | there's almost always some way to break things up, it's one of the things I do rather frequently/well ;) |
| 10:20.48 | brlcad | the message is still informative and concise |
| 10:21.01 | brlcad | so nbd |
| 10:21.38 | mafm | about the acount in brlcad? |
| 10:22.14 | mafm | what was the missing part, state explicitly to accept the conditions |
| 10:23.36 | brlcad | yep |
| 10:39.01 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 10:46.24 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 11:20.26 | Axman6 | http://yaws.hyber.org/contact.yaws |
| 11:20.29 | Axman6 | whoops |
| 11:42.44 | CIA-22 | BRL-CAD: 03bob1961 * r31857 10/brlcad/trunk/ (29 files in 4 dirs): |
| 11:42.44 | CIA-22 | BRL-CAD: Added the following commands to libged: isize, keypoint, lookat, m2v_point, |
| 11:42.44 | CIA-22 | BRL-CAD: model2view, orient, perspective, pmat, pmodel2view, pov, rmat, rot_point, |
| 11:42.44 | CIA-22 | BRL-CAD: rotate_about, scale, setview, v2m_point, view2model, viewdir, c, cat, color and |
| 11:42.44 | CIA-22 | BRL-CAD: prcolor. |
| 11:58.01 | CIA-22 | BRL-CAD: 03bob1961 * r31858 10/brlcad/trunk/src/libged/ (perspective.c rmat.c): Initial check-in. |
| 11:59.33 | *** join/#brlcad saltan (n=lievensa@d51530284.access.telenet.be) |
| 12:04.10 | *** join/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 12:06.25 | starseeker_ | scolds the European Union politicians for more silly copyright ideas |
| 12:06.38 | starseeker_ | (not that ours don't have plenty...) |
| 12:23.44 | *** join/#brlcad cad28 (n=4684e06a@bz.bzflag.bz) |
| 12:23.48 | *** part/#brlcad cad28 (n=4684e06a@bz.bzflag.bz) |
| 12:38.02 | *** join/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 12:38.58 | *** part/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 12:53.54 | *** join/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 12:54.23 | *** join/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 12:54.38 | *** join/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 13:02.30 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 13:07.14 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 13:12.00 | mafm | hi again |
| 13:12.11 | mafm | network outages down here :S |
| 13:25.27 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 13:51.31 | thing1 | *ywan* |
| 13:56.31 | *** join/#brlcad docelic (n=docelic@78.134.204.53) |
| 14:46.47 | mafm | brlcad: internal classes a no-no? |
| 14:56.21 | *** part/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 15:28.12 | CIA-22 | BRL-CAD: 03homovulgaris * r31859 10/brlcad/trunk/ (include/raytrace.h src/libpc/pc_test.c): Modification to pc_param and pc_constrnt structs in particular removal of character arrays and usage of bu_vls for supporting expression of the form "radius=3.24" for parameters and "radius*centre.x=4.0" for constraints |
| 15:30.10 | ``Erik | brlcad: your team leader is taking abuse for your slides, save him! :D also; I has me a couple shiney new sun machines |
| 15:39.02 | CIA-22 | BRL-CAD: 03homovulgaris * r31860 10/brlcad/trunk/ (include/pc.h src/libpc/pc_main.c): |
| 15:39.02 | CIA-22 | BRL-CAD: modification of macros to initiate the bu_vls struct added to pc_param and |
| 15:39.02 | CIA-22 | BRL-CAD: pc_constrnt; definition of pc_free_pcset, pc_pushparameter and pc_pushconstraint |
| 15:39.02 | CIA-22 | BRL-CAD: functions for adding parameters and constraints to pc_pc_set using a simple |
| 15:39.02 | CIA-22 | BRL-CAD: string expression |
| 15:49.10 | CIA-22 | BRL-CAD: 03mafm * r31861 10/rt^3/trunk/src/g3d/ (CameraModes.cxx CameraModes.h): Basically completing Blender camera mode, and factoring out more functionality in the base class (now basically the different modes act only on input, defining the bindings) |
| 16:06.49 | CIA-22 | BRL-CAD: 03homovulgaris * r31862 10/brlcad/trunk/src/libpc/solver_test.cpp: quasi-detailed definition of constraint and variable expression grammars, and testing the usage of bu_vls for passing information to the Parser object |
| 16:09.26 | *** join/#brlcad jonored (n=jonored@c-24-34-212-39.hsd1.ma.comcast.net) |
| 16:14.42 | CIA-22 | BRL-CAD: 03homovulgaris * r31863 10/brlcad/trunk/src/libpc/pcParser.h: quasi-detailed definition of constraint and variable expression grammars, and testing the usage of bu_vls for passing information to the Parser object. sorry about 31862 accidental -m |
| 16:21.22 | CIA-22 | BRL-CAD: 03homovulgaris * r31864 10/brlcad/trunk/src/libpc/ (Makefile.am pc_constraint.h pc_solver.cpp): Removal of obsolete/empty files |
| 16:37.12 | CIA-22 | BRL-CAD: 03mafm * r31865 10/rt^3/trunk/src/g3d/ (CameraModes.cxx CameraModes.h): Adjustments to the implementation for better compliance and maintainability, and copying better Blender mode. |
| 16:42.42 | brlcad | mafm: why do you ask? |
| 16:58.21 | mafm | I created one Vector3 :P |
| 17:01.10 | ``Erik | heh, starseeker, http://thedailywtf.com/Articles/28-(Around-Going).aspx |
| 17:02.27 | starseeker | Heh |
| 17:03.27 | jonored | Oif. |
| 17:03.34 | brlcad | mafm: ah, well in general I would have said it's fine -- for that one, for vector/matrix structures, it should probably use what is already provided |
| 17:04.14 | mafm | I just want to hold together 3 floats, no operations |
| 17:04.33 | brlcad | you hadn't had the need yet so I hadn't said much, but you should utilize the mainline brl-cad libs when they have functionality you need (libbu, libbn, librt in particular) |
| 17:04.47 | mafm | http://rafb.net/p/Zm93t624.html |
| 17:05.50 | ``Erik | hum, how is that, uh, different than, say, the vector in vmath.h ? :D |
| 17:05.53 | mafm | I was considering using Ogre::Vector3 because it's going to be assigned as such, eventually |
| 17:06.11 | mafm | what's vmath.h? |
| 17:06.23 | ``Erik | file in brlcad's include dir |
| 17:06.39 | brlcad | don't really want to expose ogre's data types, encapsulated at best, avoided if possible |
| 17:07.23 | ``Erik | (is BRL-CAD not a requirement for the new rt^3 shtuff?) |
| 17:07.23 | brlcad | vmath.h is part of libbn, vect_t is basically the same as your Vector3 |
| 17:07.53 | mafm | ``Erik: it would be eventually, but not yet |
| 17:08.28 | brlcad | why "not yet" .. sounds like you have a need now ;) |
| 17:09.30 | mafm | well, after I finish with cameras the main thing left is to use the remote library, so it would be needed soon enough |
| 17:10.26 | brlcad | remember that the (only) reason you're off in a different directly is for language/api separation, that doesn't mean it shouldn't utilize what it would have available if it were in brlcad/src/g3d |
| 17:10.27 | mafm | and by "no yet" I just mean that I don't use it |
| 17:11.03 | mafm | well, but apart from PI_NUMBER, it's the first thing that I feel need for |
| 17:11.18 | mafm | not that I don't want to use anything from BRL-CAD, is that I didn't need it yet :D |
| 17:14.52 | Ralith | other than vect_t. |
| 17:15.54 | mafm | that emerged just now, it doesn't count :P |
| 17:17.56 | brlcad | mafm: sure, and it's not a huge deal for a tiny Vector3 class .. but even that lil snippet becomes dead/wrong code that has to get fixed eventually -- less cost if dealt with early |
| 17:26.42 | *** join/#brlcad cad56 (n=c8b8820a@bz.bzflag.bz) |
| 17:26.43 | mafm | I already put a doxygen \todo, but anyway after I make the shift-grips mode (and I guess that it would take about 1 day) I'll start to look into using the geometry service |
| 17:27.17 | mafm | btw I don't know if tomorrow I'm going to be available because they need to exchange router and many things in the network |
| 17:27.26 | brlcad | libged at this point, not via the service |
| 17:27.36 | brlcad | but cool either way |
| 17:27.38 | Ralith | mafm: I'm pretty sure you don't even need to link with anything in this case. |
| 17:27.43 | mafm | but if not, it would be by the beginning of next week |
| 17:28.16 | mafm | doesn't libged incoporate the remote service? |
| 17:28.34 | brlcad | the service sits on top of libged |
| 17:29.00 | mafm | and libged doesn't include network abstractions yet? |
| 17:29.23 | brlcad | but the service isn't ready for use just yet (the dev is still documenting and sorting out protocol issues) |
| 17:30.04 | brlcad | libged won't have any network abstractions, you or me or someone would have to work on that now if you wanted to make it entirely abstracted from the start |
| 17:30.35 | brlcad | libged is basic geometry management, editing, querying .. at a command level ala mged's command line |
| 17:30.52 | brlcad | where commands like ged_e() give you wireframe data for a given object, for example |
| 17:31.41 | brlcad | that is supposed to sit underneath the geometry engine, which frankly doesn't exist yet (at least not in C++) |
| 17:32.02 | brlcad | and the geometry service makes the engine available through a port protocol interface (ala mysqld for example) |
| 17:33.38 | brlcad | there has been a dev working for several months on that layer as well as several working on the libged layer, so it's all starting to come together |
| 17:34.22 | mafm | "the geometry engine, which frankly doesn't exist yet (at least not in C++)" -- if it communicates via sockets, why does the language matters? |
| 17:35.58 | Ralith | mafm: because, at least ideally, the project includes production of a straightforward client lib so you don't have to manage the network bits yourself. |
| 17:36.22 | brlcad | the geometry engine is just an API, the geometry service provides the communication layer |
| 17:36.55 | brlcad | difference between libmysql and mysqld |
| 17:37.44 | mafm | but unless the library is written in tcl, C++ can use the C libraries directly... :) |
| 17:39.09 | brlcad | which is why I said you could start by simply hooking into libged for now (just so you have commands that you could issue on the command line and access to display list data for geometry) |
| 17:39.18 | ``Erik | rewrites the library in bf |
| 17:40.26 | brlcad | the engine itself is specifically a project in providing an OO C++ geometry processing layer similar to the ACIS or Granite engines, wrapping up our geometry processing facilities in libbu, libbn, libwdb, librt, and libged |
| 17:41.30 | mafm | so there's no "library geometry service" yet, not even in C... I though that libged would include support for this |
| 17:42.02 | mafm | anyway, I'll use that |
| 17:42.44 | brlcad | no, libged's job is very simply "perform this geometry command" |
| 17:43.00 | brlcad | massive refactoring of most of mged's command functionality into a library |
| 17:44.07 | brlcad | which amounts to moving and reworking about 100k lines of code |
| 17:45.00 | brlcad | bob's about 40% done from the looks of it (after about two months of effort) so it won't be fully complete for at least two or three more |
| 17:45.13 | brlcad | not that he needs to be complete for it to be functional, it should be usable now |
| 17:46.10 | brlcad | going on in parallel are the engine bits and the service bits |
| 17:47.35 | brlcad | Ralith: did someone review/apply your patch yet? |
| 17:47.51 | Ralith | uh, lemme check |
| 17:48.13 | brlcad | also, was it posted to the patches tracker or just in here? |
| 17:48.28 | Ralith | appears to not have been reviewed |
| 17:48.30 | Ralith | http://sourceforge.net/tracker/index.php?func=detail&aid=2019951&group_id=105292&atid=640804 |
| 17:48.53 | Ralith | also needs to upload his mocha patch |
| 17:49.09 | brlcad | k |
| 17:51.11 | mafm | did you submit it to OIS guys as well? |
| 17:52.51 | Ralith | like I said, I'm not sure it's entirely appropriate for upstream use; it's the sort of thing that really should be done in the build system, but I really have no idea how to do target-conditional config in autotools. |
| 17:53.04 | Ralith | the mocha patch, however, I have sent upstream |
| 17:53.42 | Ralith | the most that can be said for the ois patch is it's clean and it works. |
| 17:55.08 | mafm | well, OIS guys should be able to test if it's safe in other linux systems |
| 17:55.28 | mafm | btw, how did you contact mocha/rbgui guys? I couldn't contact them |
| 17:56.01 | Ralith | I would be very, very surprised if this broke other systems. |
| 17:56.06 | Ralith | Their website has a contact form :P |
| 17:56.28 | mafm | huh |
| 17:58.20 | mafm | where's that? I can't see it |
| 17:58.26 | Ralith | http://rightbraingames.com/contact.php |
| 17:58.44 | mafm | :S |
| 17:59.10 | mafm | how did you get there? their main website is a fedora apache welcome site |
| 17:59.22 | Ralith | google |
| 17:59.33 | mafm | you can enter via /tech/ but I cannot see that form from there |
| 18:00.04 | Ralith | heh, that's a completely different website |
| 18:00.09 | mafm | Forbidden |
| 18:00.10 | mafm | You don't have permission to access /contact.php |
| 18:00.28 | brlcad | Ralith: not that I like their approach, but did you see: http://sourceforge.net/tracker/index.php?func=detail&aid=1835815&group_id=149835&atid=775955 |
| 18:02.01 | brlcad | found after the reference in this thread: http://www.wreckedgames.com/forum/index.php/topic,115.0.html |
| 18:02.10 | mafm | you also can see more info from them in this site, but their forums look like quite dead :) http://www.rightbraingames.com/tech/node/40 |
| 18:03.59 | Ralith | brlcad: hm, SDL is a pretty big dep, and I don't see anything in this patch about removing the linux-specific code that was the problem in the first place |
| 18:04.43 | Ralith | there is some mention about what may be a drop-in replacement from SDL, though |
| 18:04.44 | brlcad | Ralith: yeah, that's why I didn't like it .. don't really want (or see a need for) the sdl dep just for input |
| 18:04.53 | Ralith | the only difference is joystick support |
| 18:05.09 | Ralith | SDL *may* provide it, whereas my patch will not. |
| 18:05.16 | brlcad | especially given they've already taken care of windows, linux, and are working on mac |
| 18:05.23 | brlcad | sdl does provide joystick support |
| 18:05.27 | Ralith | on FreeBSD? |
| 18:05.30 | Ralith | I'm not sure that's even possible. |
| 18:05.43 | ``Erik | I think it does, though the fbsd joystick interface changed a few years ago |
| 18:05.43 | Ralith | linux seems to have had to go out of its way to. |
| 18:06.01 | brlcad | erm, haven't tested it, but it certainly compiles our sdl joystick interface for bzflag |
| 18:06.24 | ``Erik | couldn't get his usb joystick to work with fbsd when he tried it, thinks it was due to a gimpy usb card |
| 18:06.28 | mafm | hmm, but is it also the mouse, apart from the joystick? |
| 18:06.45 | Ralith | mafm: the mouse is handled completely differently. |
| 18:06.54 | Ralith | I'm sure my patch leaves that intact. |
| 18:06.55 | brlcad | no, they provide separate events and require different processing styles |
| 18:07.24 | mafm | doesn't X.org abstract that part? |
| 18:07.38 | Ralith | X doesn't touch joysticks afaik |
| 18:07.52 | mafm | I mean the mouse part |
| 18:07.57 | Ralith | what mous epart |
| 18:08.18 | mafm | you modify LinuxMouse too |
| 18:08.21 | ``Erik | heh http://lgdc.sunsite.dk/articles/19.html :D |
| 18:08.29 | Ralith | yeah |
| 18:08.58 | Ralith | that's taken from the patch in ports |
| 18:09.17 | Ralith | it looks like it should work fine on any platform |
| 18:09.31 | Ralith | though if someone could test it out on linux that would be good |
| 18:10.03 | Ralith | ``Erik: linux 2.0. and 2.2.? :P |
| 18:10.09 | ``Erik | yeah, from 2000, dude |
| 18:10.25 | mafm | don't they have a description about why is the patch necessary at all? |
| 18:10.45 | Ralith | ``Erik: hm, I guess FreeBSD does support it. |
| 18:11.05 | Ralith | does it matter enough that I should put together a nice clean patch w/ proper joystick support? |
| 18:11.09 | Ralith | (which may be nontrivial) |
| 18:12.41 | mafm | I'd say that, whatever you might do, it's preferable to have it uptream when possible |
| 18:12.55 | Ralith | well, it's not going upstream without real support |
| 18:13.03 | Ralith | I'm not even going to try to pitch a quick fix like this :P |
| 18:13.21 | mafm | I was talking mostly about the mouse one of netbsd |
| 18:13.57 | mafm | it doesn't seem like that it's for API issues or something, but because they want to process things in different orders |
| 18:14.16 | Ralith | I'm not even sure that's necessary; it would require testing that's beyond my current means. |
| 18:14.33 | Ralith | I'd have to cobble together some sort of OIS app |
| 18:15.15 | mafm | did you try to use OIS without the changes to the mouse file? |
| 18:15.38 | mafm | or does it everything come in the same patch in freebsd, or what? |
| 18:15.42 | Ralith | like I said, I have no way to 'try' OIS. |
| 18:15.54 | Ralith | and the freebsd version of OIS uses that patch, yes. |
| 18:17.11 | mafm | http://www.wreckedgames.com/forum/index.php?action=printpage;topic=115.0 |
| 18:17.31 | mafm | "Probably would be best to create a seperate BSDInputManager than trying to hack it into the LinuxInputManager, can share the Keyboard and Mouse classes just need to make the JoyStick classes." |
| 18:17.53 | mafm | I think that it's the best solution |
| 18:18.00 | Ralith | I'm sure it is |
| 18:18.13 | mafm | without creating the joysticks at the moment |
| 18:18.14 | Ralith | my patch, however, should give us a working OIS in the meantime |
| 18:19.40 | mafm | well, that's fine... but I want you to understand me... I don't even like the idea of having libraries in src/other :P |
| 18:19.54 | mafm | much less to start maintaining private patches for them |
| 18:20.04 | Ralith | brlcad's goal of a simple, unified, build system that *just works* is laudable. |
| 18:20.11 | Ralith | such a system inevitably requires local hacks. |
| 18:20.57 | mafm | probably we'll have to do that for mocha and rbgui inevitably, and I'm even thinking about forking them and maintaining them separately... |
| 18:21.21 | Ralith | that reminds me |
| 18:21.24 | Ralith | just why did you pick rbgui? |
| 18:21.41 | mafm | because I don't like CEGUI |
| 18:21.47 | Ralith | you may not like it |
| 18:21.50 | Ralith | but CEGUI has a community |
| 18:21.57 | Ralith | you can rely on CEGUI not dissapearing and dying. |
| 18:22.11 | Ralith | rbgui, on the other hand, we can't even tell if it's maintained right now, let alone in the future. |
| 18:23.04 | mafm | according to brlcad's metric, they both would be about the same pain in the ass to maintain separately, if needed at all |
| 18:23.12 | mafm | so the choice didn't matter much :) |
| 18:23.45 | Ralith | we don't want to maintain them separately. |
| 18:23.54 | Ralith | we just want to make the build process simple. |
| 18:24.03 | Ralith | this is *easier* if somebody else is actually maintaining upstream |
| 18:25.22 | Ralith | using libs where you can't get in contact with the authors or even confirm their continued existence is a bad idea, imo. |
| 18:26.09 | mafm | yep, but I have a plan to follow, and that happened relatively late :D |
| 18:26.22 | Ralith | that doesn't justify it :P |
| 18:26.48 | Ralith | would it be helpful if I ported your existing work to CEGUI? |
| 18:27.10 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 18:27.14 | mafm | maybe not for you, but for me it's most important until gsoc finished |
| 18:27.23 | Ralith | uh |
| 18:27.26 | Ralith | was that a yes? |
| 18:27.30 | Ralith | because I'm happily offering my time here |
| 18:27.52 | Ralith | I'm just interested in seeing this poject succeed |
| 18:28.03 | brlcad | ``Erik: you might enjoy this read: http://www.gladwell.com/2004/2004_01_12_a_suv.html |
| 18:28.07 | mafm | it was a reply to "that doesn't justify it", not the second one :D |
| 18:28.11 | Ralith | using questionable software is not a good start. |
| 18:28.23 | Ralith | ah, heh |
| 18:28.30 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 18:28.33 | Ralith | well, I'm offering a solution |
| 18:28.42 | Ralith | it won't mess up your schedule any if it's my problem :P |
| 18:28.43 | mafm | and I would mind you to switch to CEGUI before gsoc finishes, yess :P |
| 18:29.00 | Ralith | you're saying that would be a problem? |
| 18:29.31 | mafm | yes, I would have to make windows in CEGUI and so on, and it's a PITA |
| 18:29.58 | mafm | I don't think that CEGUI is better than RBGui anyway :D |
| 18:30.05 | Ralith | that's not really debatable |
| 18:30.22 | mafm | be right back |
| 18:30.30 | Ralith | CEGUI is obviously and actively maintained by multiple developers who are easy to get ahold of |
| 18:31.11 | Ralith | RBGui is pretty obscure, hosted on a hard-to-access website by developer(s) who might not even be around anymore, and has no community to speak of. |
| 18:33.33 | brlcad | wonders how much effort it would take to abstract the gui portion into just one or few classes such that the backend can be rbgui, cegui or whatever |
| 18:33.44 | brlcad | without replicating everything in that library of course |
| 18:34.42 | Ralith | I think that would be more work to no particular gain; abstract we may, but in the end we'll just use a single one, and probably depend on unique features of it, even. |
| 18:34.48 | mafm | Ralith: what if you notice that CEGUI is severely limited and they don't want to add your changes? :) |
| 18:35.00 | brlcad | Ralith: in all fairness, looking at the various gui toolkits, most of them are so far away from providing the sorts of interaction styles I've had in mind that it *almost* doesn't matter which toolkit we go with -- it's going to be a fair bit of work on our part |
| 18:35.01 | Ralith | mafm: what changes? |
| 18:35.31 | Ralith | brlcad: I'm not even looking at quality of library here; my issue with rbgui is simply that it's not visibly maintained. |
| 18:35.52 | brlcad | mafm: well in that case, if we really needed some change -- it's no different than rbgui -- we'd fork and move on |
| 18:36.26 | Ralith | I suppose brlcad is of sufficient scope that doing that sort of thing really isn't out of the question. |
| 18:36.32 | mafm | brlcad: I'd say that only Gui files have code which would depend on one or the other, except from some initial instantiation |
| 18:36.42 | Ralith | in which case rbgui may well be justifiable, if the way it does things is that much more convenient. |
| 18:37.16 | mafm | brlcad: re:changes, it was speculation... but I feel the same as you do, any of is severely lacking |
| 18:37.23 | brlcad | Ralith: understood, that part really sucks about it -- I know of about 3 or 4 commercial guis that are nearly *exactly* what I'd want for our gui, but then that's not helpful.. ;) |
| 18:37.32 | Ralith | hehe |
| 18:38.16 | mafm | and the point of using RBGui was mostly to play with it, since the alternative CEGUI is well known |
| 18:38.25 | mafm | at least rbgui feels more slick |
| 18:38.41 | mafm | and it has no external dependencies I think, so that also helps |
| 18:38.52 | Ralith | well, there is mocha |
| 18:38.58 | brlcad | what I'm not going to be too compromising on is the features and interactions we need for a clean gui -- that's fairly custom as it is meaning we just need a framework that is functional enough to work in |
| 18:39.04 | Ralith | which seems like your token inhouse util lib |
| 18:39.25 | Ralith | if we're all but resigned to forking in the first place it's pretty moot. |
| 18:39.27 | brlcad | mafm: was it you that sent the link a day or two ago about the pango-based interface? |
| 18:39.58 | brlcad | Ralith: yeah, i'm sure it was *exactly* that -- a simple little lib that was developed for their game's world editor or something and they've moved on |
| 18:40.28 | brlcad | i mean, not just mocha, but rbgui itself too |
| 18:40.35 | Ralith | but if it's a good, usable, extensible lib, that's probably sufficient. |
| 18:41.02 | Ralith | I mean, we should face it; we're going to have some pretty arcane GUI requirements in this editor sooner or later, and we'll have to implement those widgets or w/e ourselves anyway. |
| 18:41.30 | Ralith | the question is if we want to add that much more software to maintain |
| 18:42.01 | brlcad | i certainly don't want to fork and don't think it's a resolved issue .. but I don't think it's one that has to be resolved today either |
| 18:42.01 | mafm | brlcad: yes |
| 18:42.08 | mafm | (wrt pango interface) |
| 18:44.14 | mafm | other than that, did you get things working, Ralith? |
| 18:44.14 | Ralith | not really |
| 18:44.15 | Ralith | rbgui depends on a function inside ogre which is no longer there in the latest version. |
| 18:44.17 | brlcad | the open source custom gui toolkit scene has been (and still is) teh suck .. it really is a shame that none of them are realy 'good' |
| 18:44.43 | Ralith | friend of mine actually has a *really* cool GUI toolkit put together, but it's in D. |
| 18:44.51 | mafm | Ralith: 1.4? you have to use either the one in src/other or trunk (but maybe it has their own problems) |
| 18:44.58 | mafm | its* |
| 18:44.59 | Ralith | mafm: 1.4.9 |
| 18:45.01 | brlcad | Ralith: I can say the one fairly fundamental problem I've had with cegui is their lack of vector support and scalable guis |
| 18:45.10 | mafm | trunk as in... 1.7.something |
| 18:45.23 | Ralith | mafm: oh, we've backported stuff from their dev code? |
| 18:45.33 | Ralith | brlcad: I'm sure it has plenty of problems, but it's active. |
| 18:45.46 | mafm | not backported: using trunk directly :D |
| 18:45.49 | brlcad | I talked to the cegui devs a while back about it and they had it on their todo but said it was a huge task given how they currently do things, and not likely to happen anytime soon |
| 18:46.24 | Ralith | mafm: what's in src/other doesn't look like trunk, it looks like 1.4.8 |
| 18:46.28 | mafm | <brlcad> the open source custom gui toolkit scene has been (and still is) teh suck .. it really is a shame that none of them are realy 'good' -- and do you say that even if there's not even a decent network library? ;) |
| 18:46.46 | brlcad | Ralith: i know, preaching to the choir .. just noting that upstream support is only one piece to consider (and not necessarily the biggest one) |
| 18:46.56 | mafm | it's trunk, really |
| 18:47.10 | mafm | and it has to be, not only me but homovulgaris got it working |
| 18:47.11 | Ralith | must be very old trunk. |
| 18:47.20 | brlcad | mafm: decent network library? there are several decent network libraries |
| 18:47.39 | Ralith | brlcad: I don't suppose we've considered using a more mainstream GUI lib like qt or gtk? |
| 18:47.49 | Ralith | I imagine there's some reason those are inappropriate? |
| 18:47.51 | brlcad | Ralith: yes |
| 18:48.00 | brlcad | they were the first things considered |
| 18:48.07 | brlcad | wrought with lots of issues |
| 18:48.11 | mafm | brlcad: s/decent/standard :D |
| 18:48.40 | mafm | Ralith: not very old, it's from may or so |
| 18:49.04 | Ralith | huh. |
| 18:49.12 | brlcad | mafm: the great thing about standards is that there are so many to choose from -- i'm not sure what standardization would get you (for this sort of project) |
| 18:49.16 | Ralith | well, I'll see about making *it* bsd happy then. |
| 18:49.41 | brlcad | we have our own net lib in brlcad that should generally be used unless there is some functional reason not to |
| 18:52.08 | mafm | brlcad: not for this project, I mean in general |
| 18:52.15 | mafm | and I wanted them in std:: :P |
| 18:52.53 | Ralith | there are networking thingies in std::. |
| 18:53.10 | brlcad | Ralith: not to get too far into it but the biggest negatives for the two big camps aside from community/dev polarization are that gtk is cross-platform dependency hell and qt is under an unfortunate license |
| 18:54.25 | Ralith | dependency hell? |
| 18:54.34 | brlcad | otherwise, qt is fairly high on the list from a features perspective |
| 18:54.46 | Ralith | actually, that's a thought |
| 18:54.46 | brlcad | yes |
| 18:55.03 | Ralith | qt has a *ton* of stuff that we wouldn't need. |
| 18:55.05 | brlcad | gtk is about as bad as it gets if you manage all dependencies |
| 18:55.13 | Ralith | that sucks. |
| 18:55.18 | Ralith | ah well, if rbgui works, then great. |
| 18:56.11 | brlcad | like I said, I don't think the gui problem is solved .. it'll more amount to how easily can a given toolkit be customized |
| 18:57.07 | ``Erik | when I was your age, we built gnome without package managers! and we liked it! |
| 18:57.07 | ``Erik | ;D |
| 18:57.18 | Ralith | hehe |
| 18:57.27 | pacman87 | ``Erik: yeah i tried that with kde4 a few weeks ago... |
| 18:58.23 | mafm | ``Erik: then the came the gentoo guys and blew you all away... :P |
| 18:59.45 | ``Erik | nah, debian got gtk into apt, freebsd added it to ports, gentoo wasn't around, ... |
| 19:00.39 | Ralith | back to an earlier note, that wreckedgames link someone pasted seems to imply that they've already got somebody solving the OIS problem cleanly |
| 19:01.19 | Ralith | so the quick fix I set up should do to hold us over for now. |
| 19:02.44 | mafm | solved it in which release? we're using 1.2.0 IIRC |
| 19:03.08 | Ralith | nobody's solved it |
| 19:03.12 | Ralith | read what I said :P |
| 19:06.17 | mafm | ah, the guy is still *solving* it? |
| 19:08.45 | Ralith | so he says. |
| 19:13.01 | mafm | do you remember the name of the guy? I can't see the one that I know in IRC at the moment |
| 19:15.05 | Ralith | Post by: AMDmi3 on June 17, 2008, 04:13:33 PM |
| 19:17.59 | mafm | the one that I know it's similar to pacman87, but now his nick is clobbering the other one :D |
| 19:18.58 | pacman87 | mafm: do you log chats? |
| 19:20.11 | mafm | nope |
| 19:20.26 | mafm | pjcast, that's it |
| 19:20.31 | mafm | not very similar after all :D |
| 19:21.15 | brlcad | three letters match :) |
| 19:22.51 | mafm | I recalled 1st letter and approximate length, just that :D |
| 19:32.10 | *** join/#brlcad clock_ (n=clock@77-56-84-80.dclient.hispeed.ch) |
| 19:35.07 | brlcad | "And the old pro said to him that people who succeed in the business are not those that are the most talented, and theyâre not the people that know the most people, but they are the people who are able to endure." |
| 19:35.15 | brlcad | that's such a good quote |
| 19:37.13 | ``Erik | I thought you were working, not reading slashdot :> |
| 19:38.33 | ``Erik | looks around for his emacs crib sheet |
| 19:39.09 | mafm | lol |
| 19:42.12 | mafm | Ralith: are you going to try with ogre trunk? |
| 19:42.28 | mafm | there was a simple patch adding a function for get it working with older versions |
| 19:42.28 | Ralith | mafm: yeah, on the wrong system right now |
| 19:42.39 | Ralith | I saw it |
| 19:42.53 | mafm | good |
| 19:43.12 | mafm | maybe I won't be able to join tomorrow and I'll probably be out the rest of the weekend |
| 19:43.36 | mafm | but you can send me a mail with your progress or doubts, if you want :) |
| 19:44.52 | Ralith | kk |
| 19:44.55 | Ralith | your email's on your userpage? |
| 19:44.57 | brlcad | dev mailing list ftw ;) |
| 19:45.04 | Ralith | should get on that |
| 19:45.27 | mafm | that too |
| 19:45.36 | brlcad | it's low traffic, but a good alternative to irc for the non-screen+irssi or simply non-irc folks |
| 19:45.53 | brlcad | at least until there's a decent forum |
| 19:46.12 | mafm | woot, I think that I got a complete Blender implementation for the basic functions |
| 19:47.01 | ``Erik | rocket racing league heh |
| 19:47.24 | Ralith | mafm: nice! sounds like you're making fast progress. |
| 19:48.18 | brlcad | mafm: cool, that should be really useful in the long run |
| 19:49.51 | mafm | it has: zoom in & out, zoom reset, orbit up/down/left/right, pan 4 dirs, full reset |
| 19:50.00 | mafm | and mouse drag with free rotation |
| 19:50.35 | mafm | (and keyboard with 15 degree steps, as in blender too) |
| 19:51.12 | Ralith | is there any sort of test-object so you can actually tell it's rotating? |
| 19:52.44 | mafm | yes, the boring tetrahedron-like |
| 19:55.14 | pacman87 | tetrahedrons aren't boring, you just have to get to know them first |
| 19:55.39 | mafm | well, it doesn't even have texture and it's all grey |
| 19:55.51 | mafm | it's like a tetrahedron from Roswell |
| 19:56.07 | mafm | you can't get acquainted with them easily |
| 20:03.22 | pacman87 | make a wireframe-type version: 4 spheres, 6 cylinders |
| 20:06.32 | mafm | the problem is that it's still not shaded or anything |
| 20:07.27 | brlcad | pacman87: hehe |
| 20:09.21 | mafm | btw, making spheres and cylinders requires more manual programming :D |
| 20:10.16 | pacman87 | surely i'm not the only one who anthropomorphizes the platonic solids? |
| 20:10.31 | Ralith | I didn't |
| 20:10.33 | Ralith | but I will now |
| 20:10.40 | Ralith | because that is an AWESOME idea. |
| 20:10.58 | Ralith | now I have someone to blame when a model doesn't work out :> |
| 20:11.45 | pacman87 | Ralith: if you get mad at them, they'll never work for you |
| 20:11.52 | pacman87 | you have to be friendly |
| 20:12.00 | Ralith | I never said I'd be cruel |
| 20:12.10 | Ralith | I just might take away their material privledges for a little while |
| 20:12.42 | Ralith | make them spend some time in a region all alone |
| 20:13.31 | pacman87 | woohoo, i just fixed a bug by adding 4 characters in two places :) |
| 20:14.25 | brlcad | hehe, you guys are nuts |
| 20:14.53 | brlcad | like a torus |
| 20:17.57 | starseeker | I know I can check the region flag on a combination to see if it IS a region - is there any logic to let me ask a combination if it CONTAINS any regions? (i.e., is it an assembly?) |
| 20:20.33 | mafm | Could not read status line: Secure connection truncated (https://brlcad.svn.sourceforge.net) |
| 20:20.33 | brlcad | not that come to mind, but you should be able to find out pretty easily with db_walk_tree or one of the other traversal funcs |
| 20:20.34 | mafm | :| |
| 20:20.49 | starseeker | cool. |
| 20:21.24 | starseeker | checks how db_apply_state_from_comb works... |
| 20:21.39 | pacman87 | wireframe: https://webspace.utexas.edu/trv82/www/rev_wf09.png |
| 20:21.39 | pacman87 | raytrace: https://webspace.utexas.edu/trv82/www/rev_rt16.png |
| 20:22.03 | pacman87 | the sketch is just four line segments |
| 20:22.17 | pacman87 | autoclosed |
| 20:22.19 | mafm | so I can't commit the rest of the code today... |
| 20:22.51 | mafm | heading home, take care folks :) |
| 20:23.09 | pacman87 | later |
| 20:25.21 | pacman87 | i can't commit either |
| 20:27.11 | brlcad | me either |
| 20:29.19 | brlcad | pacman87: hah, that is wicked cool -- i take it that is at least 4 line segments? |
| 20:29.35 | pacman87 | the sketch is only the 4 segments |
| 20:29.42 | pacman87 | all others were auto-added |
| 20:30.02 | brlcad | right |
| 20:30.10 | brlcad | looks great |
| 20:30.15 | pacman87 | thanks |
| 20:30.39 | pacman87 | i think i'll write a rt_sketch_contains( point2d pt ) function |
| 20:36.40 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 20:38.09 | starseeker | note to self - looks like logic needed is somewhere in db_tree |
| 20:42.02 | brlcad | starseeker: there are about five walkers |
| 20:42.13 | brlcad | make sure it's not something already available in one of the other walkers |
| 20:42.21 | starseeker | right :-) |
| 20:42.24 | pacman87 | brlcad: file is here: https://webspace.utexas.edu/trv82/www/wireframe.g |
| 20:42.39 | pacman87 | won't look right for you yet, since i can't commit |
| 20:42.51 | starseeker | knows the region creator warns of there is a region below it - a variation on that is all I need |
| 20:43.25 | brlcad | e.g. db_find_tree maintains a db_tree_state with the matrices applied, but none of the others do, etc |
| 20:43.47 | brlcad | er db_walk_tree |
| 20:44.02 | brlcad | db_walk_tree stops at regions, it's probably using that |
| 20:46.12 | brlcad | there we go, db_recurse would probably do the trick, feed it a db_tree_state that has a region callback set |
| 20:46.18 | starseeker | Hmm - db_count_subtree_regions |
| 20:46.27 | brlcad | ooh, even better :) |
| 20:46.50 | brlcad | one of the great and bad things about librt .. it's big |
| 20:46.58 | starseeker | assumes the name is descriptive... |
| 20:47.02 | brlcad | but if you need it, highly likely someone else needed it too |
| 20:47.04 | starseeker | read read read |
| 20:47.32 | starseeker | for naming, a LACK of an extension is only OK (sometimes) if its an assembly |
| 20:47.45 | starseeker | e.g. if there's one or more regions in there |
| 20:47.58 | starseeker | so I have to check |
| 20:55.42 | brlcad | woot |
| 20:55.49 | CIA-22 | BRL-CAD: 03brlcad * r31866 10/brlcad/trunk/ (configure.ac include/common.h include/config_win.h): since we're always defining it, push USE_PROTOTYPES up into common.h so our headers are closer to working without needing a config.h |
| 20:56.44 | CIA-22 | BRL-CAD: 03pacman87 * r31867 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: make the wireframe handling more robust - don't automatically draw a line from an open endpoint to the axis if there is another open endpoint with the same Y value |
| 21:01.07 | CIA-22 | BRL-CAD: 03starseeker * r31868 10/brlcad/trunk/src/librt/namegen.c: Make it a bit easier to throw test strings at the parsing routine, tweak some behavior, a few notes on things to figure out. Still a long way from usable. |
| 21:04.28 | PrezKennedy | brlcad, i got my learner's permit! |
| 21:09.39 | brlcad | woo hoo! |
| 21:09.52 | brlcad | now you just need one of those four-wheeled thingies |
| 21:12.09 | pacman87 | brlcad: a car? |
| 21:12.46 | brlcad | pacman87: ;) |
| 21:12.57 | pacman87 | i need one too |
| 21:13.16 | Ralith | get me one while you're at it |
| 21:13.27 | CIA-22 | BRL-CAD: 03brlcad * r31869 10/brlcad/trunk/ (8 files in 7 dirs): if we're going to always define USE_FBSERV then why does it even exist? push it out of configure up into dm.h, make it non-conditional for libtclcad but keep libdm's just in case. |
| 21:23.34 | brlcad | Ralith: curious, back on the rbgui point, did you see the video? |
| 21:23.43 | brlcad | (just wondering) |
| 21:44.27 | Ralith | brlcad: the 'ideal UI' thing? |
| 21:45.05 | pacman87 | <PROTECTED> |
| 21:45.07 | pacman87 | lol |
| 22:15.17 | poolio | brlcad: howdy :) |
| 22:15.42 | pacman87 | poolio: apparently we Ps are taking over IRC |
| 22:15.55 | poolio | pacman87: according to? Ralith? |
| 22:16.41 | brlcad | Ralith: no, the rbgui demo video |
| 22:16.54 | pacman87 | (02:14:16 PM) mafm: do you remember the name of the guy? I can't see the one that I know in IRC at the moment |
| 22:16.54 | pacman87 | (02:19:14 PM) mafm: the one that I know it's similar to pacman87, but now his nick is clobbering the other one :D |
| 22:17.38 | poolio | aawww, hi mafm |
| 22:17.50 | Ralith | brlcad: nope |
| 22:18.05 | Ralith | didn't know there were any |
| 22:18.18 | poolio | pacman87: I think the issue is just that we have the same first character...I think that everyone else is unique in that respect |
| 22:21.16 | pacman87 | there are currently 32 people in this channel, and only 26 letters. therefore, there must be other sets of nicks that start with the same first letter. |
| 22:27.04 | poolio | oh how I love the pigeonhole principle |
| 22:27.34 | Ralith | what about non-alphabetical nicks? |
| 22:27.37 | Ralith | IRC allows that |
| 22:28.05 | *** join/#brlcad hml (n=x@unaffiliated/hml) |
| 22:28.20 | hml | how do i efficiently take the intersection of two water tight meshes? |
| 22:30.52 | brlcad | hml: combine them together in a combination with an intersection operation .. (?) |
| 22:31.09 | hml | no sorry; i meant how to implement this operatioln |
| 22:31.21 | hml | if i have an array of vertices, an array of edges, and an array of faces |
| 22:31.26 | hml | as the structure for a mesh; |
| 22:31.40 | hml | giveh two of these water tight meshes, how I can calculate their intersection |
| 22:31.45 | hml | this seems like a rather complicated operation |
| 22:31.49 | brlcad | heh, explaining that is somewhat more complicated |
| 22:32.00 | brlcad | "read the source" ;) |
| 22:32.14 | brlcad | we have an implementation of that in brl-cad |
| 22:32.23 | brlcad | it amounts to .. a lot of code |
| 22:33.11 | hml | hmm; is the csg library easy to factor out? |
| 22:33.32 | brlcad | it's fairly modular as it is |
| 22:34.10 | brlcad | but yeah, you could probably extract those portions that relate to this fairly easily |
| 22:34.50 | brlcad | it all happens in src/librt (with most in src/librt/primitives/nmg) |
| 22:35.15 | hml | can you give me a few pointers on which dirs to start with? |
| 22:35.27 | brlcad | otherwise, we published a research paper on the technique we use about a decade ago |
| 22:36.23 | brlcad | what are you doing? |
| 22:36.44 | hml | i see src/librt, but not primitives/nmg |
| 22:36.59 | brlcad | starseeker, pacman87, etc .. if you use rss, sf.net has a feed for site status now: feed://sourceforge.net/community/forum/rss.php?forum=11 |
| 22:37.56 | brlcad | he talks about the recent svn outage earlier today as just being part of working on the new svn infrastructure in chicago, sorting out performance problems |
| 22:38.11 | brlcad | that shouldn't be longer than a half-hour else they'll update the site status |
| 22:42.01 | hml | why is thisalled librt |
| 22:42.18 | hml | (why is csg in ray tracing) |
| 22:43.18 | hml | actually, where's the pape ryou write 10 years again |
| 22:43.32 | hml | maybe i can read it and implement a crapppppy version of it for my own needs |
| 22:44.20 | pacman87 | hml: is that like a Ppppppowerbook? |
| 22:44.20 | hml | no; it's an ultra sensistivbe keyboard |
| 22:44.20 | hml | it's xrate 150 100 |
| 22:44.38 | brlcad | csg ray tracing is at the heart of what we do and why we do it, they are very closely tied to one another |
| 22:44.50 | pacman87 | http://www.zug.com/pranks/powerbook/ |
| 22:44.56 | brlcad | csg of polygonal surfaces is entirely secondary |
| 22:45.35 | brlcad | we can evaluate csg on any geometry format whether it be implicit, explicit polygonal, explicit spline surface, etc |
| 22:45.43 | brlcad | by doing it at the ray-trace level |
| 22:46.05 | hml | so you do csg via ray traceing? |
| 22:46.19 | brlcad | yes |
| 22:46.44 | brlcad | not for the polygonal surface on polygonal surface calculation I referred to |
| 22:46.50 | hml | hmm |
| 22:47.02 | hml | where's the paper ? :-) |
| 22:47.11 | brlcad | though if you just put the two meshes into one combination and ray-trace it, it'll evaluate the csg at ray-trace time |
| 22:47.24 | hml | i need to get the csg into a mesh to load ito opengl |
| 22:48.14 | brlcad | specifically for meshes, you can also evaluate the result by facetizing .. which if you have two meshes and a boolean will be the resultant mesh of that boolean |
| 22:48.40 | brlcad | i don't have a cite link on hand for the paper, you'll have to search for it -- pretty sure it's reachable via google |
| 22:49.01 | brlcad | try brl-cad, nmg, n-manifold geometry, muuss, terms should help |
| 22:49.28 | brlcad | otherwise, I'd be glad to help you modularize our code for your need |
| 22:52.11 | hml | okay; I'm going to tkae you up on this offer; right after I eat |
| 22:54.23 | brlcad | as in help you work with us, provide pointers in the code, maybe work towards commit access |
| 22:54.26 | brlcad | not do it for you in any sense of the offer ;) |
| 22:54.52 | brlcad | collaboration is key, I have more than enough on my plate to do it for you ;) |
| 22:54.58 | hml | of course |
| 22:55.12 | hml | you job will solely be as a wiki; i'll write every line of code :-) |
| 22:55.40 | brlcad | you really shouldn't need to write code other than to optimize (this chunk of code is entirely not optimized) |
| 22:56.07 | brlcad | mostly moving stuff around, maybe moving all the nmg code into its own library |
| 22:56.22 | brlcad | since that's what it sounds like you need |
| 22:56.43 | brlcad | still, what is this for and who are you? :) |
| 22:57.37 | hml | research ... nameless grad student |
| 22:58.22 | brlcad | k |
| 22:59.04 | brlcad | then I shall be mentor ... nameless brl-cad dev |
| 22:59.28 | Ralith | what's with the nick anyway |
| 22:59.36 | Ralith | I thought you were a bot when I joined |
| 23:00.33 | poolio | it was that or 'sean-cad' |
| 23:00.58 | hml | brlcad: when are you normally on irc / what time zone? |
| 23:01.08 | CIA-22 | BRL-CAD: 03brlcad * r31870 10/brlcad/trunk/TODO: |
| 23:01.08 | CIA-22 | BRL-CAD: the topic has come up before, but raised again by someone possibly interested in |
| 23:01.08 | CIA-22 | BRL-CAD: working on the task (hml, via irc). refactor all of the nmg processing code |
| 23:01.08 | CIA-22 | BRL-CAD: (back) into its own library. would let external users manage their mesh |
| 23:01.08 | CIA-22 | BRL-CAD: geometry without needing to pull in everything else in librt. |
| 23:01.11 | brlcad | hml: I'm always on irc, even when I'm not |
| 23:01.37 | brlcad | if you linger, i'll read and answer anything in my backlog |
| 23:02.05 | brlcad | Ralith: I was using the 'brlcad' nick long before brl-cad was open source |
| 23:02.23 | Ralith | huh. |
| 23:02.23 | brlcad | just a handle because I love working on it |
| 23:02.23 | Ralith | hehe |
| 23:02.47 | Ralith | great to know you're that dedicated |
| 23:03.25 | poolio | brlcad: is src/other/openNURBS meant to be vanilla? |
| 23:03.37 | brlcad | poolio: theoretically |
| 23:03.42 | brlcad | it's not atm |
| 23:04.02 | brlcad | i (or someone(tm)) have to undo some of the mods made so we can upgrade to the latest releast |
| 23:05.02 | poolio | Hmmm, it's probably to just create a new file for what I'm thinking about doing...I was talking with ed about how to get ellipsoids, and it looks like you can just take the sphere and stretch it |
| 23:05.25 | brlcad | jason had to implement some of the evaluation routines that they ripped out in order to get ray-tracing working and it was easier at the time to just mod them instead of hacking around it some other way |
| 23:05.31 | poolio | Also, I have no clue how to do tgc :\ |
| 23:05.51 | brlcad | i can help you with the caps ;) |
| 23:06.02 | brlcad | chuckles |
| 23:06.03 | poolio | Heh, but raytracing doesn't work, does it? :P |
| 23:06.14 | brlcad | it does |
| 23:06.17 | brlcad | somewhat |
| 23:06.26 | brlcad | lots of failure cases, very raw |
| 23:06.33 | poolio | It failed pretty miserable on my torus |
| 23:07.41 | brlcad | you'll get a mix of utter failure (crashes) to working beautifully to working with nasty results to almost working with acne |
| 23:07.50 | poolio | My English is pretty terrible today |
| 23:08.04 | poolio | brlcad: good luck fixing that :) |
| 23:08.35 | brlcad | we have a matrix of a slew of things exported from Rhino3D .. about a third worked flawless, about a third with some problem, and about a third failing hard |
| 23:08.50 | poolio | yeah I saw, you sent it to me |
| 23:08.56 | brlcad | right |
| 23:09.00 | brlcad | that thing |
| 23:12.40 | poolio | After ell/tgc/arbs, what would you say is the next most important? |
| 23:14.08 | brlcad | tor |
| 23:14.30 | poolio | done tor :) |
| 23:14.47 | poolio | I guess I should say openNURBS did tor... |
| 23:15.19 | brlcad | for tgc, you could start with the subset cases |
| 23:15.30 | brlcad | rcc, rec, trc, tec, etc |
| 23:16.09 | brlcad | otherwise, pipe is probably the next one (which is sort of just stitching rcc's and tor's together) |
| 23:16.22 | brlcad | followed by arbn (different from arb#) |
| 23:17.05 | poolio | Do you think it's worth doing the subsets of tgc? |
| 23:20.14 | brlcad | dunno, might help figure out tgc if you figure out rcc first |
| 23:20.52 | poolio | Well rcc is just a surface of revolution...all the primitives like that are easy |
| 23:21.04 | poolio | The issue is when they aren't a surface of revolution...have to take a totally different approoach |
| 23:21.21 | poolio | Although, if the scaling thing ed told me about works, then that may be grossly simplified |
| 23:24.06 | brlcad | ah, true |
| 23:24.15 | brlcad | i was thinking of defining that surface directly |
| 23:24.23 | brlcad | but a revolution would be easier |
| 23:25.08 | *** join/#brlcad punkrockgirl (n=Pandora@c-69-243-244-154.hsd1.mo.comcast.net) |
| 23:25.35 | brlcad | poolio: er, hold up .. isn't tgc one of the few that were actually already done? |
| 23:25.55 | brlcad | i.e. it has a tnurb callback |
| 23:26.05 | brlcad | just need to convert that to opennurbs lingo |
| 23:26.08 | poolio | brlcad: oh yeah? lemme go look :) |
| 23:26.15 | brlcad | yeah it does |
| 23:26.48 | poolio | brlcad: yes! schweet :) |
| 23:27.06 | poolio | ell does too. I forgot about these |
| 23:27.41 | *** join/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 23:27.52 | brlcad | so do a few others from the looks of it |
| 23:27.56 | brlcad | howdy punkrockgirl |
| 23:28.49 | brlcad | poolio: yet even a third option is that we have an okay to utilize the code in BOOLE |
| 23:29.45 | *** part/#brlcad saltan (n=lieven@d51530284.access.telenet.be) |
| 23:29.56 | brlcad | boole implements a lot of this too (it's a sytem for ray-tracing csg nurbs surfaces, specifically built from brl-cad geometry) |
| 23:29.58 | poolio | So is there any reason not to use BOOLE? |
| 23:30.31 | brlcad | yeah, it was an academic effort that has a hell of a lot of failure cases |
| 23:30.39 | brlcad | but that's at the CSG eval level |
| 23:30.50 | brlcad | the underlying pieces might be helpful reference code |
| 23:30.52 | poolio | yeah...if the conversion to brep works... |
| 23:31.31 | brlcad | they have a website with a tarball up |
| 23:32.08 | poolio | I'm browsing the source right now |
| 23:34.33 | brlcad | their "ascii" format is actually our old v4 file format, so I can show you how to get that if you need it |
