Compiling OpenSG (with QT4.x)

1. Introduction
   
2. Building on Linux
   
3. Building on MacOS
   
4. Building on Windows
   
5. Compiling OpenSG with QT4 support
   
6. Building a Simple OpenSG based app in QT4.x
   
7. Creating OpenSG widgets in QT4
   
8. Recommendations / Suggestions / Questions

Introduction

This document will serve as a guide to compile OpenSG on different platforms. We have successfully compiled it on Mac, Linux and Windows (Win being the most troublesome).

I am personally working on a Linux (Xubuntu) based machine, but other programmers helping me are working on Windows and Mac. This doc will serve as dump for all the tweaking we had to do with our code to get it working properly on the different platforms we are working on.

 

Google Docs link to this document: http://docs.google.com/View?id=dgz9dtmx_18mrv63dcc

 

Building on Linux

Standard instructions worked for me for normal build with glut.

http://opensg.vrsource.org/trac/wiki/Tutorial/OpenSG1/Introduction

Building on MacOS

Standard instructions worked for me for normal build with glut.

http://opensg.vrsource.org/trac/wiki/Tutorial/OpenSG1/Introduction

Building on Windows with VisualStudio

Follow the guide on http://opensg.vrsource.org/trac/wiki/BuildVS2005Cygwin

We needed to tweak the process a bit to get it working

• Make sure you have tar, unzip in addition to the ones mentioned in the above link.
  
• Use tar cmd on cygwin to unzip the OpenSG source. Using other unzpping softwares will cause windows style newline to be inserted, and also mess around with some folders.

                Cmdline:   tar -zxf <file name>.tar.gz

• Use unzip to extract the support libs outside the opensg source folder.
  
• If you cant make the batchfile for configure, execute each command individually on the cygwin console.
  
• Make sure to add --enable-glut to the configure line (I have intentionally left out jpeg, jasper, tiff etc)

        ./configure --with-compiler=cl.net2005 --prefix=BUILD --enable-win-localstorage --enable-png --with-png=/Project/supportlibs --with-glut=/Project/supportlibs --enable-glut

• On doing a make, you might come across a weird error about std:: not being defined in FlexLexer.h. Open this file, and remove std:: from front of FLEX_STD. Save and compile again.

• For CL.exe, you need to modify the makefile for compiling programs and tutorials
  
  
  
  • add /link to begining of LDFLAGS
    
  • remove -o $@ (something like that... and do not use /out also).
  
  
• Copy all dlls from support lib (that you extracted above) to Windows\system32. Do not overwrite the existing ones.

Compiling OpenSG with QT4 support

I am using a Linux box running XUbuntu, and came across several problems while compiling OpenSG with QT4 support. Here is what I did to get my source compiling. The changes mentioned here are according to the linux and windows config. Also, I have made this document *after* I got my system up and running, hence the line numbers stated here are approximate ones. Please use these steps as a guide, not as a tool to fix your problems blind-folded.

 

Note

    Green - steps required for Windows users only

 

• Install Qt4.x SDK (I used Qt4.5)
  
• Compile Qt




• This is needed for windows as Qt comes with default lib files for g++ (*.a). You cannot link to these files using VS2005.
  
• Open the Visual Studio cmd prompt
  
• Use this cmdline: configure -shared -opensource -release -no-fast -stl -platform win32-msvc2005 -arch windows -no-webkit 


• configure opensg with options for enabling Qt4 (these are in addition to the other options we have already used)
  ./configure --with-compiler=cl.net2005 --prefix=BUILD --enable-win-localstorage --enable-png --with-png=/Project/supportlibs --with-glut=/Project/supportlibs --enable-glut --enable-qt4 --with-qt4includedir=/cygdrive/c/Qt4/qt/include --with-qt4libdir=/cygdrive/c/Qt4/qt/lib --with-qt4bindir=/cygdrive/c/Qt4/qt/bin
  
  Also, do not condence the cmd line to --with-qt4dir="bla bla" as it is unable to pick up libraries for some reason.

 

• QT4.x has several chages to the organization of the include folder; hence we make some changes to accomodate them.

 

 

File = OpenSG/Builds/<arch>/CommonPackages/commonQT4.mk

• 
  
  Add this line after defining INCLUDE_QT4

                    INCLUDE_EXTRA_QT4 := -I$(INCLUDE_QT4)/Qt -I$(INCLUDE_QT4)/QtGui -I$(INCLUDE_QT4)/QtOpenGL -I$(INCLUDE_QT4)/QtCore -I$(INCLUDE_QT4)/Qt3Support -I$(INCLUDE_QT4)/QtDesigner

• 
  
  Add this to the Qt4 libs

                LIB_QT4 := QtCore4.lib QtGui4.lib QtOpenGL4.lib Qt3Support4.lib QtNetwork4.lib

 

File = OpenSG/Common/DefaultRules.mk

• 
  
  line 62 for Windows config - add $(INCLUDE_EXTRA_QT4) to the action line of the rule.


• 
  
  line 75 or 76 for linux config - add $(INCLUDE_EXTRA_QT4) to the action line of the rule.
  
  
  
• 
  
  line ~167 - locate "linux_make_depends" [line 146 for Wndows - win_make_depends] and add the INCLUDE_EXTRA_QT4 to the end of the cmdline.
  
  
  
  
  • 
    
    $(CC) $(DEPEND_OPTION) $< $(CCFLAGS) $(CCLOCALFLAGS) $(INCL)     \
         $(INC_OPTION)$(OBJDIR) $(INC_OPTION) $(INCLUDE_EXTRA_QT4)
  
  
• 
  
  locate CONFIGURED_QT4 (line numbers in approx 395 to 399 / line 383-386 for Windows)




• 
  
  Remove -i option from rule with %_qt.h and %_qt.cpp (not sure if this exists for %_qt.cpp)
  
  
• 
  
  Add the INCLUDE_EXTRA_QT4 macro to moc cmdline for %_qt.cpp rule

                            $(MOC) $< -DOSG_WITH_QT -I$(INCLUDE_QT4)/QtDesigner $(INCLUDE_EXTRA_QT4) -o $@

 

File = common/common.i686-pc-cygwin-cl.net2005.mk (assuming you are using VS2005)

• 
  
  Line 117: CompilerMajorVer = 14 (get rid of the script. It is giving wrong result. 14 comes from the version dumped when you run cl.exe on console.)


• 
  
  Line 131: add -DOSG_COMPILEWINDOWATLIB  /bigobj (-D stuff allows Qt files to be included as __dll_import; second one allows large obj files)


• 
  
  Line 188/189: Path to your platform sdk include and lib. For me it is "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK".


• 
  
  Line 294: INCL_$(OS_BASE) := ...

        Hard code -I"<path to platformsdk>\include"  -LIBPATH:"<path to platformsdk>\lib"   I found no better place to place these two. Do not use the AdditionalInclude and Lib varialbles a

        few lines below;  as they will cause make to start complaining about your makefiles.

• 
  
  Please correct the path to your VS2005 include/lib folders if you are using a 64 bit os... the correct path has "Program Files (x86)".


• 
  
  Compilation should go smoothly after these changes, and you will see another libOSGWindowQT4.so / libOSGWindowQT4.lib  file generated in the lib folder.

• 
  
  do a make install to copy the files to /usr/local/... or whatever folder you specified in the configure options.
  
  
• 
  
  Also make sure that you copy the lib files to /usr/lib or some place which is in the loader serarch path; otherwise your app will fail to load.
  
  
• 
  
  Also make sure that you have copied OpenSG/<arch>/bin/osg-config to your /usr/bin folder.

 

** -i option will ask the meta-object-compiler not to place any additional #includes in the generated _moc.cpp file. If this is allowed, then any Qt specific class usage will trigger an error of non-usage of QOBJECt and other similar namespace related errors. By removing the -i option we allow the moc to place the required #includes that indirectly include the necessary Qt files, solving our problems.

Building a Simple OpenSG based app in QT4.x

• Make a simple Qt app using the tutorial provided at http://www.opensg.org/doc-1.6.0/QT.html
  
• Go the the cmdline and navigate to the folder containing your project code.
  
• Type qmake (troubleshooting - *)
  
• Open the Makefile generated and add the following lines to the start of the file (use --opt instead of --dbg if using release version)
  
  
  
  
  
  
  • OSGCONFIG=osg-config
    OSG_CPPFLAGS=$(shell $(OSGCONFIG) --cflags --dbg Base System QT4)
    OSG_LIBS=$(shell $(OSGCONFIG) --libs --dbg Base System QT4)
  
  
• Add $(OSG_CPPFLAGS) to end of CXXFLAGS
  
• Add $(OSG_LIBS) to end of LIBS
  
• Save and close Makefile
  
• Go to main.cpp and make these changes (otherwise you will get a segmentation fault on Linux)
  
  
  
  
  • #include "OpenSG/OSGQT4WindowBase.h"
    
  •  in main(), add this as the first line: OSG::osgInit(argc, argv); -- missing this line will cause the app to crash in the vicinity of a getAspect() function
    
  
  
• Make the project by typing make
  
• Execute the project file :)
  

Troubleshooting
* If qmake is not found, use the full path to qmake. It is usually in the <QT4.x dir>/qt/bin

** Every time you use qmake, you will loose all changes to the makefile. So make sure that once you made your changes to makefile, avoide using qmake unnecessarily (and/or make a copy of the Makefile for easy cut/paste).
*** osg-config is usually placed in /usr/bin after a make install on OpenSG. If it wasn't copied for some reason, you can find it at OpenSG/Builds/<arch>/bin.

Creating OpenSG widgets in QT4

OpenSG provides a QT4 designer widget that we can use as our starting point. The OpenSG widget details
File = OpenSG/OSGQGLManagedDesignerWidget_qt.h
Class = OSGQGLManagedDesignerWidget

We can start with subclassing this osg widget class; and add the functionality we need. Don't forget the Q_OBJECT macro if this widget need access to the signal-slot mechanism.
Well, that was simple enough, and really not worth mentioning. But the real reason for including this section is when we are using g++ (don't think that this is a problem with other compilers).
Once you have created the new widget class, and placed it in your Qt form/dialog; you will be hit by a compiler error which looks like

    undefined reference to `vtable for <yourWidgetClass>'

I googled for this error, and found that g++ spits it out if you have declared some virtual function in your subclass, but not defined it in your code.
Something like this
    class A : public B
    {
        ...
        public:
            virtual void foo(); // foo() declared
    };
    // foo() not defined

A second look at your code, and you might say that this is not the case with you; that you have don't have any virtual functions or have defined *all* the virtual functions. That may be true :) but the problem lies in the Q_OBJECT macro. It declared/overrides a couple of virtual functions, but doesn't define them. You can see for yourself by including the -E option in g++  [ g++ -E <more usual flags> yourWidget.cpp ].

I don't have an immediate solution to this problem, except that you take out the Q_OBJECT macro; but this will prevent your widget from recieving any signals / slot messages.

Update: I was blocked on this vtable error since yesterday; and did some experiments with test code. I found out that even if the virtual functions are distributed across several files, but are compiled and linked together, we should not get this error. I scanned thru the commandlines being executed, and found that one of my object file was missing. This was somehow being missed out by qmake. Once I added this file to the final object list, everything was fine.

Recommendations / Suggestions / Questions

I am listening at vijay.michaeljoseph@gmail.com :)

Building OpenSG in Linux

I am writing this post from my first laptop which is at the moment running XUbuntu (a light weight version of linux) coz its standards measure to "Under Powered" PCs in todays world. But i still stick to it for all my experimental stuff :)
Anyway, I have been busy with shaders for the past few months. I've stalled the development of Pulse3D coz of lack of maturity of design of the game engine. I've moved my attention to shaders for a change, and have been facinated by the visual shader editing softwares. They are fast, easy to create content, and also come at a cost of low optimization.
Being a low budget freelancer, I've always hunted for opensource tools to help me with my hobby projects. I've tried ShaderFx, MentalMill etc. but all are some or the other way not free in their availability. ShaderFx totally depends on 3DSMax for its operations, hence cannot be used freely after the demo version of 3DSMax has expired.
On the text based creation/editing, I've been using FxComposer; but it too has its limitations on the kind of control I wish to have over the scene created. Since I cannot extend FxComposer, I have decided to create a small tool for loading effects and creating worlds using those effects. I am targetting to make this tool available for Linux, Mac besides windows, so that I can hopefully contribute to the OpenSource community.
I initially thought that NvSG would be a great starting point for the tool, but ran into a road-block even before leaving the runway. Nvidia has not provided any libraries for Mac; and not being open-source, I cannot compile any also. Looking for another solution i hit OpenSG. This SceneGraph is opensource, and i've compiled it on Mac, currently compiling on Linux and hopefully it will compile on Windows also.

Compiling on Linux, and on this ancient system brought up a number of problems. Thought that sharing them here will save some people a little frusturation.

1. If you want to have the libs/include/bin of OpenSG at a customized location, use the --prefix=BUILD at the ./configure cmdline. On executing "make install" the files will be copied to OpenSG/Builds//.

2. If your compilation fails with an error pointing to a file named something like SkelParser.tabs.h make sure that you have "bison" installed on your system. It was missing on my sytem and once I got it, I passed this error as though it were never there.

3. If your build process is terminated with "Killed" message; even though you did not hit Ctrl+C or kill some process... then it means that your build process was taking up too much memory and the kernel decided to snap its neck before it caused any instability problems to the OS operations. Causes include that your swap space is not properly setup, or you need more memory (swap space).
I checked my /etc/fstab file to see for the entry of the swap partition that I had created during installation of Linux. Everything there seemed fine, so I drew a conclusion that the memory + swapspace wasn't enough.
Solution: Since I didn't have a free partition, I create a new swapfile, and offer it to the kernel as added space for the build process.
How: http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/custom-guide/s1-swap-adding.html
For a 300Mb swap file,count=1024*300
dd if=/dev/zero of=/swapfile bs=1024 count=307200

mkswap /swapfile
swapon /swapfile

Making this swapfile load on startup, add this line to /etc/fstab
/swapfile swap swap defaults 0 0

For checking the swap partitions, type
cat /proc/swaps

My experiments with CrystalSpace (continued)

Today I gave another day to Crystal Space, hitting my head hard to try to import models made in 3ds to my cs app.

My first shot was at blender3d exporter, but ran into trouble as soon as i installed the exporter. Some of the leassons i learnt here...

Blender's script directory on a OSX: Blender.app/Contents/MacOS/.blender/...

I managed to place the exporter into the correct folder such that Blender could pick it up, but then it came up with another error whenever I tried to export stuff ... "Script error, Check console".

I hunted a lot for the console in Blender, but finally got my lesson 2.

Console is available in Applications/Utilities/Console. This is somewhat similar to the dmesg cmd on Linux.

Now that I've givenup on the blender stuff, I came across online documentation that CS has inbuilt support  to read 3ds files... :)

With my smile back in place, I'm going to experiment with this new found feature.

My experiments with CrystalSpace

In an attempt to understand a 3d engine's internal layout, I decided to work with some free engine. Professional side is keeping me active on the Unreal3 engine, while I started my own experiments with CrystalSpace.

I downloaded the source code for the engine for mac and built it some weeks ago. I have now come to have read the documentation (partially)... and built the tutorials successfully. I would like to mention the interesting problem that i came across while working with the tutorial.

CrystalSpace is using the Appkit framework (NSApp) for the windowing interface with MacOS. The window comes up all right, and rendering is also proper, but I my app was not receiving the keyboard and mouse events. I found out after some struggling that MacOS treats the CS exec as a background process, hence does not deliver the events other than the rendering ones.

Only Cocoa processes are considered as foreground processes and receive all the events and a place in the dock.

As far as I understand, cocoa applications are simple folders with the name "XXX.app". MacOS shows these folders as single clickable (executable) files. To see the contents of these folders just RClk them and select "Show Package Contents".

As a solution I copied one of the Cocoa wrappers and changed it to include my app. I am now copying the generated executable into the wrapper as from the makefile itself.

I also modified the tutorial to generate a square out of the coordinates I provided... in my future works i will be loading meshes and providing the coordinates myself. I am now looking into the materials and wireframe rendering modes.

Unfortunately, I haven't found a screen capture utility with MacOS, hence cannot post the picture of my first humble experiment.

Pulse3D stalled !!!

A lot of new stuff has been going on lately. This post is basically compressing the last 5 months into a few words. I had to stall pulse3d for an indefinate period owing to the excess work pressure building up at Nvidia. Also during that time, I was contacted by a Singapore based gaming studio, working of a MMOG. I took the opportunity as a break into the gaming industry, and decided to move here.
I'm working on the Unreal 3 engine, and it was now that I realized the large handicapp my design of Pulse3D was suffering with. I decided to get more info on the design of an engine by getting my hands wet using some of them first hand. As for now, I have stalled working on Pulse3D, but hope to come back someday to complete what I have started.
My loyal laptop stopped charging a few months ago, and I had to get a new one with a better graphics card... went in for a macbook. MacOS feels much like my first hands on Linux. Have downloaded and setup CrystalSpace, hoping that it will help me understand a typical 3D engine better.

Pulse3D

Pulse3D started as a result to the addiction to game programming. I got my first real taste of this new flavor of programming when I made a few ridiculously small games for competitions; and then a rather crude one for my college major project.

Pulse3D is supposed to be a game engine (rather rendering engine) that will allow game developers to use OpenGL or DirectX as the underlying rendering subsystem. Being a hardcore fan of Linux; I'm targeting OS independence by isolating the Windowing and event system from the engine.
The project being propelled by a one man army at the moment, I'm not much into documentation; but the design is rather clear in my mind. The features supported at the moment include frustum culling, meshes, lighting, collision detection, camera, memory management and the other basic infrastructure. Currently everything is using OpenGL as the renderer, but the design is flexible and will have DirectX added at a later stage.

After building in basic support for meshes, rendering and lighting, I thought of giving my own code a shot from the developer's side. So I built an app that was using Pulse3D, loaded and rendered a chess piece I found on the net. The screen-shots demonstrate the use of meshes, and lighting.
However, I did find out that my api as yet is not very user friendly; and has some bugs I'll like to get rid of.
The next feature on the list will be Textures; so that Pulse3D will be able to load basic textures, and instruct the underlying rendering subsystem on how to apply them.

The obvious question that comes to mind is that will it revolutionize something in the gaming industry ??? Well just being blunt in my answer, its too big of a dream to think that way. I'm working on this project just as a hobbyist programmer, just for the passion. I learn new stuff this way; going and developing stuff (often from scratch).

Pulse3D is hosted on Sourceforge where you can track its development;. http://sourceforge.net/projects/pulse3d
Although be warned that at times you will not see updates for weeks in a row... just presume that I'm either caught up with office stuff or collecting the ingredients for the next magical spell.