User:Ralith
SoC
Further OpenGL Geometry Editor GUI development
Log
2009-06-10
- Set up g3d's cmake to pull in Qt4
- Began work on experimental Qt Ogre widget
2009-06-11
- Cleanup
2009-06-17
- Moved RBGui/OIS initialization into OgreGLWidget, where it will remain until they can be completely purged.
- Repaired numerous bugs in said initialization introduced by the unusual initialization times/procedures of the OgreGLWidget.
- Found evidence that a SVN version of Ogre will be necessary for the desired wrapping until their next release is made.
Currently very close to having old g3d running within a logical Qt Application and an actual Qt window.
2009-06-18
- Configured a secondary FreeBSD machine for development
- Improved ability of CMake package-finding scripts to locate libbu and libged when pkg-config is unavailable or providing inaccurate or insufficient information
2009-06-20
- Fixed Ogre bug leading to X error on shutdown
- Began process of purging RBGui, as its Ogre backend appears to be incompatible with the version of Ogre required for embedding in Qt
- Began multipart checkin of Ogre SVN, patched for clean shutdown when embedded in Qt
- Successfully tested complete Qt Ogre widget startup/shutdown
2009-06-21
- Finished the (surprisingly painful) multipart checkin of Ogre SVN.
2009-06-23
- Moved Ogre code from a QGLWidget-derived class to a QGraphicsScene-derived class to allow integration of Qt widgets
- Added experimental resize handling
- Attempted to test Qt widget integration, only to find Ogre's rendering call preventing Qt widgets from being visible. Posted a request for help on the Ogre forums.
- Researched OpenGL state-saving as a possible solution to the Ogre/Qt conflict.
2009-06-24
- Further research into Ogre/Qt conflict:
- Looked into what appears to be the standard way to do raw OpenGL calls in an Ogre context. Not resorting to this yet because it would require interacting with Qt on a significantly lower level than that enabled by the current GraphicsScene approach.
- Obtained an OpenGL call tracer for possible use working out how Qt manages to reset things after a frame.
2009-06-25
- Dug around in the Qt code looking for reset hints. Nothing found that does the job yet.
2009-06-28
- Further Qt digging; identified a possible approach based on modifying Qt (undesirable), and the potential for an Ogre-centric solution, if certain functionality provided by the Qt-centric solution can be replaced.
2009-06-29/30
- Final research and experimentation in the hopes of replicating Qt's reset mechanisms. Found something very promising with QPainter::load and QPainter::save, but unless I am misusing them they proved insufficient to prevent Ogre from hiding Qt. No other content of QGraphics(Scene|View)::render seems to be able to do the trick, unfortunately. Barring unexpected discoveries, further attempts will focus on pure Qt-in-Ogre.
Abstract
I propose to continue the development of the OpenGL Geometry Editor GUI effort began during Summer of Code 2008 through modifying the existing application to take advantage of the Qt application and UI framework and then taking advantage of the wide array of development tools, widgets, and libraries offered by the framework to rapidly flesh out the front end, with the ultimate goal of preparing a powerful and intuitive CSG modeling GUI ready for connection to the geometry service.
Content
BRL-CAD is unparalleled in power and maturity in the small world of open-source CAD, and has a feature-set capable of competing successfully with commercial CAD products. However, the suite has until recently, as an in-house tool, been targeted almost exclusively at small population of trained experts. As such, the current standard modeler, mged, is highly unintuitive, requiring extensive perusal of documentation before even relatively straightforward modeling tasks can be completed reliably. To make BRL-CAD a useful and attractive toolset for a wider audience, it is therefore critical to implement a more intuitive GUI without sacrificing the power offered by mged.
As a well-recognized need, this project was first addressed in a 2008 Summer of Code project which produced the beginnings of a working prototype based upon Ogre and RBGui. While it provides an attractive beginning, it lacks any actual editing interface, and suffers from limited potential for direct growth as a result of the selection of RBGui, which is unmaintained (to the extent that I found it unbuildable on Linux without numerous modifications), has a limited selection of widgets, has no design tools or other development aids, and lacks much of the higher-level functionality that can be found elsewhere. To remedy this, I propose to within the existing codebase swap out RBGui with Qt, an extremely powerful, well-documented, and widely-used application and UI framework, and is well supported on all remotely popular platforms, and popular itself to the extent that up to date binaries for it exist in most package management systems, offsetting the admitted problem presented by the notoriously slow build process of the framework. Additionally, a wide variety of development tools exist, which have the potential to accelerate prototyping immensely compared to the hand-coded measures necessary in the current implementation. Although Qt is traditionally rendered in software, making it seem an odd choice for use within an OpenGL context as RBGui is currently used, Qt recently gained support for this type of use.
Once I have successfully integrated Qt with Ogre and substituted it for all uses of RBGui, I will work to continue the efforts made last year to develop it into a complete geometry editor frontend based upon the Ideal Operating Environment concept around which the work up to this point has been based. In particular, I will work to construct a framework for the rapid prototyping of a highly usable GUI composed of actions accessible through multiple routes, including the command line and multiple GUI methods, and leveraging it to form an interface with functions to perform and display a variety of common basic editing operations. Support for actually performing these operations will be implemented through stubs wrapping libged functionality, to be replaced with use of the geometry service as soon as it is practical. This will allow a degree of actual functionality sufficient to test the GUI design in practice, allowing for meaningful early analysis of the effectiveness of design decisions, which will support the direct evolution of the interface towards the greatest possible usability. Although the scope of functionality to be implemented will be inevitably limited by the time allowed for the Summer of Code, I hope to continue on with this project after the Summer's completion, as I believe strongly in the importance of such an interface to BRL-CAD's success, and the benefits such success has to offer to a diverse audience; as the sole example of high-quality open CAD software, bringing an accessible BRL-CAD into reality would not only benefit current users of such technology, but help make CAD accessible to those unable to afford the expensive licenses typically required for commercial options, potentially opening up a whole new world of open community-oriented design projects, paralleling with real-world products the massive success of open software.
To achieve these goals I will take advantage of my existing familiarity with both the BRL-CAD internals and the modeling interface (and power thereof) offered by mged, as well as experience with the popular Blender modeling and 3D graphics toolkit, the familiarity with C, C++, and many similar languages I've developed through years of self-motivated programming, and the familiarity with build systems, command line interaction paradigms, and diverse user interface designs conferred by regular use of Unix-based systems for both software development and everday tasks. Additionally, I will take advantage of my familiarity with the community, a result of my presence on IRC for most of the past year under the nick "Ralith," to engage with the current primary users of BRL-CAD for immediate feedback on my prototypes, in the interest of creating a tool that is not only attractive to new users, but powerful and intuitive to long-time users of the system as well.
Milestones
- Integrate existing work with a Qt OpenGL context
- Replace all use of RBGUI with Qt. RBGUI and Mocha removed as dependencies.
- Present a clean, consistent, and appealing look in all GUI states
- Design and implement system for handling popup command line instructions
- Parallel all relevant current GUI features in the popup command line
- Implement mged-style wireframe rendering of a limited subset of primitives
Timeline
- April 20 through May 22
- Determine best approach for Qt/Ogre integration
- Become familiar with Qt development tools and techniques
- Become familiar with the relevant libged/geometry service API
- Discuss design issues with mentor
- May 23 through May 30
- Modify g3d to render to a Qt OpenGL context
- Render Qt widgets into the context
- May 31 through June 20
- Replace existing GUI elements with Qt widgets
- Adapt Qt widget appearance/functionality to g3d's needs
- June 21 through July 11
- Generalize actions such that both the command line and multiple GUI widgets can trigger a single implementation
- Implement easily extensible noun/verb based popup command line system
- Implement command line control over existing functionality
- July 11 through July 25
- Implement editing framework (loading of geometry, 3D cursor, connection to libged or geometry service
- July 26 through August 2
- Implement mged-style rendering of a limited subset of primitives
- August 2 through August 10
- Review usability and intuitiveness of interface, taking comments from community and making optimizations
- August 11 through August 17
- Clean up/document existing code and fix bugs. Implement no new functionality.
