| 00:03.34 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 00:48.48 | Ralith | I don't suppose the SoC rules allow third parties to aid development? |
| 00:48.55 | Ralith | (not counting the mentor) |
| 00:58.36 | Ralith | Can one even get ahold of the code from the current SoC projects? |
| 01:00.38 | Ralith | Also, just how much of a task might a realtime shaded view be? |
| 01:12.28 | brlcad | Ralith: sure they do |
| 01:12.52 | brlcad | collaboration and integration is actually highly encouraged |
| 01:13.23 | brlcad | the student just can't use that as a crutch to not do work and the collaboration can't negatively impact their ability to do work |
| 01:15.24 | Ralith | oo! |
| 01:15.34 | Ralith | in that case, where can I get at the new GUI code? |
| 01:16.06 | brlcad | the main point of gsoc is actually to (hopefully) make them new (long-term) developers, build up our dev team .. not just for them to work on a project |
| 01:16.32 | brlcad | the new gui code is sitting in the rt^3 branch |
| 01:16.35 | brlcad | ~cadsvn |
| 01:16.36 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 01:17.15 | Ralith | woo |
| 01:17.17 | Ralith | thanks |
| 01:17.18 | brlcad | replace brlcad/brlcad with brlcad/rt^3 (and brlcad with rt^3 |
| 01:17.33 | Ralith | is there summary of the branches anywhere? |
| 01:17.53 | brlcad | yeah, it's asking one of the devs in here or on the mailing list ;) |
| 01:18.01 | Ralith | consider yourself asked |
| 01:19.13 | brlcad | there are 5 top level "modules" that came over from our cvs repo, seen at http://brlcad.svn.sourceforge.net/viewvc/brlcad/ |
| 01:19.49 | brlcad | brlcad is the main codebase, core libraries, the big hot dog kahuna mamma million lines of cadness |
| 01:20.26 | Ralith | oh, so it's not actual code branches, just organization? |
| 01:20.41 | brlcad | jbrlcad is/was a test project by one of the core devs that implemented a (very very small) portion of our "librt" raytrace library in pure java |
| 01:20.51 | Ralith | heh |
| 01:21.19 | brlcad | there are also branches, potentially, for each of these modules -- though afaik, 'brlcad' is the only one that has branches and STABLE is the only one of interest atm |
| 01:21.21 | Ralith | a raytracing library in java; you don't hear about that every day |
| 01:21.44 | brlcad | it was actually a rather enlightening exercise |
| 01:21.48 | Ralith | oh? |
| 01:22.34 | *** join/#brlcad thing0 (n=ric@124-169-154-132.dyn.iinet.net.au) | |
| 01:22.41 | brlcad | not so much the java part but how we can go about restructuring our huge librt library into an object-oriented framework (hint: it surprisingly converts over very neatly) |
| 01:23.11 | brlcad | librt is at brl-cad's core, it provides the geometric representation, data i/o, primitives, boolean operations, ray-trace evaluation, etc |
| 01:23.42 | Ralith | is there much to be gained from such a restructure, though? |
| 01:24.36 | brlcad | rtcmp is another pet project for comparing librt ray-trace results against our libtie high-performance "triangle intersection" library (as well as another closed source lib) |
| 01:26.16 | brlcad | my bad, misspoke we wouldn't want to replace librt with such a restructuring -- s/restructuring our huge librt/structuring a new object-oriented API on top of our librt/ |
| 01:27.13 | brlcad | there is a pretty strong request to also have an oo c++ api in addition to and/or on top of our c libs |
| 01:27.32 | Ralith | ahh. |
| 01:27.50 | brlcad | continuing, the 'web' module is a stubbed (mostly empty) placeholder for revision controlling the website |
| 01:27.52 | Ralith | Isn't that a pretty simple (if lengthy) task? |
| 01:28.11 | brlcad | very lengthy |
| 01:28.23 | brlcad | mostly simple, there are some complex things to sort out |
| 01:28.41 | brlcad | especially how to best leverage our c libs, don't want to rewrite |
| 01:30.41 | brlcad | that leaves the last 'rt^3' module whose original purpose isn't so important, but has become a place to put the new gui and oo geometry engine infrastructure |
| 01:30.44 | brlcad | (don't want to mix C++ in with the brl-cad's C sources any more than we need to) |
| 01:31.30 | brlcad | plus we (directly) manage all external dependencies and the front-end gui has a hell of a lot of dependencies that have nothing to do with the rest of brl-cad |
| 01:31.42 | Ralith | yeah, I noticed that |
| 01:32.10 | Ralith | it seems kind of strange; one doesn't need all that much for such a purpose-specific app. |
| 01:33.03 | Ralith | Is there an existing wiki page buried somewhere that would be good for this info, or shall I start a new one? |
| 01:43.36 | brlcad | there are some pages on the wiki that relate to it |
| 01:44.30 | brlcad | http://brlcad.org/wiki/OpenGL_GUI_Framework and http://brlcad.org/wiki/User:mafm for starters |
| 01:45.04 | brlcad | otherwise there's not a lot up yet |
| 01:46.23 | Ralith | I was referring to the SVN branch info, actually |
| 01:55.47 | brlcad | oooh |
| 01:55.52 | brlcad | sure, go for it if you like |
| 01:56.36 | brlcad | hugs the wiki and hugs MinuteElectron |
| 02:00.42 | starseeker | Ralith: Actually, you'd be surprised how much a full featured GUI needs |
| 02:01.26 | brlcad | starseeker: that's pretty freaky relying on snprintf(null, 0) like that .. :) might want to pass a valid non-zero-length buffer just in case |
| 02:01.27 | starseeker | at least for something like CAD |
| 02:02.11 | starseeker | brlcad: sure, no problem - is that actually the "right way" to do it? |
| 02:02.25 | starseeker | the snprintf trick works, but eeek |
| 02:02.30 | brlcad | it's certainly "a" way |
| 02:02.38 | brlcad | and at least one supported by c99, dunno about c89 |
| 02:02.46 | starseeker | hmm. |
| 02:03.10 | starseeker | was looking for a "right" way, but will take working... |
| 02:03.45 | brlcad | curious, what doyou need dynamic size for? |
| 02:04.10 | brlcad | usually taboo and potential security issue to have non-const format specifiers |
| 02:05.06 | starseeker | strings with different numbers of digits - prim-0001.s up to prim-1000.s, prim-01.s to prim-10.s, etc |
| 02:05.35 | starseeker | %04d works for the first, %02d for the second |
| 02:06.16 | brlcad | hmm |
| 02:06.17 | starseeker | but if I don't specify the number of zeros needed up front, I get stuff like prim-1.s to prim-10.s |
| 02:06.22 | starseeker | bad |
| 02:06.29 | starseeker | doesn't list nicely |
| 02:06.34 | brlcad | sure |
| 02:07.05 | starseeker | I have a little test routine working using the snprintf trick, which could eventually get put into the get_name logic we discussed |
| 02:07.34 | brlcad | and ideally preserves the original padding, or automatically pads up to the 'n' specified (for cloning) that fits whatever increment |
| 02:07.35 | starseeker | I figured non-const was OK since it's defined in the routine itself based on the input params... |
| 02:07.44 | starseeker | exactly |
| 02:07.51 | brlcad | except the input params are user-provided |
| 02:07.58 | starseeker | right |
| 02:08.06 | starseeker | whoops, gotta run - biab |
| 02:08.08 | brlcad | means it's exactly the sort of case that would need to be extra-checked ;) |
| 02:09.08 | Ralith | starseeker: well, I've seen all sorts of GL-using programs do it *without* ogre |
| 02:09.22 | Ralith | and I have the strong (perhaps incorrect?) perception that ogre is about as heavy as they come |
| 02:09.54 | pacman87 | starseeker: i just remembered you could also use log|x| to find the number of digits |
| 02:09.58 | brlcad | i'd say that's not entirely correct .. ogre's one of the smallest "engines" out there |
| 02:10.17 | brlcad | especially given they only focus on the rendering |
| 02:10.46 | brlcad | iirc, osg was a fair bit bigger, cs is definitely bigger |
| 02:11.26 | Ralith | aren't these all designed for use with things like games? |
| 02:11.36 | brlcad | not at all |
| 02:11.44 | Ralith | I thought the requirements here were far simpler than what those libraries support. |
| 02:12.00 | brlcad | "graphics" applications for those three |
| 02:13.14 | Ralith | well, so long as it works, I suppose. |
| 02:13.23 | Ralith | nothing wrong with a nice, abstract interface |
| 02:13.27 | brlcad | the main reasons for ogre (or any engine) have been to provide proper scenegraph management, automatic LoD, automatic rendering styles, and cross-platform acceleration support |
| 02:13.50 | Ralith | rendering styles? |
| 02:14.29 | pacman87 | digits = floor( log10(number) ) + 1; |
| 02:14.47 | brlcad | home-grown usually has "no" scenegraph management beyond a simple "here display all this stuff" on/off, which is hell for exceptionally large models |
| 02:15.08 | Ralith | that makes sense, given the complexity of things done with brl-acd |
| 02:15.10 | Ralith | cad* |
| 02:15.21 | Ralith | pacman87: neat |
| 02:15.41 | brlcad | rendering styles like non-hidden wireframe, fully-shaded displays, cell-shaded, flat-shaded, hidden wireframe, etc |
| 02:16.22 | pacman87 | Ralith: thanks, my older brother told me about that trick a while ago |
| 02:16.23 | Ralith | so the new GUI's going to include a proper shaded display? :D |
| 02:17.29 | poolio | WOOHOO. NMG -> brep works for all arbs :D |
| 02:17.30 | brlcad | Ralith: yes, that is one of the primary goals |
| 02:17.40 | brlcad | poolio: woot! |
| 02:17.54 | pacman87 | poolio: congrats |
| 02:17.54 | poolio | pacman87: so yes, algorithm did work but it's awfully inefficient |
| 02:18.01 | pacman87 | which one? |
| 02:18.04 | poolio | I probably have ~2 hours worth of code cleanup/etc though |
| 02:18.14 | Ralith | brlcad: awesome! |
| 02:18.37 | brlcad | Ralith: though the main reason mged doesn't do shaded displays has much more to do with geometric representation -- unevaluated implicit surfaces with boolean operations have no intrinsic polygonal representation to send to opengl, it has to be evaluated |
| 02:19.36 | brlcad | to do proper shaded displays of arbitrary geometry requires what poolio is working on right now (unevaluated implicit primitives -> spline surface or polygonal boundary representation primitives) |
| 02:20.06 | brlcad | then CSG evaluation of brep on brep surfaces, then tessellation of breps |
| 02:20.16 | brlcad | *then* we have fully shaded displays of ANY geometry |
| 02:20.20 | poolio | pacman87: The project onto the arbitrary axes, calculate min u/v on that plane -> 3-space |
| 02:21.04 | poolio | It's also nice in that if you have a rotate arb with a rectangular face the surface w/out trimming curves matches up....although that's just nice for staring at /debugging brep output |
| 02:21.14 | brlcad | poolio: that's where coming in to talk with Ed would certainly help, he's great at finding ways to optimize/simplify an algorithm |
| 02:22.14 | brlcad | though I forgot to mention last week that there was something cool you could have gone to today .. :/ |
| 02:22.43 | brlcad | drinks a mt dew for dinner |
| 02:22.44 | poolio | aww man :( was it the tour? |
| 02:23.36 | poolio | brlcad: So do you think it's more important to continue and fully support all types of NMGs (multi-shell/region, inner wire loops, etc...) or supporting other primitives? |
| 02:26.52 | brlcad | poolio: yeah :( |
| 02:27.03 | brlcad | ordnance museum |
| 02:31.05 | brlcad | poolio: if you want to try out other primitives, go for it -- maybe add a section to the top-level TODO or to a doc in src/librt/primitives with details on where you left off at, what's working, and/or what's remaining |
| 02:44.54 | starseeker | brlcad: In this case, I think the check would be that the number of user supplied clones is between 1 and INT_MAX or some such |
| 02:45.11 | starseeker | brlcad: The string size follows directly and internally from that |
| 02:51.34 | brlcad | that's not quite what I mean |
| 02:53.22 | brlcad | if the user can provide the input string (which they are in this case), there's the potential to inject print specifiers of their own -- often in ways that can creatively overrun a buffer and jump to code of their own (security hole) |
| 02:55.08 | brlcad | it'd even be safer to count the number of digits in the pattern and do a for loop that iterates over printing "%c" to print each digit one at a time, or a case table that supports a set of sizes .. but all of them still using a constant format specifier |
| 03:02.25 | starseeker | I don't quite see - the user isn't providing the string, except to specify they want an incrementer in position x |
| 03:03.24 | starseeker | according to what you outlined this evening, they aren't supplying any strings at all except for an already valid primitive name |
| 03:05.08 | starseeker | Or are you thinking some operation that doesn't use an existing primitive? |
| 03:06.15 | starseeker | is just trying to envision an attack vector |
| 03:12.34 | brlcad | more around the idea that you're implementing a general librt routine for naming objects and don't really know where the input string comes from |
| 03:13.48 | brlcad | could come up with a variety of example, but say specific to clone's case, the modeler says "clone my_object_0000.c -n 100" .. |
| 03:14.47 | brlcad | that my_object_0000.c would be the pattern you'd want to fit to and probably even start from (at least dwayne has said as much, and I believe clone already tries to preserve such existing numerations) |
| 03:16.05 | brlcad | especially if the pattern in that case was something like {prefix}{num}{suffix}, so it matches 0000 and you'd expect to end up with my_object_0100.c and so on |
| 03:17.08 | starseeker | OK, that's a good argument for digit counting, if there are any, and comparing it to what is needed by the arg to -n |
| 03:18.15 | starseeker | but I still don't see how it presents an attack vector - in the end it's just a count of digits and reading them in as an int |
| 03:19.24 | starseeker | I suppose you could do an append operation to add chars as numbers one at a time, but ouch... |
| 03:24.03 | brlcad | could do lots of twisted things with something like: clone my_%n_0000.c |
| 03:24.27 | brlcad | and various variations thereof |
| 03:26.34 | poolio | oo. Never had "]]))" appear in my C code before :P |
| 03:26.48 | brlcad | the point wasn't so much to come up with a specific failure case, there are plenty of links throughout the web for tricks you can play ;) |
| 03:29.31 | brlcad | the point was more "try to structure the processing so you don't need dynamic format specifiers" -- just about any dynamic format specifier can be turned into a loop, then you just need to do some basic sanity checking |
| 03:35.55 | yukonbob | hello, cadheads |
| 03:36.36 | brlcad | howdy yukonbob |
| 03:37.08 | yukonbob | what's happening, my friend? |
| 03:39.51 | starseeker | brlcad: OK... I'll have to run it by you once I've got something written. (Maybe we could just disallow % in primitive names? ;-) |
| 03:40.24 | starseeker | hates having to deal with individual characters when there are more powerful tools available |
| 03:43.10 | starseeker | Oh, well... I guess that's life |
| 04:10.05 | *** join/#brlcad thing1 (n=ric@123.208.38.160) | |
| 04:13.32 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 04:23.09 | *** join/#brlcad thing0 (n=ric@124-169-154-132.dyn.iinet.net.au) | |
| 04:27.22 | brlcad | starseeker: like I said, you're making a new public api call -- that's where the checking needs to occur to be 'secure' regardless of whatever validation/limitations that mged or other apps impose on their end |
| 04:27.52 | poolio | brlcad: I think I'm getting some weird C/C++ header confusion. I'm including vmath.h but it's not picking up the constant definitions, like 'X', and 'Y' |
| 04:28.19 | poolio | If I also include 'dm.h' I get the X,Y, and Z but not W/H |
| 04:28.26 | brlcad | poolio: hum, perhaps some subsequent header is undefining them |
| 04:28.54 | brlcad | try adding it last to test |
| 04:28.58 | poolio | It's the last one included... but maybe one of the previous header includes it as well |
| 04:29.59 | poolio | ah hmm: |
| 04:30.09 | poolio | brep.h:#undef X |
| 04:31.05 | brlcad | yeah, I forget exactly what that was needed |
| 04:31.34 | brlcad | those are such general symbols, iirc there was some borkage deep in the c++ template headers |
| 04:31.42 | brlcad | or it was something in the openNURBS headers |
| 04:32.12 | poolio | Yeah...has a XXX ack, a hack comment. I can't force it because rtgeom.h includes vmath.h and then brep.h |
| 04:32.31 | poolio | The only thing to do seems to be to just add a definition myself |
| 04:32.58 | brlcad | you can change our header logic to accommodate |
| 04:33.17 | brlcad | conditionally def/undef or redef after undef, etc |
| 04:38.17 | poolio | brlcad: do you remember what it broke? |
| 04:52.39 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1128564908.dsl.bell.ca) | |
| 05:16.23 | Ralith | hm, Ogre seems to depend on CEGUI. I wonder if that can be cut out. |
| 05:45.47 | brlcad | Ralith: it doesn't/shouldn't depend on it, though some of their code samples may |
| 05:45.54 | brlcad | poolio: compilation ;) |
| 05:46.24 | Ralith | smacks ports |
| 05:46.29 | Ralith | I disabled code samples >:| |
| 06:00.50 | *** join/#brlcad clock_ (n=clock@217-162-111-193.dclient.hispeed.ch) | |
| 06:05.20 | brlcad | Ralith: bsder? |
| 06:05.34 | Ralith | yep |
| 06:05.35 | Ralith | freebsd |
| 06:05.42 | brlcad | awesome |
| 06:05.50 | Ralith | o/ |
| 06:05.55 | Ralith | wrestling with porting Mocha right now |
| 06:06.14 | Ralith | mafm come on here ever? |
| 06:06.20 | brlcad | you did hopefully see that the sources are in the rt^3 module I hope? :) |
| 06:06.28 | Ralith | yeah |
| 06:06.32 | brlcad | they require some minor patches and latest sources |
| 06:06.32 | Ralith | I'm worrying about deps |
| 06:06.42 | Ralith | oh, they're already made portable? |
| 06:06.42 | Ralith | cool |
| 06:06.51 | Ralith | oh! |
| 06:06.54 | Ralith | I see what you meant |
| 06:07.00 | brlcad | they're in src/other |
| 06:07.04 | Ralith | kk |
| 06:07.24 | brlcad | he included some makefile logic to build them |
| 06:07.51 | brlcad | but forewarning that it's not been tested by more than just a couple people so far, so not compilation-robust |
| 06:08.10 | Ralith | that's what I'm here for |
| 06:08.24 | Ralith | if I wasn't happy to be testing and making patches, I wouldn't have checked out SVN code. |
| 06:08.32 | brlcad | \o/ |
| 06:09.58 | Ralith | glad to see he's got the build problem largely addressed, though |
| 06:10.18 | Ralith | was worried when I saw the rbgui page stating non-windows was unsupported |
| 06:10.45 | brlcad | yeah, I rattled his cage for quite a while to try to make it more seamless and automatic to build |
| 06:11.09 | Ralith | argh |
| 06:11.20 | Ralith | why does NOTHING put /usr/local/include in the default search path >:| |
| 06:11.45 | brlcad | automatic dep management is a pretty big deal (and pet peeve) for the project in general, fully portably managing deps, not depending on anything being installed, not requiring the user go get stuff |
| 06:12.16 | brlcad | our main module does :) |
| 06:12.32 | Ralith | kudos |
| 06:13.43 | Ralith | oh this looks bad |
| 06:14.13 | Ralith | :D |
| 06:14.19 | Ralith | there's already freebsd patches for ois |
| 06:15.15 | *** join/#brlcad thing1 (n=ric@124-169-154-132.dyn.iinet.net.au) | |
| 06:15.43 | Ralith | hm, I wonder if these break non-freebsd |
| 06:16.05 | yukonbob | Ralith: add to brlcad's description the tension of being able to use a system's pre-installed libraries, etc. and it's "fun" with a capital "F". |
| 06:16.48 | Ralith | yukonbob: I don't entirely follow |
| 06:16.56 | Ralith | that's not tension so much as a useful feature |
| 06:17.23 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 06:17.24 | brlcad | yeah, tries to detect system libs and prefer them by default unless overridden, otherwise compiling the dep cleanly as if it were bundled |
| 06:17.34 | Ralith | nice. |
| 06:18.21 | brlcad | the hard part there is the plethora of versions, e.g. having a tcl/tk 8.4 but no itcl installed, yet our itcl requires 8.5, and a variety of combinations thereof |
| 06:18.38 | yukonbob | :) |
| 06:18.46 | yukonbob | Capital "F", I tell ya... |
| 06:19.42 | yukonbob | would you say I have a plethora of gifts? |
| 06:20.38 | brlcad | a plethora of .. something ;) |
| 06:20.42 | yukonbob | heh -- |
| 06:20.47 | Ralith | hehe |
| 06:20.52 | yukonbob | is channeling The Three Amigos |
| 06:21.05 | Ralith | brlcad: I don't suppose there's a makefile equivalent of #ifdef __FreeBSD__ ? |
| 06:22.43 | Ralith | well, I can always wrap the entire file in that |
| 06:22.47 | Ralith | but that's hacky |
| 06:22.48 | brlcad | those makefile(s) in src/other can change |
| 06:22.58 | brlcad | they're not going to stay that way |
| 06:23.11 | Ralith | yeah |
| 06:23.20 | Ralith | my idea was to be an agent of that change :P |
| 06:23.59 | brlcad | his project is also a mild experiment in cmake's flexibility, but he isn't very familiar with it (and doesn't really have time during gsoc to figure it out more than absolutely necessary) |
| 06:24.34 | brlcad | so the idea would be to eventually end up with something similar to our gnu build system infrastructure on the main trunk in cmake for rt^3 |
| 06:24.52 | brlcad | or just gut it for gbs if it turns out to be too much hassle |
| 06:25.11 | Ralith | well, this will still make it work on freebsd without breaking other stuff for the short term. |
| 06:25.17 | brlcad | having it be seemlessly cross-compilable to Windows would be a big win, though, which cmake offers |
| 06:26.49 | yukonbob | Ralith: I'm not entirely sure what you're working on, but you might consider patching as part of the build in ports, too, w/o touching the BRL-CAD tree... |
| 06:27.04 | Ralith | yukonbob: I'm taking the patches from ports, actually |
| 06:27.07 | yukonbob | s/entirely sure/sure at all/ |
| 06:27.11 | Ralith | except applying them nondestructively |
| 06:27.17 | Ralith | or should I not even bother, and just grab from there? |
| 06:28.22 | yukonbob | are you trying to get some FreeBSD-specific building happening that's not already addressed in the patches? |
| 06:28.46 | Ralith | I'm trying to apply what's in the patches nondestructively to the stuff in svn |
| 06:29.08 | yukonbob | ?"nondestructively" |
| 06:29.24 | Ralith | the existing patches kill a variety of things for the sake of making it work on FreeBSD, which doesn't actually support them in the first place |
| 06:29.40 | Ralith | gtg now, actually |
| 06:29.44 | Ralith | guess I'll leave the ois stuff alone for now |
| 06:29.51 | yukonbob | chat later :) |
| 06:30.11 | brlcad | cya later Ralith |
| 06:30.12 | Ralith | I'll probably be forced to make it up as I go along for other bits that aren't in ports, anyway |
| 06:30.30 | Ralith | seeya |
| 06:30.32 | brlcad | looks forward to seeing patches ;) |
| 06:30.44 | yukonbob | looks forward to hitting hay... |
| 06:30.50 | brlcad | yukonbob: crazy talk |
| 06:30.52 | brlcad | yawns |
| 06:31.42 | yukonbob | knows that brlcad seems to get by on .5h sleep/day, and an occasional sushi platter, but I'm not brlcad... so I sleep. |
| 06:32.15 | yukonbob | on that note... ciao for now, geeks. |
| 06:32.32 | brlcad | heh, cya |
| 06:32.46 | brlcad | wonders what timezone he's in |
| 06:33.20 | yukonbob | == pacific... 11:30 now -- 5am approaching too soon... |
| 06:58.57 | *** join/#brlcad Axman6_ (n=Axman6@pdpc/supporter/student/Axman6) | |
| 07:01.24 | *** join/#brlcad elmom_ (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) | |
| 07:15.52 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 07:22.10 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 07:45.09 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 08:26.22 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 08:33.58 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 08:36.27 | *** join/#brlcad lleroy (n=chatzill@axsguard.bepco.com) | |
| 08:36.58 | lleroy | starseeker: printf("%*d", 4, i) |
| 08:40.36 | *** part/#brlcad lleroy (n=chatzill@axsguard.bepco.com) | |
| 08:40.48 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 08:42.09 | mafm | hey |
| 08:45.50 | CIA-22 | BRL-CAD: 03mafm * r31846 10/rt^3/trunk/src/g3d/ (CameraModes.cxx CameraModes.h): Separating declaration and implementation of camera modes, since the code in these files is going to grow |
| 08:51.25 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 09:00.57 | brlcad | howdy mafm |
| 09:02.37 | mafm | o/ |
| 09:02.48 | brlcad | mafm, you had a fan checking out your project earlier, he started poking at the code .. he'll undoubtedly be back in a while |
| 09:03.32 | mafm | huh? |
| 09:03.41 | mafm | sombody from brl-cad? |
| 09:03.50 | brlcad | someone new |
| 09:04.18 | brlcad | (a coder) |
| 09:09.58 | mafm | huh |
| 09:10.09 | mafm | why does he know about the code? trade secret! |
| 09:10.51 | mafm | can we silence him before he spreads the word? |
| 09:11.28 | brlcad | he wants to help work on it |
| 09:12.19 | CIA-22 | BRL-CAD: 03mafm * r31847 10/rt^3/trunk/src/g3d/ (CameraManager.cxx CameraManager.h): Changing private Observer/Listener pattern implementation by the one already existing in the project |
| 09:12.49 | mafm | I see |
| 09:13.00 | mafm | do you remember his nickname? |
| 09:13.39 | brlcad | Ralith |
| 09:14.48 | mafm | fine, I'll speak with him when I see him :) |
| 09:15.42 | mafm | but I don't know if it's advisable for other people to start developing it this early? I don't know if that would mess gsoc plans |
| 09:35.29 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 09:36.12 | brlcad | working integrated with others is part of gsoc, you've been "lucky" so far ;) .. but not to worry, nothing that would significantly derail your schedule/progress |
| 09:38.40 | brlcad | as I mentioned to him, collaboration and integration is actually highly encouraged for most projects/students |
| 09:38.46 | brlcad | the student just can't use that as a crutch to not do work and the collaboration can't negatively impact their ability to do work |
| 09:39.18 | mafm | yes, I mean if he wants to work in things like the communication with libged... |
| 09:39.47 | brlcad | the main point of gsoc is actually to (hopefully) make you a new (long-term) developer, build up our dev team .. not just for folks to work on a project ;) |
| 09:41.17 | brlcad | yeah, would try to find something productive of course |
| 09:41.31 | brlcad | at this point, he's just compiling -- was going to look into cleaning up the build system |
| 09:43.14 | mafm | goody |
| 09:43.59 | mafm | btw, I think that maybe shortly after gsoc we have to start to worry about the GUI toolkit at least |
| 09:46.22 | CIA-22 | BRL-CAD: 03mafm * r31848 10/rt^3/trunk/src/g3d/CameraModes.cxx: Setting limits to orbital camera mode, so it doesn't cause strange artifacts when verticalRotation is greater than PI/2 (or smaller than -PI/2). Maybe it should continue to rotate but seamlessly, I don't know... |
| 09:47.01 | mafm | they're like missing in action, and apart from the private patches there are small glitches here and there, even if I didn't start to create very complex things |
| 09:47.43 | brlcad | i don't care so much that they're missing in action, but the glitches are cause for concern |
| 09:47.55 | brlcad | have you been able to get a feel for how well it's suited to customization yet? |
| 09:48.39 | brlcad | input binding customization, theming the appearance, developing custom layout managers |
| 09:49.33 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 09:52.26 | CIA-22 | BRL-CAD: 03mafm * r31849 10/rt^3/trunk/src/g3d/ (Application.cxx CameraManager.cxx CameraModes.h Commands.h): Minor changes in comments/indentation, adding missing #ifdefs around Commands.h |
| 09:52.55 | mafm | not much of that yet, but in example the Text widget for the console doesn't seem to have scrolling working |
| 09:56.07 | mafm | about theming I changed fonts and minor things only, and you can define many things (corners, borders, etc) but it looks like it needs minucious/detailed work, or a good editor |
| 09:56.31 | mafm | that is, I think that it's not difficult to get a theme that you work, but probably it needs time |
| 10:10.23 | mafm | http://graphjam.com/2008/07/15/song-chart-memes-breakdown-of-government-funding-in-england/ -- Silly Brittish :) |
| 10:20.58 | mafm | brlcad: http://www.clutter-project.org/ | http://moblin.org/playground/?q=node/76 |
| 10:21.48 | mafm | brlcad: it seems that they're going to experiment with that with 3.0, still I don't know if it's advisable to try that path, it's the 1st time that I hear from that project |
| 11:11.40 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 11:15.37 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 12:07.56 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 12:30.32 | brlcad | mafm: I've heard of them, they've come a long ways |
| 12:32.00 | brlcad | mafm: I wouldn't try that path unless you were set on *not* using rbgui for sure |
| 12:33.18 | brlcad | clutter has decent portability on paper, but also a few additional dependencies too so they'd have to be reviewed .. plus their actual widget/interactions is fairly minimal -- you'd have to implement things like tabbed contexts, input text areas, etc |
| 12:35.00 | brlcad | otherwise, I love their overall approach, there are lots of features in the moblin interface that show how some reasonably powerful widgets and interactions can be made to work |
| 12:35.19 | brlcad | integrating that with the 3D render engine could be interesting.. |
| 12:44.19 | mafm | oki, I'll keep it in mind for after gsoc |
| 12:45.09 | mafm | in the meantime, I have a question about trackballs -- what input events they generate? the computer sees it as a regular mouse? |
| 12:45.52 | brlcad | "trackball mode" has nothing to do with a physical trackball ... :) |
| 12:46.12 | brlcad | but yah, they're usually regular mice |
| 12:46.37 | yukonbob | morning, cadheads |
| 12:46.42 | brlcad | turn a mouse with a ball upside down, make the ball a lot bigger |
| 12:47.28 | mafm | yes, I know that, but I mean if the computer/OS feeds that as a mouse, in x-windows |
| 12:48.07 | brlcad | yep |
| 12:48.19 | mafm | goody |
| 12:48.19 | brlcad | it really is just an upside down mouse |
| 12:48.38 | mafm | and the rotations are discrete, as in blender? |
| 12:48.59 | brlcad | discrete in what way? |
| 12:49.20 | mafm | in that with each key stroke means 15 degrees or whatever |
| 12:49.24 | brlcad | the rotations are whatever you make the bindings do :) |
| 12:49.35 | mafm | currently my orbital mode acts almost in the same way, just that it's continuous |
| 12:49.48 | mafm | and has the vertical glitch |
| 12:50.08 | brlcad | key stroke? i don't have any keys on my trackball |
| 12:50.16 | brlcad | lots of buttons, but no kesy |
| 12:50.31 | mafm | I'm now talking about trackball, the mode :D |
| 12:51.08 | mafm | is the one that implements blender, IIRC from your conversation yesterday |
| 12:51.17 | mafm | and to move the camera, you use the numpad |
| 12:54.30 | mafm | so the difference between blender an mine is: |
| 12:55.28 | mafm | in blender) each keypressed event acts as a trigger, and makes 30 degrees of rotation or so; if you maintain it pressed it for longer time it rotates for that while, but in discrete steps of same 30 degrees |
| 12:56.22 | brlcad | mged behaves that way too, discrete vertical/horizontal view rotations |
| 12:56.31 | brlcad | though I think we're about 5 degrees |
| 12:56.36 | mafm | in mine) keypressed and released act as on a switch, and the rotation is "continuous" (from when you press until when you release); the camera position is updated every loop of the renderer |
| 12:58.10 | mafm | 360 / ~24 steps for full revolution = 15 degrees |
| 12:58.11 | brlcad | press x/y/z/X/Y/Z/0 in mged graphics window, you get that |
| 12:58.40 | brlcad | that'd be the shift-grips/mged binding style of course |
| 13:00.35 | mafm | shift-grips? we were talking about trackball |
| 13:00.45 | brlcad | be sure to peek at blender's View -> View Navigation menu |
| 13:01.11 | brlcad | sure, just commenting that they're there |
| 13:01.21 | brlcad | so you can test it out |
| 13:02.15 | mafm | erm... so the mged and blender are very different |
| 13:03.33 | brlcad | oh sure |
| 13:03.49 | brlcad | blender is a heck of a lot different than most modeling guis, much less a cad gui |
| 13:04.13 | mafm | so my orbital mode is different than both |
| 13:04.24 | mafm | do you want me to mimic brlcad's, I guesS? |
| 13:04.34 | mafm | brl-cad's, I mean :) |
| 13:05.04 | mafm | or rather, mged's |
| 13:06.08 | brlcad | if you set it up right, the only different between shift-grips, blenders, and your orbital mode is default bindings -- the same operations are pretty much available to all of them (just via different bindings or unspecified) |
| 13:06.42 | brlcad | so you really just have to focus on the events/actions that can be bound, and managing sets of bindings as an input style set |
| 13:08.03 | mafm | yes, eventually I'd create the generic operations in the base class |
| 13:08.45 | mafm | but the question is: do you want me to create Trackball and Shif-grips with exactly the same keys and behaviours than mged? |
| 13:11.55 | brlcad | hm, actions that come to mind... pan up/down, pan left/right, pan freely, rotate horizontally left/right, rotate vertically up/down, rotate freely, fly navigation, zoom in, zoom out -- and all as continuous/quasi-modal or discrete events |
| 13:13.10 | brlcad | well, at least mimic'ing shift-grips .. beyond that whatever else you like |
| 13:13.40 | mafm | well, that shift-grips is quite... complete :D |
| 13:13.58 | brlcad | I would recommend blender's default bindings as another predefined, but up to you |
| 13:14.11 | brlcad | shift-grips should cover most any interaction except a fly mode |
| 13:14.42 | mafm | the bindings for the different modes are switchable, or all of them are present at the same time? |
| 13:14.55 | brlcad | forget about "trackball" as a mode -- what was mostly meant by that was a mode where left-mouse+drag bound to "rotate view" |
| 13:15.06 | mafm | switchable as "only one active at a given time" |
| 13:15.18 | brlcad | blender's is pretty close to that, they use middle mouse for rotate view |
| 13:16.09 | brlcad | only one active at a given time |
| 13:16.20 | brlcad | they can't be active simultaneously, the bindings are entirely different |
| 13:16.41 | mafm | I find your trackball mode -or whatever you call to the x/y/z/0- very funny :D |
| 13:17.43 | brlcad | middle-mouse+drag is what I was referring to as a "trackball" view manipulation, btw .. and a pretty good implementation |
| 13:18.16 | brlcad | (in blender) |
| 13:19.44 | mafm | So... to make things clear, what should I implement for my trackball? Blender middle-mouse+drag and x/z/y/0 for axial rotation? |
| 13:23.42 | brlcad | control+(any)-mouse+drag in mged == middle-mouse+drag in blender == 'view rotation' == 'trackball view rotation' |
| 13:24.53 | brlcad | make a 'mafm' style, have it do whatever you want :) |
| 13:24.57 | mafm | OK, but I mean exactly which keys do you want :) |
| 13:25.18 | mafm | I already have my style, it's the orbital one -- which is very similar in essence |
| 13:25.19 | brlcad | have an 'mged' style that is effectively shift-grips as close as you can get it |
| 13:26.21 | brlcad | then maybe add a 'blender' style that is as close to blender as possible (not hybridized with 'mged' bindings, that just makes it confusing and error-prone) |
| 13:27.54 | brlcad | if you have those three with a relatively straightforward way to define new styles, any one of those three styles would be more than enough |
| 13:28.45 | mafm | okish, thanks :) |
| 13:31.15 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 13:37.17 | mafm | hi d_rossberg |
| 13:42.12 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 13:43.26 | d_rossberg | moin mafm |
| 14:52.31 | *** join/#brlcad andrecastelo (n=chatzill@189.71.36.28) | |
| 14:52.33 | andrecastelo | hey guys |
| 14:52.41 | pacman87 | hi andrecastelo |
| 14:52.49 | andrecastelo | hi pacman87 |
| 14:53.09 | mafm | hi |
| 14:56.08 | andrecastelo | hey mafm |
| 15:01.36 | mafm | heyo |
| 15:01.59 | mafm | too hot cold there in Brazil? :P |
| 15:12.24 | andrecastelo | it's raining now :S |
| 15:14.20 | mafm | at Lisbon it's 30+ degrees |
| 15:14.29 | mafm | and it's a cold summer, fortunately :D |
| 15:21.14 | d_rossberg | moin pacman87, now the revolve ray-trace works for me too :) |
| 15:22.30 | d_rossberg | (if not along a coordinate axis) |
| 15:26.57 | mafm | svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svnroot/brlcad/!svn/act/683d9f64-d642-4309-846b-f929d2cad1b5' |
| 15:26.59 | mafm | ? |
| 15:27.31 | mafm | fascist pigs, they forbid me to commit!!!111! :P |
| 15:29.55 | *** join/#brlcad docelic (n=docelic@78.134.201.183) | |
| 15:30.41 | prasad_ | brlcad: so i started working out again |
| 15:30.57 | prasad_ | after a ~1 yr hiatus |
| 15:31.02 | prasad_ | :) |
| 16:00.12 | *** join/#brlcad clock_ (n=clock@77-56-95-207.dclient.hispeed.ch) | |
| 16:01.40 | mafm | hi clock_ |
| 16:01.48 | mafm | is anybody else having problems with commiting? |
| 16:05.14 | mafm | even google accounts are failing |
| 16:05.39 | mafm | it might be a sign of the Apocalypsis or something... |
| 16:11.32 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 17:05.42 | mafm | brlcad: is there a way for you to check svn logs? |
| 17:07.33 | mafm | oh, it seems that it's an scheduled downtime |
| 17:13.16 | poolio | mafm: so svn on sf.net is down? |
| 17:15.01 | mafm | read-only, they are migrating to a new datacenter, it seems |
| 17:19.55 | mafm | poolio: http://sourceforge.net/community/forum/topic.php?id=2874&page |
| 17:51.17 | brlcad | wb andrecastelo |
| 17:51.50 | brlcad | andrecastelo: any new progress, working on depth-based lighting or shadows next? |
| 17:52.08 | brlcad | mafm: sourceforge svn is down for the next 6 hours or so |
| 17:52.23 | brlcad | sourceforge is moving svn to their new datacenter in chicago today |
| 17:52.26 | andrecastelo | i was thinking about starting some kind of prototype path tracing system, what do you think? |
| 17:52.32 | mafm | >:[ |
| 17:52.47 | mafm | so no more commits today, now that I have lots and lots of new things |
| 17:53.13 | brlcad | mafm: yeah, I didn't realize it was today or I would have sent out a note |
| 17:58.14 | andrecastelo | do you think i should improve the shading or start the path building?? |
| 17:58.52 | brlcad | I think you should do at least shadows just so you see how to shoot secondary rays |
| 18:10.20 | andrecastelo | hm ok, ok |
| 18:10.28 | mafm | I received some random crap from sf.net yesterday but I didn't even bother to read it |
| 18:10.37 | mafm | too much mail :| |
| 18:10.48 | andrecastelo | have classes now |
| 18:10.52 | andrecastelo | later guys |
| 18:11.15 | pacman87 | mafm: that's why i switched the gsoc mail to 'digest' |
| 18:11.35 | mafm | the gsoc I read in less than 30 seconds |
| 18:12.26 | mafm | basically I click next next next and read the subject in the split second :) |
| 18:12.54 | pacman87 | it'd be nice if i could flag the mail from LH and other official google people |
| 18:13.01 | pacman87 | to make sure i dont' miss anything important |
| 18:13.18 | mafm | it's no so easy with other mails that I have to reply... but yes, gsoc lists are annoying :D |
| 18:14.19 | pacman87 | i treat it as a forum instead of a mailing list |
| 18:18.47 | mafm | I basically don't read anything |
| 18:19.01 | mafm | just the initial mail of the thread if it's from LH |
| 18:19.18 | mafm | and then only some specific if it interests me |
| 18:32.38 | ``Erik | %*d? when did that happen? O.o |
| 18:33.02 | pacman87 | ``Erik: hmmm? |
| 18:34.44 | ``Erik | printf("%*d", x, y); |
| 18:44.50 | mafm | neat-o |
| 18:55.45 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 18:56.15 | mafm | hi Ralith |
| 19:06.23 | Ralith | oh hey! |
| 19:06.36 | Ralith | needs to make his irssi highlight better. |
| 19:08.11 | Ralith | mafm: I, along with at least part of the reprap community, am quite interested in your GUI work; myself to the extent of a desire to contribute. |
| 19:09.34 | mafm | yep, brlcad told me a bit about it |
| 19:09.55 | Ralith | cool |
| 19:10.24 | mafm | that's the reprap of http://reprap.org/bin/view/Main/WebHome ? |
| 19:10.27 | Ralith | yeah |
| 19:12.01 | mafm | that's an interface for a 3D printer? |
| 19:12.58 | Ralith | it *is* a 3D printer. |
| 19:13.44 | mafm | :D |
| 19:14.05 | mafm | neat |
| 19:14.14 | mafm | and what does my project have to do with that? |
| 19:15.24 | mafm | are you already using BRL-CAD to design it or something? |
| 19:15.27 | Ralith | well, I'll give a bit of background |
| 19:15.59 | mafm | please :) |
| 19:16.01 | Ralith | reprap is supposed to be completely open source |
| 19:16.17 | Ralith | so we can't standardize on professional CAD packages |
| 19:16.29 | Ralith | (there's very good reasons for this which aren't entirely relevant; we can get into that later) |
| 19:16.59 | Ralith | currently, we're standardized on this kinda shitty java mesh modeler called Art of Illusion that afaik nobody likes much. |
| 19:17.36 | Ralith | however, there's no argument that that's really a good tool for CAD/CAM |
| 19:18.00 | Ralith | it's just something like the first oss modeler that the founders ran into |
| 19:18.20 | Ralith | now lately, people have been hitting its limitations and starting to search for alternatives |
| 19:18.54 | Ralith | but, as you may or may not be aware, there really aren't any open source CAD tools worth mentioning; let alone professional quality ones. |
| 19:19.00 | Ralith | Except for BRL-CAD. |
| 19:19.20 | mafm | not even k-3d? |
| 19:19.50 | Ralith | k-3d states from the start that it's meant for animation :P |
| 19:20.21 | Ralith | BRL-CAD has the additional advantage of its purist CSG approach, which is great because of the level of precision it maintains. |
| 19:21.04 | Ralith | to put this in perspective, AoI is so inappropriate that the founders actually modeled some of the current reprap design using professional CAD tools isntead, and just exported to an open format. |
| 19:21.14 | Ralith | STL |
| 19:21.28 | Ralith | which is another bad choice, because conversion to trimeshes loses precision. |
| 19:21.49 | mafm | I thought that they had added (or wanted to, maybe it was some gsoc project) to get into other modelling, but I know mostly zero about that so I shut up :D |
| 19:22.11 | Ralith | well, we want something as professional quality as we can get |
| 19:22.31 | Ralith | and BRL-CAD seems to be nothing if not professional. |
| 19:22.43 | Ralith | however, its interface is very tangibly from the 1980s. |
| 19:23.03 | Ralith | one of reprap's goals is to be widely and easily accessible. |
| 19:23.33 | Ralith | Standardization on a CAD suite with such an arcane modeling interface would conflict with that. |
| 19:23.43 | Ralith | as attractive as the technology behind the interface may be. |
| 19:24.27 | Ralith | So, your SoC project seems to be the solution to all our worries. |
| 19:25.03 | mafm | goody :D |
| 19:25.21 | Ralith | especially since, imo, a tried and true back-end with a newly developed interface is much more suitable than a tried-and-true interface with newly developed CAD support. |
| 19:25.24 | mafm | I'm very glad to hear that it can be helpful for you |
| 19:25.30 | Ralith | besides, you don't get much more tried-and-true than BRL-CAD. |
| 19:25.41 | Ralith | far more than us, I'm sure |
| 19:26.10 | Ralith | there's a *lot* of people out there who would benefit from professional and accessible open source CAD. |
| 19:26.15 | mafm | did you already try it? it's in very initial state... |
| 19:26.26 | Ralith | I haven't built it yet |
| 19:26.31 | Ralith | but I've reviewed your log |
| 19:27.25 | mafm | :D |
| 19:27.57 | mafm | well, if you have some sort of GNU/Linux (or even BSD) variant, should be quick easy to get it running |
| 19:27.57 | Ralith | I'm quite eager to lend whatever aid I can. |
| 19:28.02 | *** join/#brlcad philipix (n=c91adbe1@bz.bzflag.bz) | |
| 19:28.02 | Ralith | I'm on FreeBSD |
| 19:28.21 | Ralith | luckily, the larger of your deps are in ports |
| 19:28.53 | mafm | I think that you mostly need some image library like DevIL |
| 19:29.00 | Ralith | that'll be in ports too. |
| 19:29.05 | Ralith | I was talking about ois and ogre |
| 19:29.24 | Ralith | I'll be submitting a patch for ois freebsd compatibility despite this |
| 19:29.58 | mafm | $ aptitude show libogre-dev |
| 19:29.59 | mafm | ... |
| 19:30.07 | Ralith | ? |
| 19:30.08 | mafm | Depends: libfreeimage-dev | libdevil-dev, libfreetype6-dev, libogremain-1.4.6 (>= 1.4.6.dfsg1-1), libopenexr-dev, |
| 19:30.08 | mafm | <PROTECTED> |
| 19:30.34 | Ralith | deps are not an issue :P |
| 19:30.37 | mafm | I think that these are the only dependencies needed, apart from std C++ things |
| 19:30.38 | Ralith | at least, I don't think so |
| 19:30.47 | brlcad | Ralith: interesting background interest |
| 19:31.01 | Ralith | I haven't tried building your versions of rbgui or mocha yet |
| 19:31.04 | Ralith | brlcad: I think so. |
| 19:31.10 | mafm | and apart from that, the rest of the things that you need is just contained in src/other :D |
| 19:32.26 | brlcad | Ralith: if you're interested in our long-term project goals, I wrote up an overly wordy document that you might find interesting .. it's being completely restructured and reworded, but it captures a fair bit even with the layout/temp state that it's in |
| 19:32.39 | Ralith | brlcad: I would be interested in that. |
| 19:33.01 | mafm | I think that RBGui and Mocha don't depend on anything but standard C++ libraries |
| 19:33.33 | Ralith | yeah, but you never know |
| 19:33.43 | Ralith | besides, what you think is standard is often moved around in FreeBSD |
| 19:33.57 | mafm | oh, you need pkg-config too |
| 19:34.03 | mafm | is fan of pkg-config :P |
| 19:34.03 | Ralith | who doesn't have pkg-config? |
| 19:34.07 | brlcad | Ralith: http://brlcad.org/~sean/BRL-CAD_Priorities.png (there's a .pdf too, but many renderers do a horrible job on the fonts it's using) |
| 19:34.23 | mafm | well, I had an argument with postgresql guys a while ago, they're not so fans of it :D |
| 19:34.45 | Ralith | oo, neat layout |
| 19:34.52 | brlcad | again, not really intended for public consumption as it's going to change a fair bit, but it's the high-high-level project overview of what I'm trying to focus on |
| 19:35.22 | Ralith | by the way, I've been curious: you're the maintainer, right? Just how did you end up as such? |
| 19:36.33 | brlcad | dedication, years of keeping the flame alive |
| 19:36.54 | brlcad | I really do love working on BRL-CAD -- it has so much potential and so much existing powerful functionality |
| 19:37.35 | brlcad | just not-so-great usability for the newcomer, hence the focus on gui enhancements, brep (for visualization), and open source |
| 19:39.33 | mafm | and weeks of wasting time talking with prospective gsocers |
| 19:39.40 | mafm | :P |
| 19:39.42 | Ralith | hehe |
| 19:40.10 | Ralith | did you have anything to do with it when it was still proprietary? |
| 19:40.48 | mafm | warns: if SourceForge doesn't reenable commits now, you're all going to miss my wonderful new Blender mode... SF, we're watching you |
| 19:41.03 | Ralith | Blender mode? |
| 19:41.10 | Ralith | camera control? |
| 19:41.13 | mafm | yep |
| 19:41.15 | Ralith | oo, fun |
| 19:41.19 | mafm | <PROTECTED> |
| 19:41.19 | mafm | 1046 |
| 19:41.20 | Ralith | blender has good camera control |
| 19:41.41 | Ralith | learned mesh modeling in blender |
| 19:41.55 | mafm | just that I'm making it "continuous" |
| 19:42.13 | Ralith | I'm not sure what that means |
| 19:42.27 | mafm | unless somebody has something against, I think that it's more practical and easier to implement :D |
| 19:42.48 | mafm | that instead of jumping 30 degrees when you click the numpad keys, it does so in a continuous way |
| 19:43.04 | mafm | turning slowly while you maintain the key pressed |
| 19:43.15 | Ralith | hm |
| 19:43.25 | Ralith | well, first, an interface design thought |
| 19:43.45 | Ralith | for all inputs that produce continuous movement, make it be *accelerated*, not constant rate of change. |
| 19:43.52 | Ralith | this is extremely useful since scale can vary so much |
| 19:44.11 | Ralith | makes it easy to quickly achieve the state that is desired, no matter how numerically distant it is from the current one |
| 19:44.43 | Ralith | for example, I recently implemented a spinner widget for a GUI project I'm on that does this in all cases; imo it's just that useful. |
| 19:44.59 | Ralith | I can't think of a case where it *wouldn't* be helpful. |
| 19:45.31 | Ralith | of course, one must be careful to keep the acceleration from being too sharp, else there's not enough control. |
| 19:45.31 | mafm | the zoom already works like this |
| 19:45.35 | Ralith | great! |
| 19:45.39 | mafm | it has an increment ratio |
| 19:45.47 | Ralith | oh yeah, promise me you'll rip off blender's grid system |
| 19:45.53 | Ralith | I *love* blender's grids |
| 19:46.40 | Ralith | (except don't bother implementing blender's upper and lower limits to grid size; I can't imagine why you'd want those) |
| 19:46.43 | mafm | and I hate the linear spinners too :D |
| 19:46.47 | Ralith | :D |
| 19:47.04 | Ralith | and now a more direct response |
| 19:47.13 | Ralith | blender uses fixed increments for a good reason imo |
| 19:47.21 | Ralith | it allows one to easily go to a specific perspective |
| 19:47.22 | mafm | well, I don't have almost any experience modeling, so I don't know what would be useful and what not |
| 19:47.36 | mafm | I largely follow orders/ideas/suggestions :D |
| 19:47.48 | Ralith | I've got moderate experience; I'm not a real modeler, but I've done a lot of experimentation and produced some not entirely boring works. |
| 19:48.08 | Ralith | I've got enough experience to know that blender does a lot of things right. |
| 19:48.46 | mafm | :) |
| 19:49.05 | Ralith | so if you're using that as a template for some parts, that's a good sign, imo |
| 19:49.19 | pacman87 | https://webspace.utexas.edu/trv82/www/explode.avi |
| 19:49.20 | mafm | this part is only the camera mode, which with some keys it orbits the object, with mouse drag rotates around freely |
| 19:49.31 | mafm | probably you'll have more requests in the near future :) |
| 19:49.37 | Ralith | mafm: define 'the object' |
| 19:49.43 | Ralith | sure you don't mean the origin? |
| 19:50.06 | mafm | at the moment it is, but eventually it'll pan :D |
| 19:50.23 | Ralith | I suggest a blender-style 'center camera at point' command |
| 19:50.44 | Ralith | also, 'center camera at selected object(s)'s origin' |
| 19:50.59 | mafm | I still only with camera modes this week, or the last day of the past one :) |
| 19:51.11 | Ralith | that plus orbit-style movement plus optional drawing of objects would probably cover most use cases already |
| 19:52.08 | Ralith | anyway, if you want to go for continuous camera movement, that's cool, but maybe you should include a toggle button or a keyboard bind for incremental movements of various fractions of 90 degrees? |
| 19:52.18 | mafm | the center on object is just a matter of setting the object as focused |
| 19:52.35 | mafm | I initially thought of that but it was half implemented, so I removed the little code |
| 19:52.48 | mafm | but it's easy to read when I know exactly what we want to do |
| 19:52.57 | Ralith | ll |
| 19:52.58 | Ralith | kk |
| 19:53.34 | mafm | maybe I'll just keep orbital mode as blender-like but continous, and blender as exactly blender |
| 19:53.43 | Ralith | also, my OIS patch is ready -- where's the best place for it? |
| 19:53.49 | pacman87 | anyone here used davfs2? |
| 19:54.18 | mafm | I'm just implementing functionality at this moment, defining bindings it's mostly a detail when infrastructure is in place :) |
| 19:54.29 | mafm | pacman87: no |
| 19:54.35 | Ralith | mafm: ooh, here's a neat idea for non-priority implementation that'll make continuous (and imprecise) movement useful: allow save/restore of multiple camera positions |
| 19:54.58 | Ralith | enjoys coming up with features |
| 19:55.05 | Ralith | put up with me long and your TODO list will double :> |
| 19:55.25 | mafm | Ralith: the patch maybe you could send to OIS guys themselves... IIRC the main devel lurks around in #ogre3d and the nickname starts with p :) |
| 19:55.40 | mafm | and we would have to apply it for it to work in src/other, too |
| 19:55.51 | Ralith | mafm: it's an inelegant patch that references your build system |
| 19:56.15 | Ralith | appropriate for making things work, but not so much for upstream application |
| 19:56.25 | Ralith | I've #ifdef'd out three whole files :P |
| 19:56.46 | Ralith | (only has any effect on FreeBSD, of course) |
| 19:56.53 | mafm | http://rafb.net/paste, please? |
| 19:56.56 | Ralith | sure |
| 19:57.10 | mafm | what's the error in BSD (and the compiler?) |
| 19:57.33 | Ralith | it's just the removal of linux-specific stuff |
| 19:58.09 | Ralith | http://rafb.net/p/Jz5kv519.html |
| 19:58.45 | Ralith | oh, and some X input handling stuff I'm not sure I follow, but which was used in the ports version. |
| 19:59.33 | mafm | huh... I think you need those linux files, because AFAIK they call linux to whatever using X.org |
| 19:59.42 | Ralith | huh? |
| 20:00.00 | Ralith | these files are cut straight out of the build process by the ports version |
| 20:00.03 | Ralith | they're not critical at all. |
| 20:00.34 | Ralith | note that only the first three effected files are completely #ifdef'd out |
| 20:01.31 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 20:02.19 | mafm | well, I'm not sure, whatever works for you :) |
| 20:02.49 | Ralith | the patch has no effect on non-FreeBSD anyway |
| 20:02.58 | mafm | but I guess that you could try to refine it and send it upstream, and then we can upload whatever new version to OIS -- new versions of OIS shouldn't break anything |
| 20:03.57 | Ralith | hm. I don't suppose you're familiar with pthreads? |
| 20:05.02 | mafm | not much, only generically with threads, but also not very very deeply :D |
| 20:05.14 | Ralith | hm. |
| 20:05.14 | mafm | svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svnroot/brlcad/!svn/act/6f51664b-be0d-4203-96a0-6a780e9db359' -- OK, so no more work today :) |
| 20:05.25 | Ralith | aw. |
| 20:06.02 | mafm | I have to go home anyway, it's already night here :) |
| 20:07.29 | Ralith | alright, seeya |
| 20:07.39 | mafm | I'll commit in ~14 hours or so, I guess :) |
| 20:07.46 | ``Erik | known issue, they're migrating their server from cali to chicago |
| 20:07.54 | ``Erik | so read only |
| 20:07.57 | Ralith | brlcad: I don't think you answered -- did you have anything to do with it when it was still proprietary? |
| 20:08.03 | Ralith | (brlcad) |
| 20:08.07 | Ralith | (er, BRL-CAD) |
| 20:08.39 | mafm | Ralith: I look forward to get it working, you'll be the second after other gsocer homovulgaris :) |
| 20:08.40 | ``Erik | brlcad has been working on BRL-CAD for almost a decade I think? long before it went out to the public |
| 20:08.42 | mafm | see you |
| 20:08.51 | Ralith | oo, neat |
| 20:09.00 | Ralith | seeya |
| 20:09.11 | Ralith | fixing up mocha now |
| 20:09.20 | ``Erik | (you could kinda argue it was always open source, you had to fax in a license agreement, then got an encrypted tarball of the source sent to you... wasn't redistributable back then, though) |
| 20:09.22 | ``Erik | :D |
| 20:09.27 | Ralith | this one *will* be upstream-worthy |
| 20:09.57 | Ralith | ``Erik: any idea how much brl-cad is used professionally these days, if at all? |
| 20:10.05 | Ralith | also, any idea what brought about the opensourcing? |
| 20:12.05 | ``Erik | um, several people at ARL and survice are paid to use BRL-CAD, I think beoing uses it some, air force uses it a bit, probably many others |
| 20:12.17 | brlcad | Ralith: yes, I've worked on BRL-CAD for about 10 years now, long before it was open source |
| 20:12.38 | ``Erik | and we're a bunch of open source geeks who got enough gumption to push it through the beaurocracy to get it 'public release' status |
| 20:12.46 | ``Erik | rather, brlcad and butler pushed it... :) |
| 20:12.46 | Ralith | cool! |
| 20:12.56 | Ralith | many kudos to them, then |
| 20:13.00 | brlcad | I worked persistently for about 5 years to get BRL-CAD released as open source, it was one of two goals I had from the start |
| 20:13.13 | Ralith | that must have taken a lot of pushing |
| 20:13.40 | Ralith | are you being employed as brl-cad's maintainer, or is it something you do on your own? |
| 20:16.40 | brlcad | Ralith: best place for patch is our sf.net patches tracker (reading backlog) |
| 20:16.50 | Ralith | kk |
| 20:28.26 | Ralith | uploaded |
| 20:57.53 | Ralith | augh |
| 20:57.55 | Ralith | so close |
| 20:58.13 | Ralith | rbgui refers to some ogre func that's missing in the more recent version I have installed |
| 21:05.19 | Ralith | temp-workarounds by building the rt^3 version of ogre |
| 21:05.46 | Ralith | ...which fails. >:| |
| 21:34.47 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 21:52.26 | pacman87 | https://webspace.utexas.edu/trv82/www/rev_rt15.png & https://webspace.utexas.edu/trv82/www/rev_wf06.png |
| 21:52.43 | pacman87 | wireframe upgrades for open sketches |
| 21:53.05 | pacman87 | now includes the lines that i added to close the sketch |
| 21:54.59 | Ralith | oo |
| 21:55.03 | Ralith | now just make that work for all primitives :> |
| 21:55.34 | pacman87 | Ralith: hmm? |
| 21:55.43 | Ralith | or wait |
| 21:55.47 | Ralith | wrong person |
| 21:55.47 | pacman87 | revolve takes in an arbitrary sketch |
| 21:55.51 | Ralith | all you p named people >:| |
| 21:56.10 | Ralith | anyway, looking nice! |
| 21:56.15 | pacman87 | ty |
| 21:56.25 | Ralith | can you define smooth curves in the sketch? |
| 21:56.30 | Ralith | or is it point-line only? |
| 21:56.48 | pacman87 | yes, lines, carc, bezier, and nurbs |
| 21:56.59 | pacman87 | though lines are the only ones working now |
| 21:57.20 | Ralith | so long as it's coming |
| 21:59.43 | poolio | Ralith: *achem* |
| 22:00.06 | starseeker | yay! |
| 22:00.18 | starseeker | can now parse core-001a.s into pieces |
| 22:00.45 | Ralith | poolio: sup |
| 22:00.47 | Ralith | :] |
| 22:27.22 | brlcad | Ralith: sorry, disappeared at 16:16 -- to answer your question -- it's something I predominantly do on my own, though I am (also) employed to work on BRL-CAD |
| 22:27.43 | Ralith | kk |
| 22:27.50 | Ralith | sounds pretty nice |
| 22:29.03 | brlcad | starseeker: nifty, using % parsing? |
| 22:31.43 | starseeker | not really (yet) - just a string with 4 key characters |
| 22:31.47 | brlcad | pacman87: interesting .. I think that's the first primitive that has a "self-intersecting" wireframe other than an invalid nmg/bot |
| 22:32.10 | starseeker | not sure if there is a reason to allow anything other than those 4, and if so % is not needed |
| 22:33.25 | pacman87 | i'd probably look better with a circular arc at the sketch's self-intersection point, but i'm not sure if that's worth the extra computation to find the intersection points |
| 22:33.25 | brlcad | "those four" being? |
| 22:34.09 | brlcad | for polyline/ployline, computing self-intersections is trivial :) |
| 22:34.32 | brlcad | nurbs-nurbs is probably the hardest |
| 22:35.03 | starseeker | n is for name substrings, i is for incremented regions, s is for separators, and e is for extension |
| 22:35.20 | starseeker | so core-001a.s would be nsinse |
| 22:38.24 | brlcad | how do you control how much padding? |
| 22:38.41 | starseeker | you mean 001 vs 01? |
| 22:39.17 | brlcad | sure |
| 22:40.07 | starseeker | That has to be a function of how many are ultimately needed to pad out to the maximum requested by the calling command - the larger of the supplied default (3 if in the core example you only wanted 10) or the minimum required by the maximum case (say, 5 if you wanted 10000) |
| 22:41.12 | starseeker | is currently trying to figure out how to use itoa to coax a string length out of a supplied integer |
| 22:41.31 | brlcad | withholds comments until he's let the brain enfeed some dinner |
| 22:51.38 | ``Erik | /nick p``Erik |
| 22:57.14 | PrezKennedy | golden corral! |
| 22:58.32 | pacman87 | brlcad: i wouldn't really expect too many sketches to be self-intersecting, anyway |
| 23:08.02 | *** join/#brlcad jonored (n=jonored@c-24-34-212-39.hsd1.ma.comcast.net) | |
| 23:09.34 | ``Erik | heh, old people food? :D |
| 23:17.41 | *** join/#brlcad clock_ (n=clock@77-56-92-145.dclient.hispeed.ch) | |
| 23:33.40 | *** join/#brlcad Ralith (n=chatzill@216.162.199.202) | |
| 23:57.55 | CIA-22 | BRL-CAD: 03starseeker * r31850 10/brlcad/trunk/src/librt/namegen.c: |
| 23:57.55 | CIA-22 | BRL-CAD: Upload (very) early stage work for functions intended to provide consistent |
| 23:57.55 | CIA-22 | BRL-CAD: automatic naming for tools that need it. Currently working on parsing a |
| 23:57.55 | CIA-22 | BRL-CAD: supplied primitive name into components based on a format string - routines will |
| 23:57.55 | CIA-22 | BRL-CAD: probably need to become more general. |
