Harmanpreet,
Thanks for the detailed posting, but note that shorter messages are easier to respond to, especially when you're going to post so much information that begs for a response, comment, or correction. There are way too many broad generalizations without anything specific mentioned.
Let me say beforehand that while I can be critical, I DO APPRECIATE the commentary and this is a worthwhile discussion. Thank you for posting it. That said, there are MANY issues and you wrote a lot .. so on to my feedback:
We all admit that BRL-CAD is wonderful software, but still new users
faces a lot of problem due to its GUI (mged and Archer). I am trying
remove this issue to make it browser based GUI. That demand for
knowing more about current implementation, options available and what
suits to road-map of BRL-CAD.
There's an argument that having poor usability categorically makes BRL-CAD "not wonderful". I do assert that BRL-CAD is exceptionally capable yet lacking in usability. Flexibility is one of our greatest assets and detriments. Interface is our biggest problem. Addressing our fundamental usability issues are heavily tied to our mathematical geometry representation format and is something we're in the middle of fixing (Wu's GSoC project is actually a critical piece to that puzzle).
I summarized my findings and struggle on my blog. Please take a look:
http://singhharman.wordpress.com/ under topic "'Rise of OpenGL' and
Of immediate concern is that your blog indicates you may be using the wrong version of BRL-CAD. All GSoC students need to be using latest trunk SVN sources. You should also be using Cmake to build, not Autotools.
OpenGL is fully capable of visualizing geometry.
Note that this is only strictly true for certain types of geometry that can be represented in one of the explicit forms that OpenGL supports (points, lines, polygons). OpenGL does not have inherent support for many types of geometry representation formats, particularly any of the implicit forms, volumetric forms, level sets, NURBS boundary representation, and more. There are some conversion libraries that help describe such data in a form that OpenGL can display, but it is not "inherent" capability.
Qt provides support
for integration with OpenGL implementations on all platforms, giving
developers the opportunity to display hardware accelerated 3D graphics
alongside a more conventional user interface. Just imagine, if we
successfully exploit this opportunity of combining both, then we can
take out a new outstanding GUI for BRL-CAD.
This is already planned and in the works.
Qt has been in our development roadmap for many years. I believe we'll probably have initial useful user capability in late 2014. Vlad's GSoC project involves implementing a Qt display manager, which is also a critical piece of that puzzle.
For example, OpenGL can gracefully visualize a sphere. But it may not
be capable to show the cross section. For such cases, we can use
BRL-CAD's existing functions that compute cross-section, and pass
their result to OpenGL functions to render the cross section.
Following are some of the prominent features that this proposed system
is promised to deliver:
If this is for GSoC, then you're going to need to be considerably more specific as all five points are broad generalizations that are lacking background understanding.
If this is project roadmap related, then it would be best to understand what the current roadmap already looks like before making any assumptions about what is or is not already happening.
1. Since we will be using openGL and Qt, both are cross platform
tools, so this will solve the problem of being platform independent.
This will also reduce the maintenance efforts to keep alive BRL-CAD on
different platforms.
This is already planned and in the works.
2. Although I am not sure how much time and effort is required to add
a primitive in BRL-CAD, but I can take an idea from previous and
current GSoC projects whose purpose was to add an entity or primitive,
that this task need significant efforts and time. In the new proposed
GUI it is easy to add primitive atleast upto the visualization aspect.
So, you're not sure how much time or why it takes time, but somehow the proposed GUI will make it all easy. What?? This is incredibly presumptuous, naive, and borderline offensive... I'm sure you did not intend any offense, so please do take effort to understand that you are mixing completely unrelated concepts. The effort involved in adding a new primitive has basically nothing to do with the GUI.
3. Currently we have MGED a GUI of BRL-CAD. But we all know that it
lacks attractiveness and user friendliness that every graphical
software must possess. Also we are now putting our efforts on Archer,
the new GUI of BRL-CAD, but still it lagging far behind from the day
when it will be fully available for production use. Both these GUIs
are Tcl/Tk based. Why not using Qt, a framework to make amazing user
interfaces. Moreover, we can think to acquire already made GUI from
similar software, for example, FreeCAD has its GUI in Qt, and FreeCAD
is itself a 3D modeling software, so we can also work in this
direction in order to reduce our efforts.
This is already planned and in the works.
Archer is a step in a complex refactoring process. It's predominantly a mechanism for abstracting the useful logic from within MGED into reusable library form. Specifically, this gave us the GED library, which is letting us reuse tremendous amounts of useful code that was previously held within MGED. That library supports the development of a new Qt-based interface.
4. Finally we will get rid of wireframes. However, we will be able to
easily enable or disable shaded geometry or vice versa.
5. Code of this system will be object oriented, so we will have
optimized and easy maintainable and future compatible code.
Object oriented does not inherently give you optimized code or easy maintainability. We're already heavily optimized in most of the places where it matters, considerably faster than most commercial engines even.
Improving maintainability is a personal mission I've been putting efforts into for years and is more an issue of modularity and refactoring. We will always be able to improve and we will continue striving to improve.
Besides, using pure OpenGL, there are number of APIs and glue
libraries available for easy and graceful implementation of OpenGL
such as following:
http://en.wikipedia.org/wiki/Coin3D
I wouldn't be opposed to testing use of Coin3D but the plan has been to use OGRE3D for scene graph management. OGRE has a considerably more vibrant user community, very well organized API with emphasis on design, and sufficient features for our needs. Several other options have been looked into in the past including OpenSceneGraph, OpenSG, Irrlicht, Delta3D, Java3D, FreeSG, and few others.
Please guide me, I wish to move in this direction, so that it could be
useful to BRL-CAD users as well to developers.
Please don't misunderstand my above comments as they are undeniably critical. We all are here to help make BRL-CAD better and are all generally interested in seeing the same improvements. How to go about making those improvements is key. Knowing how to do that effectively without completely wasting time and effort is something that requires substantial background understanding.
Presuming this is to change goals for GSoC, what exactly are you suggesting? To not work on a web interface of some sort and instead work on C++ code (of some sort)? It's VERY late to be drastically changing directions like this if that's the case.
Cheers!
Sean
------------------------------------------------------------------------------ This SF.net email is sponsored by Windows:
Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
