| 00:01.29 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 02:40.20 | *** join/#brlcad stevegt_1 (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) |
| 03:33.16 | Ralith | okay, I've tried saving and restoring as much OpenGL state as I can think of |
| 03:33.25 | Ralith | all three buffers, and all the attribs |
| 03:33.27 | Ralith | er |
| 03:33.30 | Ralith | all three matrixes |
| 03:33.32 | Ralith | er |
| 03:33.33 | Ralith | all four |
| 05:19.24 | CIA-32 | BRL-CAD: 03jdoliner * r34876 10/brlcad/trunk/src/proc-db/brepintersect.cpp: Added integrative test for the entire suite and fixed multiple bugs throughout the entire suite. Still a strange bug with SimpleArrays |
| 10:45.40 | d-lo | Merininin all! |
| 11:06.55 | Ralith | morning |
| 11:07.10 | d-lo | how goes the ogre debacle? |
| 11:07.25 | Ralith | not terriblywell. |
| 11:07.36 | Ralith | digging around for some clue as to how to put things back in order for Qt. |
| 11:07.43 | d-lo | what exactly is the issue with ogre? |
| 11:08.12 | Ralith | it's doing something that interferes with Qt rendering its widgets |
| 11:08.28 | Ralith | every frame that Ogre renders, the widgets don't show up; when Ogre doesn't render a frame, the widgets show up fine. |
| 11:08.41 | d-lo | interesting. |
| 11:09.08 | d-lo | do you know if the version of ogre that *was* in the repo (aka the one that got nuked) was working? |
| 11:09.16 | Ralith | huh? |
| 11:09.33 | Ralith | the ogre that *was* in the repo wouldn't have even rendered to Qt's context. |
| 11:09.54 | Ralith | only the most recent svn versions can do that. |
| 11:10.14 | d-lo | kk. That version of ogre had the 'bug fix' already done. Just checking to see if its the same bug or a different one. |
| 11:10.23 | d-lo | Sounds different. |
| 11:10.52 | Ralith | what bug fix? |
| 11:11.04 | Ralith | this is the first time we've tried to integrate Qt... |
| 11:11.07 | d-lo | dunno. It was before my time. |
| 11:11.26 | d-lo | Not Qt integration. Previous version of ogree |
| 11:11.29 | d-lo | heh, ogre. |
| 11:11.58 | Ralith | the issue only manifests through the issue with Qt integration. |
| 11:12.06 | d-lo | there was *something* wrong with ogre and it needed to have changes done to it. |
| 11:12.09 | Ralith | if I wasn't trying to do that, this version would work fine. |
| 11:12.15 | d-lo | roger that. |
| 11:12.20 | Ralith | yeah, that got fixed in the official version a long time ago |
| 11:12.23 | d-lo | is up to speed now. |
| 11:13.11 | Ralith | I was using stable ogre to run g3d even last summer |
| 11:13.12 | Ralith | kk |
| 11:13.12 | d-lo | any guesses as to the widget 'sync' issue? |
| 11:13.12 | Ralith | got a thread going on the Ogre forums, but all I'm getting is messy workaround suggestions. |
| 11:13.20 | Ralith | I'm not sure I'd call it a sync issue |
| 11:13.40 | Ralith | Ogre's doing *something* that screws with the context state, and Qt is somehow resetting it such that it's capable of rendering correctly once Ogre stops. |
| 11:14.33 | Ralith | whatever it is isn't a trivial OpenGL state thing, because I've tried saving/restoring that and I'm pretty sure I didn't miss anything |
| 11:15.21 | Ralith | so at this point I'm trying to work out how Qt resets things |
| 11:15.30 | Ralith | so I can do that manually right after Ogre renders |
| 11:16.15 | d-lo | sounds like a good approach. |
| 11:17.21 | d-lo | I need to dig into ogre more, but am slightly familiar with qt. Are you thinking of setting up ogre's render completion as a signal? |
| 11:20.44 | Ralith | Ogre does its rendering in the drawBackground function of a class derived grom QGraphicsScene |
| 11:21.10 | Ralith | as Qt already has support for rendering widgets directly into an OpenGL-backed QGraphicsScene, and Qt examples show OpenGL rendering being done in the background like this. |
| 11:21.17 | d-lo | Ralith: Possibly a silly question, but are you 1) integrating Ogre into Qt or 2) Qt into Ogre? I was assuming #1 but realized #2 is completely possible also. |
| 11:21.26 | Ralith | both actually |
| 11:21.32 | Ralith | Qt-in-Ogre-in-Qt |
| 11:21.41 | Ralith | the Qt sort of wraps around |
| 11:22.02 | d-lo | Excellent :) |
| 11:22.03 | Ralith | the important bit is that the GL context is created and managed by Qt, though. |
| 11:22.14 | Ralith | have a look at OgreScene in svn if you like |
| 11:22.37 | Ralith | I haven't checked in the main code yet 'cuz I don't want to break existing g3d until I have something at least approaching functional |
| 11:22.49 | Ralith | the main code as in the main.cxx code; the important code is all in OgreScene |
| 11:22.49 | d-lo | just got back in the office. Took 10 days off and have tons of catchup to do... email, voicemails, etc. But I will look at it at somepoint :) |
| 11:22.55 | Ralith | hehe, 'kay |
| 11:45.34 | Ralith | grabs some much-needed sleep |
| 12:10.05 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 12:16.00 | starseeker | Ralith: do you know anything about the "Render Queue Listener" used in that native code inside Ogre example? http://www.ogre3d.org/forums/viewtopic.php?p=296902 |
| 12:53.36 | *** join/#brlcad mafm (n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 13:01.18 | *** join/#brlcad mafm_ (n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) |
| 13:17.04 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 13:48.53 | *** join/#brlcad Elrohir (n=kvirc@p5B14E2F8.dip.t-dialin.net) |
| 14:15.43 | starseeker | hmm - rt^3 evidently isn't set up for out of dir building |
| 14:16.24 | brlcad | heh |
| 14:28.40 | d-lo | fyi: working on the conversion to cmake in rt^3 |
| 14:31.46 | brlcad | cool |
| 14:32.00 | brlcad | no commits, though? |
| 14:32.12 | d-lo | just started today :) first day back. |
| 14:32.13 | brlcad | that's easily parselable |
| 14:32.28 | brlcad | ah okey, sounded like you were well underway |
| 14:33.00 | brlcad | w/b, cya in a bit -- dog needed some attention this am so i'll be in at/after lunch |
| 14:33.56 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 14:54.55 | brlcad | is going to grab a sushi lunch at japan house around 11:45 if anyone is interested and in the area ;) |
| 15:12.27 | ``Erik | hrmmm |
| 15:27.00 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 15:28.11 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 16:06.31 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 16:09.13 | CIA-32 | BRL-CAD: 03davidloman * r34877 10/rt^3/trunk/src/GS/gsph0.cxx: Simple change to main(). Making it output something instead of being a stub. |
| 16:13.08 | CIA-32 | BRL-CAD: 03davidloman * r34878 10/rt^3/trunk/ (. src/ src/GE/ src/GS/ src/iBME/): Adding CMake stuff to svn:ignore |
| 16:28.13 | *** join/#brlcad samrose (n=samrose@adsl-68-77-162-150.dsl.sfldmi.ameritech.net) |
| 17:32.33 | ``Erik | http://9to5mac.com/macbook-missing-feature |
| 17:38.45 | CIA-32 | BRL-CAD: 03davidloman * r34879 10/rt^3/trunk/ (43 files in 43 dirs): More svn:ingore additions pertaining to CMake generated files. |
| 17:54.52 | CIA-32 | BRL-CAD: 03brlcad * r34880 10/brlcad/trunk/NEWS: keith and cliff have been making extensive progress on brep/nurbs raytracing support |
| 18:26.02 | *** join/#brlcad Don_ (n=Don@c-71-238-51-148.hsd1.mi.comcast.net) |
| 18:30.09 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 19:21.15 | CIA-32 | BRL-CAD: 03jdoliner * r34881 10/brlcad/trunk/src/proc-db/brepintersect.cpp: fixed segfault bug in code, it turns out that ON_SimpleArray<ON_SimpleArray<T> > will segfault on initialization. The workaround is to us ON_ClassArray<ON_SimpleArray<T> > |
| 19:28.20 | *** join/#brlcad madant (i=cb7baf0f@gateway/web/freenode/x-e10aeb456076ae64) |
| 19:29.31 | madant | is going through week-long orientation program at a business school which lets you sleep 4 hours a day |
| 20:02.38 | ``Erik | hahaha, awesome :D |
| 20:02.47 | ``Erik | kline city |
| 21:08.08 | *** join/#brlcad m03sizlak (n=x0100100@pool-98-117-160-192.bflony.fios.verizon.net) |
| 21:12.30 | CIA-32 | BRL-CAD: 03starseeker * r34882 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Clean up 4corner newton solver code - remove logic duplication. |
| 21:49.21 | CIA-32 | BRL-CAD: 03starseeker * r34883 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Doggone it, somehow that broke some of the raytracing. Tweaks to get it closer to original behavior, but still missing something. |
| 22:48.09 | *** join/#brlcad Elrohir (n=kvirc@p5B14E91A.dip.t-dialin.net) |
| 22:49.37 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) |
| 22:51.33 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) |
| 23:07.15 | CIA-32 | BRL-CAD: 03starseeker * r34884 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Oops - don't pass intersect count between multiple solver runs. |
| 23:14.36 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 23:28.21 | CIA-32 | BRL-CAD: 03jdoliner * r34885 10/brlcad/trunk/src/proc-db/brepintersect.cpp: hunted down bugs in MeshMeshIntersection now works a expected |
| 23:34.48 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) |
| 23:34.49 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) |
| 23:35.07 | starseeker | \q |
| 23:35.09 | starseeker | whoops |
| 23:35.35 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) |
| 23:42.18 | CIA-32 | BRL-CAD: 03starseeker * r34886 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: For reasons not immediately clear, still getting more visual artifacts with breakout of solver logic. In the interm, restore previous version - need to figure out what the difference is. |
| 23:42.29 | starseeker | mutter, mutter... |
| 23:45.15 | Ralith | starseeker: no, don't know much about that, but it seems to be one way people have gotten standard opengl calls to work with Ogre and I may play with it if all else fails |
| 23:45.19 | Ralith | however |
| 23:45.29 | Ralith | some opengl calls, at least, seem to work without any special handling |
| 23:45.35 | Ralith | e.g. the aforementioned glclear |
| 23:46.03 | Ralith | possibly the issue discussed on the ogre forums was because they were trying to render opengl inline, rather than calling it after renderOneFrame |
| 23:46.52 | starseeker | Right - what I was wondering about was whether that example is a method for making Ogre more "receptive" to external OpenGL drawing |
| 23:48.42 | starseeker | e.g could Qt do whatever it is that demo external OpenGL input was doing... |
| 23:49.58 | starseeker | we don't care about Direct3D at the moment, so Karan's concerns don't apply... |
| 23:50.50 | Ralith | yeah |
| 23:51.03 | Ralith | the main issue is that the Qt stuff is designed to draw when it wants to, not when you want it to. |
| 23:51.12 | Ralith | so it'd require hacking a good bit deeper. |
| 23:53.03 | Ralith | hm. |
| 23:58.45 | brlcad | ahh, there we go |