| 00:56.33 | starseeker | pacman87: funky |
| 00:59.08 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 01:07.02 | pacman87 | starseeker: i was testing my uv mapping |
| 02:03.17 | starseeker | Hmm - considering this is a completely mechanical translation to html, it's not bad: http://brlcad.org/oed/ |
| 02:42.20 | brlcad | pacman87: stack shader, you apply checker and plastic |
| 02:42.28 | brlcad | nice uv mapping |
| 02:45.16 | poolio | brlcad: Was just wondering where you wanted he brep() routine? In primitives/xxx/xxx_brep.cpp ? And would the routine just be xxx_brep(implicit shape) or something? |
| 02:47.59 | CIA-21 | BRL-CAD: 03brlcad * r31329 10/brlcad/trunk/COPYING: fix typo, remove trademark section |
| 02:48.16 | CIA-21 | BRL-CAD: 03brlcad * r31330 10/brlcad/trunk/configure.ac: ws |
| 02:48.37 | brlcad | poolio: yeah, something like that |
| 02:49.11 | brlcad | spot on for the file and function name, there are more function arguments |
| 03:07.52 | *** join/#brlcad PrezKennedy (i=Matthew@208.43.126.194) |
| 03:12.21 | poolio | brlcad: ah alright, I'll go ahead and commit sph and cyl |
| 03:12.29 | poolio | And just to confirm, no rt prefix? |
| 03:12.35 | brlcad | something like rt_xxx_brep(ON_Brep **b, const struct rt_db_internal *ip, const struct bn_tol *tol) |
| 03:13.02 | brlcad | no no, should match the style of the other callbacks, with the prefix |
| 03:13.31 | brlcad | exact params depends on what it ends up needing, but I suspect at least those three -- maybe a model instead of an ip, but same gist |
| 03:14.51 | poolio | Alright, thanks. I'll give it a shot |
| 03:16.14 | starseeker | takes a gander at the firebird docbook manual... |
| 03:16.46 | brlcad | woo hoo |
| 03:19.42 | brlcad | poolio: the idea will be (particularly for testing) to have it generate a valid solid ON_Brep that could be passed to mk_brep |
| 03:20.44 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.56.224) |
| 03:21.24 | brlcad | howdy andre! |
| 03:23.43 | starseeker | raises eyebrows - they're using what appears to be a script based build rather than teaching autotools to do it |
| 03:25.14 | brlcad | you can always make autoconf run a script ;) |
| 03:25.32 | starseeker | true :-) |
| 03:25.40 | brlcad | regardless, autoconf probably would just check for tool availability |
| 03:26.01 | starseeker | right. they have instructions for downloading tools from their website if problems arise |
| 03:27.10 | brlcad | somethin like a make doc target (have it run a script) |
| 03:33.02 | poolio | brlcad: How would I handle the bn_tol? Isn't that just for raytracing? |
| 03:33.39 | starseeker | brlcad: any idea on that html oed why there are capital As next to the navigation links? |
| 03:33.50 | starseeker | I don't get them when I view the page locally |
| 03:34.26 | brlcad | poolio: nope |
| 03:34.50 | brlcad | it's for anything that requires numerical tolerancing, which you will undoubtedly run into for some of the primitives |
| 03:36.58 | poolio | Well, in terms of creating the brep from the implicit form, why would you need to deal with the tolerancing? Like, wouldn't you just create a brep that ignored it and creating a very precise representation? |
| 03:47.07 | brlcad | poolio: sure, ideally .. some of the primitives will still require some computations |
| 03:47.28 | brlcad | e.g. arbs |
| 03:49.54 | poolio | brlcad: I don't really get it :) Could you give an example where you'd need to look at tolerances? |
| 03:50.05 | brlcad | you'll know it when you get to it :) |
| 03:50.10 | brlcad | don't worry about it till then :) |
| 03:50.46 | starseeker | brlcad: Early thoughts - xmlto uses xsltproc for the "dirty work", which is in turn part of libxslt and uses libxml. Would it be worth considering adding libxslt, libxml and the necessary style files to the src/other directory? |
| 03:51.12 | starseeker | the licenses on those two libs are MIT, and they claim to be written in basic C code |
| 03:51.13 | brlcad | eep, I'd sure hope not |
| 03:51.33 | brlcad | that'd only be if we were including and redistributing xmlto |
| 03:51.53 | starseeker | xmlto is just a script that invokes xsltproc, apparently |
| 03:52.01 | starseeker | we could probably go direct to xsltproc |
| 03:52.06 | brlcad | okay, including and redistributing xsltproc |
| 03:52.09 | brlcad | same thing |
| 03:53.13 | brlcad | I see it more like autoconf, libtool, automake, m4, perl, make .. all things we require devs have, but we don't provide them (because they are dev-only) |
| 03:53.48 | brlcad | and devs != any user that might compile brl-cad |
| 03:53.54 | brlcad | devs is our guys here |
| 03:54.23 | starseeker | OK. |
| 03:54.26 | poolio | brlcad: ok ok. So basically you shouldn't create say, multiple points if they are all within the tolerance? I was just thinking I'd go ahead and create those points, and that it wouldn't matter :) |
| 03:54.48 | starseeker | was thinking they might be in the same class as libpng, libregex, libz... |
| 03:54.57 | brlcad | poolio: yeah, something like that .. you'll end up with rather invalid surfaces and geometry |
| 03:55.24 | brlcad | that will just cascade failures (and completely invalid geometry due to floating point error alone) |
| 03:55.48 | poolio | Well, will is it really 'invalid' ? Is floating point that bad? |
| 03:55.51 | poolio | Ah, ok :) |
| 03:55.59 | brlcad | yes, it really is |
| 03:56.09 | brlcad | when it comes to validity checking on brep geometry |
| 03:56.13 | brlcad | it's a pretty major problem |
| 03:57.20 | poolio | So is implicit gemoetry not checked against tolerances? Cause wouldn't converting from valid geometry lead to valid results...maybe I should just wait til I get there |
| 03:57.22 | brlcad | you'll end up with things that are inside out, twisted, with singularities, cracks, overlaps, and other degeneracies |
| 03:57.58 | brlcad | the implicits are checked, sure .. the mere conversion to brep form, though, can (and will) introduce those errors |
| 03:58.40 | brlcad | aside from primitives that inherintly tolerancing for type detection (arbs) |
| 03:59.57 | poolio | brlcad: So should all shapes take a tolerance or only the ones that need them? I'm thinking it's easier to just use a standard...although with C++ we could overload/set a default param |
| 04:00.57 | brlcad | the api has to be the same for all of them |
| 04:01.21 | brlcad | it's a callback |
| 04:02.09 | poolio | ah, k |
| 04:02.43 | brlcad | it'll go in a table by name, and called genericly |
| 04:02.58 | brlcad | like all the other rt_xxx_* callbacks |
| 04:05.29 | pacman87 | how much time is it worth spending on moving the code back into prep() from shot/norm/uv? |
| 04:05.53 | pacman87 | and is there a standardized way to test performance improvements? |
| 04:06.10 | brlcad | pacman87: highly valuable |
| 04:06.32 | brlcad | optimizing the hell out of primitives is always a good thing |
| 04:06.51 | brlcad | that cascades performance benefits |
| 04:07.25 | pacman87 | so, keep moving code until i cant find any more code to move. |
| 04:07.30 | brlcad | standardized way .. use a good performance profiler ;) |
| 04:07.35 | brlcad | yep |
| 04:08.03 | brlcad | and then for the code that's remaining, make sure it's efficient, non-redundant, cache coherent, etc |
| 04:08.13 | pacman87 | i've never done performance profiling before |
| 04:08.40 | brlcad | ahh, fun stuff |
| 04:08.45 | brlcad | well, want to? :) |
| 04:08.57 | pacman87 | yeah, i just want to know how |
| 04:09.01 | brlcad | how easy and good it is depends entirely on your platform |
| 04:09.10 | pacman87 | slackware 12 |
| 04:09.38 | brlcad | so your basic staple of profiling on linux would be gprof |
| 04:12.04 | brlcad | it's really simple to use -- you'll recompile with configure --enable-profiling --disable-optimized .. compile .. install .. run rt on a hyp .. then run gprof |
| 04:12.04 | pacman87 | is there a compile flag for profiling? |
| 04:12.19 | pacman87 | read my mind :) |
| 04:12.52 | brlcad | when you run rt with profiling enabled, it'll generate a gmon.out file in that directory, gprof uses that along with the binary to sort out where time was spent |
| 04:13.28 | brlcad | it'll generate a fairly detailed report with lots of options and stats.. you then review that report and see if where the time is being spent makes sense |
| 04:14.29 | pacman87 | uv is skipped unless there's a texture, and i'm guessing norm is skipped if there's no shading |
| 04:14.41 | pacman87 | when is curve called? |
| 04:15.17 | brlcad | look for the rt_functab entry callers |
| 04:15.26 | brlcad | don't recall specifically |
| 04:15.42 | pacman87 | curve and tess are the last functions i have to write |
| 04:15.51 | brlcad | tess will be fun.. |
| 04:16.10 | pacman87 | yeah, i've kind of been avoiding it |
| 04:17.57 | brlcad | ehy and tgc kinda give you the formula though |
| 04:18.05 | brlcad | might be nearly identical to tgc |
| 04:19.03 | brlcad | oh yeah -- can the hyp caps have two different radii? .. and separate orientation? :) |
| 04:20.01 | brlcad | separate radii at least could be really useful for attaching pipes together |
| 04:20.01 | pacman87 | right now the endplates are identical |
| 04:20.23 | pacman87 | if you want a different radius, you could cut it off sooner |
| 04:21.10 | pacman87 | the cross sections are all similar ellipses, a/b = const |
| 04:32.48 | brlcad | except it'd be a curvature discontinuity |
| 04:35.02 | brlcad | i see these being used to smoothly tie together tgc/rcc objects, pinched cables, flow control valves, etc, connecting ends with a specific height and specific sized/shaped ends |
| 04:35.42 | pacman87 | that could be done, using a circle for the cross section at the neck |
| 04:37.37 | pacman87 | in that case, you'd need the height axis, top/bottom heights, major axis vectors for the two ends, major/minor axis lengths for both ends, and the radius of the circle in the middle |
| 04:38.11 | brlcad | major/minor for the ellipse in the middle ;) |
| 04:38.17 | pacman87 | in that case, it's not really an elliptical hyperboloid anymore |
| 04:38.29 | pacman87 | yeah, sure ;) |
| 04:38.36 | pacman87 | and the major vector for that too |
| 04:39.23 | pacman87 | but i don't see a way to handle an arbitrary elliptical neck |
| 04:40.31 | brlcad | alright, just a thought :) |
| 04:41.31 | pacman87 | if you want a shape like that, i could do it |
| 04:41.46 | brlcad | nah, doesn't have to be that way .. more just probing thought |
| 04:42.20 | pacman87 | but it'd probably take another week or so |
| 04:42.37 | pacman87 | and i'd rather go on to the revolve after hyp is done |
| 04:44.31 | brlcad | yeah, don't worry about it .. straight up elliptic hyperboloid of one sheet sounds like the plan to stick to |
| 04:45.18 | brlcad | especially since we could do the shape I'm thinking of with a generalized sweep anyways :) |
| 04:52.27 | poolio | brlcad: So apparently I break parsing of input if I manage to sneak in a '\' before it outputs the next line of parameter reading. Is this expected? |
| 05:04.36 | brlcad | doesn't ring a bell, but would have to read the source |
| 05:08.37 | pacman87 | i'm off to bed; i'll work on tess() in the morning |
| 05:18.29 | brlcad | cheers |
| 05:19.04 | starseeker | likes the ability to include multiple sub-files in a top level document - that needs more study |
| 05:31.47 | brlcad | xpath is good stuff |
| 05:31.59 | brlcad | and/or usual docbook hierarchyness |
| 05:32.57 | starseeker | breaking VolII into parts should be a good test |
| 06:35.11 | brlcad | pacman87: in hyp hyp 0 0 0 0 0 1 1 0 0 1 .5 |
| 06:35.26 | brlcad | ae 35 25 |
| 06:36.38 | brlcad | actually from any ae it seems |
| 06:37.50 | brlcad | scale is off too |
| 06:39.57 | brlcad | and all sorts of interesting results if I twitch that .5 anywhere from .1 to 10 .. :) |
| 06:41.20 | CIA-21 | BRL-CAD: 03brlcad * r31331 10/brlcad/trunk/configure.ac: don't allow system tcl to be mixed with non-system itcl under any circumstance regardless of version |
| 07:02.51 | *** join/#brlcad b0ef (n=b0ef@062016141231.customer.alfanett.no) |
| 07:32.19 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 08:25.07 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 08:49.15 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 09:16.26 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-044-078.pools.arcor-ip.net) |
| 09:22.17 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 09:23.43 | mafm | hello |
| 10:11.29 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) [NETSPLIT VICTIM] |
| 10:12.54 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 10:31.04 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 11:40.23 | *** join/#brlcad thing0 (n=ric@124-169-237-118.dyn.iinet.net.au) |
| 11:47.16 | brlcad | howdy mafm |
| 11:47.47 | brlcad | your code now has a home! |
| 11:50.14 | brlcad | the rt^3 module, you can add to that as needed probably starting with a new subdir in src, and another for src/other for the external deps |
| 12:15.37 | clock_ | There's a Swiss guy mentioned in the new who retargetted his Opel Kadett for driving on wood |
| 12:15.53 | clock_ | Has a gasifier attached to the rear of the vehicle |
| 12:16.12 | clock_ | I wonder if a gasifier large enough could feed a resonance ramjet and one could build a cruise misile running on wood |
| 12:16.42 | clock_ | Or fly to the moon on wood ;-) |
| 12:19.57 | mafm | brlcad: I guessed so by the movement in the -commit list... but is the ^ a good character for filenames? wouldn't that give problems on some systems? |
| 12:22.54 | mafm | my bet is on vivoleum: http://www.dailykos.com/story/2007/6/14/214445/536 |
| 12:23.05 | mafm | (for clock_ :) ) |
| 12:25.06 | clock_ | I wonder what happens if you put plastic into gassifier |
| 12:25.18 | clock_ | could cars run on the plastic part of household waste? |
| 12:25.30 | clock_ | Terry, eat the youghurts faster, Dad needs to drive to the work! |
| 12:26.45 | mafm | many of those contain nasty chemicals or things that cause breathing problems for humans or other nasty side effects... kind of the problem with biofuels |
| 12:27.53 | clock_ | I once put the oil from canned fish into a jar and added a makeshift wick |
| 12:27.56 | clock_ | It burned hell long! |
| 12:39.52 | *** part/#brlcad thing0 (n=ric@124-169-237-118.dyn.iinet.net.au) |
| 12:40.53 | mafm | :D |
| 12:52.38 | clock_ | I just invented how to make a transmission from slow to fast without cogs, only with levers! |
| 12:52.47 | clock_ | without cogwheels |
| 13:07.41 | brlcad | mafm: you'd think, but I've actually been surprised how many shells/OS/filesystems support it without a problem |
| 13:07.58 | brlcad | that said, the name isn't finalized, think of it as an internal dev name |
| 13:08.20 | mafm | fine |
| 13:09.05 | mafm | did you read the log about RBGui? it seems that the development effort has declined since when it was considered |
| 13:09.17 | brlcad | yep |
| 13:13.11 | brlcad | mafm: for the module, you have a fairly large amount of flexibility, nothing there is set in stone -- it'll likely be a stomping ground for the new OO API layer in order to keep a defined separation with librt/libbn/libbu, but how that is organized on the filesystem isn't set |
| 13:14.06 | brlcad | one thing that would be nice would be a conversion of rt^3 to cmake, you're welcome to |
| 13:14.20 | brlcad | especially if you're not experienced with the autotools, then it'd probably be a great idea |
| 13:18.26 | mafm | I'm not experience in cmake either :D |
| 13:18.28 | brlcad | mafm: as for rbgui, whenever you want to talk about that vs other other options, I'm game |
| 13:18.55 | mafm | well, you know about the other *option*: CEGUI |
| 13:21.03 | brlcad | sure, that is an option |
| 13:21.44 | brlcad | their activity wouldn't necessarily need to be the deciding factor, especially if you're talking about a mere couple months that have passed to declare them "inactive" |
| 13:22.01 | mafm | since March, is 3 |
| 13:22.29 | brlcad | sure, call it 6 .. that's not very long in the big scheme of things :) |
| 13:22.30 | mafm | the thing is that they patched OGRE for a new function that they {need,think is more convenient}? |
| 13:22.38 | brlcad | plenty of projects release once a year or less |
| 13:22.43 | mafm | and they removed that option from newer stable versions of OGRE |
| 13:22.44 | brlcad | yet are still quite "active" |
| 13:23.02 | mafm | and they haven't adapted their code since then |
| 13:23.12 | brlcad | the bigger issue is how readable/maintainable is their code bose |
| 13:23.31 | mafm | so well, a few months is not big hassle.. but they have a very short story |
| 13:23.42 | brlcad | so if we have to do the updates and ports ourselves, is that worth the effort (compared to the downsides of using something else) |
| 13:23.48 | mafm | so in the scale of their lifetime, it's significant, I think |
| 13:24.04 | brlcad | i'm just saying that it's not a deciding factor |
| 13:24.14 | brlcad | they could drop dead/disappear today |
| 13:24.29 | brlcad | it could still be a viable code to use, even if it doesn't work out of the box |
| 13:24.33 | brlcad | just depends on other factors |
| 13:24.50 | brlcad | i.e. the actual quality of the code and features provided |
| 13:25.20 | brlcad | build system integration issues are usually very very minor .. the actual features the various toolkits provide are where the time is spent |
| 13:25.59 | brlcad | "usually" of course, there are some outlier nasties for rapidly changing codes, but ogre isn't in that camp |
| 13:26.13 | mafm | well... yes, but in example if CEGUI dies, for sure somebody will maintain it in one way or another... but if they die almost certainly the job would be for BRL-CAD team, no other way |
| 13:27.18 | mafm | and code quality, at first glance, might be easy to analyze; but for features probably you don't know until you're deeply buried in the mud :D |
| 13:27.42 | brlcad | possibly, but I'd just treat it as if nobody is or will maintain either -- that makes evaluation a lot more simple and less influenced by popularity perception |
| 13:28.10 | brlcad | the code itself and features really should drive the decision |
| 13:28.51 | brlcad | any external code is a burden especially given we fully manage all external dependencies |
| 13:30.01 | mafm | I see |
| 13:30.35 | mafm | well, the code looks clean and pretty well commented, with lots of "const" guards and so on -- so they seem to have put good care on it |
| 13:31.07 | brlcad | are their features significantly better/worse than cegui? |
| 13:31.48 | brlcad | a minor note, you mentioned yeesterday about cegui's appearance -- you are aware that we would absolutely not use the default theme, yes? :) |
| 13:31.50 | mafm | as for the features, having seeing the video in the links of the discussion, I think that they are not behind CEGUI, but that might be just because of the default theme (as somebody suggest in OGRE forum threads) |
| 13:32.15 | brlcad | that'd probably be the first thing that'd have to change if you go the cegui route, something much simpler, lightweight, clean |
| 13:33.16 | brlcad | how big are the actual code for each? |
| 13:33.22 | brlcad | have you looked at line counts? |
| 13:33.42 | ``Erik | notes that BRL-CAD has gone more than 3 months without release before, yet is quite active... has seen programs go YEARS without releases or visible activity, yet are still active *shrug* |
| 13:34.23 | mafm | Totals grouped by language (dominant language first): |
| 13:34.23 | mafm | cpp: 11215 (95.82%) |
| 13:34.23 | mafm | ansic: 489 (4.18%) |
| 13:34.29 | mafm | and for Mocha... |
| 13:34.43 | ``Erik | (why rt^3 instead of a new top-level?) |
| 13:35.25 | mafm | Totals grouped by language (dominant language first): |
| 13:35.26 | mafm | ansic: 12426 (65.59%) |
| 13:35.26 | mafm | cpp: 6519 (34.41%) |
| 13:35.38 | mafm | (most of "ansic" being actually Lua scripts) |
| 13:35.43 | brlcad | ``Erik: because it has some basic structure in place, a build system set up, C++ files that establish/demonstrate style, documented structure, etc .. less to fix down the road |
| 13:35.53 | mafm | (mocha is a kind of helper library needed by RBGui) |
| 13:35.54 | brlcad | the module can always be renamed |
| 13:36.43 | brlcad | same mocha as seen here: http://greghoustondesign.com/demos/mocha/ ? |
| 13:37.15 | mafm | ``Erik: yes but there are also thousands of projects which make a first release and abandon very early |
| 13:37.55 | brlcad | notes that style is curiously *really* close to the style seen in the IOE demo |
| 13:38.10 | mafm | nope, that one of yours is javascript |
| 13:39.55 | brlcad | well I know that, but the logic under the hood could have been the same library |
| 13:40.05 | brlcad | especially if they were doing any server-side ajaxisms |
| 13:42.37 | mafm | http://www.rightbraingames.com/tech.php -> description of RBGui and mocha |
| 13:43.02 | brlcad | so about 30k lines for rbgui |
| 13:43.06 | mafm | it's a kind of utility library |
| 13:43.16 | mafm | the GUI itself is in RBGui |
| 13:43.29 | mafm | so I think that it doesn't have anything to do with the javascript thingy |
| 13:45.02 | brlcad | yeah, k |
| 13:45.40 | brlcad | so how much code in cegui? |
| 13:46.17 | mafm | http://feature.mmosite.com/antilia/ |
| 13:46.36 | mafm | they're creating this game, but the website has empty pages and the screenshots have no GUI :( |
| 13:46.47 | brlcad | 30k is pretty significant, but not insurmountable to maintain on our own .. anywhere from a couple months to a year of effort |
| 13:48.31 | mafm | (downloading CEGUI, I don't have it around) |
| 13:50.54 | mafm | SLOC Directory SLOC-by-Language (Sorted) |
| 13:50.54 | mafm | 26494 src cpp=26494 |
| 13:50.54 | mafm | 12503 include cpp=12149,ansic=354 |
| 13:51.21 | mafm | with image modules, renderer modules, xml and the like... about 10k more |
| 13:51.59 | brlcad | that sloc is for which? |
| 13:52.21 | mafm | cegui |
| 13:52.52 | brlcad | ah, so pretty closely on par with each other |
| 13:53.19 | brlcad | + any external deps for cegui |
| 13:54.07 | mafm | from rbgui svn: |
| 13:54.11 | mafm | r1 | brian | 2007-10-24 04:01:11 +0100 (Wed, 24 Oct 2007) | 1 line |
| 13:54.30 | mafm | r16 | brian | 2007-11-20 04:01:28 +0000 (Tue, 20 Nov 2007) | 1 line |
| 13:54.42 | mafm | that's the last one appearing in that repository |
| 13:56.02 | brlcad | nods |
| 13:57.49 | mafm | the dates of the RBGui 0.1.3 release are also from 2007, I don't know where I got the thing about march... maybe the date of the thread of OGRE forums announcing it, or the RPM package or something |
| 13:58.16 | mafm | I have to go for a meeting now, be back in about 1 hour |
| 13:58.21 | brlcad | you're still stuck on that point :) |
| 13:58.22 | mafm | or probably less |
| 13:58.25 | brlcad | treat them both as dead |
| 13:58.28 | brlcad | and compare from there |
| 13:58.55 | brlcad | have fun! |
| 13:58.56 | brlcad | :) |
| 13:59.07 | mafm | well, yes, but it turns that it's more dead than I thought :D |
| 13:59.17 | mafm | later |
| 14:00.14 | brlcad | or they're just "finished" because it was so damn good and/or they didn't need it to do anything else |
| 14:00.58 | brlcad | all the more reason to just look at what it is and does |
| 14:02.17 | brlcad | cegui may be the better choice, I'm fine with trying either -- but they should be compared on factors that matter the most to us |
| 14:03.17 | brlcad | from what I've seen, cegui is certainly more popular and better documented/supported .. but more complex to learn and integrate I bet, and will require a complete overhaul of the defaults |
| 14:04.26 | brlcad | rbgui is of course more unknown and not well documented/supported .. but more simple to integrate (less ext. deps), has a gui editor, and the defaults are "fine" for now |
| 14:04.38 | brlcad | so kinda a wash barring new information |
| 14:07.39 | brlcad | poolio: I'm listening to a presentation right now that is basically what you did last summer, but only in 2D using circles and non-overlapping unions |
| 14:08.02 | brlcad | no more, no less .. and it's a formally published IEEE paper :) |
| 14:39.24 | mafm | back |
| 14:40.20 | clock_ | brlcad: I have also an IEEE paper with ISBN! |
| 14:40.30 | clock_ | bursts with self-pride |
| 14:44.55 | clock_ | poolio: what did you do? |
| 14:54.01 | CIA-21 | BRL-CAD: 03d_rossberg * r31332 10/brlcad/trunk/misc/win32-msvc/Dll/ (BrlcadCore.def CMakeLists.txt Makefile.am): |
| 14:54.02 | CIA-21 | BRL-CAD: BrlcadCore.dll now exports some functions which brlcad.dll does not |
| 14:54.02 | CIA-21 | BRL-CAD: at least some of these functions are rather BRL-CAD private and shouldn't be used in other applications |
| 14:54.04 | mafm | no replies in #ogre3d channel :) |
| 14:54.31 | brlcad | their guys are rarely on freenode |
| 14:54.37 | brlcad | they're mainly forum driven |
| 14:55.06 | brlcad | steve says he gets nothing done when he's on irc :) |
| 14:56.47 | CIA-21 | BRL-CAD: 03d_rossberg * r31333 10/brlcad/trunk/ (3 files in 2 dirs): added asc2g and g2asc to the CMake |
| 15:01.28 | mafm | I was mostly trying to find ppl who used it for their projects -- I guess that OGRE devels don't have much time to test other stuff |
| 15:06.42 | starseeker | just out of curosity, is cegui's close relationship with OGRE of any help as compared to RBgui? |
| 15:06.58 | starseeker | can't spell today... |
| 15:07.22 | CIA-21 | BRL-CAD: 03pacman87 * r31334 10/brlcad/trunk/src/librt/primitives/hyp/hyp.c: fix scale error found by brlcad |
| 15:09.30 | d_rossberg | pacman87: the endcaps now look good |
| 15:10.08 | pacman87 | d_rossberg: only curve() and tess() left now :) |
| 15:11.17 | brlcad | hm |
| 15:11.18 | d_rossberg | and revolve and sweep ;) |
| 15:11.29 | brlcad | was getting all sorts of endcap errors |
| 15:11.32 | brlcad | updates |
| 15:12.29 | starseeker | Ah, nevermind... (found the wiki discussion of OpenGL gui frameworks) |
| 15:12.32 | starseeker | reads... |
| 15:13.37 | brlcad | clock_: he implemented a GA that performed shape matching using ray-tracing, implicits, and CSG: http://brlcad.org/Beset_Overview.pdf |
| 15:14.59 | mafm | starseeker: both them are, they were originally designed for OGRE afaik |
| 15:16.13 | clock_ | brlcad: what's a GA? |
| 15:16.31 | clock_ | and what's shape matching? |
| 15:16.37 | brlcad | you didn't look at the link apparently |
| 15:19.48 | clock_ | Preliminary results approximates a cone from spheres |
| 15:20.06 | clock_ | That's sounds a bit impractical and more theoretical |
| 15:20.13 | clock_ | Is it in some practical stage already? |
| 15:20.41 | brlcad | of course not, it was specifically theoretical research |
| 15:21.35 | brlcad | it's not been done before, and the results actually show that it's probably quite feasible for real-world results with more focus on the fitness function and convergence criteria |
| 15:22.05 | clock_ | isn't it just going to make everything from spheres? |
| 15:22.12 | brlcad | No... |
| 15:22.16 | clock_ | give it a cube and it approximates it from spheres? |
| 15:22.20 | brlcad | you're not getting it |
| 15:22.39 | clock_ | but why didn't it just produce one cone and produce tons of spheres instead? |
| 15:22.54 | brlcad | the point is to match an unknown shape with candidate shape(s) and CSG operations |
| 15:23.16 | brlcad | because that would converge nearly instantly, it's a nonsensical result |
| 15:24.05 | brlcad | that task of matching an input shape where the input shape is in you candidate shape set was matched very early on, that's pretty much trivial |
| 15:24.33 | brlcad | the (much) harder problem is when your candidate shapes don't match the input |
| 15:25.05 | clock_ | I would take a biggest sphere that would fit in |
| 15:25.08 | brlcad | so instead of cylinder, maybe it's the mounting bracket to your ronja device |
| 15:25.15 | clock_ | subtract it and recursively call the algorithm on the rest ;-) |
| 15:25.50 | clock_ | or convert the shape into an octree and then build the octree from cubes ;-) |
| 15:25.57 | brlcad | you don't know what would fit, or even where |
| 15:26.05 | brlcad | it determines that implicitly through the GA process |
| 15:26.13 | clock_ | wow |
| 15:26.14 | brlcad | it knows *nothing* about the input |
| 15:26.24 | clock_ | not even it's shape? |
| 15:26.32 | brlcad | it can sample the shape is all |
| 15:26.32 | clock_ | polishes his crystal ball |
| 15:26.41 | brlcad | single ray queries |
| 15:26.49 | mafm | (I appear to know more of GUIs than people of the channel, so no much help in that camp :) ) |
| 15:26.53 | brlcad | that tell you where material exists or does not exist |
| 15:27.19 | brlcad | mafm: what were you expecting to get from them? :) |
| 15:27.26 | clock_ | I wonder how it reacts if you give it a sponge like for washing dishes |
| 15:27.33 | brlcad | highly likely iff you got feedback, it'd be biased to the more well-known popular result |
| 15:27.38 | clock_ | then the results will depend on precise sampling point |
| 15:28.16 | brlcad | the GA itself tries to converge to match the same space occupancy |
| 15:28.34 | brlcad | mostly useful for high-dimensional search spaces as a semi-brute force search method |
| 15:29.37 | poolio | brlcad: I might try to further pursue beset off the clock :) I've got some more ideas I want to try out |
| 15:30.02 | brlcad | was inspired to code up some of the remaining ideas he had as well ;) |
| 15:30.18 | poolio | ah well, I concede. |
| 15:30.38 | brlcad | especially with more operators and primitives to choose from, and simulated annealing to increase convergence |
| 15:31.00 | brlcad | no no.. don't let me hold you up from doing anything |
| 15:31.18 | brlcad | those aren't exclusive-or decisions :) |
| 15:31.19 | poolio | Well, are you working off of the code I had implemented or starting anew? |
| 15:31.41 | clock_ | brlcad: if you give it a mounting bracket do you think it figures out the primitives from which the bracket was made? |
| 15:31.44 | brlcad | eh, why would I start new? |
| 15:31.51 | clock_ | 3 rpps and 2 cyls? |
| 15:32.00 | poolio | brlcad: no clue, just wondering :) You should keep beset up to date so we could potentially collaborate :) |
| 15:32.13 | poolio | clock_: Maybe, but it's pretty far from that currently. |
| 15:32.27 | brlcad | clock_: theoretically if the same primitives and operators were available in the sample set, that would be one of the possible solutions it could arrive at (along with billions of other less fit solutions) |
| 15:33.12 | brlcad | poolio: I rarely ever have uncommitted code, commit frequently ftw |
| 15:33.34 | poolio | commit early, commit often, commit every time you save ;) |
| 15:33.42 | clock_ | Hehe genetic algorithms on WP: "Commonly, the algorithm terminates when either a maximum number of generations has been produced, or a satisfactory fitness level has been reached for the population. |
| 15:33.47 | clock_ | " |
| 15:34.19 | clock_ | or "until intelligence capable of producing nuclear weapons evolves" |
| 15:34.39 | clock_ | what's the termination criterion for the genetic evolution of the nature? |
| 15:35.12 | poolio | It never terminates. |
| 15:35.21 | brlcad | made a GA that drove little tanks around that learned how to combat each other in teams effectively whilest in college |
| 15:35.33 | poolio | It terminates if you can solve the halting problem :) |
| 15:35.48 | poolio | brlcad: hehe, I did something like that but with little animals collecting food |
| 15:35.54 | brlcad | easy .. if (rand() == 0) abort(); :) |
| 15:36.01 | poolio | brlcad: I see you started early with the army |
| 15:36.27 | poolio | Bah, it's not even random. pseudo-random ftl. |
| 15:37.52 | brlcad | the first really impressive result I saw was another group in that same class that used a GA that learned how to play tetris .. it learned *exceptionally* well and after a couple days evolving could then easily beat any human players (and could play at 100x real-time speed) |
| 15:38.08 | brlcad | all through a GA that evolved an FSM of gameplay logic |
| 15:38.47 | poolio | That's quite impressive...but couldn't they have just brute forced something like that? |
| 15:39.09 | clock_ | I once played with a program for genetically generated art |
| 15:39.40 | brlcad | the second impressive result was terzolopolous' work where he had an articulated model of a fish and it completely and naturally learned how to swim .. that was fscking impressive |
| 15:39.44 | clock_ | or evolve tetris that is as easy as possible |
| 15:39.48 | clock_ | with only 1x1 blocks |
| 15:40.03 | poolio | brlcad: oh heh, was it just a simulation? I think I've seen that research before |
| 15:40.21 | poolio | There was also someone in #ai a while ago that used Q-learning + NNs to evolve a gait for a quadruped |
| 15:40.25 | clock_ | brlcad: I tried that with human body, biological computer and skateboarding and it also worked impressively |
| 15:40.40 | clock_ | poolio: they do it on the university of zurich in their robotic lab |
| 15:40.50 | brlcad | poolio: actually the combinatorial explosion in tetris can get pretty bad -- especially as the stragey actually needed to optimize and respond differently at different levels -- it was multi-player tetris (netris) |
| 15:41.23 | poolio | ah, I love netris :). I just did some quick figures and got 7(2^200)...I guess that's a little bit large :) |
| 15:43.13 | clock_ | Could you use GA to evolve an .mp3 that would get #1 in the world charts? |
| 15:43.29 | starseeker | <snort> that would explain a lot of current music... |
| 15:43.59 | clock_ | I wrote a program where I fed Bible and Koran and it produced a religious text on the halfway |
| 15:44.06 | clock_ | Allah and God walking hand in hand in one sentence |
| 15:44.16 | clock_ | Should solve the eternal collision between religions |
| 15:44.27 | brlcad | clock_: there's some people that have actually worked on that .. |
| 15:44.42 | clock_ | I also put in gay sex stories |
| 15:44.48 | brlcad | (the music bit, not the religious one) |
| 15:44.50 | clock_ | to make the religion less homophobic |
| 15:44.58 | clock_ | brlcad: evolved music? |
| 15:45.05 | brlcad | yep |
| 15:45.30 | brlcad | it's all in the fitness function |
| 15:45.44 | clock_ | I took like 8 bit game monsters put them into one picture and ran through the program |
| 15:46.11 | clock_ | and it created new monsters like birds and dwarfs and birds sitting on a tree branch and multi-headed monsters etc. |
| 15:46.30 | clock_ | Apparently, the extremely primitive algorithm somehow understood how a monster should look like |
| 15:46.41 | clock_ | wouldn't it be possible for shapes? |
| 15:47.13 | clock_ | You give it a complicated model and it ideates and phantasizes based on that? |
| 15:47.45 | starseeker | can hear the marketing slogans for GA music software "Record studios - when you can't afford or identify musical quality and talent, evolve it with Hit-Gen 3.0!" |
| 15:49.31 | clock_ | or like "Throw away all discrimination and prejudice - hitmaking for the deaf, painting for the blind!" |
| 15:50.29 | poolio | I think it'd be more interesting to have some program train on all the top hits ever and mash them together |
| 15:50.32 | clock_ | Well I solved the problem how deaf people can accompany music |
| 15:50.59 | clock_ | I wrote an analyzer that shows coloured graphs of the semitones being played and you put coloured stickers on a piano and press the same color you see is coming |
| 15:51.03 | clock_ | And it mostly sounds good. |
| 15:51.32 | clock_ | DJ Elvis and MC Jimi Hendrix |
| 15:51.37 | starseeker | poolio: agree it would be an interesting experiment to run, but I'm not sure we need any more ways to kill off human culture generation... |
| 15:52.42 | brlcad | pacman87: looking better, next bug: in hyp hyp 100 100 100 0 0 1 .5 0 0 .5 .5 ; left ; zoom 4 ; rt |
| 15:52.43 | starseeker | more interesting would be to see if such a program could identify what decade a song was most popular in based on some baseline of popular songs from the last six decades or so |
| 15:53.05 | clock_ | starseeker: it would be necessary to discriminate structure in music |
| 15:53.05 | starseeker | Perhaps you could identify core "sounds of an era" |
| 15:53.34 | clock_ | you need just one human brain in a vat |
| 15:53.39 | clock_ | with a happiness indicator |
| 15:53.49 | clock_ | feed the music in and find such music that produces the best happiness signal |
| 15:54.06 | clock_ | but would have ethical issues |
| 15:54.46 | clock_ | I hope humans will be replaced by immortal computers before I die |
| 15:55.18 | clock_ | then I will upload my mind into a compact flash chip and be killed from a falling brick animated in BRL-CAD |
| 15:55.20 | starseeker | Uh - unless you are an immortal computer I doubt that |
| 15:55.36 | clock_ | from -> by |
| 16:01.01 | pacman87 | brlcad: what problem did you see? |
| 16:10.40 | brlcad | a line right through the middle, flipped normals |
| 16:11.10 | pacman87 | screenshot plz? |
| 16:11.45 | brlcad | http://brlcad.org/tmp/hypnorm.png |
| 16:12.34 | brlcad | http://brlcad.org/tmp/hypnorm2.png |
| 16:12.40 | pacman87 | https://webspace.utexas.edu/trv82/www/hyp_rt15.png |
| 16:13.07 | brlcad | it's some near-zero tolerancing problem |
| 16:14.14 | *** join/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) |
| 16:15.35 | brlcad | probably floating point fuzz, that's exactly on the midline |
| 16:15.52 | mafm | brlcad: "what were you expecting to get from them? :)" experience on using it |
| 16:16.13 | brlcad | fair nuff :) |
| 16:16.39 | brlcad | I think you just need to "pick one" and run with making it work, for better or worse |
| 16:17.14 | brlcad | I'll pick one if you want, but they do seem fairly even to be rather bikeshed issue barring any other information about the code quality and APIs |
| 16:17.49 | brlcad | how easy / hard does it seem to be to themee rbgui ? |
| 16:18.02 | mafm | I think that peole gathering in those channels are usually people like me, using OGRE for their projects, along with some core devels, sometimes of the difefferent addons themselves |
| 16:18.16 | mafm | (though I would not expect to fin rbgui devels here :) ) |
| 16:18.17 | brlcad | and does the ui scale non-raster |
| 16:18.42 | mafm | so I'm going to patch OGRE to make it work with RBGUI |
| 16:19.59 | brlcad | patch ogre, not patch rbgui? :) |
| 16:32.22 | mafm | yep... it's calling a non-existing method in some ogre class |
| 16:33.19 | mafm | http://www.ogre3d.org/phpBB2/viewtopic.php?p=239174&sid=ce193664e1d3d7c4af509e6f4e2718c6 |
| 16:33.44 | CIA-21 | BRL-CAD: 03pacman87 * r31335 10/brlcad/trunk/src/librt/primitives/hyp/hyp.c: fix normals near z=0 |
| 16:33.49 | pacman87 | brlcad: try that |
| 16:41.11 | brlcad | mafm: ah, another interesting patch for rbgui+mocha here: http://www.ogre3d.org/phpBB2/viewtopic.php?t=32929&postdays=0&postorder=asc&start=650 |
| 16:41.32 | brlcad | finds that method of exchanging patches utterly appalling |
| 16:42.09 | pacman87 | brlcad: i just realized i can get rid of the z=0 check by multiplying the normal vector through by z |
| 16:42.21 | brlcad | ok |
| 16:42.22 | pacman87 | and it also takes care of the z>0 conditional |
| 16:42.38 | pacman87 | so 10 lines of code -> 1 line :) |
| 16:42.44 | brlcad | excellent |
| 16:42.58 | pacman87 | testing it now |
| 16:43.49 | mafm | you mean for me to include the sources+patches of all this in our brl-cad branch? |
| 16:44.39 | mafm | oh, that function exists in OGRE-bleeding-edge-trunk at least, gonna try that first |
| 16:51.56 | *** join/#brlcad PrezKennedy (i=Matthew@208.43.126.194) |
| 16:54.19 | CIA-21 | BRL-CAD: 03pacman87 * r31336 10/brlcad/trunk/src/librt/primitives/hyp/hyp.c: new and improved normals\! |
| 16:55.32 | *** join/#brlcad clock_ (n=clock@77-56-86-41.dclient.hispeed.ch) |
| 16:59.14 | brlcad | starseeker: those circumflex A's are undoubtedly unicode conversion problems -- try changing the doctype in the html header source, maybe from utf-8 to one of the iso types |
| 16:59.24 | brlcad | or just regex replace them .. |
| 16:59.29 | brlcad | mafm: yup |
| 16:59.36 | brlcad | fully managed dependencies |
| 17:00.04 | brlcad | if we can't build it for ourselves, it's kinda silly to expect our users to be able to |
| 17:03.13 | *** join/#brlcad thing0 (n=ric@124-169-237-118.dyn.iinet.net.au) |
| 17:05.11 | brlcad | we may later pull ogre out given it's size, but for now it'll really help to consistently become familiar with their sources, build layout, etc |
| 17:06.39 | brlcad | traditionally, though, anything that is need to compile (other than the compilation environment itself) is provided with the sources and optionally/only used if a suitable system version isn't installed |
| 17:06.39 | mafm | uh, that's a huge one :) |
| 17:06.39 | brlcad | no bigger than tcl/tk iirc |
| 17:06.44 | brlcad | and you wouldn't include some of their binary goo that we don't need |
| 17:06.58 | louipc | what now? brl-cad's going to include ogre? |
| 17:07.12 | brlcad | louipc: no |
| 17:07.22 | mafm | dunno about TK, but TCL was supposed to be a tiny interpreter :) |
| 17:07.23 | brlcad | this is experimental development |
| 17:07.38 | brlcad | if it works out well, certainly |
| 17:07.57 | mafm | go for a coffee while compiling trunk |
| 17:07.59 | brlcad | separate module, though, not the brlcad module |
| 17:08.01 | mafm | brb |
| 17:08.06 | louipc | ah |
| 17:08.45 | brlcad | this can be thought of as an app that uses brl-cad's libraries/tools, a unified environment |
| 17:14.10 | brlcad | pacman87: that seems to have done the trick! |
| 17:16.55 | louipc | mafm: well it's pretty small compared to others. |
| 17:21.43 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) |
| 17:36.06 | brlcad | pacman87: the primitive is nicely robust down to computation tolerance sizes... very nice! |
| 17:36.22 | brlcad | e.g. a hyp that is only 0.0005 mm tall |
| 17:50.01 | pacman87 | how exactly is the tesselation stored in the nmgregion? |
| 18:29.15 | brlcad | faces, loops, edges, vertices |
| 18:29.27 | brlcad | they stitch together a solid surface |
| 18:33.03 | pacman87 | what is tess() used for; ie, how can i test it? |
| 18:37.41 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 18:40.19 | pacman87 | what's the best way to handle the case where the ellipse's major axis vector isnt' perpendicular to the height? |
| 18:41.33 | pacman87 | give an error and refuse to work, or just take the component of the vector that is perpendicular? |
| 18:42.43 | pacman87 | in test hyp 0 0 0 0 0 4 0 1 1 1 1 |
| 18:43.48 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 18:45.11 | mafm | OGRE crashing my X... no good >:[ |
| 18:46.21 | louipc | heheh |
| 18:54.30 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177725958.dsl.bell.ca) |
| 18:55.21 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/shot2.png :) |
| 19:00.25 | louipc | what is it? :P |
| 19:00.41 | IriX64 | computer burped and that came out :) |
| 19:03.35 | *** join/#brlcad andrecastelo (n=chatzill@189.71.61.92) |
| 19:03.59 | andrecastelo | good afternoon guys |
| 19:05.29 | pacman87 | hi andrecastelo |
| 19:05.46 | andrecastelo | hey pacman87, how are u ? |
| 19:12.32 | pacman87 | pretty good, still trying to wrap my mind around tess() |
| 19:12.38 | pacman87 | how are you? |
| 19:12.38 | ibot | pacman87: mas o menos |
| 19:15.54 | andrecastelo | pretty good too, got some free time, trying to work my way into stting up a grid |
| 19:15.59 | andrecastelo | s/stting/setting |
| 19:27.16 | brlcad | pacman87: tess is used by most of the converters -- you can test it with the E and/or ev commands inside mged |
| 19:54.17 | andrecastelo | ``Erik: mlt's view_setup() will be pretty similar to rt's view_setup() ? perhaps expanding it a little to handle mlt specific stuff?? |
| 20:08.07 | mafm | be back tomorrow or sunday to recover a bit of the time and speed up things |
| 20:08.34 | mafm | and fix this OGRE thing broking my X-Windows :P |
| 20:08.40 | mafm | cya |
| 20:46.20 | pacman87 | hmm, the ehy will accept a major axis vector that's not perpendicular to the height vector, but ehy's export5() gives a scary error message. Would it be better to check this in typein.c instead of export5()? |
| 21:23.23 | ``Erik | 2/det |
| 21:25.18 | *** join/#brlcad docelic (n=docelic@78.134.202.42) |
| 22:25.23 | *** join/#brlcad thing1 (n=ric@203-59-26-22.perm.iinet.net.au) |
| 22:44.40 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177725958.dsl.bell.ca) |
| 23:30.56 | brlcad | pacman87: you should check in both places .. there are other ways to directly create primitives that side-step typein |
| 23:31.35 | brlcad | export is ultimately where it's "actually" created on disk, so that makes sense too |
| 23:35.42 | brlcad | otherwise you could handle it in a variety of ways, but probably not worth the effort |
| 23:38.56 | brlcad | andrecastelo: likely very similar or even empty |
| 23:39.20 | brlcad | view_init is rarely used .. it's what you can do after you know your view grid but before you've prep'd geometry .. which isn't very much |
| 23:40.48 | andrecastelo | brlcad: i see.. i have a night class now but i'll be back in an hour, an hour and a half.. will you be online then? |
| 23:42.17 | andrecastelo | hehe, i'm kinda late, so cya later |
