Into the Code

Yesterday I finished the “Introduction to MGED” and now I’m looking into its source code.

in qtged branch there is already a display manager made in Qt but like I wrote in my previous post it is not yet embedded in the Tk window.

This Tk window must be replaced by the Qt Window which must require some introductory knowledge on Tk windows are created. So now we are delving into the Tk as well though it’s just for the overview.

We are also studying BRL-CAD source code associated with the same.

 

Modeling in MGED

I am reading upon MGED and how to model inside it with shapes, regions and assemblies.

I found it quite easy once you get the hang of the commands to work in BRL-CAD.

Better familiarity as a user will result in better understanding as a developer. So before diving into the code of MGED I am going through the editor as a user.

Till now I have touched upon basic shapes, regions, assemblies, boolean operations, and raytracing.

BRL-CAD’s Display Manager

There is a Qt Display Manager which will be used in BRL-CAD. But qt framebuffer is currently not embedded inside the window. This is because the window is created using Tk. So the task would be to create a Qt window and then embed the qt framebuffer inside it.

I compiled BRL-CAD’s qtged branch against qt for checking this out instead of the trunk source.

The first step is to get myself familiar with MGED(Multi-Device Geometry Editor) in BRL-CAD.

I am learning to create models inside MGED using commands as well as GUI.

Trek to BRL-CAD

Kamalpreet implemented Point clicks in Ogre Scene but there was an issue of lag in displaying and there is some offset between the click and where the point is drawn. Might be some bounding rectangle kinda issue.

After discussion with our mentor, we are now heading towards the source of BRL-CAD. We are going to work on GUI in qt for BRL-CAD.

Currently BRL-CAD is using tcl/tk for implementing windows. But there has been a lot of chatter of replacing tk with qt. So I talked on irc channel and got to know their expectations as well.

This GUI port would be really beneficial for BRL-CAD as well. There is already some work done on qtged branch and we’ll continue over it. The GUI for eCAD would be reused for this purpose.

 

Controlling the Pace

Now with Ogre/eCAD working correctly on my system it’s time to set the pace for our work.

We have decided that we’d work adjacent to the Ogre tutorials provided officially. This would ensure that we would be working in a correct manner in regards to embedding Ogre in Qt.

Next task is to implement mouse events in the render window. This will enable us to draw entities directly on the screen using mouse as well traverse the scene.

Zoom in and zoom out will be added as well.

Finally fathomed a slight set-back

Fighting a small fight with my system for running Ogre application in Qt made us realize that we should perform each and every step with great care and understanding.

Today we figured out why eCAD was not running on my system. It was due to dual installation of Ogre. The older version (1.7.4) was also installed on my system and this was resulting in “assertion failed errors”.

So I purged this older version of Ogre from my system and then the application ran smoothly. 🙂

Now we are looking into Ogre3D to see whether it supports Solid Modeling. On asking on the irc channel #ogre3d about using Ogre3D to use in a CAD software I got a reply that Ogre would be quite feasible to be used in a CAD type application.

We must look at Ogre as a pure rendering library and if we are planning on generating coordinates ourselves, it does not matter what Ogre does by default. There are ManualObjects that basically could be anything.

Also we need to know about RT^3 to ascertain whether it’d be useful for us or not.

Back to the Grind

After attending VISA interview at the U.S. Embassy, New Delhi I am back to work.

Now it’s time to figure out why eCAD is working properly on everyone’s system but mine. I still didn’t find anything amiss in the code ’cause it is identical to the code of others.

What I have speculated so far is that this problem is occurring because of the old packages(libraries) in Mint 13.

There was also a discussion about using rt^3 library from BRL-CAD. Still we need to discuss this in detail to clear our doubts.

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.