Editing User:Ralith

From BRL-CAD

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 50: Line 50:
 
=====2009-07-10=====
 
=====2009-07-10=====
 
* Completed and began debugging test code for operating Qt on Ogre's terms.  Widgets are not yet rendered correctly, but there is some evidence that adjustments to this approach, perhaps in the details of resetting OpenGL state in QtRenderListener::renderQueueEnded, still have potential.  Initial attempts resulted in a black window with the dark grey of the configured Ogre background color present in a rectangle in the lower left corner.  Disabling Ogre buffer swap (as Qt almost certainly performs its own bufferswap when stepped, although I'm not at all certain swapping buffers at the point at which Qt is stepped (which is much earlier than when Ogre normally swaps buffers, although it ostensibly occurs at the end of the render queue, of whose significance I am uncertain) is safe in Ogre, particularly considering that OpenGL state is saved/restored/otherwise twiddled across the swap) replaced this rectangle with one of white, the color which Qt draws as a background to its widgets by default.  If this is in fact the source of the white, then it may be that getting that rectangle realigned with (i.e. filling) the context will result in visible widgets—although then the opaque white background will need to be removed.
 
* Completed and began debugging test code for operating Qt on Ogre's terms.  Widgets are not yet rendered correctly, but there is some evidence that adjustments to this approach, perhaps in the details of resetting OpenGL state in QtRenderListener::renderQueueEnded, still have potential.  Initial attempts resulted in a black window with the dark grey of the configured Ogre background color present in a rectangle in the lower left corner.  Disabling Ogre buffer swap (as Qt almost certainly performs its own bufferswap when stepped, although I'm not at all certain swapping buffers at the point at which Qt is stepped (which is much earlier than when Ogre normally swaps buffers, although it ostensibly occurs at the end of the render queue, of whose significance I am uncertain) is safe in Ogre, particularly considering that OpenGL state is saved/restored/otherwise twiddled across the swap) replaced this rectangle with one of white, the color which Qt draws as a background to its widgets by default.  If this is in fact the source of the white, then it may be that getting that rectangle realigned with (i.e. filling) the context will result in visible widgets—although then the opaque white background will need to be removed.
=====2009-07-11=====
 
* Experimented with disabling portions of the OpenGL state reset in QtRenderListener to solve presumed alignment issues, identifying interesting effects observed yesterday as unrelated to Qt.
 
* Observed the alignment issue dissapear and reappear across multiple runs of an unmodified test binary.  Perhaps this is some side effect of an absence of special handling for the resizes enforced by my (tiling) window manager?
 
* Attempted to contact the author of the Ogre native render system code on which the current effort is founded for advice and further information.
 
=====2008-07-12=====
 
* Original native render system author had nothing to offer.  Started [http://www.ogre3d.org/forums/viewtopic.php?f=2&t=51199 a new thread] on the Ogre forums with more detailed information in the hopes of hooking in someone more knowledgable.
 
=====2008-07-14=====
 
* In light of the incredible resistance of the Ogre/Qt conflict to solution, I discussed alternatives with mentors and decided to attempt rendering Qt atop, rather than into, Ogre's heavily defended context.
 
** First attempt used a QDialog for testing.  No luck until a call to QDialog::show() is applied to the QDialog, which leads to apparent initial success tempered by the realization that the QDialog is being rendered as, surprisingly, a popup dialog—that is, a separate top-level window.  It turns out this is documented behavior; I must assume that its use in the model renderer example from the Qt blog using the GraphicsView system is an exception to this rule.  Thus, previous experiments' use of it was likely not invalid.
 
** Second attempt used a simpler widget, the QPushButton.  Again no initial results, but the removal of code giving the OgreGLWidget an initial size of 1024x768 on a hunch that it was leading to some form of subtle conflict with my window manager lead to the widget becoming visible within the OgreGLContext as desired.  Thus, this attempt was a success.
 
*** Further experimentation showed that a call to QPushButton::show(), in this case left over from the symbol's original role as a QDialog, was necessary for it to appear, although I don't recall seeing such calls in the original model renderer (quite possibly they were hidden elsewhere; it had quite a bit of widget initialization code).  Earlier failed attempts to get Ogre and Qt to cooperate will bear repetition with this call added, as ideal results may still be attainable through its use.
 
=====2008-07-17=====
 
* Verified support for more advanced Qt functionality within OgreGLWidget
 
* Successfully integrated support for Qt Designer's output files into the build system
 
* Using Qt Designer, assembled a simple GUI based on the original G3D GUI as designed by mafm
 
* Wrapped Qt Designer output to allow functionality to be attached to GUI signals
 
* Created a new "Console" widget that includes an auto-hiding output window, and successfully used Qt Designer to place it in the GUI
 
* Added timer code to ensure that the OgreGLWidget is redrawn frequently
 
* Encountered a heisenbug in which garbage is scribbled all over areas of the GUI intended to be transparent; I conjecture that this relates to the drawing of Qt widgets on top of, rather than into, the OpenGL context, and that drawing Qt directly into the OgreGLWidget would resolve the issue.
 
* Tweaked the GUI layout to make aforementioned bug unobtrusive when it manifests to allow an attractive and usable GUI to be implemented without relying upon a fix for the bug manifesting in short order.
 
=====2009-08-03=====
 
Much has happened since last log.  In summary, OpenGL embedding is now functional, and after some work the GUI has been restored to original G3D functionality and can be seen following.
 
[[Image:G3d-2009-08-03.png]]
 
  
 
====Abstract====
 
====Abstract====

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)