| 01:40.36 | *** join/#brlcad stevegt_ (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 01:54.17 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 05:15.48 | Ralith | quiet evening |
| 06:43.37 | CIA-32 | BRL-CAD: 03ralith * r35072 10/rt^3/trunk/src/g3d/ (CMakeLists.txt OgreScene.cxx OgreScene.h ogretest.cxx): Incomplete test for Ogre/Qt integration |
| 06:47.33 | CIA-32 | BRL-CAD: 03ralith * r35073 10/rt^3/trunk/src/g3d/ogretest.cxx: Initialize and single-step Qt before Ogre to ensure that a GL context exists for Ogre to render to. |
| 06:55.27 | CIA-32 | BRL-CAD: 03ralith * r35074 10/rt^3/trunk/src/g3d/ogretest.cxx: Moved to Ogre's mainloop |
| 06:59.15 | Ralith | hm. |
| 07:01.07 | CIA-32 | BRL-CAD: 03ralith * r35075 10/rt^3/trunk/src/g3d/ (QtRenderListener.cxx ogretest.cxx): Added the usual test widget, which does not render correctly, but which has some interesting side effects on what is rendered. |
| 07:05.14 | *** join/#brlcad PrezKennedyIII (i=Matthew@whitecalf.net) |
| 07:05.31 | Ralith | wait |
| 07:05.36 | Ralith | I guess that's not a side effect of the widget |
| 07:05.37 | Ralith | damn. |
| 07:09.19 | *** join/#brlcad pacman87 (n=pacman87@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 07:09.20 | *** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net) [NETSPLIT VICTIM] |
| 07:09.32 | Ralith | ooh |
| 07:09.33 | Ralith | promising, I think |
| 07:10.08 | *** join/#brlcad pacman871 (n=pacman87@bz.bzflag.bz) |
| 07:13.28 | CIA-32 | BRL-CAD: 03ralith * r35076 10/rt^3/trunk/src/g3d/ogretest.cxx: |
| 07:13.30 | CIA-32 | BRL-CAD: Switched to a custom mainloop which instructs Ogre not to swap the OpenGL |
| 07:13.32 | CIA-32 | BRL-CAD: buffers, because Qt presumably does this. While it has not been determined |
| 07:13.34 | CIA-32 | BRL-CAD: whether Qt's buffer swap occurs at the right time, this has a promising side |
| 07:13.36 | CIA-32 | BRL-CAD: effect: a corner of the render window contains a block of white, the default |
| 07:13.38 | CIA-32 | BRL-CAD: background color of Qt's rendering. |
| 07:14.34 | Ralith | I wonder if that guy Assaf who came up with this approach is still around. |
| 07:21.03 | Ralith | listens to his hdd click away |
| 08:40.24 | CIA-32 | BRL-CAD: 03Ralith 07http://brlcad.org * r1559 10/wiki/User:Ralith: Log for 2009-07-10 |
| 08:43.14 | CIA-32 | BRL-CAD: 03Ralith 07http://brlcad.org * r1560 10/wiki/User:Ralith: Added additional notes on the questionable safety of Qt's buffer swap to 2009-07-10's log entry |
| 09:20.45 | *** join/#brlcad mafm (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 11:14.58 | *** join/#brlcad _sushi_ (n=_sushi_@84-73-206-252.dclient.hispeed.ch) |
| 11:17.07 | ``Erik | *yawn* |
| 12:04.20 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 13:49.08 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 13:56.47 | brlcad | stevegt_: either of those two alternatives should work. anything you write in 2 could be pretty trivially rewritten as 1 by one of us |
| 13:59.10 | brlcad | stevegt_: and you're right regarding special-purpose binaries in a unix-style that do one thing (presumably well) and that can be tied together with other commands, mged then adds a slew of special-purpose scripting facilities (in Tcl) on top of that -- there are about 400 binaries, about 700 tcl commands (although many are "dev" commands) |
| 14:04.21 | brlcad | the performance of scripting nirt really shouldn't be a problem unless you need to invoke nirt or mged thousands/millions of times, then the overhead starts to heavily outweight the ray-shooting time |
| 14:04.43 | brlcad | if you just invoke nirt once and keep streaming it commands, it'll be negligible |
| 14:07.17 | ``Erik | unless the geometry is insane (millions of regions or something) |
| 14:07.56 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) |
| 14:25.12 | brlcad | the more insane the geometry is, the even less of a problem scripting nirt/mged will be though |
| 14:26.08 | brlcad | ah, you mean a heavy prep .. yes, that's true |
| 14:27.12 | brlcad | prep+shot have to be on par or less than process creation+initialization overhead to start with, at least within order of magnitude I'd say |
| 14:29.51 | ``Erik | the, uh, woogie/skippy geometry I have takes over a minute to prep on my workstation :( parallel prep would be nice |
| 14:34.40 | ``Erik | http://brownsharpie.courtneygibbons.org/?p=21 |
| 14:34.42 | ``Erik | heh |
| 14:44.01 | *** join/#brlcad Don_ (n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 14:54.24 | *** join/#brlcad PrezKennedyIII (i=Matthew@whitecalf.net) [NETSPLIT VICTIM] |
| 14:54.24 | *** join/#brlcad cosurgi (n=cosurgi@chello089079134153.chello.pl) [NETSPLIT VICTIM] |
| 14:54.24 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 15:11.11 | CIA-32 | BRL-CAD: 03erikgreenwald * r35077 10/isst/trunk/ (Makefile.am configure.ac src/Makefile.am utils/Makefile.am): cleanup. Remove unused library info. distcheck acid test. |
| 15:25.39 | brlcad | yeah, we do need parallel prep, it's just going to get worse |
| 15:27.04 | brlcad | i think the best approach for that will be to break up prep into its contituent parts (bounding sphere, bounding box, precalcs), and parallelize those |
| 15:27.33 | brlcad | though it probably wouldn't take much book-keeping to also parallelize each primitive's prep independently too |
| 15:29.54 | ``Erik | was thinking a task graph with dependancies to build a queue and a worker set *shrug* |
| 15:35.54 | brlcad | does a doubletake at the new user :) |
| 15:36.04 | brlcad | how'd you capture the data dependencies? |
| 15:36.24 | *** join/#brlcad b0ef (n=b0ef@084202026157.customer.alfanett.no) |
| 15:36.50 | ``Erik | huh? |
| 15:37.02 | ``Erik | if you don't like the new user, migrate to the new machine, damnit |
| 15:37.25 | ``Erik | I'm trying to futz for a semi-safe daily rsync cron :( |
| 15:37.27 | brlcad | no, it's fine, just made me doubletake =() |
| 15:37.46 | brlcad | who? .. someone break in .. oh right, heh |
| 15:44.07 | ``Erik | blehehhhh |
| 15:47.50 | ``Erik | there we go heh |
| 15:49.41 | brlcad | :) |
| 15:50.44 | ``Erik | echo "0 0 * * * root echo 'migrate to the new machine!' | write sean" >> /etc/crontab |
| 15:50.46 | ``Erik | *cough* |
| 16:48.16 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net) |
| 17:15.20 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-7.sbndin.btas.verizon.net) |
| 17:22.09 | brlcad | heh |
| 17:23.17 | brlcad | signs up for google voice, conviently finding a baltimore city prefix with his balanced prime house number |
| 17:40.15 | Axman6 | i'm seriously considering submitting that to bash.org for how geeky it is :) |
| 17:51.14 | ``Erik | don't forget qdb.us if you do that |
| 17:51.42 | ``Erik | is annoyed that both of them have gone to updating so infrequently :( |
| 17:57.21 | Axman6 | :( |
| 18:32.00 | *** join/#brlcad roberthl (n=robert@rhl.me.uk) |
| 18:32.51 | *** part/#brlcad roberthl (n=robert@silentflame/member/roberthl) |
| 18:32.59 | *** join/#brlcad roberthl (n=robert@silentflame/member/roberthl) |
| 18:59.28 | CIA-32 | BRL-CAD: 03starseeker * r35078 10/brlcad/trunk/ (include/opennurbs_cleanup.h src/librt/opennurbs_cleanup.cpp): More tweaking openNURBS cleanup |
| 19:34.36 | CIA-32 | BRL-CAD: 03starseeker * r35079 10/brlcad/trunk/ (include/opennurbs_cleanup.h src/librt/opennurbs_cleanup.cpp): |
| 19:34.39 | CIA-32 | BRL-CAD: Hmm. There is some flaw in the way the surface tree is being built (the leaves |
| 19:34.43 | CIA-32 | BRL-CAD: are coming out different, and the intersects hierarchy test is reporting misses |
| 19:34.45 | CIA-32 | BRL-CAD: where geometrically there shouldn't be misses.) Will have to more carefully |
| 19:34.47 | CIA-32 | BRL-CAD: compare how the trees are being built between old and new methods. |
| 20:10.39 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:46.16 | *** join/#brlcad _sushi_ (n=_sushi_@84-73-206-146.dclient.hispeed.ch) |
| 20:47.51 | *** join/#brlcad Patmcc19 (n=chatzill@71-223-27-160.phnx.qwest.net) |
| 23:06.12 | Ralith | brlcad: there you are! |
| 23:06.15 | Ralith | how're my commits? |
| 23:19.09 | brlcad | Ralith: they are great, keep it up :) |
| 23:19.27 | brlcad | that's exactly what should be sustained from everyone .. :) |
| 23:19.39 | Ralith | ^^ |
| 23:19.56 | Ralith | current approach is promisingish |
| 23:20.31 | Ralith | I'm sort of abusing Qt but it may get/have gotten us at least partway there.. |
| 23:21.37 | Ralith | s/.././ |
| 23:22.04 | Ralith | I managed to make it ogre-driven while still having Qt manage the OS window |
| 23:22.27 | Ralith | I have to say, I'm appreciating how flexible that toolkit is already. |
| 23:32.49 | brlcad | aaah, the reminders get sent today, hm |
| 23:33.22 | brlcad | yeah, I saw the looping updates -- not sure I'd call it abuse :) |
| 23:33.32 | brlcad | they make it flexible for this exact sort of purpose |
| 23:33.54 | brlcad | another option is/was to inherit off of one of the base classes and override behavior |
| 23:41.45 | Ralith | I'm not sure how I'd do that and to achieve the goal of getting Qt to render when Ogre wants it to |
| 23:42.09 | Ralith | short of somehow deferring all opengl calls |
| 23:45.20 | Ralith | the original approach with OgreScene overriding QGraphicsScene's drawBackground amounted to rendering Ogre when Qt wanted it to, and didn't really work at all. |
| 23:46.12 | Ralith | though if this doesn't work out, I think I'll try using Assaf's state-reset techniques within the QGraphicsScene drawBackground; they're rather more elaborate than what I had attempted. |