A Salient Triumph

This last week we had daily scuffles with Ogre and Qt. Even though there are some examples available to incorporate them but you can’t really acquire everything at a single place. There are lots of compatibility issues to take note of as well.

We managed to implement the Ogre Render Window inside our MDI area of our eCAD. Also corrected the window size issue in a tabbed widget.

Weird thing is that the same example of QT-OGRE runs absolutely fine on both of our systems. And yet the eCAD version of the example runs only on Kamalpreet’s system and not on mine. Segmentation Fault at its best. Debugging it but no solution so far.

This small victory is a stepping stone towards the 3D version of our software.

Enticing Engine

It is one of my greatest desire to work on a 3D game of my own someday. And now I’m getting an opportunity to play with a 3D Game Engine.

Ogre3d is an open source Game Engine and even though I am not really working on a real game, it still leaves me in a state of bliss.

Right now I am frolicking in this engine, following basic examples to get myself acquainted with it.

It’s mesmerizing to see your code snippet revamp a scene.

The examples are fairly useful in grasping the key concepts of a scene in Ogre3d. The Scene Manager, scene nodes, entities, camera, lights, etc., I am already quite familiar with these concepts. So for me it’s kinda like breezing through them.

But embedding Ogre3d in Qt is an onerous task as the guides available to do such are out-dated and erroneous. Hoping to do this asap.

Got the Direction

Today we gave a presentation on what are our views on GUI of a CAD. In which we explained to follow the approach of User Experience driven softwares.

We believe our software’s GUI must influence our coding rather than our code driving the user experience.

After that we had discussion regarding what should be used and how.

And it was decided that we must base our CAD’s foundation as 3D.

On note of 3D, BRL-CAD will be used for the libraries like libbu(utilities), libbn(maths), librt(ray-tracing and entities), etc. Whereas the 3D primitives will be rendered by Ogre3D as our scene.

Our eCAD’s GUI will be modified accordingly to suit our needs.

I compiled Ogre3D Game Engine today following Kamalpreet’s blog.

Now it’s time to get myself familiar with it.

More Depth

Now as we are working on GUI of the CAD it is equally important to keep track of the backend stuff.

In this case Kernel is that backend where everything is to stored or processed.

We discussed today among our team and with Harmanpreet Singh, that before going further ahead in GUI and start implementing other entities and operations, we should divide our work and get the backend upto date with our GUI.

This will help us in the long run so as not to complicate things.


Today we dived into MDI (Multiple Document Interface) with tabs view for our GUI.

This defines how the interface will look like for our software. The new tabs are created but still need to work on the code to generate new subWindow child for MDI widget with correct graphicsScene associated with it.

Once this is completed we are going to start working on the core of the software, i.e Kernel.

Here everything will be handled, from events to adding or removing entities to performing operations on these entities. Even storage of the entities will be done in this module.

Save ‘n Load it

Now we are on track and going on a steady pace.

Today we implemented the save and load feature in eCAD.

We can save our points in an xml format. And this xml file will have a <point> tag which has x and y as its attributes and will store the point entity’s x coordinate and y coordinate respectively. This information is written with the help of QXmlStreamWriter.

And the same xml file can be opened in eCAD, which is parsed using QXmlStreamReader which then allows us to re-draw the entities.

The CadGraphicsScene class has read and write functions which are responsible for parsing.

Getting Back on Track

Today we finally got an answer to our query on how to work with QGraphicsScene and QGraphicsItems.

We asked around on IRC and ML but didn’t get a reply. So we posted our query along with code of our demo application on Qt’s forum.

And at last somebody replied and pointed our mistake.

We were creating a scene directly in our mainwindow and each entity has its own mouse events associated with it like mousepress, mousemove, etc. and the paint event was also defined here.

But we have to handle events in the scene and not in the item. Only painting is to be done in item class. So now we have separate graphicsscene class which will handle the events.