| 00:01.26 | brlcad | is to blame |
| 00:03.05 | Ralith | blames brlcad |
| 00:03.16 | Ralith | so what are they? |
| 00:03.55 | brlcad | it looks like we very likely may end up adopting maintenance of a gui toolkit (whether it be rbgui, cegui, llmozlib, fork of blender's, whatever) to have something maintainable that will serve the long-term design criteria |
| 00:04.24 | Ralith | blender's GUI is libifyable? |
| 00:04.30 | Ralith | 'cuz they have a *very* nice GUI, iirc. |
| 00:04.42 | Ralith | (at least, I liked it) |
| 00:04.44 | brlcad | any code is libifyable |
| 00:04.54 | Ralith | libifyable for sane effort, that is |
| 00:05.48 | brlcad | given the scope and goals of the task, with one of the viable options being the near rewrite or unfinished implementation of one of the alternatives, a major refactoring becomes sane |
| 00:06.57 | Ralith | fair. |
| 00:08.57 | brlcad | as for "bars of color", don't know what you were referring to |
| 00:09.21 | Ralith | http://bzflag.org/~mafm/g3d-screenshots/brlcad_rbgui_20080824-1.png |
| 00:09.32 | Ralith | below the X/Y/Z rot numbers |
| 00:10.33 | brlcad | oh |
| 00:11.02 | brlcad | just guessing, but looks like progress bars representing the numeric 0->360 rotation value |
| 00:11.29 | Ralith | ah. |
| 00:11.49 | Ralith | in that case I'm still a bit confused as to what that dialog is testing |
| 00:13.21 | brlcad | I think conceptually, it was more just visual placement of items to test that rbgui could even do the basics |
| 00:13.27 | mafm | sorry for the delay Ralith |
| 00:13.33 | Ralith | no worries |
| 00:13.35 | mafm | yes, those are the things |
| 00:13.36 | brlcad | pop up a window with buttons, sliders and events, invoke actions, etc |
| 00:13.55 | Ralith | that seemed odd to me 'cuz of all the earlier screenshots showing more advanced tests |
| 00:14.25 | brlcad | Ralith: have you seen the IOE prototype? that has several design criteria that are very relevant for the new gui design |
| 00:14.41 | Ralith | I watched a bit of the presentation video |
| 00:14.45 | brlcad | k |
| 00:15.01 | mafm | they're RBGui::Widgets, specialized for the task (albeit very simple) |
| 00:15.09 | mafm | so if a text widget has setText, etc |
| 00:15.33 | mafm | these ones have the "setProgress" and "setLabel" and so on |
| 00:15.46 | mafm | so you can put that as a widget in any part, not having to create it anew |
| 00:16.24 | mafm | that's like creating a dialog window to be used in many places of the program, provided that the toolkit doesn't already provide one |
| 00:16.37 | Ralith | brlcad, seems like a nice set of concepts, but pretty divergent from standard paradigms |
| 00:16.44 | Ralith | then again, what 3D modeler isn't? |
| 00:17.00 | mafm | so it's not testing advanced features, it's just extending a widget to create a simple one |
| 00:18.53 | Ralith | hmm |
| 00:20.18 | Ralith | I wonder if blender could actually be easily extended to interact with the geometry service itself |
| 00:21.00 | Ralith | I suppose it's a bit focused upon mesh modeling for that to be entirely appropriate. Still, interesting thought. |
| 00:23.34 | mafm | btw brlcad, there's a new GUI on the block |
| 00:24.09 | mafm | althought quite new and still has to prove that it's worthy |
| 00:24.19 | mafm | osgWidgets, from OpenSceneGraph |
| 00:24.48 | brlcad | mafm: there's more than one |
| 00:25.02 | brlcad | I was just about to mention/remind the one I saw at siggraph this year |
| 00:25.09 | brlcad | from one of the g3d developers |
| 00:25.17 | brlcad | (the graphics engine) ;) |
| 00:25.38 | brlcad | http://graphics.cs.williams.edu/papers/GuiUniversalSIGGRAPH08/gui-poster.pdf |
| 00:25.38 | mafm | GNU 3D? :) |
| 00:26.42 | brlcad | http://graphics.cs.williams.edu/papers/GuiUniversalSIGGRAPH08/ |
| 00:27.32 | Ralith | oh hey |
| 00:27.35 | Ralith | now that's a neat concept |
| 00:27.36 | brlcad | figure 2 is a nice collage of the various features |
| 00:28.16 | Ralith | I want to play with this now |
| 00:28.17 | brlcad | the developer that worked on that is morgan mcguire, the code is bsd licensed |
| 00:28.30 | Ralith | yay! |
| 00:28.45 | brlcad | he said he thinks it'd take about a month for someone to port it to ogre |
| 00:28.54 | brlcad | (knowing nothing) |
| 00:29.11 | Ralith | oh right ogre |
| 00:29.12 | Ralith | damn |
| 00:29.31 | brlcad | it's already in the g3d engine, you can play with it there |
| 00:30.18 | Ralith | think that might be a viable ogre alternative long-term? |
| 00:30.43 | brlcad | not really |
| 00:30.51 | brlcad | ogre still has *way* more momentum and activity |
| 00:30.54 | Ralith | why's that? |
| 00:31.17 | Ralith | hm, scope is a bit large |
| 00:32.22 | mafm | WTH is universal pointer pattern? :) |
| 00:33.11 | Ralith | mafm, it's explained; seems to mean that you bind widgets directly to vars |
| 00:33.31 | mafm | yes, but it's such a new pattern that google doesn't know about it |
| 00:33.42 | mafm | I need to find a new oracle :) |
| 00:34.29 | madant | is still a 6 minute miler :( |
| 00:35.01 | louipc | that's decent |
| 00:36.15 | louipc | wow the world record is down to 3:43 |
| 00:36.26 | brlcad | that's just his fangled name for a concept that's been around for a while (though I forget the other names it goes by) |
| 00:36.39 | brlcad | you can do the same thing in tk actually, aqua too |
| 00:38.13 | madant | louipc: i think 5km in 12.37 minutes is even more freaky |
| 00:38.45 | louipc | oh yea |
| 00:47.37 | mafm | so what's the plan brlcad, test that one also? |
| 00:47.44 | mafm | it's separated in a lib already? |
| 00:48.24 | madant | too thinks Morgan McGuire's idea is neat |
| 00:48.36 | Ralith | doesn't make a good GUI alone though |
| 00:51.38 | madant | this work of mcguire looks neat too :) http://graphics.cs.williams.edu/projects/YangFan/about.html |
| 00:51.55 | brlcad | mafm: I think it would be good for someone(tm) should test that one out -- especially if it really is just a month's work to port it on over |
| 00:52.08 | Ralith | I still like the idea of Blender's GUI; it's had a lot of refinement for use with a similar set of requirements |
| 00:52.33 | brlcad | but sorting out the gui is still secondary to completing the gui infrastructure and engine/service work |
| 00:52.52 | Ralith | gui infrastructure? |
| 00:53.06 | Ralith | 'course, no point having a shiny GUI without the geometry service to back it |
| 00:53.32 | madant | nods with Ralith |
| 00:55.16 | brlcad | Ralith: basic classes in place to support managing a graphics context, the input controls for manipulation, how key bindings are managed, displaying "panels" and tabs of information, etc |
| 00:55.16 | Ralith | that said, I can probably be of much more use playing with a GUI than on the geometry engine. |
| 00:55.25 | mafm | I don't know how intricate is the GUI implementation with the rest of the engine |
| 00:55.40 | Ralith | brlcad, a lot of that sounds like stuff that would be provided by w/e GUI lib. |
| 00:55.55 | mafm | but in other GUIs porting means one week, or even one afternoon for somewhat knowledable people |
| 00:55.56 | Ralith | mafm, ideally, I imagine it would be fairly well abstracted out. |
| 00:56.25 | mafm | so low as to inject the input, and draw it in an object to be passed to the engine to render it |
| 00:57.11 | brlcad | Ralith: they can be, but some aren't -- think of it as the subset of things you'd still have to do regardless of what gui was chosen |
| 00:57.23 | Ralith | right |
| 00:57.35 | brlcad | or even better, what you'd have to do if you wanted to cleanly support multiple gui interfaces (not that we'd want/need to) |
| 00:58.28 | brlcad | but that separation of responsibilities -- e.g., a gui lib isn't going to manage or know about geometry, but the interface is at some point going to have to have a container for displayed sets of geometry |
| 00:58.40 | brlcad | much of that mafm actually already has done fortunately |
| 00:59.09 | brlcad | mafm: yeah, he said he ported to wxwidgets and java in less than a day for both |
| 00:59.30 | brlcad | the premise for a month was assuming a dev that had no knowledge of the lib and would have to learn where everything was |
| 00:59.44 | brlcad | unassisted |
| 01:04.10 | mafm | then that might take years :D |
| 01:04.59 | mafm | (unassisted, without idea of how engines work, etc) |
| 01:05.56 | mafm | anyway, did you check OpenSceneGraph? I recall you having a strong bias for using OGRE, but I don't know exactly if we talked about problems with others |
| 01:07.02 | brlcad | no, I mean his estimate that it'd take about a month was without him helping someone through the code -- about a month for someone to figure it out and port |
| 01:07.16 | brlcad | not someone completely involent |
| 01:07.30 | brlcad | and yes, I'm very familiar with OSG |
| 01:08.54 | mafm | why are you familiar with OSG? adn why did you favor OGRE? |
| 01:10.08 | brlcad | are you asking out of curiousity of as a means to justify not using ogre? :) |
| 01:10.22 | brlcad | I used OSG a few years ago for some test projects, have talked to their devs on a few occasions |
| 01:11.16 | mafm | curiosity, I like OSG better |
| 01:11.39 | brlcad | osg is very close in appeal as an engine, they ranked up in the top five easy, maybe even #2 |
| 01:12.32 | brlcad | they have a fair bit of complexity creepage, especially compared to ogre staying focused on rendering |
| 01:13.25 | brlcad | their docs, support, and community aren't nearly as easy/quick/effective to work with as some of the other engines |
| 01:14.28 | mafm | docs for starting up are hard, yes |
| 01:14.45 | brlcad | ogre has some outstanding leadership, steve is a really great guy to work with, the devs are exceedingly helpful |
| 01:14.56 | mafm | which are the others in the top? |
| 01:15.07 | brlcad | assaf was in the middle of porting bzflag to ogre by the time the gsoc mentor summit was done |
| 01:16.04 | mafm | uh, bzflag is in ogre... interesting :D |
| 01:16.21 | *** join/#brlcad sporty__ (n=sporty_@217.118.79.40) |
| 01:16.24 | brlcad | they just really have their act together and are organized for long-term growth/maintenance compared to OSG, which is a lot more academics that throw in features from time to time with a lot more half-hazard less-dedicated leadership |
| 01:16.36 | sporty__ | brlcad: need help |
| 01:16.48 | brlcad | mafm: it's not yet, we've just been in talks and evaluations about adopting an engine for a couple years |
| 01:17.07 | sporty__ | brlcad: Question: dxflib code: key/value pairs - is it eaxactly a way the code looks like? Or it is just a low-level API for Dxflib? |
| 01:17.42 | brlcad | sporty__: we don't support dxflib |
| 01:18.03 | brlcad | or have anything to do with them |
| 01:18.14 | mafm | well, nice anyway |
| 01:18.29 | mafm | I don't have really objections about using OGRE |
| 01:18.29 | brlcad | we have a prototype port of bzflag to crystalspace already |
| 01:18.31 | sporty__ | brlcad: i want your answer as a programer's one for ***another*** translation. |
| 01:18.53 | sporty__ | brlcad: it is question about the DXF-files |
| 01:19.10 | brlcad | sporty__: so then ask a generic question that has nothing to do with dxflib |
| 01:19.20 | sporty__ | brlcad: i do |
| 01:19.27 | brlcad | asking me about dxflib isn't going to get you an answer ;) |
| 01:19.30 | Ralith | brlcad, is that bzflag 2? |
| 01:19.40 | brlcad | Ralith: nope |
| 01:19.53 | brlcad | maybe 2.2 |
| 01:20.13 | Ralith | engine change seems like a pretty big thing for a minor release |
| 01:20.28 | sporty__ | brlcad: Am i right to think real .DXF files consist of key/value tuples? Or am i just a sad looser? |
| 01:20.40 | brlcad | the CS port is pretty much a stalled/dead effort right now, but there have also been tests using three or four other engines too |
| 01:21.00 | brlcad | it just made the most progress in a short time (because it got a core dev excited for a couple weeks) |
| 01:21.13 | brlcad | sporty__: it sounds like you're a sad loser :) |
| 01:21.23 | brlcad | they're more complicated than that |
| 01:21.23 | sporty__ | brlcad: seriously, please |
| 01:21.36 | brlcad | hey if you want serious, don't ask stupid questions :) |
| 01:21.47 | sporty__ | brlcad: that's why it is only a low-level API, right? |
| 01:21.57 | brlcad | it's not an API at all |
| 01:22.00 | brlcad | it's a file format |
| 01:22.17 | Ralith | :P |
| 01:22.38 | sporty__ | brlcad: yes, but is it exactly a format, or these key/values pairs represent a way of low-level programming?? |
| 01:23.02 | brlcad | that question fails to parse, rephrase |
| 01:23.10 | sporty__ | brlcad: is it a syntax of DXF, or something .. |
| 01:23.19 | brlcad | is DXF a syntax of DXF? |
| 01:23.48 | brlcad | stop saying "it", replace with a different word |
| 01:23.49 | sporty__ | """key = value""" = syntax (within the headers of) DXF-files ? |
| 01:24.27 | brlcad | dxf files do not entirely consist of key/value paris |
| 01:24.44 | brlcad | there is statefulness in them that a parser has to be aware of |
| 01:25.13 | sporty__ | brlcad: but are these "tuples" or "pairs" just a ***particular*** part of the syntax? |
| 01:25.37 | brlcad | as opposed to what? |
| 01:25.57 | mafm | brlcad: crystalspace? in parallel with OGRE or was decided to use that one finally? |
| 01:26.04 | brlcad | sporty__: are you asking if there are any key/value pairs in the format? |
| 01:26.16 | sporty__ | brlcad: exactly |
| 01:26.17 | brlcad | mafm: it doesn't work like that |
| 01:26.47 | sporty__ | brlcad: and surely just love any your word ;) |
| 01:26.51 | brlcad | sporty__: there are key/value representations *somewhere* in the format, I'm sure |
| 01:27.00 | brlcad | just like there are key/value pairings in .g files too |
| 01:27.10 | brlcad | that just doesn't mean the whole format is that way |
| 01:27.46 | sporty__ | brlcad: ok, i have an answer to my question |
| 01:27.47 | brlcad | sporty__: "and surely just love any your word" doesn't make any sense to me either |
| 01:28.07 | sporty__ | i'm about the Dxflib Programmer's Manual |
| 01:28.24 | sporty__ | brlcad: it's all right |
| 01:29.31 | brlcad | mafm: picking up an engine is a major endevour, so testing out various engines have been mostly independent (some in parallel, some collaborative, some not) activities |
| 01:29.44 | brlcad | depends heavily on which dev is doing the work and what's being looked into |
| 01:31.17 | brlcad | it's a major undertaking because bz already has it's own rendering engine and opengl is just about *everywhere* in the game client code, so cleaning things up is a bit of a chore |
| 01:32.25 | mafm | I guess so |
| 01:32.54 | mafm | but I was curious in the case that you finally disregarded OGRE and chose CS instead |
| 01:42.49 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 01:45.33 | brlcad | nope, it's still an open item until it's "done" |
| 01:47.43 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 02:14.54 | CIA-6 | BRL-CAD: 03brlcad * r33388 10/brlcad/trunk/src/conv/dem-g.c: autoformat, style and ws consistency cleanup |
| 02:20.59 | CIA-6 | BRL-CAD: 03brlcad * r33389 10/brlcad/trunk/src/conv/dem-g.c: use libbu facilities where appropriate, bu_log bu_exit BRLCAD_ERROR/OK status codes |
| 02:24.44 | CIA-6 | BRL-CAD: 03brlcad * r33390 10/brlcad/trunk/src/conv/dem-g.c: don't need signed keyword, it's signed by default |
| 02:25.44 | mafm | I see |
| 02:25.53 | mafm | well, I'm going to sleep soon |
| 02:26.00 | mafm | have a nice night/whatever :) |
| 02:38.23 | CIA-6 | BRL-CAD: 03brlcad * r33391 10/brlcad/trunk/src/conv/dem-g.c: restructure reduce the logic nesting, simplify; remove a few obvious comments; more style cleanup |
| 02:38.36 | sporty__ | mafm: you can imagine someone from "the malibu beach" TV series (ladies) - who's drafting in BRL-CAD suite in attempt to build some another brave new vehicle |
| 02:39.23 | sporty__ | ...and do it right in that red swim suits, two ladies behind one personal computer! |
| 02:40.08 | mafm | nice thing to imagine before sleeping.. :) |
| 02:40.41 | sporty__ | ...it's getting "just a bit hot" - and voila! they want to dry each other with a tiny towel! |
| 02:40.48 | sporty__ | mafm: yeah |
| 02:41.27 | sporty__ | mafm: could be real |
| 02:42.17 | mafm | it happens all the time among computer geeks, yep :D |
| 02:44.05 | CIA-6 | BRL-CAD: 03brlcad * r33392 10/brlcad/trunk/src/conv/dem-g.c: quell compilation warnings. curious unused arguments for process_manual_dem_max_real_elevation() and it's nearly identical cousin func. |
| 02:49.29 | mafm | bye! |
| 02:58.27 | CIA-6 | BRL-CAD: 03brlcad * r33393 10/brlcad/trunk/src/conv/dem-g.c: some last touch-ups to restore some of the comment alignments and use multiline comments in (just some of) the places where the comments spanned multiple lines. |
| 03:00.25 | CIA-6 | BRL-CAD: 03brlcad * r33394 10/brlcad/trunk/include/bn.h: quell warning, extern is not at beginning of declaration |
| 03:01.27 | CIA-6 | BRL-CAD: 03brlcad * r33395 10/brlcad/trunk/include/bn.h: oh, right, they go inside |
| 03:04.03 | *** join/#brlcad pacman871 (n=Timothy@pool-71-170-39-105.dllstx.fios.verizon.net) |
| 03:06.15 | CIA-6 | BRL-CAD: 03brlcad * r33396 10/brlcad/trunk/include/bn.h: comment consistency/ws cleanup |
| 03:10.56 | CIA-6 | BRL-CAD: 03brlcad * r33397 10/brlcad/trunk/NEWS: richard added a new dem-g terrain importer as part of getting up to speed with some of the proc-db basics. |
| 03:15.21 | *** join/#brlcad madant (n=madant@117.196.130.146) |
| 03:19.19 | starseeker | Ah, starting to get the hang of this: http://bzflag.bz/~starseeker/MarkVIII_Rock_Island_bw.pdf |
| 03:21.04 | brlcad | neat |
| 03:27.00 | sporty__ | what is its size? in kb? |
| 03:27.30 | sporty__ | .bz - belgian? |
| 03:27.44 | brlcad | ~bz |
| 03:27.45 | ibot | well, bz is Belize |
| 03:28.00 | sporty__ | a city? |
| 03:28.21 | sporty__ | ~nkz |
| 03:29.06 | sporty__ | ~time |
| 03:29.06 | ibot | 2008.12.17 3:29:06 GMT |
| 03:32.22 | brlcad | you don't know if belize is a city or not? |
| 03:32.56 | brlcad | suggests an encyclopedia |
| 03:37.36 | kanzure_ | hrm, pipe append with mouse is neat, but "append" isn't a command? hints? |
| 03:39.27 | brlcad | kanzure_: you can "press" the edit menu options via the command-line |
| 03:41.24 | kanzure_ | hrm, the naming convention is odd, what's going on? "press help" -> says I can do "press accept", where accept is Edit->Accept (or really just 'accept' as a command, but anyway) |
| 03:41.30 | kanzure_ | so is it press -> directly to the command? |
| 03:42.37 | brlcad | there is an "accept" command just because it's so frequently used |
| 03:42.46 | brlcad | "press accept" is the long variant |
| 03:43.02 | brlcad | press "Move V" |
| 03:43.06 | kanzure_ | in particular I'm looking for what "edit -> append point" is when I've done 'make thing.s pipe'. |
| 03:43.20 | brlcad | so probably: press "append point" |
| 03:43.33 | kanzure_ | unknown operation |
| 03:43.39 | brlcad | case? |
| 03:43.47 | kanzure_ | yeah :( |
| 03:43.55 | kanzure_ | okay, so how do I "virtually click" or specify a point? |
| 03:43.58 | kanzure_ | this isn't asking me for a parameter. hrm. |
| 03:44.15 | brlcad | good ol' "p" command? |
| 03:44.18 | brlcad | p x y z |
| 03:44.23 | brlcad | (guessing) |
| 03:44.49 | brlcad | have to trace into the tcl to see what command the mouse event is actually bound to |
| 03:45.09 | kanzure_ | yep, that does it |
| 03:45.33 | kanzure_ | thank you. by trace do you mean that I should just go look at the sources? or is there some other method that I should know of? |
| 03:50.36 | brlcad | kanzure_: actually I meant that I should go look, but yeah, you could go look too ;) |
| 03:50.49 | brlcad | and yea, I meant the sources |
| 03:58.16 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 04:04.25 | brlcad | kanzure_: also, if you've not seen it, the mged quick reference sheet in the docs section on the website might be of use to you |
| 04:05.02 | brlcad | it covers commands like press and p |
| 04:06.04 | *** part/#brlcad sporty__ (n=sporty_@217.118.79.40) |
| 05:02.06 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 06:17.42 | brlcad | that's quite a name Dr_Phreakenstein |
| 06:22.41 | *** join/#brlcad ashishrai (i=41310298@gateway/web/ajax/mibbit.com/x-6ddcf8e34d89f2ee) |
| 06:23.52 | *** join/#brlcad ashishkumar (i=41310298@gateway/web/ajax/mibbit.com/x-cf022e245d2be41d) |
| 06:25.53 | *** join/#brlcad ashishkumarIT (i=41310298@gateway/web/ajax/mibbit.com/x-1ff8d087edf99e6a) |
| 06:51.43 | Dr_Phreakenstein | well, thanks |
| 06:52.25 | Dr_Phreakenstein | . |
| 06:58.05 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 07:54.39 | *** join/#brlcad Testerr (n=943c150a@bz.bzflag.bz) |
| 08:49.50 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 08:53.09 | *** join/#brlcad madant (n=madant@117.196.130.146) |
| 09:01.15 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) |
| 10:03.09 | *** join/#brlcad clock_ (n=clock@77-58-247-228.dclient.hispeed.ch) |
| 11:14.14 | *** join/#brlcad madant (n=madant@117.196.148.183) |
| 11:38.43 | *** join/#brlcad mafm (n=mafm@172.Red-83-45-253.dynamicIP.rima-tde.net) |
| 11:42.36 | mafm | hi |
| 11:45.57 | madant | howdy mafm :) |
| 11:57.09 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 12:01.41 | claymore | morning all! |
| 12:02.33 | madant | :) sunset here :P |
| 12:04.32 | mafm | past noon here! :D |
| 12:04.51 | claymore | madant: India? |
| 12:05.02 | mafm | however, for IRC greeting purposes, joining is "morning" and going away is "night" |
| 12:05.04 | mafm | :D |
| 12:05.22 | madant | claymore: yep |
| 12:05.47 | madant | mafm: like erdos's when did you arrive |
| 12:08.54 | mafm | madant: erdos? |
| 12:10.02 | madant | Paul erdos, the eccentric and probably most prolific mathematician of 20th century :D |
| 12:10.37 | madant | "When did you arrive" = when were you born :) "Supreme fascist" = God, "epsilon" = children etc.. |
| 12:11.59 | mafm | lol |
| 12:12.05 | mafm | then it's the same, yep |
| 12:12.20 | claymore | heh, women="bosses" and men="slaves" ...nice! |
| 12:14.10 | madant | :) logical |
| 12:14.31 | claymore | lol, of course you'd think so :P |
| 12:14.50 | madant | huh :O i am a a slave myself :D |
| 12:15.15 | mafm | you are a zero slave yourself |
| 12:15.18 | madant | my name is a bit confusing in American circles i guess :P |
| 12:15.42 | madant | in india there are lots of guys named dawn. but i guess not a single male dawn must be there in us :) |
| 12:16.52 | madant | and i was particularly impressed by Erdos (+Euler) proof for the divergence of inverse sum of primes |
| 12:20.31 | mafm | I mean zero because for him, himself was 0 |
| 12:20.32 | mafm | :D |
| 12:20.49 | mafm | so you are 0 as yourself, slave as a man |
| 12:20.58 | madant | ;P |
| 12:21.10 | mafm | weird guy, yep :) |
| 12:21.24 | madant | prolific |
| 12:21.32 | claymore | madant: Sorry, I thought I heard somewhere in conversation that you were married :) |
| 12:21.42 | madant | :D |
| 12:22.49 | madant | Even erdos's idea of god having a book of all the nicest mathematical proofs is quite nice.. this book dedicated to him is indeed such a pleasure to read.. :) http://books.google.com/books?id=KvQr9l0wgf8C&printsec=frontcover&dq=Proofs+from+the+book&ei=y-5ISeroL4bWlQTTkJnjDg |
| 12:23.03 | claymore | brlcad: Just fyi, but I am not commiting right now simply because I am evaluating a few different angles for the serialization part of the GS. |
| 12:23.47 | claymore | ``Erik: How ya feeling? |
| 12:24.54 | claymore | brlcad: bytebag = sexiness. |
| 12:30.04 | CIA-6 | BRL-CAD: 03d_rossberg * r33398 10/brlcad/trunk/include/bn.h: scarcely imaginable this code was tested before check in ;) |
| 12:44.10 | CIA-6 | BRL-CAD: 03davidloman * r33399 10/rt^3/trunk/ (2 files in 2 dirs): Added ByteBag.hpp and .cxx |
| 13:57.02 | ``Erik | alive O.o stomach's bugging me, couldn't really eat lunch on monday and almost lost what little I did get down on the drive home O.o a lot better today, though :) |
| 13:58.02 | d-lo | good deal! WoW servers ever come up yesterday? |
| 13:58.39 | ``Erik | yeah, I played a little, but spent most of the day asleep |
| 14:08.26 | brlcad | d-lo: that was all in good fun :) |
| 14:09.28 | d-lo | brlcad: BaCk OfF Okay?!?!!11!1! |
| 14:09.29 | brlcad | like I keep saying, can't be too frequent |
| 14:09.48 | d-lo | if you want me to start commiting all my 'essssperiments' then sure :) |
| 14:09.54 | brlcad | sure |
| 14:10.19 | d-lo | grins evily. |
| 14:10.32 | brlcad | that's often very useful actually -- part of the revision history intent is to see why code evolved in a direction it did |
| 14:11.08 | brlcad | if you see a piece of code for serialization tried out paths A and B before ending up at C -- a lot more insightful/useful that just seeing it at the end-state of C |
| 14:11.55 | d-lo | if you say so! I need to get stuff in the repo so I can work on it over the vaca. |
| 14:12.01 | brlcad | especially since many devs will go through the same thoughts and wonder .. well what about A and B? .. and proceed to make changes thinking nobody tried |
| 14:12.15 | starseeker | Got the size down to 10 megs, automated the color removal part :-) http://bzflag.bz/~starseeker/MarkVIII_Rock_Island-bw.pdf |
| 14:14.46 | brlcad | starseeker: nice cleanup! |
| 14:14.51 | brlcad | you know the macs have an automatic size reduction filter yes? |
| 14:16.32 | brlcad | (and acrobat of course gives you obscene knobs on the quality encoding controls) |
| 14:16.59 | starseeker | brlcad: size reduction? |
| 14:18.41 | brlcad | yeah, though looks like the default is already "too much" |
| 14:19.23 | starseeker | do you mean autosizing the pdf for viewing? |
| 14:19.41 | brlcad | no, sizing the file by re-encoding the image data |
| 14:20.02 | starseeker | Oh, ok |
| 14:20.12 | brlcad | just didn't know if you'd tried it |
| 14:20.16 | starseeker | did that one in Scribus actually |
| 14:20.55 | starseeker | notices the scribus dpi resample, tries it... |
| 14:21.22 | brlcad | says let them be huge |
| 14:21.38 | starseeker | 300dpi max... yeah, that'll be huge :-) |
| 14:21.40 | brlcad | not like someone else is ever going to do this -- the higher res the better, so long as they're clean and readable |
| 14:22.23 | starseeker | is saving the original scans, the color "clip outs" that constitute actual content, and the processed b&w cleaned up image :-) |
| 14:22.26 | starseeker | plus the pdfs |
| 14:22.59 | starseeker | doubts the museum will know what to do with any of it, judging by their websites, but oh well... |
| 14:23.06 | starseeker | does :-) |
| 14:24.01 | starseeker | hmm, actually 300dpi was a bit of a downsample |
| 14:24.03 | starseeker | interesting |
| 14:24.21 | starseeker | takes it down to 9.7 megs |
| 14:24.29 | starseeker | negligible on this one |
| 14:24.53 | brlcad | d-lo: fyi, the bytebag classes could use some work -- the toND and fromND wrappers, for example, are now pointless (they originally did something different on windows) |
| 14:24.53 | starseeker | needs to make a wiki page with the image processing details |
| 14:25.27 | brlcad | the error handling could be probably obliterated with a non-exception-generating approach |
| 14:25.33 | brlcad | with guarantees on memory and such |
| 14:26.00 | d-lo | is working it right now. There were some blantant OO violations too :) |
| 14:26.13 | brlcad | but the typeless streamability of the packing and unpacking mechanism is the nice part |
| 14:26.20 | d-lo | Just poking and prodding to see what the intent was before I go a-changing things. |
| 14:26.51 | brlcad | hrm, what blatant OO violations? |
| 14:27.29 | brlcad | that was also a version from like .. a long time ago, probably not the latest but close enough |
| 14:27.31 | d-lo | char * data was set to public when it didn't need to be. |
| 14:27.38 | d-lo | simple fix. |
| 14:27.52 | d-lo | also looking into why all the 'friend' statements are there. :/ |
| 14:27.58 | brlcad | ah, sure |
| 14:30.27 | d-lo | also am moving implementation *out* of the header... just for uniformity's sake. |
| 14:31.09 | brlcad | yeah... there was a reason for that -- but unless it was documented, I couldn't say off the top of my head |
| 14:31.34 | d-lo | well, they were only the simple getters 'n' setters |
| 14:31.44 | d-lo | and the very well could have stayed put. |
| 14:32.08 | brlcad | i mean why all the streams are friends |
| 14:32.51 | brlcad | the header bit was undoubtedly for inlining |
| 14:32.53 | d-lo | well, it *obviously* has to do with the member access... just trying to extrapolate the pro's and cons from that approach. |
| 14:33.32 | d-lo | its more learning that figuing out what/if he did anything silly. |
| 14:33.32 | brlcad | especially with old compilers, you would *only* get actual inlining if it was in the class declaration |
| 14:33.57 | brlcad | regardless of the inline statements and practices elsewhere, they just wouldn't do it |
| 14:34.03 | d-lo | inlining == speed ...right? |
| 14:34.16 | brlcad | yep |
| 14:34.31 | d-lo | does that count as premature optimization :D |
| 14:34.36 | d-lo | ? |
| 14:35.23 | brlcad | it wasn't done beforehand, it was part of another code originally (and later part of a small handful of codes) |
| 14:35.32 | brlcad | it was refactored into the header |
| 14:35.45 | brlcad | where having a revision history would possibly help ;) |
| 14:35.55 | d-lo | cool. Does Jason pop in here often? |
| 14:36.18 | brlcad | not really often, no -- but he's an easy phone call |
| 14:36.39 | brlcad | that was a long time ago for him, though -- hehe, dunno if he'd even remember why |
| 14:37.17 | brlcad | this was before he even started down the M3 and java path, used to be a top-notch c++ programmer |
| 14:37.35 | d-lo | ...till java got him? :D |
| 14:38.11 | brlcad | nah, java just annoyed him slightly less -- just about every language frustrates him :) |
| 14:38.34 | d-lo | none good enough? |
| 14:38.48 | brlcad | pretty much |
| 14:51.05 | d-lo | interesting approach to it alright.... |
| 14:58.26 | d-lo | brlcad: in the << and >> operator overloads that deal with std::strings, do you know why he had the 'string length' parameter variable? aka, WID_8, WID_16, WID_32, etc. Whats that for efficiency? |
| 14:58.47 | d-lo | Whats == was |
| 15:09.34 | brlcad | glancing through it, yes -- I think the point was to store the length with only exactly as many bytes as it needs |
| 15:09.58 | brlcad | almost undoubtedly, that was for space efficiency |
| 15:10.39 | brlcad | so if the length was only 58 chars, it used one byte -- if it was 588 chars long it used two bytes -- if it was 58888 chars long, it used three bytes, etc |
| 15:11.29 | d-lo | actually, it looks like it switched on a preset width, set at instantiation of the object.... neat :) |
| 15:12.02 | brlcad | at one point, bytebag was part of a larger effort to rewrite librt's I/O layer in C++ -- where it has a lot of performance requirements to even do as well as what it does now |
| 15:12.45 | brlcad | that's just initialization |
| 15:12.52 | brlcad | look for the "this stupid function" comments |
| 15:13.26 | brlcad | if you were packing a string, you had to set the width of your bytebag |
| 15:13.58 | brlcad | that's undoubtedly about where things were a work in progress -- didn't actually have any strings being packed |
| 15:14.22 | d-lo | was thinking about an optimized byte array concept a few weeks back. Need to write it down and play with it sometime. |
| 15:14.53 | d-lo | lol , yeah, I saw that 'stupid function' :D |
| 15:15.00 | d-lo | i love comical comments. |
| 15:16.25 | brlcad | libbu has a "variable length buffer" vlb set of routines that might be useful for packing binary arrays of data without having to manage memory (there's a similar stl and boost interface to such as well) |
| 15:18.17 | d-lo | it does seem like the actual storage part of bytebag is a re-invented wheel.... i was just thinking of that very thing. |
| 15:18.32 | d-lo | does vlb store *only* bytes? |
| 15:18.46 | brlcad | opposed to what else? |
| 15:19.14 | brlcad | you pass it a pointer and a length, it puts that many bytes into an array that is automatically grown as needed |
| 15:19.21 | d-lo | as opposed to all the other data types. Maybe I worded my question poorly. |
| 15:19.43 | brlcad | I wouldn't use it for serialization by itself |
| 15:20.06 | brlcad | it could be the memory management portion of something that does, though, for example |
| 15:20.39 | brlcad | not suggesting using that in particular, just wanted you to be aware of it since it's related |
| 15:21.11 | brlcad | you have the benefit of working in C++ where the default stl data containers are available to you, some of which are outstanding |
| 15:21.17 | d-lo | right, I was thinking of: a) revamping the how the bytes are stored inside a ByteBag, b) building similar << >> overloads on top of a vlb, or c) replacing the byte storage in a ByteBag with a vlb. |
| 15:21.24 | d-lo | ponders. |
| 15:21.25 | brlcad | bytebag was written before stl was prevalent |
| 15:22.32 | d-lo | also looking at some ByteInputStream and ByteOutputStream implementations I found. |
| 15:22.55 | clock_ | What exercise do you do for biceps brachii? |
| 15:23.55 | brlcad | clock_: everything around them, especially your tris and shoulders |
| 15:25.33 | *** join/#brlcad Elrohir (n=kvirc@p5B14FBE1.dip.t-dialin.net) |
| 15:38.12 | brlcad | d-lo: using std::vector or std::string for the memory management would probably be how I'd approach it if needed, but then I'd probably just use it first too so I could evaluate the baseline/current behavior and performance with it in place |
| 15:41.00 | d-lo | brlcad: are you gonna make the 1300? |
| 15:41.05 | brlcad | the itch to change the code because you can look under the hood and see ways to make it better is pretty strong, I'm sure .. but must fight those urges :) |
| 15:41.13 | brlcad | d-lo: of course |
| 15:41.35 | d-lo | lol. |
| 15:41.43 | d-lo | must... fight.... urges..... :) |
| 15:42.09 | d-lo | well, its actually stemmed from looking at how to gut the exception throwing. |
| 15:42.13 | brlcad | that's the problem with some of the "fun" code .. it's fun because it's actually kinda easy |
| 15:42.48 | d-lo | there is a check for bytesRead >= bytesFilled that throws an EmptyError |
| 15:43.02 | brlcad | that was part of my point yesterday, no so much what you were doing, but more that that sort of code takes up the same amount of time but is very often (very) short-lived code too |
| 15:43.57 | brlcad | there's harder code to be written for certain :) |
| 15:45.07 | d-lo | which led me to see there were two 'postions' being tracked.... which begged the question 'how could that be done easier?' |
| 15:45.14 | d-lo | so, here i am :) |
| 15:45.41 | brlcad | exceptions are supposed to be exceptional too, could just ignore them, or rip them all out too |
| 15:46.01 | brlcad | make them asserts |
| 15:47.15 | brlcad | a failure in serialization isn't something that should happen outside of a bug that creeps in, hard failure wouldn't be unwarranted |
| 15:47.57 | PrezKennedy | hey brlcad, what sort of recliner did you get? |
| 15:48.45 | d-lo | brlcad: righto, thats another thing I was looking for: failure modes. I don't really see too much of a danger with bytebag |
| 15:48.54 | brlcad | PrezKennedy: a rock-solid snazzy leather one |
| 15:56.56 | d-lo | heh http://www.wikihow.com/Turn-an-Oversized-T-Shirt-Into-a-Hot-Mini-Dress |
| 16:05.01 | d-lo | how would I 'include' headers/source from the brlcad module into rt^3 without duplicating files? |
| 16:05.14 | d-lo | or is the answer simpler that I am making it out to be? |
| 16:18.30 | *** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net) |
| 17:06.49 | brlcad | d-lo: you should assume it's all installed, so you use it like you'd use stl headers or libpng headers/libs |
| 17:07.20 | d-lo | alrighty. what about compliation testing then? |
| 17:07.27 | brlcad | e.g. source file/header might just #include "bu.h", use some libbu routine |
| 17:07.55 | brlcad | that then implies you need headers search paths to find the header and a lib search paths to find -lbu |
| 17:08.17 | brlcad | which is all configure.ac's job and decls in the Makefile.am files |
| 17:08.36 | brlcad | there is a brlcad-config binary that reports the cppflags and ldflags |
| 17:08.57 | brlcad | e.g. brlcad-config --libs bu |
| 17:09.30 | brlcad | and brlcad-config --cflags bu |
| 17:09.58 | brlcad | there are other things you can ask for from brlcad-config (and if things aren't right there, they should get fixed -- that's infrequently tested internally) |
| 17:10.10 | brlcad | should all be right though |
| 17:10.51 | d-lo | okie. thanks! |
| 17:26.05 | kanzure_ | I don't know why I'm making this harder than it is; I just want to plot a spiral made out of the pipe primitive. So when I plot the points, it's always telling me that the points are wrong because of the bend radius being too small - so I increase the bend radius, but then the points are out of alignment. So I change the points by some factor of 10, and then the points are too close, or too far, etc. Any suggestions? I'm just plotting wi |
| 17:26.44 | kanzure_ | and by plotting I mean I'm generating the "p x y z" commands, I'm not aware of internal plotting functions beyond scripting. |
| 17:28.09 | d-lo | kanzure_: what *exactly* is the error message you get that is about 'bend radius being too small' ? |
| 17:30.59 | CIA-6 | BRL-CAD: 03bob1961 * r33400 10/brlcad/trunk/src/libtclcad/ged_obj.c: When refreshing the display, temporarily turn off the zbuffer IF the framebuffer is active AND the zbuffer is on. This fixes the problem of having the wireframe partially bleed through into the rendered image. |
| 17:44.13 | kanzure_ | d-lo: Bend radii (2.40603e+09mm) at ( 18577.5 -71662.6 -4.81201e+09 ) and (2.40603e+09mm) at ( 18577.5 -71662.6 4.81209e+09 ) are too large |
| 17:44.16 | kanzure_ | for pipe segment between ( 18577.5 -71662.6 -4.81201e+09 ) and ( 18577.5 -71662.6 4.81209e+09 ) |
| 17:44.19 | kanzure_ | last segment ( 18577.5 -71662.6 4.81209e+09 ) to ( -2827.43 3.11624e-12 0 ) is too short to allow |
| 17:44.22 | kanzure_ | bend radius of 2.40603e+09mm |
| 17:44.24 | kanzure_ | and on and on for the 1k points that I'm plotting |
| 17:44.53 | d-lo | okay, thats actually telling you that your bend radius is too large, not too small. |
| 17:45.07 | d-lo | is the pipe of a constant diameter from end to end? |
| 17:46.36 | d-lo | if it is, then my suggestion is to set the overall pipe bend radius to 1/2 of the outer diameter. |
| 17:46.51 | d-lo | it will not look like a spiral yet. |
| 17:47.20 | d-lo | once all your points are in the correct position, start bumping up the bend radius for the whole pipe untill it starts to give you errors. |
| 17:47.38 | d-lo | apologizes for his bad spelling :) |
| 17:48.30 | d-lo | well, off to a meeting :/ |
| 20:47.44 | *** join/#brlcad Elrohir (n=kvirc@p5B14FBE1.dip.t-dialin.net) |
| 21:10.04 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177879116.dsl.bell.ca) |
| 21:16.28 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/workmode.png <--- the hippo at work :) |
| 21:41.54 | *** join/#brlcad sporty__ (n=sporty_@217.118.79.35) |
| 21:43.24 | IriX64 | http://rafb.net/p/eLuXlY18.html <---- been fighting this for a while, any idea whats wrong here? |
| 21:43.55 | IriX64 | thats in librt |
| 21:44.04 | IriX64 | comb.exe |
| 21:44.34 | sporty__ | IriX64: i saw this page, don't know |
| 21:49.21 | sporty__ | IriX64: you can forget about this particular broblem and model another models |
| 21:50.05 | sporty__ | maybe, those restrictions for ms w. os ? Brl-cad has some restrictions in there |
| 22:03.57 | *** part/#brlcad sporty__ (n=sporty_@217.118.79.35) |
| 22:41.23 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 23:04.40 | *** join/#brlcad geocalc (n=geocalc@lns-bzn-59-82-252-137-216.adsl.proxad.net) |
| 23:47.28 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 23:49.25 | Ralith | brlcad: you around? |
