| 00:05.25 | starseeker | wow... it looks like they're trying to lay the ground work for modernizing how Xorg and hardware autodetection (hal) work together |
| 00:06.56 | starseeker | figures... I upgrade, get power failure, reboot with bad config setup... |
| 00:07.03 | starseeker | yeesh, one of those weeks |
| 00:07.31 | starseeker | oh, well - I guess on the bright side I didn't get killed by a tornado, so it's all good... |
| 00:20.07 | starseeker | there we go - ah, X feels good |
| 01:28.48 | Ralith | hm. |
| 01:29.01 | Ralith | I can't seem to get a test mesh visible in Ogre-in-Qt :/ |
| 01:29.31 | Ralith | Ogre seems to be working, though; at least, its background color is showing up fine. |
| 01:30.56 | Ralith | mafm: you around? |
| 01:44.00 | mafm | Ralith: briefly, almost 4am here and I want to go to bed :) |
| 01:51.39 | Ralith | mafm: ah. How'd you get that shape thingy to render in ogre? |
| 01:52.03 | Ralith | I've got ogre at least apparently rendering, but nothing seems to be visible |
| 01:52.36 | mafm | I had a shape floating around, for testing purposes |
| 01:52.42 | mafm | aren't you using it? |
| 01:52.55 | Ralith | no, I mean how did you get it to actually RENDER? |
| 01:52.58 | Ralith | I'm loading a mesh fine. |
| 01:53.22 | mafm | well, it's been almost a year ago since I did that, I can't remember |
| 01:53.29 | Ralith | 'kay |
| 01:53.35 | mafm | probably you have to put it in a point where you can see it |
| 01:53.51 | Ralith | I'm using: |
| 01:53.52 | Ralith | _camera->lookAt(sphereNode->getPosition()); |
| 01:53.52 | mafm | I don't think that you need anything special |
| 01:54.00 | Ralith | so I'm pretty sure it's visible |
| 01:54.07 | indianlarry | starseeker: back up and runnin I see |
| 01:54.08 | mafm | is the camera far away? |
| 01:54.15 | Ralith | shouldn't be |
| 01:54.20 | Ralith | camera's at 0,0,0 and the sphere's at 10,0,0 |
| 01:55.18 | mafm | I meant that if it's inside the sphere (because the sphere has a large radius) probably it's not painting the inside, so you can't see it |
| 01:55.29 | Ralith | could be |
| 01:55.30 | mafm | try to get controls working, too |
| 01:55.32 | Ralith | s/10/50/ |
| 01:55.47 | mafm | I remember to have problems with culling |
| 01:55.50 | Ralith | I'm hesitant to do that until I have something to look at, cuz there'd be no way to test |
| 01:56.03 | Ralith | I pretty much copypasted the scene setup code from Application.cxx |
| 01:56.14 | Ralith | so any solution you applied should be working here, too. |
| 01:56.30 | mafm | so in some distances, for no obvious reasons, I couldn't see my tetrahedron in action |
| 01:56.49 | Ralith | yeah, nothing visible at 50,0,0 either |
| 01:56.50 | mafm | so I had sometimes to zoom in or out, etc |
| 01:57.27 | mafm | mmm, check if the node is visible, it should have a getter method for that |
| 01:57.45 | Ralith | I already force it to visibility |
| 01:58.47 | Ralith | I think maybe I'll add the Qt overlay, get a widget up for displaying current camera position/orientation, and then see about enabling controls. |
| 02:03.24 | mafm | yep |
| 02:03.35 | mafm | aren't you using my camera controls? |
| 02:03.51 | mafm | you can hook it to Qt right away, I think |
| 02:04.00 | mafm | blender mode, mged mode, etc |
| 02:04.21 | Ralith | since I had to drop RBGui, right now I'm working with a very minimal setup that just tests the Ogre/Qtness. |
| 02:04.30 | mafm | so you would readily have zooming, rotating around the object and so on |
| 02:04.54 | Ralith | I'll be bringing your code back in once I get this working and can begin to swap in Qt for the existing stuff. |
| 02:04.57 | mafm | well, I think that you can use it even without Qt |
| 02:05.08 | mafm | probably the input is still working |
| 02:05.21 | mafm | it only requires OGRE and OIS, IIRC |
| 02:05.44 | mafm | so you don't really need anything related with GUI to control the camera |
| 02:05.54 | Ralith | I'm not init'ing OIS currently, partly due to some weird singleton errors it was causing |
| 02:06.03 | mafm | ops :S |
| 02:06.13 | Ralith | and I think Qt provides input, too, so it shouldn't be necessary long-term |
| 02:06.29 | Ralith | I'll see if I can wire up Qt's input to your existing camera control stuff, though; good idea thre. |
| 02:06.40 | Ralith | after I get Qt widgets rendering. |
| 02:12.18 | mafm | I think that my input works directly with OIS, so it would be easier if you get it working |
| 02:12.54 | mafm | also, I don't know if you can pass the input Qt->OGRE, or you have to get the input in Ogre and pass it over to Qt |
| 02:13.13 | mafm | since Qt works with OpenGL probably you can |
| 02:17.07 | Ralith | ah, crap, looks like I dropped the Ogre stuff in the wrong place |
| 02:19.02 | Ralith | well, thanks for the input |
| 02:21.59 | mafm | ok |
| 02:22.02 | mafm | good night! |
| 02:22.06 | Ralith | nite! |
| 02:39.12 | starseeker | indianlarry: heh, yep |
| 02:58.36 | CIA-32 | BRL-CAD: 03ralith * r34866 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx OgreGLWidget.h OgreScene.cxx OgreScene.h): Moved code Ogre to a subclass of QGraphicsScene, OgreScene, instead of a subclass of QGLWidget, in preparation for drawing Qt GUI elements on top. |
| 03:13.59 | CIA-32 | BRL-CAD: 03ralith * r34867 10/rt^3/trunk/src/g3d/ (OgreScene.cxx OgreScene.h): Removed an unnecessary state-tracking bool and added experimental resize handling. |
| 03:26.06 | Ralith | damn, Qt stuff isn't working first try :/ |
| 03:27.17 | louipc | not too bad. my shell script doesn't even work first try heheheh |
| 03:28.37 | Ralith | hm |
| 03:28.53 | CIA-32 | BRL-CAD: 03ralith * r34868 10/rt^3/trunk/src/g3d/OgreScene.cxx: Qt test widgets (not yet working) |
| 03:28.56 | Ralith | maybe my tiling wm is to blame. |
| 03:29.00 | Ralith | needs to go eat, though |
| 03:35.52 | *** join/#brlcad b0ef (n=b0ef@062016142244.customer.alfanett.no) [NETSPLIT VICTIM] | |
| 03:36.49 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] | |
| 03:52.30 | *** join/#brlcad Ralith_ (n=ralith@216.162.199.202) | |
| 04:06.03 | *** join/#brlcad stevegt_1 (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) | |
| 04:12.21 | Ralith | okay, the widget shows up when Ogre doesn't render anything. |
| 04:24.00 | Ralith | it looks like, somehow, Ogre is rendering on top of the Qt stuff. |
| 04:24.05 | Ralith | anyone here familiar with OpenGL? |
| 04:33.46 | Ralith | I need to work out how to force Ogre's rendering to happen *underneath* Qt's. |
| 04:44.27 | starseeker | is this something Qt would need to manage? |
| 04:44.48 | starseeker | I would suggest checking how Qt manages overlapping windows in OpenGL without Ogre being involved |
| 04:48.23 | Ralith | starseeker: I'm not sure I see what overlapping windows has to do with it. |
| 04:48.36 | Ralith | Ogre's being drawn in the 'background' of a GraphicsScene |
| 04:48.48 | Ralith | but somehow it's also ending up on top of the widgets. |
| 04:48.49 | starseeker | hmm |
| 04:49.06 | Ralith | I thought generally things drawn first ended up underneath things drawn later? |
| 04:49.14 | starseeker | not sure |
| 04:49.19 | Ralith | maybe I should clear the depth buffer after drawing Ogre? |
| 04:49.54 | starseeker | what happens with a "normal" background in Qt + opengl? |
| 04:50.04 | starseeker | if you change the background I mean |
| 04:50.11 | Ralith | change? |
| 04:50.27 | starseeker | that's essentially what Ogre is doing - continually updating the background |
| 04:50.56 | starseeker | if you painted a different color (or something) in the background of a GraphicsScene, does something similar happen? |
| 04:51.06 | starseeker | doesn't know, just throwing out questions |
| 04:51.31 | Ralith | Ogre isn't exactly doing anything continuously; it's doing it whenever Qt asks it to draw. |
| 04:51.55 | Ralith | it's Qt-in-Ogre-in-Qt, and the two Qts are actually one Qt, so in theory it should know what's up. |
| 04:52.27 | Ralith | I'm doing things very similar to the way they're done in a known-working Qt-in-OpenGL-in-Qt example I have |
| 04:53.02 | starseeker | hmm. |
| 04:54.08 | Ralith | just instead of calling OpenGL stuff directly in drawBackground, I call ogreRoot->renderOneFrame(); |
| 04:54.57 | starseeker | and the render is painting the OpenGL context and overwriting the dialog views? |
| 04:55.13 | Ralith | or something that looks that way. |
| 04:55.25 | Ralith | okay, clearing depth buffer did no good |
| 04:56.07 | starseeker | what about calling an explicit repaint (or something like that) for the dialog widgets after the renderOneFrame? |
| 04:57.12 | Ralith | I'm pretty sure that already happens. |
| 04:57.17 | starseeker | hmm |
| 04:57.24 | stevegt_1 | okay, for the record, lurkers, and irc logs (after struggling with it and digging through the code off and on all afternoon trying to figure out what some of the parms mean), the 'in ... extrude' command to generate extrude primitives can be used like this: |
| 04:57.24 | Ralith | okay, it's def. something that Ogre does |
| 04:57.27 | stevegt_1 | in foo.e extrude 0 0 0 0 0 5 1 0 0 0 1 0 sketch.1 |
| 04:58.12 | Ralith | starseeker: if I comment out the Ogre render call and just do glClearColor(...) and glClear(colorbuffer | depthbuffer) I get a white background with my widget on top of it. |
| 04:58.26 | stevegt_1 | that's assuming that you want a 5 mm thick extruded sheet in the shape of sketch.1, which in my case was imported from qcad using dxf-g |
| 05:00.07 | Ralith | (when white is my clear color, that is |
| 05:00.33 | starseeker | Ralith: probably means renderOneFrame is making some assumption it shouldn't |
| 05:00.41 | Ralith | yeah |
| 05:00.43 | Ralith | but what :/ |
| 05:00.44 | stevegt_1 | the '1 0 0 0 1 0' vectors (A and B in the mged prompts, uvec and vvec in the code) are the part of that i haven't yet completely understood -- they control stretching and rotation, but i haven't figured out exactly how yet, so i just used the vectors brlcad mentioned earlier today |
| 05:01.09 | stevegt_1 | (we now return you to our regular programming...) |
| 05:01.13 | Ralith | stevegt_1: if you leave the params out it will prompt informatively for them. |
| 05:01.37 | stevegt_1 | informatively?!? it wants "A" and "B"... |
| 05:01.47 | Ralith | hm, maybe not. |
| 05:01.50 | stevegt_1 | hee |
| 05:04.02 | stevegt_1 | the closest i came to any enlightenment was in Unigraphics/ug-g.c, which makes me think that looking at some Unigraphics docs might explain the history of those two vectors |
| 05:04.54 | Ralith | or just fiddle them and ratyrace and see what it looks like :P |
| 05:05.54 | starseeker | Ralith: you probably don't want to hear this, but I would suggest looking at the source of the glClear stuff and renderOneFrame to see what the differences are in how they address the ogl window |
| 05:06.00 | Ralith | starseeker: here's something interesting; if I render the Ogre stuff then glClear everything, the widgets are *still* not rendered. |
| 05:06.13 | stevegt_1 | did that, didn't get a feel for what I was doing |
| 05:06.15 | Ralith | ...the source of glClear? I'm pretty sure that's in the drivers >_> |
| 05:06.32 | starseeker | it's not a Qt function? |
| 05:06.39 | Ralith | no, it's an OpenGL function. |
| 05:06.42 | starseeker | ah |
| 05:06.55 | Ralith | that's why its results as mentioned above are interesting |
| 05:07.16 | starseeker | if you render Ogre, do a glClear, and then call some sort of Qt redraw event does that restore the widgets? |
| 05:07.22 | Ralith | Ogre's renderOneFrame does something that makes *all* GL stuff go on top, at least until Qt resets it (it doesn't happen if I only call renderOneFrame once) |
| 05:07.33 | stevegt_1 | would have to play with it a while longer, probably while looking at the code |
| 05:07.55 | Ralith | starseeker: because glClear alone results in the widgets displaying, and based on the aforementioned working example, I think a widget redraw happens automatically. |
| 05:08.14 | Ralith | as I mentioned above, if I render Ogre and then do a glClear, the widgets do NOT display. |
| 05:08.20 | Ralith | so Ogre's setting some OpenGL flag or something. |
| 05:08.53 | Ralith | wonders if there's some way to catch all OpenGL calls ogre makes |
| 05:09.34 | stevegt_1 | hint to future self: play with those 'in ... extrude' vectors in mged while looking at src/librt/primitives/extrude/extrude.c; also see how extrusions are handled in src/conv/* |
| 05:11.15 | starseeker | Ralith: is this related? http://www.ogre3d.org/forums/viewtopic.php?p=296902&highlight=&sid=ce193664e1d3d7c4af509e6f4e2718c6 |
| 05:13.38 | Ralith | starseeker: hmm, looks like it might be; I don't know how Qt does its OpenGL, but it could well be immediate mode. |
| 05:17.18 | starseeker | I'm wondering about the last post here, if it's still true in Qt: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=33065 |
| 05:17.33 | Ralith | seems like there must be some way to reenable whatever it is that Ogre disables |
| 05:17.41 | Ralith | I mean, if I render a single Ogre frame, Qt manages to recover. |
| 05:17.47 | Ralith | so obviously it's reset somehow. |
| 05:20.19 | starseeker | are the Qt widgets creating their own GL contexts? I thought it was one shared context, but maybe I'm wrong... |
| 05:20.27 | Ralith | it is one shared context. |
| 05:20.45 | Ralith | this thread is from before Ogre supportes context sharing. |
| 05:23.13 | Ralith | it looks like renderOneFrame is doing extra stuff, though; I'll try finding this RenderTarget;:update thing and using that |
| 05:31.12 | Ralith | :/ |
| 05:32.04 | starseeker | no dice? |
| 05:32.28 | starseeker | is wondering about the swapBuffers parameter on RenderTarget::update... |
| 05:32.31 | Ralith | wait... |
| 05:32.33 | Ralith | yeah I'm trying that |
| 05:33.35 | Ralith | yeah, doesn't work |
| 05:33.50 | Ralith | that is, it has the same results as renderOneFrame |
| 05:34.18 | starseeker | hmm. any chance of asking the ogre forums what's going on? |
| 05:34.34 | Ralith | could give that a try |
| 05:34.55 | Ralith | I think I'll try the approach in that first thread you posted, if I can find some way to manually call the widget update |
| 05:40.19 | starseeker | Ralith: is QGLWidget::isSharing important? |
| 05:40.45 | Ralith | don't think so |
| 05:41.01 | Ralith | that's to do with display lists |
| 05:41.02 | starseeker | there's also QGLWidget::paintGL and QGLWidget::paintOverlayGL... |
| 05:41.05 | Ralith | good go dthis example code sucks. |
| 05:41.36 | Ralith | I'm not actually touching QGLWidget here; the Ogre stuff is going on in GraphicsScene::drawBackground |
| 05:41.44 | Ralith | well, a class derived from GraphicsScene |
| 05:41.47 | starseeker | erm |
| 05:42.25 | starseeker | oh, right |
| 05:43.10 | Ralith | this guy uses variable and class names that take up almost the entire width of my editor singlehandedly ;_; |
| 05:43.20 | starseeker | you're doing what this is doing? http://doc.trolltech.com/qq/qq26-openglcanvas.html ? |
| 05:43.35 | Ralith | yup |
| 05:45.13 | starseeker | so the widgets are QGraphicsItem objects? |
| 05:45.28 | Ralith | they get wrapped in those at some point, I imagine |
| 05:45.39 | Ralith | the whole point is that they can be any QWidget though. |
| 05:47.16 | starseeker | yeah, I'd contact Samuel Rodal and/or ask in the ogre forums |
| 05:48.05 | starseeker | be right back, must reboot |
| 06:03.01 | starseeker | phew - it worked |
| 06:03.20 | starseeker | sets up large packages for overnight rebuild and turns off brain... |
| 06:05.55 | Ralith | heh |
| 06:05.55 | Ralith | nite |
| 06:05.59 | Ralith | Ogre forum post made. |
| 06:10.12 | CIA-32 | BRL-CAD: 03Ralith 07http://brlcad.org * r1505 10/wiki/User:Ralith: Log for 2009-06-23 |
| 06:52.48 | CIA-32 | BRL-CAD: 03Ralith 07http://brlcad.org * r1506 10/wiki/User:Ralith: Addendum to log for 2009-06-23 |
| 07:40.01 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 10:11.40 | *** join/#brlcad mafm (n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 10:45.46 | *** join/#brlcad Elrohir (n=kvirc@p5B14DAA2.dip.t-dialin.net) | |
| 12:01.01 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] | |
| 12:14.10 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] | |
| 12:17.08 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 14:48.53 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) | |
| 15:14.42 | CIA-32 | BRL-CAD: 03irpguardian * r34869 10/brlcad/trunk/src/proc-db/human.c: Fixed some formatting, and added a hollow bounding box representation |
| 16:28.14 | CIA-32 | BRL-CAD: 03irpguardian * r34870 10/brlcad/trunk/BUGS: Added bug in regards to rtedge and perspective viewing |
| 16:34.41 | CIA-32 | BRL-CAD: 03bob1961 * r34871 10/brlcad/trunk/src/libged/typein.c: Fixed a few cases where the return value should be GED_MORE instead of GED_ERROR. |
| 16:39.20 | CIA-32 | BRL-CAD: 03erikgreenwald * r34872 10/brlcad/trunk/misc/Makefile.am: msvc9 went byebye |
| 16:42.27 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 17:03.09 | CIA-32 | BRL-CAD: 03indianlarry * r34873 10/brlcad/trunk/configure.ac: more msvc9 removal |
| 17:08.04 | brlcad | oops |
| 17:19.11 | CIA-32 | BRL-CAD: 03irpguardian * r34874 10/brlcad/trunk/BUGS: |
| 17:19.11 | CIA-32 | BRL-CAD: Added that rtedge works correctly in non-perspective mode, but still incorrect in |
| 17:19.12 | CIA-32 | BRL-CAD: low-res perspective modes |
| 17:31.06 | *** join/#brlcad samrose (n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) | |
| 17:39.50 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 17:55.50 | jdoliner | does anyone know why this is segfaulting?: |
| 17:56.04 | jdoliner | ON_SimpleArray<ON_Polyline> answer; |
| 17:56.27 | jdoliner | ON_Polyline initial_segment = ON_Polyline(); |
| 17:56.27 | jdoliner | initial_segment.Append(segments.First()->from); |
| 17:56.27 | jdoliner | initial_segment.Append(segments.First()->to); |
| 17:56.27 | jdoliner | answer.Append(initial_segment); |
| 18:17.48 | *** join/#brlcad stevegt_ (n=stevegt@cislunar.TerraLuna.Org) | |
| 18:50.22 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) | |
| 18:54.21 | brlcad | jdoliner: not without a debugger |
| 18:54.51 | jdoliner | yeah I figured it out |
| 18:57.00 | jdoliner | weird thing during the initialization that was causing it to try to extend the array |
| 20:09.25 | CIA-32 | BRL-CAD: 03indianlarry * r34875 10/brlcad/trunk/ (include/opennurbs_ext.h src/librt/primitives/brep/brep.cpp): |
| 20:09.25 | CIA-32 | BRL-CAD: changed tolerance on vertical trim check; added near hit/miss logic to shotline cleanup |
| 20:09.29 | CIA-32 | BRL-CAD: but still WIP |
| 20:55.30 | *** join/#brlcad stevegt_1 (n=stevegt@cislunar.TerraLuna.Org) | |
| 20:57.42 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 21:27.58 | *** join/#brlcad Elrohir (n=kvirc@p5B14DAA2.dip.t-dialin.net) | |
| 21:35.22 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 21:53.10 | *** join/#brlcad m03sizlak (n=x0100100@pool-98-117-160-192.bflony.fios.verizon.net) | |
| 21:53.43 | m03sizlak | i need a high quality 3d model of manhattan |
| 21:54.59 | Ralith | starseeker: thanks for the participation in the thread |
| 22:39.48 | starseeker | Ralith: well, I don't know if it accomplished anything :-/ |
| 22:40.05 | starseeker | figured if it was active it might attract more attention |
| 22:40.08 | Ralith | starseeker: at the very least, it held the attention of someone knowledgable. |
| 22:40.12 | Ralith | yeah. |
| 22:40.31 | Ralith | and answered an important question |
| 22:42.29 | starseeker | hmm, I can't get the forums to come up - have there been more replies? |
| 22:43.21 | Ralith | nothing of interest, unless you count my own recent post explaining why I'd rather like to make things work within the current setup |
| 22:43.47 | starseeker | ah, there we go. |
| 22:43.48 | Ralith | and simplifying the question down to two simple queries |
| 22:44.32 | Ralith | if only there was some simple way to log all OpenGL calls g3d as a whole makes |
| 22:45.13 | Ralith | that way we could see what Qt does to get the context back to a usable state after an Ogre render call |
| 22:45.24 | Ralith | and isolate Qt's own rendering for test purposes |
| 22:45.40 | starseeker | hmm: http://www.opengl.org/sdk/tools/GLIntercept/ ? |
| 22:46.21 | Ralith | windows only. |
| 22:46.32 | Ralith | I don't have any windows devboxes |
| 22:46.43 | Ralith | perhaps I could get someone to log it for me? |
| 22:47.38 | Ralith | brb |
| 22:47.47 | starseeker | http://www.hawksoft.com/gltrace/ claims to have preliminary Linux support |
| 22:48.21 | Ralith | worth a try |
| 22:48.44 | *** join/#brlcad Elrohir (n=kvirc@p5B14D386.dip.t-dialin.net) | |
| 22:49.04 | starseeker | http://graphics.stanford.edu/courses/cs448a-01-fall/glsim.html |
| 22:50.23 | Ralith | NOTE: trace doesn't seem to work with Linux NVIDIA OpenGL drivers. If you need to make a trace on Linux, use a Linux machine with Mesa drivers. |
| 22:50.26 | Ralith | >:/ |
| 22:50.28 | starseeker | http://www.opengl.org/sdk/tools/BuGLe/ |
| 22:50.46 | Ralith | oh nice |
| 22:51.20 | starseeker | GPL, but usable as a tool I would think (brlcad?) |
| 22:51.26 | Ralith | certainly |
| 22:51.28 | Ralith | gcc is GPL, after all |
| 22:51.46 | starseeker | nods - this is for debugging, not for inclusion anyhow |
| 22:52.01 | Ralith | grabs some lunch |
| 22:54.54 | starseeker | old, but maybe useful? http://spyglass.sourceforge.net/ |
| 22:55.52 | brlcad | m03sizlak: and I need a high quality model of a lightcycle and a replicator ;) |
| 22:56.44 | starseeker | Ralith: yeah, it's looking like most roads lead to BuGLe |
| 22:57.11 | brlcad | okay to use during development, it's not being integrated |
| 22:57.23 | brlcad | there's also a very powerful opengl debugger on the mac |
| 22:57.43 | brlcad | part of the performance tools |
| 22:58.42 | brlcad | still, you should be able to back down to basic qt tests first without having to worry about opengl calls |
| 23:16.51 | Ralith | brlcad: basic qt tests like what? |
| 23:17.10 | Ralith | I've already confirmed that everything works, even rendering OpenGL stuff, when Ogre isn't called. |
| 23:17.27 | Ralith | (including rendering Qt widgets, if that wasn't clear) |
| 23:17.30 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 23:17.52 | starseeker | what about setting up the "bad" condition (Ogre having futzed up the rendering) and walk through the Qt cycle that restores it? |
| 23:18.01 | Ralith | starseeker: that's what I was planning to do. |
| 23:18.05 | starseeker | nods |
| 23:18.14 | Ralith | only, save a lot of time by stripping it down to just the OpenGL calls. |
| 23:18.23 | Ralith | I guess I could grab a source checkout of Qt and do it the other way, though |
| 23:18.34 | Ralith | might lead to a tidier fix. |
| 23:18.41 | starseeker | would recommend that, actually |
| 23:18.54 | starseeker | awareness of Qt source code will probably be a requirement sooner or later... |
| 23:19.16 | starseeker | eyes the Tcl/Tk trees living in src/other |
| 23:20.14 | Ralith | let's not intern Qt |
| 23:20.18 | Ralith | :P |
| 23:20.42 | starseeker | heh :-) |
| 23:20.52 | starseeker | well, the chips will fall where they need to |
| 23:22.40 | Ralith | I'm certainly not checking it in myself after that Ogre mess. |
| 23:22.48 | starseeker | hehe |
| 23:23.14 | starseeker | if it has to be checked in, I'll take a stab at it - only if we need to though |