IRC log for #brlcad on 20080717

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

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.