game engine gaming delta3d
p-51 open source GNU Lesser General Public License
Fedora Surface Tactics Visualization Plane Guard ChrAVE
Chromakeyed Augmented Virtual Environment CAVE Automatic Virtual Environment National Geospatial-Intelligence Agency Terrian Forward Observer PC Simulator FOPCSIM Shipboard Firefighting Trainer
backed by the U.S. military sourceforge eric johnson I/ITSEC Interservice Industry Training Simulation and Education Conference
Delta3D - Open source gaming & simulation engine
      Welcome to Delta3D | Login 
Friday, September 10 2010 @ 05:41 AM EDT 
MOVES Institute Naval Postgraduate School Naval Education and Training Command
  
IITSEC


AND     OR
 

 
 Home »  Non-technical »  Compiling latest version with gcc 4.4.0
     Prev TopicNext Topic          Printable Version
Compiling latest version with gcc 4.4.0 Views: 585
 Wednesday, February 03 2010 @ 06:16 PM EST

Good afternoon,

So most of the issues I hit yesterday had to do with just getting Delta3D compiled, so I figure the "General Forum" is the right place for them.

I have a handful of issues that I'll report right now. I think they basically all pertain to getting Delta3D compiled, so one note should be acceptable.

The system I'm working on is a Fedora-11 installation. The important thing about that is that this distro comes with gcc version 4.4.0, which is fairly new, and I think more picky on a few things than past gcc compilers.

I'll first note that one of my goals was to attempt to compile the most minimal Delta3D possible. Later I may expand to using more of the features, but right now I'm looking for the graphics and the physics, and I'm also looking at minimal 3rd party software requirements.

So with that goal in mind, I hoped that what one of the wiki pages indicated as a minimal setup would hold true. I.e. requiring only:
- OpenSceneGraph
- Xerces-C
- OpenThreads (which I get with OpenSceneGraph)
- OpenDynamicsEngine

I also already have Qt installed on my system, so I figured I'd go with the Qt examples too.

This nearly worked as marketed. One problem is that while trying to compile "dtDirectorNodes" there was a requirement for ALUT (and thus OpenAL). So, even though I selected a non-audio build, these two packages were required. Not a huge problem, I just used "yum" to download the "devel" versions of these. After the install I tried to pick up with where I left off with a simple "make" command, but that didn't get too far -- of course, the dtDirectorNodes build requires libdtAudio.so. So I had to go back to ccmake and turn the audio selection to "ON" and reconfigure/regenerate.
From there I was able to continue on with "make" (ie. without the need to do a "make clean" first).

The other issue I had with requirements is that since I had Qt on the system I went ahead and positively selected the "BUILD_WITH_QT" option in ccmake. But it turns out that one of the QT examples requires the Cal3D package, and thus the entire QT build failed. That seemed a bit extreme to me. I think the ParticleEditor demo is the culprit (or at least one of the culprits).

Related to requirements, I tried doing a "yum" install of ODE, but there was no "devel" option, so I ended up downloading and compiling. That part wasn't a big deal. The major problem here is that I opted for the "double-precision" version of ODE -- I figure the more accurate the better. Well, this caused about 80% of the Delta3D test programs to crash. I don't see where I recorded the message, but the problem was reported to be from "odecontroller.cpp:20". Fortunately, on a bit of intuition I thought I'd go back an recompile ODE as a single-precision library. This worked -- now most of the test programs mostly work.

So there are two issues from that. 1) The Delta3D instructions should strongly point out that ODE needs to be compiled in single-precision, and 2) Delta3D should be fixed to be able to handle a double-precision version of ODE.

Next issue: audio. Actually, on reflection I think I'll hold off on this, the audio problem I'm having may be related to the fact that I changed the ccmake config in the middle of the process.

So next then is the compiler issue hinted at above. I tend to prefer official releases to SVN versions, so I can tell other people how to make their system work as mine works. So I started with version 2.4. But there were a bunch of errors during the compilation, so again on intuition I thought before I track all these down, I'll see whether the SVN version will compile, because I'm sure there are a lot of issues related to the 4.4.0 compiler, and surely in the time since the 2.4 release someone on the Delta3D team has run into this and fixed it. And that seems to have been the case -- for the most part, the SVN version (from yesterday) compiled with practically no warnings -- but I saved those if anyone is interested.

But the SVN download does raise a sour point. After determining that I need to test the SVN version I went to the wiki or whatever page with the SVN instructions, so them there in a big bold box, cut and pasted them to a shell and left for a meeting. Only to come back 90 minutes later and find that it's still downloading. Well, then I see a box in muted yellow, and in a SMALLER FONT that says I probably don't want to do the above, highlighted command, but probably want to add "/trunk" to it. I felt a bit like Hawkeye in the M.A.S.H. episode with the CIA bomb. I think a better way to describe the process is to give the best SVN command in the bold box, and then in muted, fine print you can talk about how the entire 20Gigs of stuff can be downloaded if the trunk isn't sufficient. I ended up with 20Gigs of too much stuff.

And one final thing for this message (I'm already late picking someone up) -- the test demos.

I got most of the demos to work, but most of them complained about not finding an "Arial.ttf" font -- how do I go about fixing this? Also most of them complained about not finding their "config.xml" file. Oddly, the "testWeather" program was able to find it's config.xml file, and all the other config.xml files seemed to be in similar locations, so not sure why they had trouble. There are other details that I'll save for a later note.

Thank you for your help,
Bill

 Quote   

 
 Wednesday, February 03 2010 @ 08:41 PM EST

Hi Bill,

[Quote  by:  wsherman]One problem is that while trying to compile "dtDirectorNodes" there was a requirement for ALUT (and thus OpenAL). So, even though I selected a non-audio build, these two packages were required.
This was detected and fixed just the other day. Now, if you haven't enabled BUILD_AUDIO, the dtDirectorNodes project will not be generated. dtDirectorNodes does indeed make use of dtAudio.




[Quote  by:  wsherman]But it turns out that one of the QT examples requires the Cal3D package, and thus the entire QT build failed. That seemed a bit extreme to me. I think the ParticleEditor demo is the culprit (or at least one of the culprits).
I wouldn't expect "the entire" Qt build to fail, only those projects that make use of dtAnim (or CAL3D). I found and just now fixed the ParticleEditor, which was trying to include the CAL3D include folder (which it shouldn't have been). If you find any other Qt-based projects failing due to missing dependencies, please let me know!

[Quote  by:  wsherman] 1) The Delta3D instructions should strongly point out that ODE needs to be compiled in single-precision, and 2) Delta3D should be fixed to be able to handle a double-precision version of ODE.
True and true. Some of the "how to build" tutorials state that ODE needs to be single-precision, not it's not apparent.

[Quote  by:  wsherman] So I started with version 2.4. But there were a bunch of errors during the compilation...
True. Your linux and compiler has been released after the 2.4.0 release. I'm pretty good, but I can't go back in time and fix 2.4.0 for newer compilers. Smile


[Quote  by:  wsherman] Well, then I see a box in muted yellow, and in a SMALLER FONT that says I probably don't want to do the above, highlighted command, but probably want to add "/trunk" to it.
Unfortunately, that's a Sourceforge auto-generated page and we have no control over it. It's probably better to have a Wiki page describing how to check out Delta3D from SVN, that all of our "source" links point to.


[Quote  by:  wsherman]I got most of the demos to work, but most of them complained about not finding an "Arial.ttf" font
Not sure about that - maybe that's coming from osgText? Good question.

[Quote  by:  wsherman]Also most of them complained about not finding their "config.xml" file.
Yeah, we're a little lazy when it comes to that. The config.xml file allows you to tweak some of the initial settings for the application - mainly the window size and such. The examples don't really care if they have the file or not, so it tends to get overlooked.

Thanks for the detailed summary. Feel free to post any more quirks you find!
-Erik Johnson

 Quote   

 
 Friday, February 05 2010 @ 07:22 PM EST

Hello again,

And thanks for the quick feedback.

And before I begin -- how'd you get my quoted text to be indented? I'm trying to use the QUOTE tags, but they only indent the bit between the open and close tag.
So, I'll use italics for the quoted material.

[Quote ErikJohnson
This was detected and fixed just the other day. Now, if you haven't enabled BUILD_AUDIO, the dtDirectorNodes project will not be generated. dtDirectorNodes does indeed make use of dtAudio.

Great. I'll try to do an SVN update next week and experiment more with the build options.

[Quote ErikJohnson
I wouldn't expect "the entire" Qt build to fail, only those projects that make use of dtAnim (or CAL3D). I found and just now fixed the ParticleEditor, which was trying to include the CAL3D include folder (which it shouldn't have been). If you find any other Qt-based projects failing due to missing dependencies, please let me know!

Will do. Regarding the entire build failing -- once make gets an error with one of the applications, it quits. I probably could compile other bits by hand, but I don't know the target names (I suppose I could look in the Makefile). But since Qt was of lesser importance to me, I turned it off and moved on.

[Quote ErikJohnson
True. Your linux and compiler has been released after the 2.4.0 release. I'm pretty good, but I can't go back in time and fix 2.4.0 for newer compilers.

Understandable, and in fact, I wouldn't expect you to be right up to date with any particular release. But I must have misread the release date for 2.4.0 as begin November instead of June.

[Quote ErikJohnson
Not sure about that - maybe that's coming from osgText? Good question.

Well, I went back and ran all the examples again -- there is a one to one mapping between examples that provide on-screen help and the complaining about a missing "Arial.ttf" font. The help still appears though. Also, I did a locate on Arial.ttf, and there is no such file anywhere on my machine -- so it's probably not an issue of code looking in the wrong place.

[Quote ErikJohnson
Yeah, we're a little lazy when it comes to that. The config.xml file allows you to tweak some of the initial settings for the application - mainly the window size and such. The examples don't really care if they have the file or not, so it tends to get overlooked.

Well, I think I can shed some light on that. After further investigation, I found that the "testWeather" application appends "/examples/testWeather" to the datafilepathlist, whereas the other examples that I checked append "/examples/data" -- and the config files are all in the directories named after the program. I suppose the other examples need stuff from the data directory too (but then so does testWesther), so the other applications can handle an unset DELTA_DATA environment variable. I suppose both directories should be being added to the datafilepathlist.

[Quote ErikJohnson
Thanks for the detailed summary. Feel free to post any more quirks you find!

No problem -- all my posts of bugs and problems are meant to help make the library better.

And I'll be posting some documentation requests momentarily.

Thank you,
Bill

 Quote   

 

 


Delta3D is released under the GNU Lesser General Public License (LGPL) | Powered by GeekLog