| 02:15.03 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 02:50.12 | CIA-32 | BRL-CAD: 03indianlarry * r35080 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 02:50.12 | CIA-32 | BRL-CAD: added adjacent face code to curve trims, also added cleanup of face hitlist |
| 02:50.14 | CIA-32 | BRL-CAD: for cases where multiple INs/OUTs of faces encountered |
| 02:53.22 | CIA-32 | BRL-CAD: 03indianlarry * r35081 10/brlcad/trunk/include/opennurbs_ext.h: add adjacent face code to curve trims |
| 02:54.49 | CIA-32 | BRL-CAD: 03indianlarry * r35082 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: add adjacent face code to trim curves |
| 02:56.12 | CIA-32 | BRL-CAD: 03indianlarry * r35083 10/brlcad/trunk/src/ (libged/brep.c librt/primitives/brep/brep_debug.cpp): added more debugging code/options to mged brep command |
| 06:53.34 | Ralith | brlcad: I'd like to discuss the possibility of just not rendering Qt into the OpenGL context, at least for now; most of the rest of what I proposed to work on can be completed with Qt simply sitting on *top* of the context, although some parts might not be quite as shiny as would otherwise be possible. |
| 06:54.43 | Ralith | and I don't think it would take much rewriting to modify said work to operate inside a GL context when a way is (hopefully) eventually found. |
| 06:55.24 | Ralith | considering how standard Qt widgets and even entire windows can be literally dropped directly in with little or no special consideration. |
| 06:56.25 | Ralith | I can produce much more visible and interesting work this way, and continue conversations with more Ogre- and Qt-knowledgable people to work out the GL issue in the background. |
| 07:02.54 | *** join/#brlcad LarsG (n=lars@dial208-53.dialup.nus.edu.sg) | |
| 07:03.01 | *** part/#brlcad LarsG (n=lars@dial208-53.dialup.nus.edu.sg) | |
| 07:25.07 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 11:59.00 | d-lo | Mernin all!! |
| 12:19.45 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net) | |
| 12:36.47 | *** join/#brlcad docelic_ (n=docelic@78.134.200.170) | |
| 13:01.37 | ``Erik | *burp* |
| 13:03.04 | ``Erik | any news on the injector/server project, d-lo? |
| 13:36.17 | CIA-32 | BRL-CAD: 03brlcad * r35084 10/brlcad/trunk/src/other/step/src/cleditor/STEPfile.inline.cc: |
| 13:36.19 | CIA-32 | BRL-CAD: apply a simple patch that should hopefully fix sf bug 2820579, reported by Jeff |
| 13:36.21 | CIA-32 | BRL-CAD: Meldrum (jspaces) regarding a const to non-const conversion. according to a |
| 13:36.23 | CIA-32 | BRL-CAD: handful of online sources, c++ apparently changes the signature of strrchr from |
| 13:36.25 | CIA-32 | BRL-CAD: the posix C decl with two overloaded possibilities, both input and return are |
| 13:36.27 | CIA-32 | BRL-CAD: either const or non-const. |
| 13:54.40 | CIA-32 | BRL-CAD: 03irpguardian * r35085 10/brlcad/trunk/src/proc-db/human.c: Changed the torso parts to use a TGC instead of a RCC to make it less bulkly looking, and more human shaped. |
| 14:26.55 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 14:30.19 | d_rossberg | d-lo: to have a header file with defines for the version numbers appears to be an issue of its own |
| 14:36.17 | d_rossberg | d-lo: because of the common.h issue i need to have a look at my linux build at home ... |
| 14:39.05 | d-lo | ah! minimized the irc window. Sorry. |
| 14:39.36 | d-lo | fyi a simple rename of common.h to cicommon.h worked like a champ. |
| 14:40.14 | d-lo | Looking through things, I see that in order to generate {RT3}/include/brlcad/brlcadversion.h, you have to have the source from the BRLCAD module. |
| 14:41.00 | d-lo | One of the assumptions I am making for the CMake build system in the rt^3 module is that, at a minimum, there is a BRLCAD install on the machine. Not necessarily the source. |
| 14:41.24 | d-lo | so I suppose I need to find out if there is a way to extract versioning information from a BRLCAD install. |
| 14:41.28 | d-lo | .... anyone know? |
| 14:42.02 | d_rossberg | this would have been my next question :) |
| 14:42.23 | *** join/#brlcad mafm (n=mafm@83.42.152.74) | |
| 14:42.32 | d-lo | i remember running across it somewheres.... just gotta find it :/ |
| 14:43.27 | d-lo | There is a string reference to the package version on line 412 in brlcad_config.h |
| 14:44.35 | d-lo | heh, I don't even know if its possible to do string parsing with CMake.... |
| 14:45.31 | _clock_ | d-lo: if it's turing equivalent then definitely yes :) |
| 14:48.35 | d_rossberg | my philosophy with the core Interface is something different from yours: |
| 14:48.50 | d_rossberg | the core interface is the interface for external programs |
| 14:49.13 | d_rossberg | there shouldn't be any other include/brlcad |
| 14:50.07 | d_rossberg | and, to be honest we don't have such a directory at the moment |
| 14:50.21 | d-lo | Hrm, then, I suppose, the question is: Why are there coreInterface include files in rt3? By that philosphy, shouldn't they be in the brlcad module? |
| 14:50.40 | d_rossberg | the include/brlcad from the installation has to be added explicitely (i hink) to the inlude paths |
| 14:50.56 | d_rossberg | d-lo: yes |
| 14:51.03 | d-lo | the include/brlcad from the BRLCAD installation? |
| 14:51.10 | d_rossberg | however, that's my opinion |
| 14:51.25 | d_rossberg | the one you have the problem with |
| 14:52.59 | d_rossberg | now i remember: i added only the include/brlcad directory from the installation to the include paths |
| 14:53.08 | d-lo | Heh, well, if its your opinion that they should be in the BRLCAD module... put em there :) They're your babies, store them wherever you want :) don't let that BRLCAD guy tell you otherwise :) |
| 14:53.29 | d_rossberg | i.e. not the inlude directory alone |
| 14:54.22 | d-lo | ah, so {BRLCAD_INSTALL_PATH}/include/brlcad/ and not {BRLCAD_INSTALL_PATH}/include/ ? |
| 14:54.35 | d_rossberg | this way i didn't get the confusion between the two common.h |
| 14:54.46 | d_rossberg | d-lo: yes |
| 14:55.53 | d-lo | Another question then: What is stopping you from moving the coreInterface files into the brlcad module? |
| 14:57.44 | d-lo | doesn't want to sound offensive. Just trying to get rt^3 whipped into shape. |
| 14:58.07 | d_rossberg | there are still some incompatibilities: e.g. which files should be copied into the installation directory at include/brlcad ? :) |
| 14:59.38 | d-lo | why not put all your headers into include/brlcad/ci/ ? |
| 14:59.46 | d-lo | resolves a lot of problems... |
| 15:00.15 | d_rossberg | no, they are intended for include/brlcad |
| 15:00.50 | d_rossberg | on the other side, d-lo, you have a point ther with the common.h issue |
| 15:01.15 | d-lo | heh, well I am good at causing, er, finding problems. |
| 15:01.42 | d_rossberg | the core interface should be usable in virtually every program |
| 15:02.20 | d-lo | Right, but how does having the includes in include/brlcad/ci/ change that? *confused* |
| 15:03.19 | d_rossberg | i.e. we may solve the issue with our own includes, but it could be wise to have a prefix for the BRL-CAd headers |
| 15:03.53 | d_rossberg | ... i see the ci as the only interface, so why should it be in a subdirectory? |
| 15:04.32 | d-lo | Organizational reason only. |
| 15:05.03 | d-lo | As far as I can tell, common.h is the only conflict. all the rest of the coreInterface headers don't conflict. |
| 15:05.34 | d-lo | And for organizational reasons, you are thinking that there should be prefixes on headers? Did I understand that correctly? |
| 15:06.57 | d_rossberg | at the moment it is only an idea, i thought brlcad/ is already prefix enough ... |
| 15:07.16 | d-lo | ah, okay. I see what you mean. |
| 15:07.52 | d-lo | I haven't looked at the difference in the files, but is there a way to merge the two common.h's or should it be solved by a rename of one of them? |
| 15:08.31 | d_rossberg | you could rename it to brlcadcommon.h |
| 15:08.44 | d_rossberg | this name would match with brlcadversion.h |
| 15:09.30 | d-lo | so rt^3/include/brlcad/common.h -> rt^3/include/brlcad/brlcadcommon.h ? |
| 15:09.39 | d_rossberg | yes |
| 15:10.10 | d-lo | and then once that rename is done, would there be any other problems moving the coreInterface files to the brlcad module? |
| 15:10.14 | d_rossberg | and maybe rt^3/include/brlcad/globals.h -> |
| 15:10.28 | d_rossberg | rt^3/include/brlcad/brlcadglobals.h |
| 15:10.39 | d-lo | okay, the globals makes sense also. |
| 15:11.01 | d_rossberg | the other file names start with a capital letter |
| 15:11.07 | d_rossberg | i.e. are unique |
| 15:11.42 | d_rossberg | (at least fot *IX) |
| 15:12.10 | d-lo | right on. |
| 15:13.03 | d-lo | If you would like, I can move the coreInterface files over to the BRLCAD module... or I can just leave them where they are and unwire them from the CMake build system I am making. Your choice, whatever you feel like. :) |
| 15:16.29 | CIA-32 | BRL-CAD: 03davidloman * r35086 10/rt^3/trunk/cmake/FindBRLCAD.cmake: Fixing some bugs in FindBRLCAD.cmake |
| 15:21.38 | d_rossberg | how does this go together with your plans with the "Geometry Engine"? |
| 15:22.34 | d-lo | I am working on changing the whol rt3 module over to CMake, and since coreInterface is in the rt3 module, I assumed I needed to work it in to the build also. |
| 15:24.46 | d_rossberg | i meant you wanted to make the coreInterface part of your GE |
| 15:26.35 | d_rossberg | has to go now |
| 15:51.00 | brlcad | ~seen madant |
| 15:51.01 | ibot | madant <i=cb7baf0f@gateway/web/freenode/x-a32eed164597bd06> was last seen on IRC in channel #brlcad, 9d 19h 29m 7s ago, saying: 'nothing more disastrous than non-cooperative softwares ;)'. |
| 15:51.30 | d-lo | wow... 9 days |
| 15:58.40 | CIA-32 | BRL-CAD: 03davidloman * r35087 10/rt^3/trunk/src/ (3 files in 3 dirs): Unwiring coreInterface from CMake for now. There is a dependancy that requires the brlcad source to be present on the computer instead of just the installation. |
| 15:58.41 | d-lo | howdy brlcad ! |
| 16:08.45 | d-lo | hates having an ogre<->boost dep. |
| 16:08.49 | d-lo | bangs head on wall. |
| 16:18.15 | d-lo | Ralith: based on what I have read, I think your current approach is the best. You may have to modify your GSoC goals though. |
| 16:20.22 | brlcad | boost is an easy dep, just a bunch of header files :) |
| 16:20.59 | d-lo | right, but ogre isn't building without it. Even when i set OGRE_USE_BOOST to OFF, it still tries to link against it :/ |
| 16:21.21 | brlcad | so? .. don't turn it off.. |
| 16:21.46 | d-lo | not to mention, when it IS properly linking, its claiming that boost::thread::hardware_concurrency() doesn't exist... when it does. grrr. |
| 16:22.01 | brlcad | or you mean they don't provide it and our subset doesn't provide what they need either? |
| 16:22.05 | d-lo | Right, I have tried it both ways, both have compile problems. |
| 16:22.21 | d-lo | I have boost installed in its entirety. |
| 16:22.27 | brlcad | boost threading is in the core, which brlcad module provides |
| 16:22.47 | d-lo | Even with that, ogre is failing |
| 16:23.00 | brlcad | then that's a problem with ogre, not boost |
| 16:23.08 | d-lo | right. |
| 16:23.16 | d-lo | never said it wasn't. :) |
| 16:23.50 | brlcad | well the "hate" is still somewhat misplaced :) |
| 16:24.19 | brlcad | i mean you're free to hate whatever you want, of course :) |
| 16:24.27 | d-lo | I was gonna say... |
| 16:24.33 | d-lo | its MY hate not yours. |
| 16:24.35 | d-lo | get your own |
| 16:24.41 | brlcad | i hate you! |
| 16:24.48 | d-lo | *GASP* |
| 16:24.59 | d-lo | Don't me hatin |
| 16:25.14 | brlcad | hates d-lo's ogre<->boost hate |
| 16:25.41 | d-lo | I figure since Ogre loves boost so much, I *MUST* hate boost. Seems natural. |
| 16:27.18 | brlcad | aside: you do know that most/many of the core (tr1) components of boost are going to become part of the c++ standard, yes? |
| 16:27.18 | d-lo | when I build BRLCAD and install it, does libboostcore get installed also> |
| 16:27.20 | d-lo | ? |
| 16:27.53 | d-lo | Yeah, you mentioned that. I figure that will be a good time to become a pure C Zealot. ;) |
| 16:28.09 | brlcad | heh |
| 16:29.26 | brlcad | libboostcore?? |
| 16:30.05 | d-lo | yes, boost's core lib that you said is in the brlcad module. |
| 16:30.17 | brlcad | it's not a lib, it's headers |
| 16:30.24 | d-lo | well, whateveritsactuallycalled. |
| 16:30.53 | d-lo | so it gets installed then? |
| 16:31.22 | brlcad | if you mean do we install the headers, I don't believe so at the moment as there was no need |
| 16:32.00 | brlcad | would be trivial to install, but if we do that, we probably should bundle more than we are bundling so it's a complete dependency |
| 16:32.06 | brlcad | not a subset like it presently is |
| 16:32.15 | d-lo | Well hell. How am I going to make Ogre behave then..... hrm |
| 16:32.23 | brlcad | or you make rt^3's build require having a brlcad source tree as well |
| 16:32.39 | brlcad | or you just require folks install all of boost first, old school |
| 16:33.53 | d-lo | I was wondering about that... what would be your opinion of 'best practice'? Linking rt3 to a brlcad install or making rt3 dependant on the brlcad source? |
| 16:38.21 | brlcad | plenty of projects do both, the latter tends to suck more as it's just mostly dev convenience |
| 16:38.36 | brlcad | rt3 already requires a brlcad install, that's inevitable |
| 16:39.21 | brlcad | and our project practice is towards dependency management, not user-required actions (having them install boost would be a user-required dependency action) |
| 16:39.44 | brlcad | short term, though, doesn't really matter -- so, they have to install qt+boost |
| 16:40.18 | brlcad | long term, can probably upgrade the boost dep in brlcad module to a full copy and have it fully managed like other deps |
| 16:41.44 | d-lo | alrighty then. |
| 16:41.58 | d-lo | Have you read up on what Dr Rossberg and I were yaking about? |
| 16:42.18 | starseeker | thinks cracking proper Qt/OGRE integration would be very useful, even if it produces less visible result... |
| 16:43.46 | d-lo | starseeker: when I get install permission failures concerning tkhtml3, do i need to --disable-documentation to bypass that? |
| 16:44.11 | brlcad | not yet, working on evals |
| 16:44.11 | starseeker | no, that's a mistake in the make file |
| 16:44.24 | starseeker | is that that nroff thing? |
| 16:44.25 | d-lo | brlcad: okie. |
| 16:44.30 | starseeker | huts |
| 16:44.34 | starseeker | er, hunts even |
| 16:44.42 | brlcad | has indianlarry done his eval yet? |
| 16:44.53 | brlcad | he hadn't as of this morning |
| 16:45.00 | brlcad | only has an hour or so before the deadline |
| 16:45.05 | starseeker | I'll ask |
| 16:49.19 | starseeker | d-lo: what's the specific failure on the permission? |
| 16:49.44 | d-lo | I don't have access to /usr |
| 16:49.50 | d-lo | err write access |
| 16:51.45 | starseeker | hmm. |
| 16:52.02 | starseeker | I remember seeing that, and it had something to do with tkhtml.n |
| 17:05.21 | CIA-32 | BRL-CAD: 03starseeker * r35088 10/brlcad/trunk/src/other/tkhtml3/Makefile.in: Don't set DESTDIR to empty in tkhtml3 Makefile.in |
| 17:05.28 | starseeker | d-lo: does that help? |
| 17:05.43 | d-lo | lemme check. |
| 17:09.42 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 17:09.53 | d-lo | *buildbuildbuild* |
| 17:13.04 | d-lo | starseeker: Nope :( still getting: mkdir: cannot create directory `/usr/lib/Tkhtml3.0': Permission denied when trying to install to /home/dloman/ |
| 17:13.24 | starseeker | hmm |
| 17:16.55 | starseeker | grr |
| 17:21.58 | brlcad | could be some DESTDIR problem if there are custom install rules (not that there should be custom install rules) |
| 17:22.40 | starseeker | is wondering if the TEA extensions are getting into the act |
| 17:22.50 | brlcad | hm, could be |
| 17:22.57 | brlcad | loooks like they do have DESTDIR properly |
| 17:23.20 | starseeker | that's why I nuked the empty DESTDIR line - thought perhaps that was killing the DESTDIR feed from configure |
| 17:23.42 | starseeker | wonder why it doesn't happen on all platforms... |
| 17:24.19 | starseeker | ponders a pleading email to the TEA devs to integrate with autoconf/automake out of the box... |
| 17:24.24 | brlcad | maybe it does |
| 17:24.41 | starseeker | just did a make install on the mac - went to my local directory |
| 17:24.52 | brlcad | have him send you his Makefile that was generated, compare it to yours |
| 17:25.45 | d-lo | starseeker: do you have write permissions to /usr/lib/ ? |
| 17:25.54 | starseeker | I shouldn't |
| 17:26.14 | starseeker | nope |
| 17:26.21 | d-lo | starseeker: FYI, just got same error. |
| 17:27.01 | d-lo | where is the brlcad.org pastbin again? |
| 17:27.19 | starseeker | ~pastebin |
| 17:27.20 | ibot | [~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste |
| 17:28.02 | starseeker | well, I don't see ours there... |
| 17:29.00 | d-lo | ah ha: http://pastebin.bzflag.bz/ |
| 17:30.29 | d-lo | starseeker: http://pastebin.bzflag.bz/m94c45f1 |
| 17:33.18 | ``Erik | *readreadread* |
| 17:33.54 | brlcad | d-lo: you can tell rain that I made her some ceviche de camarones |
| 17:33.56 | brlcad | i'll bring some in for everyone to try tomorrow |
| 17:34.07 | d-lo | kk |
| 17:34.08 | ``Erik | that sounds... so.. wrong... |
| 17:34.35 | brlcad | so yummy! |
| 17:34.47 | d-lo | from Rain: Spicy |
| 17:34.48 | d-lo | ? |
| 17:35.04 | d-lo | 'Rain's Spicy' that is. |
| 17:43.54 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net) | |
| 17:52.19 | CIA-32 | BRL-CAD: 03erikgreenwald * r35089 10/isst/trunk/src/main.c: set database and master hostnames in main() |
| 17:53.31 | CIA-32 | BRL-CAD: 03erikgreenwald * r35090 10/isst/trunk/src/gui.c: extract attach code out of validation function |
| 17:57.38 | CIA-32 | BRL-CAD: 03erikgreenwald * r35091 10/isst/trunk/ (8 files in 2 dirs): indent. |
| 18:02.07 | CIA-32 | BRL-CAD: 03erikgreenwald * r35092 10/isst/trunk/src/main.c: fix wrong variable being set. woops. |
| 18:02.18 | CIA-32 | BRL-CAD: 03erikgreenwald * r35093 10/isst/trunk/src/gui.c: have .g loading automatically attach to the master daemon. |
| 18:06.38 | CIA-32 | BRL-CAD: 03starseeker * r35094 10/brlcad/trunk/src/librt/opennurbs_cleanup.cpp: Ooops - add in the check to ensure bounding box dimensions are not degenerate in x, y or z |
| 18:17.43 | brlcad | not so spicy |
| 18:17.57 | brlcad | I made it pretty mild |
| 18:18.21 | brlcad | she'll probably still think it's hot, but it's not anywhere near what I usually do |
| 18:18.39 | brlcad | only used a few habaneros for nearly 2lbs of shrimp |
| 18:21.44 | brlcad | starseeker: any reason to not just increment the amount you tested against? |
| 18:22.13 | brlcad | pushing both max and min will make it 2x that value, should be enough |
| 18:22.22 | brlcad | and a lot tighter |
| 18:23.34 | starseeker | brlcad: That's an option - right now I'm just trying to reproduce the bounding box behavior of the original code |
| 18:23.41 | starseeker | still not there yet :-( |
| 18:24.46 | starseeker | Once I do, I can go back and tighten it to the tolerance and see what that does :-) |
| 18:25.00 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 18:29.45 | CIA-32 | BRL-CAD: 03erikgreenwald * r35095 10/brlcad/trunk/src/adrt/slave/load_g.c: join slave_load_g() and some_intermediate_function() |
| 18:33.27 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net) | |
| 18:35.37 | ``Erik | *snrkt* wells fargo sueing itself, grand |
| 18:37.39 | starseeker | so when lawyers run out of targets, they start suing themselves? |
| 18:38.02 | ``Erik | it's on /. |
| 18:38.54 | ``Erik | comments seem to indicate the combination of wells fargo having two mortgages on a house and florida law are forcing it to happen *shrug* |
| 18:41.14 | starseeker | talk about poetic justice... |
| 18:47.35 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) | |
| 18:52.29 | ``Erik | here's a better one, deep purple is paying fines for playing their own songs |
| 18:52.34 | ``Erik | http://techdirt.com/articles/20090710/0340345512.shtml |
| 18:59.50 | d-lo | ``Erik: heres SimStapler http://www.freeverse.com/games/game/?id=7022 |
| 19:27.01 | ``Erik | nice |
| 19:29.33 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-160.sbndin.btas.verizon.net) | |
| 19:33.05 | ``Erik | what're the build instructions for the gs thingymajigger? |
| 19:35.41 | d-lo | 1) cmake . |
| 19:35.45 | d-lo | 2) make |
| 19:35.58 | d-lo | Qt needs to be in your PATH |
| 19:35.58 | ``Erik | ok, so I gotta figure out how to get cmake installed |
| 19:36.01 | ``Erik | and qt |
| 19:36.19 | d-lo | automake is still working btw. |
| 19:36.28 | d-lo | err autotools build still works. |
| 19:36.54 | ``Erik | hm, thought I ran into issues with auto* |
| 19:47.15 | ``Erik | hrm, are you building 64b? |
| 19:47.42 | d-lo | yes. whats up? |
| 19:48.06 | ``Erik | GS/tests/streamSerialTests.cxx makes some bad assumptions... "unsigned long" being 64b where it's 32 on a 32 bit system |
| 19:48.21 | ``Erik | uint64_t might be better for that |
| 19:48.57 | d-lo | righto, its on the lists of things to fix. That was an ooooooold hack that I never got around to working on yet. ;) |
| 19:49.41 | d-lo | Well, I out. Peace. |
| 19:55.39 | CIA-32 | BRL-CAD: 03erikgreenwald * r35096 10/rt^3/trunk/src/tests/streamSerialTests.cxx: use types with explicit widths. Change 'long' to 64b int. Change magic #s to hex (should it be stdint.h INTX_MAX?). |
| 20:10.27 | CIA-32 | BRL-CAD: 03irpguardian * r35097 10/brlcad/trunk/src/proc-db/human.c: |
| 20:10.29 | CIA-32 | BRL-CAD: Completly redone all functions to take human data structure, as opposed to numerous variables. |
| 20:10.31 | CIA-32 | BRL-CAD: However, currently does not build anything, as it bus-fails when attempting to put information into |
| 20:10.33 | CIA-32 | BRL-CAD: the human_data->torso->torsoLength location. |
| 20:38.57 | *** join/#brlcad stevegt_ (n=stevegt@cislunar.TerraLuna.Org) | |
| 20:50.25 | Ralith | d-lo: I don't see anything particularly critical about rendering Qt *in* OpenGL. I mean, it has nice parts and is certainly desirable, but it's quite possible to get by without itâlook at the competition. |
| 20:51.51 | CIA-32 | BRL-CAD: 03irpguardian * r35098 10/brlcad/trunk/src/proc-db/human.c: Fixed it to where the human builds, but some parts are not in their correct locations |
| 20:58.18 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 20:58.53 | CIA-32 | BRL-CAD: 03irpguardian * r35099 10/brlcad/trunk/src/proc-db/human.c: |
| 20:58.55 | CIA-32 | BRL-CAD: Fixed everything, so now it's a human generator with all variables stored in the human_data_t struct. |
| 20:58.58 | CIA-32 | BRL-CAD: Even works with all poses. |
| 21:50.19 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-160.sbndin.btas.verizon.net) | |
| 22:13.25 | ``Erik | "fixed everything" hehehe, if only |
| 22:23.26 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) | |
| 22:48.03 | ``Erik | nice, my alma mater made collegehumor.com http://www.freeverse.com/games/game/?id=7022 |
| 22:48.07 | ``Erik | woops |
| 22:48.36 | ``Erik | http://www.collegehumor.com/picture:1916488 |
| 22:53.27 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) | |
| 23:23.01 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) | |
| 23:28.46 | ``Erik | *omnomnom* mm bourbon steak strips |
| 23:29.24 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) | |
| 23:37.18 | *** join/#brlcad BigAToo2 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) | |
| 23:39.05 | *** join/#brlcad BigAToo3 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) | |
| 23:39.56 | *** join/#brlcad BigAToo4 (n=BigAToo@pool-96-230-124-207.sbndin.btas.verizon.net) | |