| 00:10.54 | ``Erik | it was the best of times, it was the blurst of times |
| 01:05.40 | ``Erik | that should make pedro happy, 7.14.8 port has been submitted for fbsd |
| 01:38.55 | *** join/#brlcad stevegt_ (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 03:14.28 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 03:39.51 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 03:51.25 | CIA-32 | BRL-CAD: 03starseeker * r35100 10/brlcad/trunk/include/opennurbs_cleanup.h: |
| 03:51.27 | CIA-32 | BRL-CAD: Ah HAH. Fix the flatness test to use corner and interior points the way the old |
| 03:51.29 | CIA-32 | BRL-CAD: setup did (even though the interior points are a bit different.) Appears to fix |
| 03:51.31 | CIA-32 | BRL-CAD: the visual flaws from the default rt view, but the strange symmetrical dot lines |
| 03:51.33 | CIA-32 | BRL-CAD: in the top down view (that disappear on zoom in) are still there. |
| 03:55.34 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 04:41.09 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 05:52.29 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 05:55.26 | *** join/#brlcad _sushi_ (n=_sushi_@84-73-206-47.dclient.hispeed.ch) |
| 08:37.07 | *** join/#brlcad Patmcc19_ (n=chatzill@71-223-63-122.phnx.qwest.net) |
| 09:45.41 | *** join/#brlcad mafm (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 10:50.52 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 11:01.53 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 11:28.22 | CIA-32 | BRL-CAD: 03jdoliner * r35101 10/brlcad/trunk/ (6 files in 3 dirs): Initial commit for bivariate polynomial support |
| 11:49.02 | *** join/#brlcad Patmcc19 (n=chatzill@71-223-46-33.phnx.qwest.net) |
| 11:49.57 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 11:59.06 | brlcad | jdoliner: fyi, several of your defines are provided in include/vmath.h |
| 11:59.24 | brlcad | and should use the std math macros for min/max like other parts of the code (follow suit) |
| 12:02.00 | brlcad | also, make sure you don't replicate functionality that is included in the JAMA/TNT library in src/other, includes various numeric routines (lu decomposition, eigenvectors, matrix manipulations, etc) |
| 12:04.22 | jdoliner | how high level do its routines get? |
| 12:08.18 | jdoliner | the types of computations that we need to do are pretty high level, I don't think we have anything right now capable of doing it |
| 12:08.28 | jdoliner | I guess we already knew about that |
| 12:08.40 | jdoliner | otherwise it wouldn't be much of a challange now would it |
| 12:10.09 | jdoliner | so I think at least for some of the more nuts and boltsy polynomial algorithms it would be smarter to link in another library |
| 12:10.16 | jdoliner | instead of rewriting it all |
| 12:10.53 | jdoliner | because it's some pretty technical stuff |
| 12:10.58 | jdoliner | what say you? |
| 12:12.33 | brlcad | the closest is probably the specialized evaluations used within the current nurbs raytracing code (which is what indianlarry was mention earlier about evaluations being highly related) |
| 12:14.22 | brlcad | take a look at src/other/tnt first and see what you could leverage, there's also the option to utilize stuff in boost as we already depend on that, and then the specialized routines in src/librt/primitives/brep/* and src/librt/opennurbs_* |
| 12:15.23 | brlcad | the biggest concern is keeping the entropy low in order to improve maintainability -- that means keeping depencencies low/simple but not reinventing and leveraging what's already available as much as possible |
| 12:16.41 | brlcad | can't overlook simple things like sqrt(3) defines, even more important to leverage existing infrastructure for higher-level routines that don't exist |
| 12:30.47 | jdoliner | so it looks like there's some stuff in src/libry/primitives/brep that I can leverage for a marching implementation |
| 12:34.37 | brlcad | if you do, try to generalize so both codes use the same routines, not just copy and specialize, if at all possible |
| 12:35.03 | brlcad | otherwise it's just as bad as writing it from scratch |
| 12:36.03 | jdoliner | k |
| 12:45.04 | *** join/#brlcad Patmcc19_ (n=chatzill@71-223-43-80.phnx.qwest.net) |
| 12:50.23 | starseeker | Fair warning - the opennurbs_ext.* and brep* codes are in a state of rather massive flux at the moment |
| 12:54.33 | *** join/#brlcad docelic_ (n=docelic@78.134.204.215) |
| 13:01.46 | ``Erik | *nod* converting adrt from its own homerolled stuff to vmath was a time consuming process even with sed |
| 13:24.35 | *** join/#brlcad Don_ (n=Don@71.238.51.148) |
| 13:27.32 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 13:28.01 | jdoliner | starseeker: thanks I guess I'll just have to enter the fray :) |
| 13:30.11 | *** join/#brlcad BigAToo (n=BigAToo@host-69-95-46-65.spr.choiceone.net) |
| 13:35.47 | *** join/#brlcad mafm_ (n=mafm@83.42.152.74) |
| 13:36.19 | *** join/#brlcad BigAToo (n=BigAToo@69.95.46.65) |
| 13:39.43 | ``Erik | oh heh |
| 13:40.48 | ``Erik | Herr Roßberg, I just responded to your version email, did I understand you correctly? |
| 13:43.00 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 13:43.07 | d_rossberg | ``Erik: brlcad_version.h is unfortunately not part of the installation (make install) |
| 13:44.03 | ``Erik | hm, bu_version() in libbu isn't adequate? |
| 13:44.11 | ``Erik | (or was it bu_ident() hrm) |
| 13:44.32 | d_rossberg | i.e. the information i need is of course in the BRL-CAD sources, but not in the standard installation |
| 13:45.02 | d_rossberg | bu_version() gives the version information on run-time but not on compile time |
| 13:46.20 | ``Erik | whistles innocently |
| 13:46.21 | d_rossberg | i.e. i want to compare the version i used to compile/link my program with the version of the BRL-CAD libraries i'm using on run-time |
| 13:46.33 | CIA-32 | BRL-CAD: 03erikgreenwald * r35102 10/brlcad/trunk/include/Makefile.am: install brlcad_version.h for third party apps to use |
| 13:47.00 | d_rossberg | brlcad_version.h needs the conf directory ... |
| 13:47.03 | *** join/#brlcad Patmcc19 (n=chatzill@71-223-53-118.phnx.qwest.net) |
| 13:47.11 | ``Erik | ahhh, yeahhhhhhh |
| 13:47.52 | ``Erik | gimme a minute, need a cup of coffee, then I'll do... something... horrible |
| 13:50.00 | ``Erik | what I'm thinking probably won't groove well with msvc |
| 13:50.07 | d_rossberg | this looks like a shot from the hip :| |
| 13:50.25 | ``Erik | no, this is more bull in chinashop :D |
| 13:50.46 | d_rossberg | maybe it would work with CMake |
| 13:51.14 | d_rossberg | i'm using CMake currently to generate my brlcadversion.h |
| 13:52.23 | d_rossberg | the generation of COUNT/DATE/HOST etc works with CMake too |
| 14:04.42 | ``Erik | effin' pain to type with this cast, stupid broken wrist :( |
| 14:21.15 | CIA-32 | BRL-CAD: 03erikgreenwald * r35103 10/brlcad/trunk/include/ (Makefile.am brlcad_version.h brlcad_version.h.in): remove brlcad_version.h dependancy on conf. (still need to de-GNU the makefile a bit.) |
| 14:23.37 | CIA-32 | BRL-CAD: 03irpguardian * r35104 10/brlcad/trunk/src/proc-db/human.c: |
| 14:23.39 | CIA-32 | BRL-CAD: Added functionality to the custom position stance (-s999) which takes |
| 14:23.41 | CIA-32 | BRL-CAD: in XYZ for setting arm position in degrees. |
| 14:28.07 | brlcad | jdoliner: nice work commenting on the tracker item, but don't forget the other fields -- you should assign it to yourself and close it out at a minimum, could also set low priority and a category of being a compilation issue |
| 14:29.52 | brlcad | for auditing purposes, your commit that fixes the bug can say the sf tracker number that it refers to (e.g., this fixes sf tracker # 1234567 reported by blah (rt crash on exit)), then can tell the user which commit that was in your closing comment so they can make sure they have the right svn revision to test the fix |
| 14:33.13 | brlcad | d_rossberg: that was done intentionally, whether good or bad, that the version header files aren't installed |
| 14:33.16 | d_rossberg | ``Erik: i think i see where this will lead to ... i'll see how this can be done with CMake ... |
| 14:34.07 | d_rossberg | i assumed that thia was your intention |
| 14:34.19 | brlcad | with the intent being that only run-time information is used with the libs since the headers could conceivably be out of sync |
| 14:34.41 | brlcad | most importantly, to avoid projects that might get into a habit of relying on any defines in a bad way |
| 14:35.13 | brlcad | #if BRLCAD_MAJOR == 7 && BRLCAD_MINOR == 10 ... do one thing .. else do something worse |
| 14:35.30 | brlcad | aside from header mismatches too |
| 14:36.15 | brlcad | there is the brlcad-version configuration script, that is meant to provide compile-time libs, linkage, and version information |
| 14:36.27 | brlcad | we could turn that into a binary so that windows has it as well |
| 14:37.28 | brlcad | what is the exact problem that needs solving? |
| 14:39.28 | ``Erik | doesn't like this. :/ |
| 14:39.57 | d_rossberg | if the libs and the headers are out of sync you are in trouble any way, or? |
| 14:40.22 | *** join/#brlcad BigAToo (n=BigAToo@host-69-95-46-65.spr.choiceone.net) |
| 14:40.28 | brlcad | not necessarily, we rarely ever break ABI compat on the C side |
| 14:41.30 | brlcad | it's happened in isolated cases before too, nothing major but then we didn't give them a means to rely on a behavior or conditionalize their code at compile-time |
| 14:41.58 | *** join/#brlcad BigAToo1 (n=BigAToo@69.95.46.65) |
| 14:43.03 | *** join/#brlcad Patmcc19_ (n=chatzill@71-223-54-29.phnx.qwest.net) |
| 14:44.02 | indianlarry | jdoliner: Hey Joe, you around? |
| 14:46.37 | CIA-32 | BRL-CAD: 03erikgreenwald * r35105 10/brlcad/trunk/include/ (Makefile.am brlcad_version.h brlcad_version.h.in): revert changes with brlcad_version.h |
| 14:48.01 | ``Erik | tries to wake up O.o |
| 14:48.15 | d_rossberg | brlcad: therefore you have/had projects with different versions of run-time (libs) and interface descriptions (headers) where you want to prevent trhe user to see this difference? |
| 14:49.06 | d_rossberg | ... because he could do something ugly with this information? |
| 14:49.45 | *** join/#brlcad Patmcc19__ (n=chatzill@71-223-60-113.phnx.qwest.net) |
| 14:50.34 | d_rossberg | btw, where can i find this brlcad-version script? |
| 14:51.00 | ``Erik | $PREFIX/bin/brlcad-config |
| 14:51.26 | ``Erik | there're also pkg-config files (.pc) floating around |
| 14:55.23 | brlcad | d_rossberg: no, I don't want to accommodate a bad install -- that wasn't the point -- but I do want to try to prevent devs from using defines as compile-time conditionals |
| 14:56.49 | brlcad | pkg-config is a 'standard' application that uses our config descriptor files -- more portable, less custom. brlcad-config is our project-specific version of that same interface |
| 14:57.07 | brlcad | "brlcad-config --version" for example |
| 14:57.25 | *** join/#brlcad elena (n=elena@89.136.118.141) |
| 14:57.57 | brlcad | g'morning elena |
| 14:58.06 | elena | hi brlcad. |
| 14:58.26 | elena | do you have time for one question? |
| 14:58.29 | CIA-32 | BRL-CAD: 03brlcad * r35106 10/brlcad/trunk/src/librt/ (opennurbs_cleanup.cpp opennurbs_ext.cpp): |
| 14:58.31 | CIA-32 | BRL-CAD: refactor the tolerances being used into TOL and TOL2 to make it more apparent |
| 14:58.33 | CIA-32 | BRL-CAD: that there are two numbers being used. should test and document the effect of |
| 14:58.34 | elena | possible with a long answer. |
| 14:58.35 | CIA-32 | BRL-CAD: tightening/loosening these tolerances or make them functions if they need to be |
| 14:58.37 | CIA-32 | BRL-CAD: dynamic based on model parameters. |
| 14:58.42 | ``Erik | no, he has time for eleventy billion :D *duck* |
| 14:59.09 | elena | if he doesn't, i'll get you ;) |
| 14:59.29 | ``Erik | panics and bolts |
| 14:59.35 | elena | :) |
| 15:00.55 | ``Erik | assumes brlcad is not planning on getting in early enough to chuck his crevice or creviche or whatever in the fridge and join the lunch crowd? O.o |
| 15:03.06 | ``Erik | (elena: just ask your question and lurk for best results, someone will eventually answer your question even if everyone is busy at that moment) |
| 15:03.54 | elena | when I convert from other formats to brlcad, will I get different objects? |
| 15:04.00 | elena | or a single main object. |
| 15:04.06 | ``Erik | depends on the original format |
| 15:04.14 | elena | i suspect different file formats will give diferent results. |
| 15:04.19 | elena | aha. |
| 15:04.53 | elena | next, is there a comment somewhere, where i can find which format creates different objects? |
| 15:04.54 | ``Erik | if sane 'region' style information can be extracted from the original source, the converters will generally try to build regions... if it's just soup, then ya get soup |
| 15:05.12 | elena | aha. |
| 15:05.21 | elena | thanks, erik. |
| 15:05.30 | elena | you're off (for now) ;) |
| 15:05.33 | ``Erik | um, I don't believe there is a single document that gives that information? the man pages and source files are all available... |
| 15:05.44 | ``Erik | that might make a good wiki page |
| 15:05.52 | elena | i think the right expression is "off the hook" |
| 15:06.13 | ``Erik | (who'm I kidding, EVERYTHING makes a good wiki page... I'm gonna go make a wiki page about what I'm going to have for lunch) |
| 15:06.22 | d_rossberg | brlcad: i'll think about it ... tomorrow |
| 15:06.31 | ``Erik | yes, off the hook is a common american (possibly english) expression :) |
| 15:06.32 | brlcad | ``Erik: i already have lunch plans |
| 15:06.34 | elena | send here the link. |
| 15:06.35 | brlcad | d_rossberg: ok |
| 15:06.57 | brlcad | d_rossberg: likewise.. but what is the problem situation? or is that described in the e-mail? |
| 15:07.03 | brlcad | i've not read it all just yet |
| 15:07.17 | d_rossberg | it should be in my e-mail |
| 15:07.21 | brlcad | okay |
| 15:07.36 | brlcad | then no need to rehash, I'll reply if have questions |
| 15:08.19 | brlcad | elena: different file formats can give vastly different results, especially if it changes the format of the geometry |
| 15:09.22 | brlcad | at the simplest level, you can just report the geometry format -- most all formats fall into one of just a few categories of formats and operations |
| 15:10.27 | brlcad | e.g. regardless of the format, you can say whether a given _format_ supports boolean operations or not, and whether a given model uses boolean operations |
| 15:12.12 | brlcad | three really common geometry formats are implicit representation (which go hand-in-hand with booleans operations) and explicit representation (which generally don't use booleans but *can*) |
| 15:12.52 | brlcad | er, sorry -- I said three -- there are two primary explicit formats, polygonal meshes and spline surfaces |
| 15:13.52 | brlcad | uploads his overview presentation |
| 15:15.52 | elena | would it make sense to setup some experiments |
| 15:15.56 | elena | to convert from brlcad to different formats and back |
| 15:15.58 | elena | or the exporter may also destroy geometry? |
| 15:16.08 | elena | did you get my previous question? (i got disconnected) |
| 15:16.32 | elena | would it make sense to setup some experiments to convert from brlcad to different formats and back or the exporter may also destroy geometry? |
| 15:19.25 | brlcad | conversions are rarely ever lossless |
| 15:20.03 | elena | ok. thank you. |
| 15:20.27 | elena | have a great lunch (both of you) |
| 15:20.49 | brlcad | so setting up samples aren't really going to help -- all you can really speak to is what you have format-wise and object-wise |
| 16:00.19 | CIA-32 | BRL-CAD: 03IRPGuardian 07http://brlcad.org * r1567 10/wiki/Cutting_and_Pasting_PIX_files: /* Cutting and Pasting Pix Files */ |
| 16:05.09 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 16:52.58 | ``Erik | *burp* |
| 17:21.19 | CIA-32 | BRL-CAD: 03bob1961 * r35107 10/brlcad/trunk/ (include/ged.h src/libged/copy.c src/libtclcad/ged_obj.c): |
| 17:21.21 | CIA-32 | BRL-CAD: Added ged_dbcopy to libged for copying between databases. Added go_copy to |
| 17:21.23 | CIA-32 | BRL-CAD: libtclcad to use ged_dbcopy. The immediate need here is to have Archer use this |
| 17:21.25 | CIA-32 | BRL-CAD: for its undo ledger instead of "get" and "put" which is potentially lossy. |
| 17:29.21 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) |
| 17:47.23 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 17:49.50 | *** join/#brlcad BigAToo2 (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 18:13.20 | CIA-32 | BRL-CAD: 03starseeker * r35108 10/brlcad/trunk/ (3 files in 3 dirs): Start trying to figure out the trimming code and how to integrate trim testing into the surface tree build (essential for correct bounding box generation) |
| 18:17.27 | CIA-32 | BRL-CAD: 03erikgreenwald * r35109 10/brlcad/trunk/src/libged/ (49 files): Some warning cleanup. Added missing headers, fixed varargs stuff with too many or too few arguments provided. Minor type fixes. Etc. |
| 18:32.54 | CIA-32 | BRL-CAD: 03erikgreenwald * r35110 10/brlcad/trunk/src/adrt/ (8 files in 4 dirs): reduce warnings. |
| 18:41.10 | elena | starseeker? |
| 18:41.55 | elena | ``Erik? |
| 18:44.04 | ``Erik | elena? |
| 18:44.28 | elena | did you used starseeker's famous 1+ GB models? |
| 18:45.09 | elena | or any really big database. |
| 18:45.38 | elena | does it take long to start mged with it? |
| 18:46.02 | elena | i have to do some scripts for mged. |
| 18:46.26 | elena | it would be easier to do them in separate files and start mged multiple times for each of them. |
| 18:47.07 | elena | but I'm wondering if it would be more efficient to have one big script (especially for big db) |
| 18:47.41 | ``Erik | um, the prep routine can take several minutes for large geometry |
| 18:47.57 | ``Erik | and I'm using an 8 core 3ghz machine with 16g ram, it's no slouch |
| 18:48.05 | elena | ok. so it would make a big difference. |
| 18:48.17 | elena | then i'll try to go with the all in one script. |
| 18:48.19 | elena | thank you. |
| 18:48.24 | ``Erik | prep can be brutal... starseeker is in my office talking to indianlarry |
| 18:48.31 | ``Erik | I can throw something at him if you'd like |
| 18:48.45 | elena | no. you're answer is enough. |
| 18:48.54 | ``Erik | <-- has cans of soup, staplers, computers, etc... they'll get his attention when on ballistic trajectories |
| 18:49.07 | elena | :) |
| 18:49.24 | ``Erik | unix manuals, those're nice and hefty |
| 18:50.33 | elena | did you have lunch? |
| 18:52.18 | *** join/#brlcad mafm (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 18:52.47 | ``Erik | ja, dol sot bi bim bop at the korean restaurant |
| 18:53.54 | elena | delicious. i must have had that, too, when in seoul, but i only remember "... kim bap" |
| 18:54.29 | ``Erik | sizzling hot cast iron bowl, rice, mixed vegetables, some beef and a poached egg |
| 18:54.33 | ``Erik | good stuff |
| 18:54.49 | ``Erik | load it up with pepper paste, stir it up, ... |
| 18:55.03 | elena | :( |
| 18:55.14 | elena | there is no korean restaurant in romania. |
| 18:55.41 | elena | only chinesse. |
| 18:56.10 | ``Erik | unfortunate, at least you can hop the train to other nations easily to enjoy variety :) |
| 18:56.48 | elena | ya. |
| 18:57.00 | ``Erik | (most the food here in the US has been so "americanized", it'd be unrecognizable to visitors) |
| 18:57.49 | ``Erik | there was a nice chinese place where I lived in missouri, but you had to explicitely ask for it "chinese style" to get the good stuff |
| 18:58.27 | ``Erik | speaking a little japanese helps a bit when I go to a teppan place, too :) |
| 19:06.59 | elena | is there a man page for mged commands? i need more info about tops than it's in the Introduction_to_MGED.pdf |
| 19:07.16 | elena | i couldn't find one. |
| 19:10.31 | ``Erik | no, there's an internal "help" command |
| 19:10.46 | elena | it's not very verbose |
| 19:11.49 | ``Erik | no, it's no... I think d-lo was developing a command guide in some wiki somewhere a while back |
| 19:21.13 | CIA-32 | BRL-CAD: 03ebautu * r35111 10/web/trunk/htdocs/more/sites/all/modules/brlcad/scripts/7.14/raytrace.txt: Fixed tops enumeration |
| 19:21.33 | CIA-32 | BRL-CAD: 03erikgreenwald * r35112 10/brlcad/trunk/src/adrt/master/dispatcher.c: redaeh gnissim dda |
| 19:27.19 | CIA-32 | BRL-CAD: 03ebautu * r35113 10/web/trunk/htdocs/more/sites/all/modules/brlcad/scripts/7.14/metadata.txt: Moved to new script output format to support multiline metadata |
| 19:30.19 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 19:36.29 | jdoliner | indianlarry are you around? |
| 19:39.58 | ``Erik | he is pretty round, yes |
| 19:40.10 | indianlarry | hey joe |
| 19:40.48 | indianlarry | jdoliner: you mentioned having some questions? |
| 19:42.33 | jdoliner | yes |
| 19:43.04 | jdoliner | I spent yesterday reading over a number of papers and following wandering down citation rabit holes |
| 19:43.04 | ``Erik | ... |
| 19:43.34 | jdoliner | looking at the different implementations options |
| 19:44.28 | jdoliner | 1 option is a purely algebraic solution |
| 19:44.29 | indianlarry | k |
| 19:44.39 | jdoliner | which would be really powerful |
| 19:44.56 | jdoliner | but requires a lot of tricky algorithmics to get right |
| 19:45.32 | jdoliner | so if I took that option I think my best bet would be using some foreign abstract algebra library as a base |
| 19:46.14 | jdoliner | the other option which I'm leaning toward more and more is a marching implementation |
| 19:46.15 | indianlarry | i thought intersections between to order 3 surfaces could lead to an order 200 intersect curve? algebraically speaking |
| 19:46.39 | jdoliner | yeah sometimes they can |
| 19:47.27 | jdoliner | the literature suggest some methods to lose a bit of accuracy to drastically reduce that number |
| 19:48.25 | jdoliner | but i'm not sure exactly how good it is at this point |
| 19:48.25 | indianlarry | we have definitely run into trims that have cracks due to the error |
| 19:48.47 | jdoliner | however I spoke with brlcad earlier and we both liked the idea of the marching algorithm |
| 19:49.11 | indianlarry | would be nice to quantify/control the error |
| 19:49.18 | ``Erik | those can lead to issues with the sampling gaps |
| 19:49.22 | indianlarry | yea, need to control the error there as well |
| 19:49.26 | ``Erik | the recent metaball noise was trying to get that in check |
| 19:50.13 | jdoliner | in favor of that idea is that it could conceivably be made to share code with librt/primitves/brep |
| 19:50.27 | indianlarry | be nice |
| 19:50.44 | jdoliner | yeah agreed |
| 19:50.54 | ``Erik | hoist common stuff into libbn perhaps? |
| 19:51.17 | indianlarry | may need to do some pullbacks on face trims to get better results |
| 19:51.24 | indianlarry | in brep that is |
| 19:52.01 | CIA-32 | BRL-CAD: 03bob1961 * r35114 10/brlcad/trunk/ (4 files in 4 dirs): Added a -f option to libtclcad's go_copy and libged's ged_dbcopy. Modified archer to use "cp" instead of a "get" followed by a "put" or "adjust" when copying between the ledger and the database. |
| 19:52.30 | indianlarry | i don't have a problem if it ends up in libbn but okay to keep in librt/primitves/brep since considered work-in-progress |
| 19:52.49 | indianlarry | plus it's getting cleaned up as starseeker mentioned |
| 19:52.51 | jdoliner | yeah, I'm not sure if I could abstract it out to libbn without taking some of the openNurbs with it |
| 19:54.18 | indianlarry | we currently rely on the Ev functions in openNurbs |
| 19:54.19 | jdoliner | okay so it a marching approach seems best at this point |
| 19:54.48 | indianlarry | if you have any reference shoot them at me and i'll take a look |
| 19:55.14 | jdoliner | k I'll forward you the papers I've compiled |
| 19:55.24 | indianlarry | thanks joe |
| 20:11.48 | ``Erik | damnit, is all the creviche gone? O.o |
| 20:12.43 | brlcad | there's help for mged commands on the wiki or in the mged-internal help |
| 20:14.09 | ``Erik | hm, no sailboats in this 'bargainer', poop |
| 20:15.08 | brlcad | if pullbacks on face trims are needed by the solver to give better results, could make that some sort of "hinting callback" to the libbn solver routine |
| 20:15.26 | brlcad | so it could remain generalized, but allow customizations specific to different uses |
| 20:16.00 | brlcad | ``Erik: pfft, jeez, yes gone :) |
| 20:16.11 | brlcad | you missed the dozen people in the hallway for an hour? :) |
| 20:16.26 | ``Erik | bastages. I'm gonna barge into your domicile next time you make some to steal a portion O.o |
| 20:16.30 | ``Erik | yeah |
| 20:16.36 | ``Erik | tucked back in my corner here |
| 20:17.32 | brlcad | i'm already craving some ceviche de corvina, have to hunt for more sea bass |
| 20:18.08 | ``Erik | specialty grocery store? actual zomfg fishmonger? |
| 20:21.24 | ``Erik | decides to hold off on the boat, trailer and truck in favor of seeing how a bicycle works out for him |
| 20:21.58 | Ralith | hunts some brlcad |
| 20:23.20 | brlcad | there's a whole foods near my house, they tend to carry top shelf |
| 20:37.56 | CIA-32 | BRL-CAD: 03n_reed * r35115 10/brlcad/trunk/ (13 files in 4 dirs): initial work on a prototype ray tracing X11/OpenGL display manager (dm-rtgl) |
| 20:39.44 | brlcad | tis teh shizzle |
| 20:40.29 | Ralith | brlcad: hey so |
| 20:40.32 | Ralith | got a minute? |
| 20:40.40 | brlcad | never, sup |
| 20:41.11 | Ralith | how bout I backburner this whole Qt-embedded-in-OpenGL thing? |
| 20:41.15 | ``Erik | ngnngnggg stupid docbook crap |
| 20:41.16 | Ralith | I feel like I'm getting nowhere |
| 20:41.28 | Ralith | and the overall goals don't strictly depend on that |
| 20:41.30 | brlcad | Ralith: what's your alternative goal then? |
| 20:41.37 | Ralith | move on with the rest of what I planned to work on |
| 20:41.38 | brlcad | that's kinda the most important part of the project :) |
| 20:41.48 | Ralith | it is? |
| 20:41.53 | Ralith | I didn't realise that at all |
| 20:42.04 | brlcad | it sets the application framework |
| 20:42.14 | Ralith | was thinking I'd bring the Qt UI back to where mafm had RBGui, then extend it etc. as described in the original proposal |
| 20:42.47 | Ralith | I'm pretty sure that that work can be easily shoved into OpenGL once that bit gets worked out |
| 20:43.19 | Ralith | I'm not suggesting abandoning it, but I suspect that I can make just as much (generally minimal) progress on it while *also* making more visible progress in the other areas. |
| 20:43.53 | brlcad | not following, you mean implement customization of the UI widgets, mimicking what rbgui is presently doing? |
| 20:44.17 | Ralith | I don't imagine it will involve a great deal of customization of the widgets themselves per se |
| 20:44.39 | *** join/#brlcad stevegt_ (n=stevegt@cislunar.TerraLuna.Org) |
| 20:44.40 | Ralith | but putting together an interface at least equivalent to the current RBGui interface, yes |
| 20:45.37 | brlcad | sans the opengl context? |
| 20:46.04 | brlcad | can't wire up the controls without the 3d context working.. :) |
| 20:46.07 | Ralith | it's still easy enough to drop in an OpenGL context containing Ogre, so not exactly. |
| 20:46.15 | Ralith | just sans Qt being actually rendered as OpenGL. |
| 20:46.57 | Ralith | which means less nifty but not immediately functionality-relevant stuff like transparency |
| 20:46.58 | brlcad | what about rendering a qt widget on top of an opengl widget? |
| 20:47.04 | Ralith | yeah, basically that |
| 20:47.10 | brlcad | have you tried that? |
| 20:47.19 | Ralith | that's... not what we were going for, is it? |
| 20:47.22 | Ralith | O.o |
| 20:47.30 | Ralith | 'cuz *that* should work perfectly fine. |
| 20:47.40 | brlcad | that's very much related |
| 20:47.50 | Ralith | I can do that, easy |
| 20:47.53 | Ralith | shall I? |
| 20:47.56 | brlcad | sure |
| 20:47.59 | Ralith | yay :D |
| 20:48.04 | CIA-32 | BRL-CAD: 03starseeker * r35116 10/brlcad/trunk/ (include/opennurbs_cleanup.h src/librt/opennurbs_cleanup.cpp): More trimming tweaking, start incorporating latest changes. |
| 20:48.13 | brlcad | does that work with ogre rendering into the opengl context? |
| 20:48.18 | Ralith | oh yeah |
| 20:48.19 | brlcad | if you can show that, it's progress |
| 20:48.39 | Ralith | I got Ogre embedded in Qt to work just about first try |
| 20:48.40 | brlcad | even if it's a flat qt button painted directly over the 3d context |
| 20:48.44 | Ralith | the trick was Qt in Ogre in Qt |
| 20:49.00 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 20:49.14 | brlcad | qt in ogre in qt sounds .. way too complex |
| 20:49.16 | Ralith | if we're just drawing *over* the context, then, while not as cool, there's really no problem. |
| 20:49.25 | Ralith | brlcad: actually, it *should* have been pretty simple. |
| 20:49.36 | Ralith | Qt has support for Qt-in-OpenGL-in-Qt out of the box |
| 20:49.40 | ``Erik | it's qt's all the way down! |
| 20:49.48 | brlcad | the issue is really whether you can override the drawing routine for a button, for example, so that you can have a button alpha-blended against the 3d |
| 20:49.56 | Ralith | that's what that modelviewer demo did |
| 20:50.12 | Ralith | brlcad: don't think that can be done without actually rendering *into* the context |
| 20:50.14 | starseeker | I thought drawing over the opengl window requires that the window manager/OS cooperate |
| 20:50.17 | Ralith | (or a WM that composits) |
| 20:50.38 | Ralith | starseeker: start up a glxgears instance, drag a term over it. Works fine, no? |
| 20:50.57 | starseeker | on X, sure |
| 20:51.02 | Ralith | not elsewhere? |
| 20:51.14 | starseeker | dunno - we're looking to work on OSX and Windows too |
| 20:51.20 | brlcad | my understanding for the snippets I saw was that you'd override the Qt render method for a given widget, making it issue opengl draw commands instead of whatever it usually does |
| 20:51.30 | starseeker | that was one of the things that made the OpenGL integration so promising |
| 20:51.30 | brlcad | even if just to draw an alpha-blended texture |
| 20:51.35 | Ralith | brlcad: oh, no, not at all |
| 20:51.39 | Ralith | Qt already *has* the code to do that |
| 20:52.03 | Ralith | thought, perhaps it could be rewritten in a more Ogre-friendly way. |
| 20:52.05 | brlcad | then what's the problem? :) |
| 20:52.12 | Ralith | it doesn't work when Ogre's using the context. |
| 20:52.20 | Ralith | for some reason. |
| 20:52.30 | brlcad | that sounds incredibly vague :) |
| 20:52.36 | Ralith | now you know how I feel :| |
| 20:52.44 | brlcad | I'm pretty sure that's what I saw in the examples I reviewed :) |
| 20:52.55 | Ralith | not the modelviewer, certainly |
| 20:53.06 | brlcad | don't know that example, these were running apps |
| 20:53.13 | Ralith | so was that |
| 20:53.16 | Ralith | very neat demo |
| 20:53.26 | Ralith | big green spinny Qt logo on a blue background |
| 20:53.34 | Ralith | transparent Qt dialogs overlayed |
| 20:53.38 | brlcad | have you run stellarium before? |
| 20:53.41 | Ralith | like I said, Qt 4.5 comes out of the box with support for rendering widgets into an OpenGL context, and doing so in a Qt window is the logical way to do it. |
| 20:53.47 | Ralith | hm, yeah |
| 20:53.55 | Ralith | I keep forgetting to take a look at that. I'll do that. |
| 20:54.00 | Ralith | checks to see if he checked it out previously |
| 20:54.23 | brlcad | their approach should be nearly identical and iirc, it was a simple override |
| 20:54.23 | Ralith | considering that they've been doing it since long before 4.5 |
| 20:55.00 | Ralith | that'll take a good bit more work than rendering *on* the widget, but I'll try for it, then. |
| 20:55.39 | brlcad | you say you got ogre rendering to a qt-created opengl context, yes? |
| 20:55.43 | Ralith | yup |
| 20:55.46 | Ralith | at least, I think so. |
| 20:55.57 | Ralith | the background color's rendered properly and Ogre's internally consistent |
| 20:56.01 | brlcad | and did you try just splatting a qt button right on top of that context? |
| 20:56.07 | Ralith | splatting? |
| 20:56.15 | starseeker | and the issue was that once Ogre DID render to that context, Qt couldn't? |
| 20:56.21 | Ralith | starseeker: yes, exactly. |
| 20:56.27 | Ralith | on a frame-by-frame basis, no less |
| 20:56.32 | brlcad | one big opengl window .. put a qt window in the middle of it |
| 20:56.34 | Ralith | if I disabled Ogre for a frame, Qt would render happily. |
| 20:56.40 | brlcad | bah, s/qt window/qt button/ |
| 20:56.54 | Ralith | brlcad: do you mean in or out of the OpenGL context? |
| 20:57.07 | brlcad | neither and both |
| 20:57.09 | brlcad | on top of |
| 20:57.14 | Ralith | :| |
| 20:57.18 | Ralith | then you've lost me |
| 20:57.36 | Ralith | logically rendered as OpenGL or not>? |
| 20:58.46 | brlcad | I don't care what it does on the backend, I'm talking about the end result -- one big window with ogre able to draw a 3d scene into it, and the ability to have a button in that same window (drawn on top of the 3d context) |
| 20:59.00 | brlcad | not next to it |
| 20:59.09 | brlcad | don't care how qt draws its button |
| 20:59.19 | brlcad | can it show them both at the same time is the issue |
| 20:59.52 | Ralith | then we're back in easy territory |
| 21:00.01 | Ralith | I'm pretty sure Qt can do that trivially |
| 21:00.05 | Ralith | bears testing, of course |
| 21:00.09 | brlcad | show me :) |
| 21:00.17 | Ralith | 'kay |
| 21:00.31 | Ralith | this will almost certainly *not* permit things like transparent widgets/windows |
| 21:00.46 | brlcad | because if that works, then it really should be a matter of overriding the widget's draw routine |
| 21:00.52 | Ralith | and may or may not give trouble if we want to display other 3D content in windows, I'm not sure what multiple GL context hw support is like |
| 21:00.57 | Ralith | er... |
| 21:01.01 | Ralith | I don't see how the two approaches are related. |
| 21:01.11 | brlcad | it's a matter of compositing |
| 21:01.15 | brlcad | whether qt is doing it or not |
| 21:01.37 | brlcad | it has to have some minimal sort-order compositing in order to draw a button on top of a 3d context |
| 21:01.50 | brlcad | if it does, then we're probably good |
| 21:02.35 | Ralith | is confused but can write the test |
| 21:03.04 | brlcad | I'm thinking you're not getting what is meant by overriding the widget's draw routine ? |
| 21:03.23 | brlcad | dno't worry about that bit for now -- if you can show a button on an ogre context, that'll be progress |
| 21:03.34 | brlcad | s/on/on top of/ |
| 21:04.31 | Ralith | I assume you mean overriding it such that it draws into OpenGL directly |
| 21:05.08 | brlcad | sure, or printf's to console, whatever you want -- that's the beauty of an override :) |
| 21:05.36 | Ralith | I suspect I'll end up reimplementing QGraphicsView only less broken |
| 21:06.10 | brlcad | try the simple demo first, then take a look at stellarium's approach (or vice versa) |
| 21:39.04 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-11-1.dclient.hispeed.ch) |
| 21:57.09 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 21:58.52 | starseeker | desperately hopes this news of the Apollo 11 tapes is the real deal |
| 21:59.17 | starseeker | if they post high quality digital conversions online, I know I'll be grabbing the lot of them |
| 22:24.40 | CIA-32 | BRL-CAD: 03r_weiss * r35117 10/brlcad/trunk/src/libged/make_pnts.c: more cleanup, improved error checking and messages |
| 22:26.23 | Ralith | starseeker: design data? |
| 22:26.24 | Ralith | or what? |
| 22:27.01 | starseeker | the feeds you've seen of the original moon landing are apparently of lower quality than was originally recorded |
| 22:27.35 | starseeker | I.e., it was downgraded by pointing a video camera at a monitor |
| 22:28.04 | starseeker | there are indications they have found some of the original recordings that didn't get routed through a TV camera :-) |
| 22:28.32 | Ralith | oo, cool |
| 22:29.13 | archivist | getting the old recorders working is the fun part |
| 22:29.23 | starseeker | considering that it easily ranks as one of the greatest moments in the history of humanity, I would think getting the highest recording quality available preserved is important |
| 22:30.47 | starseeker | apparently for a while the non-degraded tapes were lost |
| 22:31.00 | starseeker | incredible, really |
| 22:32.03 | archivist | http://www.wired.com/wired/archive/15.01/nasa.html?pg=2 |
| 22:32.50 | starseeker | Of course, they wanted to use the Messel Oil Shale Pit as a trash dump, despite it containing what may be the highest quality fossils ever discovered... |
| 22:32.55 | archivist | I saw pics of the recorder some months ago |
| 22:34.13 | ``Erik | huh, richard committed without anyone harrassing him O.o (I imagine he's pissed that I mucked in his code) |
| 22:34.21 | ``Erik | or, rather, without me harrassing him |
| 22:35.12 | starseeker | this fossil still makes me stare in wonder: http://en.wikipedia.org/wiki/File:Prachtkäfer_aus_der_Grube_Messel.JPG |
| 22:38.12 | starseeker | or this one: http://www.paleontology.uni-bonn.de/wedmann%20english_version.htm |
| 22:39.33 | starseeker | 50 million years, and we get to see it. Incredible |
| 22:48.33 | CIA-32 | BRL-CAD: 03r_weiss * r35118 10/brlcad/trunk/src/libged/make_pnts.c: small data type fix |
| 22:59.45 | CIA-32 | BRL-CAD: 03starseeker * r35119 10/brlcad/trunk/src/librt/ (opennurbs_cleanup.cpp primitives/brep/brep_cleanup.cpp): Inching closer to behavior of original curve tree build - still have a ways to go, probably. |
| 23:02.10 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-181.sbndin.btas.verizon.net) |
| 23:57.27 | *** join/#brlcad CIA-30 (n=CIA@208.69.182.149) |
| 23:58.02 | ``Erik | starts looking through IOKit docs |
