Compiling ogreOde, Ogre 1.7

Did Anybody compile ogreode on ogre 1.7?
I have many errors such as:
1>d:\gamedev\ogre\ogreode\include\ogreodebody.h(142) : error C2039: UserDefinedObject: is not a member of "Ogre"
1>d:\gamedev\ogre\ogreode\include\ogreodebody.h(142) : error C2504: UserDefinedObject: base class undefined
1>d:\gamedev\ogre\ogreode\include\ogreodegeometry.h(21) : error C2039: UserDefinedObject: is not a member of "Ogre"
1>d:\gamedev\ogre\ogreode\include\ogreodegeometry.h(21) : error C2504: UserDefinedObject: base class undefined
...

there are 156 errors(

Yes, I posted a patch for this a few months ago. Check this forum, I copied it here because I don't know if it was committed to SVN yet.

I have it compiling, although I still have a few bugs. I also was not aware of the update patch. Here's the thread from the Developer forum: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=55089

The majority of those errors you are getting have to do with the deprecation of the Ogre::UserDefinedObject class, if I remember correctly. Ogre now uses a more generic class for defined object operations called Ogre::Any. It has similar functions, but they're not completely interchangeable.

Please post patch on sourceforge tracker : http://sourceforge.net/tracker/?group_i ... id=1064241

It was suggested that I merge the forked branch into mainline OgreOde. So rather than posting a patch, I will begin updating the OgreOde repository once Sinbad has authorized me to commit changes.

I'm the current maintainer of OgreOde.

Once patch posted reviewed and applied, if you want to further maintain Ogreode I or Sinbad would gladly give you the keys (SVN and forum), specially if you have plans for the future (cmake support? paging support ? etc... ), not just making it work at your place.

Posting a patch help others reviewing it and check if it's compatible with current other codebase, etc.

@tuan k,
Someone was trying to contact you regarding source maintenance some time back. Don't know if you missed the post.

viewtopic.php?f=7&t=10034

@dermont: had been on contact with him, but it didn't end in any patches...

Dude, I was contacting you about maintaining the source, and I posted the 1.7 patch and gave it to you, you said you where going to look at it first then commit it if passed your review.

@shanefarris : Sorry if I got it wrong, but since last PM, I was still waiting for the patch file ?
Cannot find it anywhere here, Did you post to http://sourceforge.net/tracker/?group_id=225283 or did you sent me the patch by mail ?

I didn't know you where waiting for it, its on this forum (check the middle of this forum). You've seen it, you're the last one to comment on it.

I wouldn't worry about support 1.6 because 1.7 is now released, and now the unstable version is 1.8.

You mean that one ? viewtopic.php?p=65876#p65876 ?
A said in the thread, copy/paste in forum is only ok for very small patch and only if the maintainer aknoledge it.
Tracker is there for that, keeping a list of pending patch when I have time to tackle it, think of other people reviewing/testing it, easy downloadable file, etc...
That really doesn't help if patch is not on sourceforge...

I wouldn't worry about support 1.6 because 1.7 is now released, and now the unstable version is 1.8.
Mmm, we need to be backward compatible, as we don't maintain branches, so it needs to work with all people still using 1.X other that 1.8

Why has no one has submitted a patch for this yet?

I wouldn't worry about support 1.6 because 1.7 is now released, and now the unstable version is 1.8.
Mmm, we need to be backward compatible, as we don't maintain branches, so it needs to work with all people still using 1.X other that 1.8

When you talk about backward compatibility and 1.X what versions are you referring to and what changes did you have in mind?

1. Replacing UserDefinedObject with Ogre::Any for Ogre1.7/1.8 - where only a couple of ifdefs are required to support 1.6.x, since 1.6.x supports set/getUserAny.

2. Versions <=1.6.x should use UserDefinedObject and versions >1.7 Ogre::Any, keeping in mind some of the particle scripts have already been updated and probably won't run on 1.4.X.

I've done (1) but run into a problem with a crash when switching scenes in SimpleScenes that contain ragdolls (probably something minor).

(2) would probably take a bit longer and be a bit messy.

I apologize for the delay. If someone can provide me with the repo address so I can check it out, I'll use what I have to make a patch with SVN. I have not tested backward compatibility as far back as 1.4, but it is backward compatible with 1.6.

I apologize for the delay. If someone can provide me with the repo address so I can check it out, I'll use what I have to make a patch with SVN. I have not tested backward compatibility as far back as 1.4, but it is backward compatible with 1.6.

The repo address is:
https://ogreaddons.svn.sourceforge.net/ ... nk/ogreode

The tracker address is given on a previous post in this thread. Once you have made your updates I'll incorporate my changes (if needed since you already appear to have done all the necessary updates) including minor fixes for 1.7/8 to the Makefiles.

Patch Applied with changes, as it wasn't working on 1.6 here. Please check it out on your side.

Patch Applied with changes, as it wasn't working on 1.6 here. Please check it out on your side.

On Linux:

from OgreOdeBody.cpp:4:
../include/OgreOdePreReqs.h:12:2: error: #error You must #define dSINGLE or dDOUBLE in project settings. (preprocessor macros)
../include/OgreOdePreReqs.h:13:2: error: #error Make sure it uses same value as ODE project settings.
../include/OgreOdePreReqs.h:14:2: error: #error you can also define it in OgreOdePreReqs.h (just after the #include "Ogre.h" )


I think your ode header should come before your dSingle/dDouble check. I'll submit a patch with a couple of makefile updates for 1.7/1.8.


#include "ode/ode.h"


#if defined(dSINGLE)
..


Also OgreOdeVehicle.cpp Vehicle::handleTyreCollision appears to be using the old get/setUserObject, looks like there was a problem applying the patch.

include ode.h doesn't work here, they really made the dSINGLE outside the ode headers... Hopefully that can be solved using Cmake.
About the "setuser", there's no more of those in SVN, so that must be some local diff/update merge conflict you have.

Browsing the svn repository they still appear to be there in Vehicle::handleTyreCollision.

fixed, thanks for the report !

I get the following errors when compiling ogreode:
undefined reference to `Ogre:: ...
and a lot of similar errors
What needs to be done in order to compile completely

Need more info than that. What, specifically, is the reference to which your compiler is referring or at least what's one of them?

I think this is a follow to this thread:
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=55355

1. Is it only the OGRE pkg check module that gives a syntax error?

If it's all pkg check modules there may be something wrong with aclocal and maybe the pkg.m4 macro isn't being picked up properly. Do a google search on for posts such as the following:
http://libtorrent.rakshasa.no/ticket/809
http://www.ogre3d.org/forums/viewtopic. ... ht=aclocal

These is package versions installed on my system:

pkg-config --version 0.22
automake --version 1.11
autoconf --version 2.64

You could try updating autogen.sh to include the ACLOCAL_FLAGS or set the ACLOCAL_FLAGS path to where the macros are installed, /usr/share/aclocal on my system.

#aclocal -I
aclocal -I . $ACLOCAL_FLAGS


2. To build with the pkg check removed you could run the following to find the paths, libs etc required, though you would be better resolving (1) first.
>>pkg-config --cflags --libs OGRE

and then build with something like:

LDFLAGS='-L/usr/local/lib -lOgreMain' CXXFLAGS='-I/usr/local/include/OGRE' ./configure


Maybe you could post details of your Linux distro; output of `pkg-config --cflags --libs OGRE`; do you have more than one version of Ogre installed; have you run sudo ldconfig or similar after installing ... so that others building with your particular distro may help.

Just a general update on the migration to CMake with OgreODE. I now have all the scripts written, the build environment being setup (thanks to the completeness of the CMake project in Ogre already), and the project outputting for MSVC. I have not tried any other compilers yet, and I'll need someone who uses OSX to straighten out any Mac-specific flags that need to be set (I know very little about that platform and don't really have any way to test it). If I run into any problems, I plan to post them on this thread.

FYI I also upgraded the tinyxml library being used because the version that was integrated was using unsafe vsprint and fopen. Rather than go through and update them by hand, I figured I'd just include the new libs, instead. They seem to be working without a hitch.

Thanks a lot bludo.
As for OSX, I think we'll have feedback "one day" as I didn't see much OSX ogreode users on forum.
Meanwhile I can test them on Linux if you can post a patch or a zip that allows to try it out.

Here's a couple of the changes to the repository I've made in the prototype using CMake:

-Created a directory called core and moved the include and src directories from the root into it. This was for the sake of CMake so that I could use the CMakeLists.txt file in the root to set the build environment and have a separate one for the OgreOde_Core target.

-Two CMake environment variables must be added before attempting to run CMake: OGRE_SOURCE and OGRE_BUILD. This comes right out of findOgre.cmake so that the included projects know where the OgreMain library is to link with.

-The CMake build will assume that the ode source directory does not have the version appended to the name. This was for simplicity's sake. Having to ensure a variable is set for the ode version and having that be interpreted by CMake and various compilers was getting too messy; so now it's just "ode".

^This does raise another issue, however. Currently, I've added CMakeLists for ode and added them as targets of the project. I am uncertain, however, if other platforms will be able to use a universal ode library configuration. I believe that GNU configure auto-generates some of the headers used for those platforms (specifically, the config.h file found in ode/ode/src). I haven't looked into this a great deal yet, but it's on my radar. Perhaps Tuan will be able to tell me more. If possible, it'd be nice to have a universal ode library checked in to the repository and have the static libs build with the project so that the latest compatible version is always available.

-Lastly, the TinyXML library was updated without any issues. Only a few headers/source files had changed and they were dropped right on top of the previous ones.

I will try and get a patch out sometime this weekend, along with a sample package for testing. I've got a little ways to go yet, but it's probably ready to be run and configured on other platforms.

Bludo

seems fine to me.

Ode was removed from Ogreode svn we should keep it like that.
Just having user to point at it's Ode directory in cmake (like ogre does for its dependencies), and let the user have a way to set the option dsingle/ddDouble (current svn ODE doesn't put it in common.h anymore, in windows at least)

OK I compiled it I think, by installing pkgconfig from source, now 0.22.

But when I run demo I get this error:
An exception has occured: OGRE EXCEPTION(5:ItemIdentityException): Cannot locate a resource group called 'Bootstrap' in ResourceGroupManager::findResourceFileInfo at /PROGRAMS/OGRE/OgreMain/src/OgreResourceGroupManager.cpp (line 1602)

So I need to do something with the media folder or resources.cfg I guess, but what?

Plus how do I tell compilation to place executables like granturismogre to be placed in ogre/bin?

OK I compiled it I think, by installing pkgconfig from source, now 0.22.

But when I run demo I get this error:
An exception has occured: OGRE EXCEPTION(5:ItemIdentityException): Cannot locate a resource group called 'Bootstrap' in ResourceGroupManager::findResourceFileInfo at /PROGRAMS/OGRE/OgreMain/src/OgreResourceGroupManager.cpp (line 1602)

So I need to do something with the media folder or resources.cfg I guess, but what?

Plus how do I tell compilation to place executables like granturismogre to be placed in ogre/bin?

For your resources error you probably need need to update your ogre/bin/resources.cfg by adding the paths to the ogreode media and OgreCore.zip with something like:

[OgreOde]
FileSystem=/ogreode/demos/Media
[Bootstrap]
Zip=ogre-v1-6-4/Samples/Media/packs/OgreCore.zip


OgreCore.zip is media zip file from Ogre1.6, if you don't have 1.6 on your system you can download using:

wget http://ogre.svn.sourceforge.net/viewvc/ogre/branches/v1-6/Samples/Media/packs/OgreCore.zip


For installing the demos to ogre/bin, there is a patch attached below with a couple of new configure options (also installs a couple of missing headers). To run something like:

./configure --with-samples-bin=/ogre/bin


@Tuan

Fair enough - but since ODE will need to be compiled with dTRIMESH_ENABLED and dTRIMESH_OPCODE defined, I'm assuming they should still be included as targets in OgreOde CMake and compiled with the project, correct? If so, I suppose it won't be that difficult to install pre-defined CMake lists to the ODE/OPCODE source directories once the user has defined a ODE_SOURCE CMake variable. If not, and those defines are not set in a pre-built ODE library, OgreOde will fail, and ODE will be required to be rebuilt specifically for OgreOde.

Things is that you'll have to maintain the cmake list for ode and all, whereas just a readme explaining the needs (ode define) or better ogreode code being conditionnally compiled on detection of those define. (if possible detetection inside cmake with warning/error being spawned to user)

Understood. I'll include the CMakeLists.txt templates for ODE and OPCODE in the CMakeModules folder in case anyone wants to use them as a template to keep the project together and put a README in the ode folder with more information.

I have the first version of the patch together, as well as an updated source package. The patch this time (as opposed to the previous update) will have all the changes, including files to be added (generally only the CMakeLists and CMakeModules folder). What it also contains, though, is all the files and file reorganization to support CMake a little more uniformly. It's just a prototype package, but you should be glad to hear that with all the premade MakeFiles and project files gone as well as no ODE package included, the package is a svelte 7.5 megs or so (I think the last one was quite a bit larger than that).

I'll post it tomorrow sometime for your review and upload the package to the same place as before. I'll also again include the link to the archive file with the patch description. I'm sure it's not ready for distro yet, but it's far enough along for you to test it on Linux and make some tweaks.

Bludo

Okay - patch and package are posted on the SF tracker. Let me know if there are any questions.

Bludo

Thanks, very appreciated !

Some remarks:
- Why opcode include/lib ?
- did you use svn move or delete and then add (move is the one to use as we want to keep svn history of each files) ?
- you did used SVN trunk OGRE (1. not 1.7 findOGRE.cmake, only the latter worked for me
- Wrong include order, ode include MUST be before ogre include (1.6 SDK has very ode include/lib in the ogre path.)
- you didn't get the latest update from SVN, when I applied your previous patch ?

Needed change were also :

IF (NOT ("${OGRE_VERSION_NAME}" STREQUAL "Cthugha") OR ("${OGRE_VERSION_NAME}" STREQUAL "Shoggoth"))
=>
IF (NOT (("${OGRE_VERSION_NAME}" STREQUAL "Cthugha") OR ("${OGRE_VERSION_NAME}" STREQUAL "Shoggoth")))


Thanks, very appreciated !

Some remarks:
- Why opcode include/lib ?
- did you use svn move or delete and then add (move is the one to use as we want to keep svn history of each files) ?
- you did used SVN trunk OGRE (1. not 1.7 findOGRE.cmake, only the latter worked for me
- Wrong include order, ode include MUST be before ogre include (1.6 SDK has very ode include/lib in the ogre path.) so I have to use
INCLUDE_DIRECTORIES(
BEFORE
${OGRE_INCLUDE_DIRS}
${ODE_INCLUDE_DIRS}
include
)
to make it works.

Needed change were also :

IF (NOT ("${OGRE_VERSION_NAME}" STREQUAL "Cthugha") OR ("${OGRE_VERSION_NAME}" STREQUAL "Shoggoth"))
=>
IF (NOT (("${OGRE_VERSION_NAME}" STREQUAL "Cthugha") OR ("${OGRE_VERSION_NAME}" STREQUAL "Shoggoth")))




(the Not has to be on both)


IF ("${OGRE_BUILD}" STREQUAL "")
SET(OGRE_BUILD ${OGRE_HOME})
ENDIF()

juste before the version thing.

a nsis/zip build would be interesting, so people afraid from SVN could still get something.


Still didn't success as the ode/ogre include order does break everything here, I'll try to continue testing later.

Good catch on these items. Yes, I was using out-of-date CMake modules. I've imported the correct ones into the CMake modules folder and removed the ones in there that weren't needed. The include ordering has been fixed and the NOT error resolved (stupidly, I forgot to test the last update against the 1.6 build).

IF ("${OGRE_BUILD}" STREQUAL "")
SET(OGRE_BUILD ${OGRE_HOME})
ENDIF()

I'm not sure we want to do this. I've seen OGRE_HOME used as a replacement for OGRE_SOURCE and this could create problems inside of the CMake environment because ultimately, we assume one or the other will point to the Ogre root. It doesn't seem unusual to me to have to force the user to set their own location of the built libraries for Ogre.

Bludo

@Tuan,

There's also something I've been meaning to inquire about.

dotOgreOdeLoader = new OgreOde_Loader::DotLoader(world);

const int _stepper_mode_choice = 0;
const int _stepper_choice = 2;
const Ogre::Real time_scale = Ogre::Real(1.0);
const Ogre::Real max_frame_time = Ogre::Real(1.0 / 4);
const Ogre::Real frame_rate = Ogre::Real(1.0 / 60);
This can be found in the demo .cpp files where they call the stepper function. In particular, you modified this line in the compatibility patch I provided:

const int _stepper_mode_choice = 0;
The stepper mode choice previously set this value to 2 in the case switch, which points it to the ForwardFixedStepHandler, where now it uses the basic StepHandler. I only just started running it in the debugger, but this change appears to be somehow amplifying the downward acceleration on the vehicles inordinately. If you run any of the demos, you should be able to notice the issue in the vehicle suspension and in their inability to navigate inclined terrain.

I'm still trying to track down how this is affecting the vehicle motion, whether it's environmental or in the vehicle load, itself. My pre-emptive apologies if there's something I've missed, but I am curious why the stepper was changed to a different handler.

Bludo

It doesn't seem unusual to me to have to force the user to set their own location of the built libraries for Ogre.
I already had to set by myself the OGRE_SOURCE var, it doesn't seem reasonnable that users have to set multiple variable, if it's pointing at the same place.
Any solution is ok as long it's as simple as possible (and documented, why could add an install.txt dedicated to cmake)
I am curious why the stepper was changed to a different handler.
In my ODE there's no more stepfast, so I had to make changes. And reverting to basic stepping instead of too clever like stepping (the forward one that can breaks if too slow, vsync, too fast, etc.).

Okay, here's my proposed resolution to prevent having to mess too much with setting CMake environment variables - it's a modification to FindOGRE.cmake. As you'll see, it's a fairly generalized solution. I wouldn't know if it warrants consideration for the engine project, but for our purposes I think it will do the job.

(edited 2010/11/02 23:34 CST)
# Get path, convert backslashes as ${ENV_${var}}
getenv_path(PROGRAMFILES)
getenv_path(OGRE_SOURCE)
getenv_path(OGRE_HOME)
getenv_path(OGRE_SDK)
SET(OGRE_PATHS
${OGRE_SOURCE}
${OGRE_HOME}
${OGRE_SDK}
$ENV{OGRE_SOURCE}
$ENV{OGRE_HOME}
$ENV{OGRE_CTHUGHA}
)

PKG_MESSAGE(OGRE "Scanning CMake and system environment variables for Ogre source path...")
FOREACH(OGRE_PATH ${OGRE_PATHS})
IF(NOT("${OGRE_PATH}" STREQUAL ""))
SET(OGRE_SOURCE ${OGRE_PATH})
BREAK()
ENDIF()
ENDFOREACH()
IF("${OGRE_SOURCE}" STREQUAL "")
# Warn user that the Ogre path was not found in the scanned variables
MESSAGE("WARNING: OGRE source path not found. To ensure the source files are included properly, please set OGRE_SOURCE in CMake to the correct path.")
ELSE()
IF(WIN32)
# Convert backslashes in path to slashes
STRING(REPLACE "\\" "/" OGRE_SOURCE "${OGRE_SOURCE}")
ENDIF(WIN32)
PKG_MESSAGE(OGRE "OGRE source path set to ${OGRE_SOURCE}. To set this manually, set OGRE_SOURCE in CMake to the desired path.")
ENDIF()

# Get the Ogre build directory or assume it is the "build" directory in the Ogre source.
getenv_path(OGRE_BUILD)
IF("${OGRE_BUILD}" STREQUAL "")
SET(OGRE_BUILD "${OGRE_SOURCE}/build")
MESSAGE("OGRE build path not provided. Setting to ${OGRE_SOURCE}/build. To set this manually, set OGRE_BUILD in CMake to the desired path.")
ENDIF()
If the system environment is set to have an Ogre root directory specified, then most people who set that value (as recommended in the Ogre setup, if I remember correctly) should not have to bother with defining any variables prior to configuration most cases, unless they're using an off-main build, at which point it's better if it's defined manually inside of CMake, anyway.

There really isn't any simple solution to pre-define the build directory. In this circumstance, I'm assuming that the most common location is in a "build" folder in the source directory. If you're aware of a more common usage of this, we can add that too. However, it's a bit of a Catch-22 because the build directory is verified by locating the libraries, and scanning for these here this early in the code or later where they're already scanned won't really work. I'm open to suggestions, and admittedly this is based on how I've configured my directory structure, but I am trying to keep it simple.

Bludo

Since I haven't heard anything, I will be posting a patch with this integrated into CMake, along with the other items Tuan mentioned previously.

@bludo: You should have direct SVN access. You can commit the "fixed" changes.

@Tuan

Okay, excellent. Would you like me to check in the entire CMake update?

Also, I should note that with the addition of CMake, I have reconfigured the folder structure and removed the superfluous directories and files that were previously checked into the repository, for instance ones that contained the build objects and project files (/lib, /obj, /scripts, etc.). One of the benefits of CMake is that it allows the source repository to remain independent and unmolested and all the build data to be relegated to the build directory. I'm not sure what your feeling is on the matter, but with CMake implemented these subdirectories and files are functionally obsolete. Is removing them satisfactory or do you foresee it causing problems?

Bludo

@Bludo: yes, check in, move the core src, and delete obsolete scripts/folder.

Update committed. I did not remove the premake files because I'm unaware if they are still useful for converting the source files (I have not really looked at the lua code contained within). Please let me know if these are also obsolete, and I will remove them and srcfileOgreOde.txt, as well. Anyone who runs into any problems, please post them so that any necessary modifications can be made as soon as possible. Thanks.

Bludo

The "core" directory causes problems when running a configure script which attempts to delete the core dump file "core" which is a directory.

Can we rename the directory to "Core" to accommodate users that wish build OgreOde via the GNU build system.
http://en.wikipedia.org/wiki/Core_dump#Naming

still the strange opcode thing here ?
is it really needed ?

Here it doesnt find exampleapplication.h on the ogresdk 1.6

SimpleScenesApplication.h(14) : fatal error C1083: Cannot open include file: 'ExampleApplication.h': No such file or directory
Landscape.h(6) : fatal error C1083: Cannot open include file: 'ExampleApplication.h': No such file or directory
1GranTurismOgre.h(6) : fatal error C1083: Cannot open include file: 'ExampleApplication.h': No such file or directory

The "core" directory causes problems when running a configure script which attempts to delete the core dump file "core" which is a directory.

Can we rename the directory to "Core" to accommodate users that wish build OgreOde via the GNU build system.
http://en.wikipedia.org/wiki/Core_dump#Naming

I will change it. However, last year, using an Apache-based SVN backbone, I ran into a problem where changing the case of a file name and checking it in to the repository created an error where SVN could not determine if the file had changed and users were unable to update. Just to be on the safe side, I'm going to move the files to a directory called Temp and delete the core folder in the first commit, and then change the case, add it, and move them back in a subsequent one. This should solve the issue.

Bludo

still the strange opcode thing here ?
is it really needed ?

Here it doesnt find exampleapplication.h on the ogresdk 1.6

SimpleScenesApplication.h(14) : fatal error C1083: Cannot open include file: 'ExampleApplication.h': No such file or directory
Landscape.h(6) : fatal error C1083: Cannot open include file: 'ExampleApplication.h': No such file or directory
1GranTurismOgre.h(6) : fatal error C1083: Cannot open include file: 'ExampleApplication.h': No such file or directory


This error is not related to ODE/OPCODE. This is because in the SDK, the path to ExampleApplication.h is OGRE_HOME/Samples/include, instead of OGRE_HOME/Samples/Common/include (as it is in the source). The include path to that header was originally assumed to be the latter. I've added a small check in the root CMakeLists.txt that will check both locations based on the OGRE_SOURCE being referenced and include the correct one. This will resolve the error.

Bludo

Both of the above-mentioned issues should now be resolved in the source repository. Please check and let me know if any other issues arise.

Bludo

Compilation is now OK.
post build event is not.

file INSTALL cannot find "D:/ogresdk/OgreSDK/bin/release/OgrePaging.dll".

(still ogre sdk 1.6)

Compilation is now OK.
post build event is not.

file INSTALL cannot find "D:/ogresdk/OgreSDK/bin/release/OgrePaging.dll".

(still ogre sdk 1.6)

I'm already ahead of you on this one, as I've begun testing it out with the OgreSDK. OgrePaging.dll shouldn't be necessary to run the demos, anyway. So I've added it, along with OgreTerrain.dll, to optional files in the CMake install options. There is, however, another small issue. I was using %OGRE_HOME% in the resources.cfg ignorantly assuming it would pick up the environment variable to use in the paths. It does not. What this will likely mean is that if you intend to run OgreOde from it's own build/bin/ folder, the path to the OgreSDK will have to be entered manually unless install copies the Ogre media directory to it's local build directory (probably a lot more file work than is necessary).

Bludo

Check that - after thinking about it for awhile, installing the required media files is actually a more efficient solution than I first thought. This allows the runtime directory to have a static path to the required media files because CMake can use system environment variables to grab the media files from OGRE_HOME. The .cfg file cannot, unfortunately. Secondly, this is a nice precursor to the installer because the package data will be entirely localized to the build directory. It took a little while, and I'm afraid I know more about CMake now than I ever expected to, but it works with all Ogre package configurations effectively. The changes to the root CMakeLists.txt have been committed. Check it out when you have time. Need sleepy.

Bludo

nearly there, it bugs on octree-zone.dll missing.

Sorry, but it's mandatory that it work out of the box at least now, so that forum isn't full of how to install/run question.

The "core" directory causes problems when running a configure script which attempts to delete the core dump file "core" which is a directory.

Can we rename the directory to "Core" to accommodate users that wish build OgreOde via the GNU build system.
http://en.wikipedia.org/wiki/Core_dump#Naming

I will change it. However, last year, using an Apache-based SVN backbone, I ran into a problem where changing the case of a file name and checking it in to the repository created an error where SVN could not determine if the file had changed and users were unable to update. Just to be on the safe side, I'm going to move the files to a directory called Temp and delete the core folder in the first commit, and then change the case, add it, and move them back in a subsequent one. This should solve the issue.

Bludo

Thanks for the change. I think you may need to update your CMake file includes to point to "../../Core/include" instead of "../../core/include".

I'm assuming the current CMake is Windows only.

On Linux there are a number of case issues, e.g:

# Setup Dependencies
ADD_SUBDIRECTORY(tinyxml)
ADD_SUBDIRECTORY(Core)
ADD_SUBDIRECTORY(prefab)
ADD_SUBDIRECTORY(loader)
ADD_SUBDIRECTORY(demos/GranTurismOgre)
ADD_SUBDIRECTORY(demos/Landscape)
ADD_SUBDIRECTORY(demos/SimpleScenes)


On Linux the pkgconfig file is ode.pc:

FindODE.cmake

use_pkgconfig(ODE_PKGC ode)

..

find_path(ODE_INCLUDE_DIR NAMES ode.h HINTS "${ODE_PKGC_INCLUDE_DIRS}" "${ODE_SOURCE}/include/ode" "${ODE_SOURCE}/ode/src" PATH_SUFFIXES ode)

find_library(ODE_LIBRARY_REL NAMES ${ODE_LIBRARY_NAMES} HINTS ${ODE_PKGC_LIBRARY_DIRS} ${ODE_SOURCE}/lib)



OGRE_HOME doesn't exist so via the CMake gui you have to manually create this, better to have a user option.

How are the defines such as dSINGLE picked up, via pkg-config?

pkg-config --cflags --libs ode
>> -DdSINGLE -I/usr/local/include -L/usr/local/lib -lode
pkg-config --static --cflags --libs ode
>> -DdSINGLE -I/usr/local/include -L/usr/local/lib -lode -lstdc++ -lm


From FindODE.cmake what are OPCODE_* for?. On Linux the opcode headers are not installed, building ode as a shared lib links against libopcode*.a, building as a static lib links against the opcode object files.

Edit:

FindODE.cmake LIBRARY_NAMES probably needs to be updated as well. On Windows I though that ode was built as ode_single* and ode_double*, shouldn't these be included?

set(ODE_LIBRARY_NAMES ode libode)



nearly there, it bugs on octree-zone.dll missing.

Sorry, but it's mandatory that it work out of the box at least now, so that forum isn't full of how to install/run question.

No problem. OgreOde actually doesn't need the Plugin_OctreeZone.dll to run either so it's also now optional. However, in the OgreSDK for 1.6 that plugin should be in the package. I'm confused why it's not (it is in the 1.6.4 version I have). Anyway, it's fixed. The only plugins you'll need are the OctreeSceneManager and the ParticleFX (as well as a valid Render plugin).

Bludo

@dermont & Tuan

I've looked into the issues you've described and believe that I have most, if not all of them taken care of. I'll need it to be tested to be certain. I added a new option to CMake for specifying whether or not to use double precision. This does, however, present another issue. After specifying dDOUBLE in the preprocessor for OgreOde_Core using an ode library compiled with dSINGLE, the project built successfully. But when trying to run it, it failed in the ode library. Unfortunately, I don't know a way to catch this before runtime.

As far as I know, there isn't a way for CMake to determine the preprocessor defines used when pre-built libraries were compiled. Thus, we are relying on the user to know whether or not their ode library was compiled with single or double precision. For most people, I'm guessing that their version of ode will be compiled using dSINGLE, anyway. Nevertheless, for less savvy users incidentally linking an ode library compiled with double precision, they will have no way of knowing why OgreOde is failing. I would like to implement a catch of some kind, but right now there's no way to do that without including the ode project in the build. As before, this is not a viable option. I'm open to suggestions, but at this point we'll have to count on user know-how.

Bludo

On Linux you can obtain the preprocessor defines from PKG_CFLAGS, eg:

pkg_check_modules(ODE ode REQUIRED)
message (STATUS "CFLAGS... ${ODE_CFLAGS}" )
>> CFLAGS... -DdSINGLE;-I/usr/local/include


For Windows if it isn't defined in a config file then I guess a reasonable solution would be to parse the OGRE_DOUBLE_PRECISION define from OgreBuildSettings.h and set initial values dSINGLE/dDOUBLE / link against ode_single/double based on the value of OGRE_DOUBLE_PRECISION.

I found a different method that will work inside of CMake by scanning the config.h file with PreprocessorUtils.cmake. The has_preprocessor_entry function works using regex to make a determination. I will be able to set the variable with that bool.

Bludo

I found a different method that will work inside of CMake by scanning the config.h file with PreprocessorUtils.cmake. The has_preprocessor_entry function works using regex to make a determination. I will be able to set the variable with that bool.

Bludo

I haven't tried your changes, what version of ode are you testing with on Linux? I'm using ode-0.11 where config.h is not installed. I don't see -DdSINGLE/-DdDOUBLE defined anywhere in the source or installed headers, only via "pkg-config --cflags".

In addition the CMake files only appear to be setup for a local build. There doesn't appear to be anyway to install the headers/libraries/pkgconfig files etc.

Also it would be easier if the OgreOdePreReqs.h header contained the OgreOde_MAJOR/MINOR/PATCH_VERSION that you could parse, as you did above, to define the libraries sonames.

Hmm, are you sure that's the only place it's defined? I tried employing a scan of the package configuration and my version of CMake did not have that functionality (I'm guessing that it's a Linux-specific feature?). I'm testing it right now to see if the configure.in script generates the definition anywhere. If not, the way you suggested will probably be the best option.

Bludo

Hmm, are you sure that's the only place it's defined? I tried employing a scan of the package configuration and my version of CMake did not have that functionality (I'm guessing that it's a Linux-specific feature?). I'm testing it right now to see if the configure.in script generates the definition anywhere. If not, the way you suggested will probably be the best option.

Bludo

Pretty sure that the ode.pc pkgconfig file is the only place it's defined.


configure.in
AC_MSG_CHECKING(if double precision is requested)
AC_ARG_ENABLE(double-precision,
AS_HELP_STRING([--enable-double-precision],
[Configure ODE to work with double precision, if not specified, single precision is used]
),
precision=$enableval,precision=no)
AC_MSG_RESULT([$precision])
if test "$precision" = yes;
then
ODE_PRECISION=-DdDOUBLE
else
ODE_PRECISION=-DdSINGLE
fi

ode.pc.in
Cflags: -I${includedir} @ODE_PRECISION@

./configure --enable-double-precision (default is single)


Okay, well that will change things a little bit. Also, I realized that the config.h header I was parsing won't work because there's no way to know if the user has specified a preprocessor for dSINGLE or dDOUBLE in the project file. I think I need to approach this differently. What do you suggest?

Bludo

As I suggested previously a ODE_DOUBLE bool based on the OGRE_DOUBLE_PRECISION define from OgreBuildSettings.h would be a cross-platform solution. Maybe someone else has a better suggestion.

Okay - I've got it checked in. I am concerned, however, that the OgreBuildSettings.h won't ensure that the precision used in ODE is consistent as well. I compiled ODE using double and then ran CMake using the updated options and found that, as expected, OgreOde will compile without exception, but will not run if Ogre and itself are compiled using single. The obvious dilemma is that it's difficult to remedy this in pre-build without a way to scan a compiled library for preprocessor defines.

There is another option that was suggested to me by a colleague, which is to simply add a catch inside of OgreOde for when ODE attempts to use an inconsistent float precision so that the runtime exception can be handled gracefully. I think that as long as the exception is caught and handled, this should be sufficient.

Bludo

Hi, I'm really struggling to build OgreOde. I keep hitting problems that I manage to solve only to hit many more problems and I've now spent 6 hours getting nowhere.

Is there a walkthrough anywhere on how to compile using CMake?

I have compiled Ogre 1.7 and Ode 0.11.1 from source trying at every stage to do things the "standard" way on windows with Visual Studio C++ 2008 Express. But when I run CMake none of the required directories are automatically found and I get the following error:

CMake Error at CMake/FindPkgMacros.cmake:112 (message):
Required library ODE not found! Install the library (including dev
packages) and try again. If the library is already installed, set the
missing variables manually in cmake.
Call Stack (most recent call first):
CMake/FindODE.cmake:56 (findpkg_finish)
CMakeLists.txt:41 (FIND_PACKAGE)

I have tried many combinations of manually specificying the directories for Ode and Ogre and get a list of different errors. This is bizzare since I had a 1 week old version of OgreOde that I managed to compile fully but it resulted in heap corruption errors. After updating from the SVN, I now cant even get passed the CMake stage. Help, please, I'm exhausted!

Thanks.

Okay, let's start from the error you're getting first. The FindPkgMacros.cmake looks for a package by checking two things: an include file and a built library. If either one of these are not found, it will return the error you're seeing. Here's a couple of checks that hopefully will give us an idea of where you're at:

1. Where is your ODE source package? The easiest way to do it is to drop all the ODE source files into the "ode" directory in the OgreOde root directory. That's the first place the find_pkg will look. Otherwise, you will have to set ODE_SOURCE in CMake to the correct path.

(edited)
2. Have you built ODE separately? Inside of the ODE source package for Windows (after extracting from the .zip file), you will need to use the Premake scripts in the build directory to generate the project file. from build/premake/ use a command prompt and type the following command: premake4 --os=windows vs2008. That will give the .sln file to build ODE.

*ODE will also need to be built using the same floating point precision as Ogre. If you're using 64-bit floats, you will want to build the Release/Debug DoubleLib and DoubleDLL configurations. If you're using single or not sure, you should build Release/Debug SingleLib and SingleDLL configurations.

3. Do you have OGRE_HOME set in your Windows environment to you Ogre source root? If not, you will need to set OGRE_HOME in CMake so that it can link the libraries and reference the headers properly.

4. Do you have the Ogre Dependencies and build directories set in CMake? Typically, many people have these inside of the Ogre source root. To build the demos, you will need OIS from the dependencies package. If you've already built Ogre, it's most likely you already do. If your Ogre build directory is in a different location, you will need to specify the location by setting OGRE_BUILD in CMake to that path.

These are the first and most important checks. Let us know the answers to these and we'll move forward from there.

Bludo

Okay - I picked up the latest ODE source and ran into some problems when I realized I was using custom named output files and directories for the ODE libraries. The standard name for the premake generated project output files are ode_single/ode_double. These needed to be added to the CMake find list. It is possible that this may have been the source of your problem. I also was able to remove the OPCODE libraries from the project as a whole, since ODE defaults to including these, anyway.

The check-in has been made. Go ahead and update and try again and post how it goes.

Bludo

@dermont & Tuan

I did an overhaul on the way ODE is included (by building ODE and OgreOde in multiple configurations from scratch) and CMake should now be able to make an accurate determination over whether or not the floating-point precision is inconsistent between ODE and Ogre. I also made a bunch of small updates to the organization of commands in the CMake lists. If you would, please start from scratch (delete the CMake cache, build folder, and ODE project - if you can) and test it out on the various platforms. Let me know if anything unexpected pops up.

Bludo

Okay - I've got it checked in. I am concerned, however, that the OgreBuildSettings.h won't ensure that the precision used in ODE is consistent as well. I compiled ODE using double and then ran CMake using the updated options and found that, as expected, OgreOde will compile without exception, but will not run if Ogre and itself are compiled using single. The obvious dilemma is that it's difficult to remedy this in pre-build without a way to scan a compiled library for preprocessor defines.

There is another option that was suggested to me by a colleague, which is to simply add a catch inside of OgreOde for when ODE attempts to use an inconsistent float precision so that the runtime exception can be handled gracefully. I think that as long as the exception is caught and handled, this should be sufficient.

Bludo
In retrospect the OgreBuildSettings.h idea probably isn't a good one since it only applies to Ogre1.7.0, so you will probably have to come up with something else. Maybe best to just have a bool option, you can always revisit this later.

@dermont & Tuan

I did an overhaul on the way ODE is included (by building ODE and OgreOde in multiple configurations from scratch) and CMake should now be able to make an accurate determination over whether or not the floating-point precision is inconsistent between ODE and Ogre. I also made a bunch of small updates to the organization of commands in the CMake lists. If you would, please start from scratch (delete the CMake cache, build folder, and ODE project - if you can) and test it out on the various platforms. Let me know if anything unexpected pops up.

Bludo

On Linux:
1. Why is CMAKE_INSTALL_PREFIX set as follows:
SET(CMAKE_INSTALL_PREFIX "${OGREODE_BUILD}/bin")

2. The OgreOde_* libs aren't created with sonames
3. There is no way to install the OgreOde_* libs/headers/pkgconfig files.
4. The media/plugins.cfg/resources.cfg files aren't copied across to the build dir.

See attached patch for 1-3. Since I try to avoid CMake whenever possible there are probably better ways of doing this but it should give you an idea of what I mean.

Went through the patch and applied the changes. Thanks for putting that together. As you can tell, I don't do much development in a Linux environment.

As far as the installation is concerned, I considered setting a check for the platform and setting a variable LIB_EXT to the valid dynamically linked library extension and installing the libraries with that variable tacked on so that the install would search for the file on Linux with .so attached. But I got the feeling that the explicit paths I was using might not be valid, or that I was doing work an existing function in CMake could handle already. I don't know how an install configuration is handled on Linux, but this would allow me to remove the WIN32 check from the current install options in the root CMake lists. I could use some guidance with this.

I don't know if taking out the OgreBuildSettings check is necessary if we add a check for the Ogre version, but you're right - we'll need another method for 1.6.

Bludo

I don't know if taking out the OgreBuildSettings check is necessary if we add a check for the Ogre version, but you're right - we'll need another method for 1.6.
Bludo
Yeah the patch was only intended as an example of what may be needed on Linux. I think the check for OgreBuildSettings should be as simple as:

IF(EXISTS ${OGRE_CONFIG_INCLUDE_DIR}/OgreBuildSettings.h)
...



As far as the installation is concerned, I considered setting a check for the platform and setting a variable LIB_EXT to the valid dynamically linked library extension and installing the libraries with that variable tacked on so that the install would search for the file on Linux with .so attached. But I got the feeling that the explicit paths I was using might not be valid, or that I was doing work an existing function in CMake could handle already. I don't know how an install configuration is handled on Linux, but this would allow me to remove the WIN32 check from the current install options in the root CMake lists. I could use some guidance with this.
Bludo

On Linux there is no need to copy across the OgreMain lib/dependencies/plugins. To run a demo you would point plugins.cfg to the plugin folder. You can get the plugin paths etc from the OGRE_* options, take a look at the GroupedView for OGRE from the cegui.

This is relevant parts of the CMake install for Ogre:

${CMAKE_INSTALL_PREFIX}/lib - libraries(*.so , *_d.so)
${CMAKE_INSTALL_PREFIX}/lib/OGRE - Plugins(*.so , *_d.so)
${CMAKE_INSTALL_PREFIX}/lib/pkgconfig - pkgconfig files (*.pc)
${CMAKE_INSTALL_PREFIX}/include/OGRE - headers
${CMAKE_INSTALL_PREFIX}/bin - binary files(exes on Windows), *.cfg
${CMAKE_INSTALL_PREFIX}/bin/debug - binary debug files(), *.cfg
${CMAKE_INSTALL_PREFIX}/share/OGRE/docs - Readme / api etc
${CMAKE_INSTALL_PREFIX}/share/OGRE/media - media


Where ${CMAKE_INSTALL_PREFIX} would be a system path installation such as /usr/local or alternatively a local install path (in which case the OgreOde installed demos may need rpath(linking) to point to the OgreOde libs).
http://en.wikipedia.org/wiki/Rpath_%28linking%29

and OgreOde:

${CMAKE_INSTALL_PREFIX}/lib - libraries(*.so *_d.so)
${CMAKE_INSTALL_PREFIX}/lib/pkgconfig - pkgconfig files (*.pc) ( TODO Debug)
${CMAKE_INSTALL_PREFIX}/include/OgreOde_Core - headers
${CMAKE_INSTALL_PREFIX}/include/OgreOde_Loader
${CMAKE_INSTALL_PREFIX}/include/OgreOde_Prefab
${CMAKE_INSTALL_PREFIX}/bin - binary files(exes on Windows) (*.cfg TODO)
${CMAKE_INSTALL_PREFIX}/bin/debug - TODO
${CMAKE_INSTALL_PREFIX}/share/OgreOde/docs - None
${CMAKE_INSTALL_PREFIX}/share/OgreOde/media - TODO


Thank you very much for taking the time to help me Bludo. Sorry I took a while to answer your questions, my Internet connection went down for 24 hours!

Okay, let's start from the error you're getting first. The FindPkgMacros.cmake looks for a package by checking two things: an include file and a built library. If either one of these are not found, it will return the error you're seeing. Here's a couple of checks that hopefully will give us an idea of where you're at:

1. Where is your ODE source package? The easiest way to do it is to drop all the ODE source files into the "ode" directory in the OgreOde root directory. That's the first place the find_pkg will look. Otherwise, you will have to set ODE_SOURCE in CMake to the correct path.

(edited)
2. Have you built ODE separately? Inside of the ODE source package for Windows (after extracting from the .zip file), you will need to use the Premake scripts in the build directory to generate the project file. from build/premake/ use a command prompt and type the following command: premake4 --os=windows vs2008. That will give the .sln file to build ODE.

*ODE will also need to be built using the same floating point precision as Ogre. If you're using 64-bit floats, you will want to build the Release/Debug DoubleLib and DoubleDLL configurations. If you're using single or not sure, you should build Release/Debug SingleLib and SingleDLL configurations.

I extracted ode to: "C:\Program Files\ode\ode-0.11.1" and installed it using premake4 with:
premake4 --os=windows --with-demos vs2008

I built all of the Single precision projects since I built Ogre with single precision.

I checked that the demos worked, they do. So I can be sure Ode is functioning.

3. Do you have OGRE_HOME set in your Windows environment to you Ogre source root? If not, you will need to set OGRE_HOME in CMake so that it can link the libraries and reference the headers properly.

I have OGRE_HOME set to "C:\ogre svn\branches\v1-7\VCBuild\sdk" but when you say "Ogre source root", that makes me think perhaps it should be "C:\ogre svn\branches\v1-7\OgreMain", or perhaps "C:\ogre svn\branches\v1-7\OgreMain\src"?

4. Do you have the Ogre Dependencies and build directories set in CMake? Typically, many people have these inside of the Ogre source root. To build the demos, you will need OIS from the dependencies package. If you've already built Ogre, it's most likely you already do. If your Ogre build directory is in a different location, you will need to specify the location by setting OGRE_BUILD in CMake to that path.

CMake is not asking for OGRE_HOME or OGRE_BUILD even though it was doing so a couple weeks ago when I last went through this process. Last time, CMake seemed happy when I set OGRE_BUILD to the same directory as OGRE_HOME. I.e. "C:\ogre svn\branches\v1-7\VCBuild\sdk". Should I just be manually specifying these variables? And yes, I have the Dependencies at "C:\ogre svn\branches\v1-7\Dependencies", though I don't know what the variable is I should be specifying to point to this. OGRE_DEPENDENCIES?

I think this is my main problem. I am not particularly experienced with the conventions of build procedures for C++. I am unsure what to specify as the locations for OGRE_BUILD, how this compares to OGRE_HOME, and generally what the conventions are for X_ROOT, X_SOURCE, X_SRC etc. Specifically, what should ODE_SOURCE point to? Here are the few I have tried:

C:\Program Files\ode\ode-0.11.1
C:\Program Files\ode\ode-0.11.1\ode
C:\Program Files\ode\ode-0.11.1\ode\src
C:\Program Files\ode\ode-0.11.1\include
C:\Program Files\ode\ode-0.11.1\include\ode

No matter which of these I use for ODE_SOURCE and after placing all of the Ode .cpp and .h files in "C:\ogreaddons svn\trunk\ogreode\ode" I get the same error from CMake - it cant find Ode.

Thanks very much again for your help.

I managed to build OgreOde and got the demos working.

I am still sure I have done something terribly wrong somewhere as I had to do a lot of manual tweaking to get it to work. But I hope this helps others who may be in the same situation. In particular, it seems very strange that I had to point CMake to the Ode DLL files to make it happy, only to later reconfigure each project to use the LIB files instead.

Here is how I managed to build OgreOde with CMake and Visual Studio 2008 for Ogre 1.7 built with Boost threads:

Build Ogre 1.7 and Ode 0.11.1 and Boost from source with the resulting “root” directories: Ogre at “C:\ogre svn\branches\v1-7\VCBuild\sdk”, Ode at “C:\Program Files\ode\ode-0.11.1” and Boost at “C:\Program Files\Boost\boost_1_42_0”

Set the following environment variables in Windows:
OGRE_HOME to “C:\ogre svn\branches\v1-7\VCBuild\sdk”, ODE_SOURCE to “C:\Program Files\ode\ode-0.11.1” and BOOST_ROOT to “C:\Program Files\Boost\boost_1_42_0”.

Check out OgreOde from the OgreAddons SVN to “C:\ogreaddons svn\trunk\ogreode”.

Run CMake and specify the source code location: “C:/ogreaddons svn/trunk/ogreode” and build location: “C:/ogreaddons svn/trunk/ogreode/VCBuild”.

Manually specify:
ODE_INCLUDE_DIR “C:/Program Files/ode/ode-0.11.1/include”
ODE_LIBRARY_DBG “C:/Program Files/ode/ode-0.11.1/DebugSingleDLL/ode_single.dll”
ODE_LIBRARY_REL “C:/Program Files/ode/ode-0.11.1/ReleaseSingleDLL/ode_single.dll”
ODE_SOURCE “C:/Program Files/ode/ode-0.11.1/ode/src”

Click Configure then manually specify:
OGRE_HOME “C:/ogre svn/branches/v1-7/VCBuild/sdk”
OGRE_BUILD “C:/ogre svn/branches/v1-7/VCBuild/sdk”

Select the tick box for OGREODE_DIST

Open “C:\ogreaddons svn\trunk\ogreode\VCBuild\OgreOde.sln”

For both the Release and Debug configurations of each the projects OgreOde_Core, OgreOde_Loader, OgreOde_Prefab, Demo_GrandTurismOgre, Demo_Landscape and Demo_SimpleScenes:

add $(BOOST_ROOT) to C/C++ / Additional Include Directories

add $(ODE_HOME)\include to C/C++ / Additional Include Directories

and change “C:\Program Files\ode\ode-0.11.1\lib\DebugSingleDLL\ode_singled.dll” to “C:\Program Files\ode\ode-0.11.1\lib\DebugSingleLIB\ode_singled.lib” or “C:\Program Files\ode\ode-0.11.1\lib\ReleaseSingleDLL\ode_singled.dll” to “C:\Program Files\ode\ode-0.11.1\lib\DebugSingleLIB\ode_singled.lib” under Linker / Additional Dependencies

Build the ALL_BUILD project for both the Release and Debug configurations.

Build the INSTALL project for both the Release and Debug configurations.

Please pick holes in my process, I’d like to know how this should actually be done!

@Pryo

Glad you got it working. Here's a couple of notes that I hope will explain where the missteps were.

1. OGRE_HOME should point to the top directory of the Ogre source. For example, it would be C:/OgreSDK, etc. if the installer was used. If you're using a source package, it would be the directory that contains the "OgreMain" directory.

2. OGRE_BUILD is simply the directory that contains the "lib" directory where the built Ogre libraries can be found. If you use CMake to build Ogre, then the directory that is specified in CMake for "Where to build the binaries:" is OGRE_BUILD. If you are using the Ogre SDK installer, then OGRE_BUILD and OGRE_HOME are the same directory because the "lib" folder can be found in there, as well.

3. Boost is not compiled with OgreOde. You only need those variables set when you're building Ogre with Boost threads. OgreOde is not affected by it.

4. add $(BOOST_ROOT) to C/C++ / Additional Include Directories
add $(ODE_HOME)\include to C/C++ / Additional Include Directories
You don't need to change any of your MSVC options (and you normally wouldn't want to, because these become global and the includes could potentially be pulled into any project that includes a file with a name of a header stored in one of those directories). CMake does this for you, by adding the proper includes directories to the specific project file.

5. You don't need to add ODE_SOURCE to the Windows environment, just to the CMake environment if the ODE package was not extracted to /OgreOde/ode/. In your case, it would be "C:\Program Files\ode\ode-0.11.1". You also don't need to build ODE with the demos unless you want to.

6. I'm not sure why the DLL files were picked up instead of the lib files. If the .lib files are there, it should have found them normally. Either way, I would recommend performing any modifications to the link libraries in CMake instead of MSVC. That way, they are stored in the cache and won't be changed automatically if you run CMake again.

7. You don't want to do this:
No matter which of these I use for ODE_SOURCE and after placing all of the Ode .cpp and .h files in "C:\ogreaddons svn\trunk\ogreode\ode" I get the same error from CMake - it cant find Ode.
ALL the files from "C:\Program Files\ode\ode-0.11.1" need to be placed here. CMake, when it searches for ODE, expects the standard directory structure as it is in the ODE package when searching for files and file paths. It will not find them if you manually drop the source files in that location. Also, that would be too much of a pain to ask people to do.

8. To see all the environment variables in CMake, you need to select "Advanced View" from the drop-down box in the GUI. That will give you a list of ALL the variables in the CMake environment that are being set, instead of just the basic user options. You can see ODE_SOURCE, OGRE_HOME, OGRE_BUILD, etc. before you generate the project files and edit their values if they are incorrect.

It's probably worthwhile to delete your CMake cache (under File->Delete Cache in the CMake GUI), remove the unnecessary Windows and MSVC environment variables that I mentioned, and run "Configure" again and then regenerate the project files. This will save you some headaches in the future should changes be made to OgreOde that affect the CMake configuration. Hope this helps.

Bludo

@dermont

I have made quite a few updates to the install configuration in CMake for all platforms. I'm quite certain the directories the installation is made to are not correct for Linux yet. It's still going to dump the majority of the files (except for Media and include) to the bin directory. But I did add the rpath property for the demos and it's now using the CMAKE_INSTALL_PREFIX instead of OGREODE_BUILD as the installation path prefix. There's also now a CMake user option to install the Ogre runtime libraries to the OgreOde runtime directory so it doesn't do it automatically. Please check it out when you get a chance and let me know where I should make corrections.

Bludo

The NSIS build scripts have been updated and the installer can now be built successfully and appears to be working properly. For anyone who would like to test it out, please post your comments on the results. Thanks.

Bludo

@dermont

I have made quite a few updates to the install configuration in CMake for all platforms. I'm quite certain the directories the installation is made to are not correct for Linux yet. It's still going to dump the majority of the files (except for Media and include) to the bin directory. But I did add the rpath property for the demos and it's now using the CMAKE_INSTALL_PREFIX instead of OGREODE_BUILD as the installation path prefix. There's also now a CMake user option to install the Ogre runtime libraries to the OgreOde runtime directory so it doesn't do it automatically. Please check it out when you get a chance and let me know where I should make corrections.

Bludo

On Linux the Ogre libraries should not be copied to the OgreOde runtime directory even if the user option is set.

There are a few problems, see attached patch. You should review and see what applies to your current revision.

1. removed soversion.
   http://ogre.svn.sourceforge.net/viewvc/ ... t?view=log[/*:m]
   
2. removed copying across the pc.in template files.[/*:m]
   
3. added plugins(_d)/resources(_d).in template files and automatically parse plugin/resource locations[/*:m]
   
4. copy across generated plugins.cfg/resources.cfg to <build_dir>/inst/bin/release/debug as Ogre does, not strictly necessary but easier to install the cfg files.[/*:m]
   
5. updated pkg-config pc.in template files for debug build.[/*:m]
   
6. removed rpath from demos, already set in OgreOdeUtils.[/*:m]
   
7. updated CMake file to read correct OgreBuildSettings.h file.[/*:m][/list:u]
   
   TODO:
   
   
   1. resolve problem with rpath and building against Ogre installed in non-standard location.
      [/*:m]
      
   2. update where the binaries and run-time config files are installed. On Linux if installed in a standard location (/usr/local/bin) the demos require administration rights to run when creating Ogre.log/Ogre.cfg etc.
      Ogre 1.7 has recently been updated to output these files to ~/.ogre/Cthugha. This would require changes to OgreOde code (see Ogre1.7 svn).
      [/*:m]
      
   3. for installation update resources.cfg file to point to media copied across to install directory( currently points to OGRE_HOME/Samples and ogreode source /demos/Media, which is fine for the build directory). [/*:m][/list:u]

@dermont

I reviewed the patch and committed the changes. Everything looks good.

resolve problem with rpath and building against Ogre installed in non-standard location.
I'm a little confused with this one. Shouldn't the RPATH location be automatically set to the directory that the runtime libraries are linked from? The install location can essentially be treated as a derivative of OGRE_BUILD and a variable set to the Ogre install location set to the non-standard path. CMake should treat it similarly.

update where the binaries and run-time config files are installed. On Linux if installed in a standard location (/usr/local/bin) the demos require administration rights to run when creating Ogre.log/Ogre.cfg etc.
I was under the impression that those files were handled by OgreMain. Admittedly, I'm not completely sure, but I had figured that the Ogre runtime handled the .cfg and .log updates. I will dig around and see what I can find.

for installation update resources.cfg file to point to media copied across to install directory( currently points to OGRE_HOME/Samples and ogreode source /demos/Media, which is fine for the build directory).
I'm not sure how this is handled for Linux using the .in files, but the resources.cfg should point to the copied media folder already.

Bludo

I'm a little confused with this one. Shouldn't the RPATH location be automatically set to the directory that the runtime libraries are linked from? The install location can essentially be treated as a derivative of OGRE_BUILD and a variable set to the Ogre install location set to the non-standard path. CMake should treat it similarly.

I've fixed this hopefully.

I was under the impression that those files were handled by OgreMain. Admittedly, I'm not completely sure, but I had figured that the Ogre runtime handled the .cfg and .log updates. I will dig around and see what I can find.

You require admin rights to write the log file/ogre.cfg file to /usr/local/bin, hence you need admin rights to run the demo, which you shouldn't be doing.

for installation update resources.cfg file to point to media copied across to install directory( currently points to OGRE_HOME/Samples and ogreode source /demos/Media, which is fine for the build directory).
I'm not sure how this is handled for Linux using the .in files, but the resources.cfg should point to the copied media folder already.

The .in files is a more generic approach and should work for all platforms. For example when building Ogre1.7 with CMake the user can disable plugins to be built.

You require admin rights to write the log file/ogre.cfg file to /usr/local/bin, hence you need admin rights to run the demo, which you shouldn't be doing.

Understood - but what I'm saying is aren't the ogre.cfg/.log files handled by OgreMain? I'm assuming when the OgreMain runtime is loaded (with the alternate folder to drop those files) by the demos, the OgreMain library will decide where they go, not the demos or OgreOde themselves.

Bludo

You require admin rights to write the log file/ogre.cfg file to /usr/local/bin, hence you need admin rights to run the demo, which you shouldn't be doing.

Understood - but what I'm saying is aren't the ogre.cfg/.log files handled by OgreMain? I'm assuming when the OgreMain runtime is loaded (with the alternate folder to drop those files) by the demos, the OgreMain library will decide where they go, not the demos or OgreOde themselves.

Bludo

AFAIK the ogre.cfg/.log are created by default in the same directory as the demo unless you specify differently when creating Ogre Root. The SampleBrowser I think creates these files in ~/.ogre/Cthugha to overcome this problem, you should check with the developers.

for installation update resources.cfg file to point to media copied across to install directory( currently points to OGRE_HOME/Samples and ogreode source /demos/Media, which is fine for the build directory).
I'm not sure how this is handled for Linux using the .in files, but the resources.cfg should point to the copied media folder already.

Bludo
The problem with the resources.cfg is easily resolved, if you let me know what the installation media directory should look like I'll post the update. The media directory layout here is:


share/OgreOde
- fonts
- materials
- models
- particle
- Media (ogrode files)
-packs (OgreCore.zip)


Any reason this all shouldn't be under one Media directory?

Any reason this all shouldn't be under one Media directory?

This was a bug. I went ahead and corrected the media install location in the root CMake list. It should be okay now.

Bludo

Hi, thanks again Bludo. I will try your suggestions later and go through the process from the beginning. Though for the time being I'll just explain in more detail why I did what I did in case it helps highlight some pitfalls others may encounter.
1. OGRE_HOME should point to the top directory of the Ogre source. For example, it would be C:/OgreSDK, etc. if the installer was used. If you're using a source package, it would be the directory that contains the "OgreMain" directory.
I am compiling 1.7. As far as I am aware, there is no installer available for 1.7 yet. I was advised on the Ogre forums to use "C:\ogre svn\branches\v1-7\VCBuild\sdk" for OGRE_HOME after building Ogre from source. Following your suggestion though, it seems it should actually be "C:\ogre svn\branches\v1-7".
2. OGRE_BUILD is simply the directory that contains the "lib" directory where the built Ogre libraries can be found. If you use CMake to build Ogre, then the directory that is specified in CMake for "Where to build the binaries:" is OGRE_BUILD. If you are using the Ogre SDK installer, then OGRE_BUILD and OGRE_HOME are the same directory because the "lib" folder can be found in there, as well.
In my case, OGRE_BUILD should then be "C:\ogre svn\branches\v1-7\VCBuild".
3. Boost is not compiled with OgreOde. You only need those variables set when you're building Ogre with Boost threads. OgreOde is not affected by it.
I have Ogre compiled with Boost threads. Though while trying to build OgreOde, I got compiler errors complaining that it couldn't find some Boost includes. This is the only reason I added Boost folder to the include paths. I wouldn't have expected that they should have anything to do with building OgreOde either.
4. add $(BOOST_ROOT) to C/C++ / Additional Include Directories
add $(ODE_HOME)\include to C/C++ / Additional Include Directories
You don't need to change any of your MSVC options (and you normally wouldn't want to, because these become global and the includes could potentially be pulled into any project that includes a file with a name of a header stored in one of those directories). CMake does this for you, by adding the proper includes directories to the specific project file.
Well again, I added the Ode include directory because I got compile errors about Ode related include files not being found.
5. You don't need to add ODE_SOURCE to the Windows environment, just to the CMake environment if the ODE package was not extracted to /OgreOde/ode/. In your case, it would be "C:\Program Files\ode\ode-0.11.1". You also don't need to build ODE with the demos unless you want to.
Yeah the demos are optional. I've built demos as a rule though, so I can know for sure which components are working and which are not. I'd strongly recommend others do the same if they're trying to upgrade a chain of applications as I am doing. I tried to wing it and ended up spending 2 weeks just trying to get Ogre 1.7, Ode, Boost, OgreOde and my own application working.

I added ODE_SOURCE as a Windows environment variable mainly because to save typing, but also because I saw this mentioned on an Ode forum as being a variable that should be set after installing Ode in much the same way that we should set OGRE_HOME after installing Ogre.
6. I'm not sure why the DLL files were picked up instead of the lib files. If the .lib files are there, it should have found them normally. Either way, I would recommend performing any modifications to the link libraries in CMake instead of MSVC. That way, they are stored in the cache and won't be changed automatically if you run CMake again.
CMake didn't actually "pick up" anything. I had to manually specify everything. Though the Configure process would break when I tried to specify the .lib files. I.e. it would clear the paths I had entered and say something like "ODE_LIBRARY_NOT_FOUND". It was only when I entered the path to the .dlls that it accepted the input and allowed me to Generate. I really struggled with CMake. As I explained in a previous post, I went through lists of paths for each configuration option until I found something that worked.
7. You don't want to do this:
No matter which of these I use for ODE_SOURCE and after placing all of the Ode .cpp and .h files in "C:\ogreaddons svn\trunk\ogreode\ode" I get the same error from CMake - it cant find Ode.
ALL the files from "C:\Program Files\ode\ode-0.11.1" need to be placed here. CMake, when it searches for ODE, expects the standard directory structure as it is in the ODE package when searching for files and file paths. It will not find them if you manually drop the source files in that location. Also, that would be too much of a pain to ask people to do.
Thanks, I can see that's a major pitfall where I went wrong. I was given the suggestion earlier to put the "ode source files" in that folder. I think I took that too literally.

Thanks for all the rest of your advice, particularly about how to clear the CMake cache.

Hi, I´m new to Ogre and I really need some help to compile OgreODE, using this guide(WIKI GUIDE) i´ve got some errors, This is what I do and what i get.


First:

I´m using:

- Ogre 1.7.1 SDK(Running perfect but without any physic and I really need it one)

- ODE 0.11.1 (Got it from here ODE 0.11.1.zip 2.9 mb)

- OgreODE (Cloned with Tortoise from OgreAddons) This is the link OgreODE Revision 2914

- Microsoft Visual Studio 2008


What I did.

First using "premake4 vs2008" in my ODE/Build directory i generate (ode.sln and ode.vcproj)

Then I opened it in Mi VS2008 and compile (DebugSingleDLL and ReleaseSingleDLL without any Compiler Warning)

and

(DebugSingleLib and ReleaseSingleLib with the following warning)

1>OPC_Picking.obj : warning LNK4221: no se encontraron símbolos públicos; el miembro de archivo será inaccesible
1>OPC_Common.obj : warning LNK4221: no se encontraron símbolos públicos; el miembro de archivo será inaccesible
1>odetls.obj : warning LNK4221: no se encontraron símbolos públicos; el miembro de archivo será inaccesible
1>collision_trimesh_gimpact.obj : warning LNK4221: no se encontraron símbolos públicos; el miembro de archivo será inaccesible

Well at this point I have my C:\ode\build\vs2008\obj with two folders (DebugSingleDLL and ReleaseSingleDLL) both of them full of .obj files.

My OgreOde Folder was in c:\ogreode

So the next step was to copy my entire ode folder(c:\ode) to my Ogreode folder(c:\ogreode), I said yes to windows prompt to overwrite ode folder.

Then i opened CMAKE (GUI version)

The "Where is the source code: " was set to my "ogreode" directory ***** c:\ogreode

and my "Where to build yhe binaries" in "ogreode\build" directory ****** c:\ogreode\build

Then in configure buttom I choose as my generator of the project Visual Studio 9 2008(The radio button checked was USE THE NATIVE COMPILER) and then BOOOMMM

This is was my errors in cmake

Check for working CXX compiler using: Visual Studio 9 2008
Check for working CXX compiler using: Visual Studio 9 2008 -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Looking for ODE...
ODE_PREFIX_PATH changed.
checking for module 'ode'
package 'ode' not found
Could not locate ODE
CMake Error at CMake/FindPkgMacros.cmake:112 (message):
Required library ODE not found! Install the library (including dev
packages) and try again. If the library is already installed, set the
missing variables manually in cmake.
Call Stack (most recent call first):
CMake/FindODE.cmake:69 (findpkg_finish)
CMakeLists.txt:40 (FIND_PACKAGE)


Configuring incomplete, errors occurred!


And the following variables NOT FOUND so I manually specified

ODE_INCLUDE_DIR // manually set to "C:/ogreode/include"
ODE_LIBRARY_DBG // manually set to "C:/ogreode/lib/DebugSingleLib/ode_singled.lib"
ODE_LIBRARY_REL // manually set to "C:/ogreode/lib/ReleaseSingleLib/ode_single.lib"
ODE_SOURCE // manually set to "C:/ogreode"
OGRE_BUILD // manually set to "C:/ogresdk"
OGRE_HOME // manually set to "C:/ogresdk"

and OGREODE_DIST checked

• 
  
  Then I clicked the generate buttom
  
  The CMAKE generated OgreOde.sld in "C:\ogreode\build\vs2008", it looks like this
  [attachment=1]ogreodevs2008.png[/attachment]
  According to Wiki Guide I need to especify in the compiler if I'm going to use (dSingle o dDouble) in my All_Build configuration so I added "dSingle" in:
  
  All_Build/Configuration properties/Compiler Events/Prebuild/CommandLine
  
  Everything seems fine, i run generate and Boom again
  
  1>c:\ogresdk\include\ogre\threading\OgreThreadHeadersBoost.h(29) : fatal error C1083: No se puede abrir el archivo incluir: 'boost/thread/tss.hpp': No such file or directory
  
  So i manually specified in my complier additional includes
  
  C:\ogresdk\boost_1_42
  
  Clicked generate again
  
  New Warnings and errors appears
  
  Some Warnigs (They are just simples warnigs but anyway i dont like warnings)
  
  2>..\..\..\Core\src\OgreOdeStepper.cpp(271) : warning C4244: 'inicializando' : conversión de 'double' a 'Ogre::Real'; posible pérdida de datos
2>..\..\..\Core\src\OgreOdeStepper.cpp(280) : warning C4244: '=' : conversión de 'Ogre::Real' a 'unsigned int'; posible pérdida de datos
  
  Andddddddddd the errors(in several parts)
  
  *1* LINK : fatal error LNK1104: no se puede abrir el archivo 'libboost_thread-vc90-mt-gd-1_42.lib'
  
  and
  
*2* LINK : fatal error LNK1104: no se puede abrir el archivo '..\..\lib\Debug\OgreOde_Core_d.lib'
  
  Then i manually added the path to libs in my ogresdk/boost folder in the compiler include libs
  
  C:\ogresdk\boost_1_42\lib
  
  I generated again everything with just one error.
  
  7>Ejecutando evento anterior a la compilación...
7>"dSINGLE" no se reconoce como un comando interno o externo,
7>programa o archivo por lotes ejecutable.
7>Project : error PRJ0019: Una herramienta devolvió un código de error de "Ejecutando evento anterior a la compilación..."
7>El registro de compilación se guardó en el "file://c:\ogreode\build\vs2008\ALL_BUILD.dir\Debug\BuildLog.htm"
7>ALL_BUILD - 1 errores, 0 advertencias
  
  So i removed dSingle in prebuild commandline(and.... generated again)
  
  This time the whole process compiled without any error(the same warnigs were show), but the linker said something like this in every project
  
  8>LINK : no se encontró C:\ogreode\build\vs2008\bin\Debug\Demo_GranTurismOgre.exe o no lo generó el último vínculo incremental; ejecutando vínculo completo
  
  Anyway i copied all the .exe and dll files from mu
  
  "ogreode\build\bin\Debug" TO "OgreSDK\bin\debug"
  
  and also the media in "ogreode\demos\Media" directly into "C:\OgreSDK\media".
  
  But when I run the demos i get this error windows..
  [attachment=0]error.png[/attachment]
  
  Any Help?????????????????????????????????

The bootstrap resource group is usually defined in the resource config file, make sure the group is being defined somewhere if not in the config file.

The bootstrap resource group is usually defined in the resource config file, make sure the group is being defined somewhere if not in the config file.

Thanks friend, I already added bootstrap to my resource config file...

The bootstrap resource group is usually defined in the resource config file, make sure the group is being defined somewhere if not in the config file.

Thanks friend, I already added bootstrap to my resource config file...

You probably need OgreCore.zip from 1.6.

wget http://ogre.svn.sourceforge.net/viewvc/ogre/branches/v1-6/Samples/Media/packs/OgreCore.zip


And in your resources.cfg file include OgreCore.zip and OgreOde's media dir, e.g.

[OgreOde]
FileSystem=/media/sda7/OGRE/ogre-addons-v1.8/ogreode_svn/demos/Media
[Bootstrap]
Zip=/media/sda7/OGRE/OgreCore.zip


Hi all, I use Ogre 1.7 and OgreOde on VC++2008. They are compiled and run fine. Except when I try to delete a geometry at the end I created earlier. The program throw me an exception without explanation.

Did anyone face the problem like that?

Find that error code on : OgreOdeMaintainedList.h

T* m = _map[id];

But what can I do to fix it?

When I tried to CMake out OgreOde .sln files, after I set all the dirs and libs then Cmake told me the following error:


CMake Error at CMakeLists.txt:45 (MESSAGE):
You need Ogre version 1.6 or 1.7 to build OgreOde.


the detail info:
[attachment=0]pic.jpg[/attachment]

does the latest version of OgreOde just match Ogre version 1.6 or 1.7? The SVN url of ogre I got from SVN 4 months ago was(now it's the same):
https://ogre.svn.sourceforge.net/svnroot/ogre/trunk , after I built the ogre, I found that Ogre was 1.8.0 unstable according to the docs built.

That's my problem, whether I only get the 1.7 version to resolve this problem or not?
Thanks.

OgreOde should build OK against 1.8, at least it did last time I built on Linux/autotools.

For Windows try updating the following in the main CMakeLists.txt to inckude a check for 1.8 - "Byatis"


IF (NOT (("${OGRE_VERSION_NAME}" STREQUAL "Cthugha") OR ("${OGRE_VERSION_NAME}" STREQUAL "Shoggoth")))
MESSAGE(SEND_ERROR "You need Ogre version 1.6 or 1.7 to build OgreOde.")
ENDIF()


@dermont,
thank you for help!

It worked well after I moidfied the main CMakeLists.txt in the folder of OgreOde by adding "Byatis" to check.

Hi, guys here, I have built Ode (D:\ODE) well and got OgreOde.sln by CMake using VS2005 generator, when I built OgreOde.sln I met the following same 8 errors :

Error 1 fatal error C1189: #error : You must #define dSINGLE or dDOUBLE D:\ODE\include\ode\common.h 102

then I did something like this:
To find configuration for ALL_BUILD->build events->prebuild->commandline , then added "dSINGLE" , I did this referring to: http://www.ogre3d.org/tikiwiki/Compile+OgreOde, strangely, I encountered the same 8 errors again and there came out another error:
Error 9 error PRJ0019: A tool returned an error code from "Performing Pre-Build Event..." ALL_BUILD

According to the guide, You should now be able to compile the "ALL_BUILD" project. Some of the projects will build perfectly, and for the others you will need to add "dSINGLE" to the preprocessor definitions. I did further as adding "dSINGLE" to the project OgreOde_Core, and then built, errors "You must #define dSINGLE or dDOUBLE" remained 8, and jumped one more error like "error PRJ0019..........OgreOde_Core", it seemed nothing worked and caused more errors, I have no idea how to fix it up now..

Could you please explain why? and whether the guide of http://www.ogre3d.org/tikiwiki/Compile+OgreOde is incorrect or I did in an incorrect way?

Btw, How to post a picture here via "Img" while editing the post?

Thank you.

Hi, guys here, How to know your precision of Ogre built? As dermont said:
For Windows if it isn't defined in a config file then I guess a reasonable solution would be to parse the OGRE_DOUBLE_PRECISION define from OgreBuildSettings.h and set initial values dSINGLE/dDOUBLE / link against ode_single/double based on the value of OGRE_DOUBLE_PRECISION.
I find that in my built OgreBuildSettings.h:
#define OGRE_DOUBLE_PRECISION 0
Then whether my Ogre was built under the precision of dDOUBLE or not? if positive, thus, should I need to build my Ode/OgreOde under the same dDOUBLE precision?
Benjamin.

I thought that my ogre was built under the precision as described in the latest post I made, so I tried to Cmake out OgreOde.sln under the double precision by using all ode_doubled.lib,then I got the messages when CMaking:
CMake Error at CMakeLists.txt:62 (MESSAGE):
Floating point precision inconsistent between Ogre and ODE. Ogre, ODE, and
OgreOde must all use the same precision or runtime will fail.

This makes it clear that generic Ogre is under the dSINGLE precision and deservedly as follow :#define OGRE_DOUBLE_PRECISION 0

Is my thought right?
Benjamin.

For your case CMake should automatically define dSINGLE for the OgreOde_Core project :
Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions

This is my Preprocessor Definitions for VS2008.

WIN32,_WINDOWS,NDEBUG,OGREODE_EXPORTS,dSINGLE,CMAKE_INTDIR=\"Release\",OgreOde_Core_EXPORTS


What version of ode are you building against?

Ok, I finished the compilation of OgreOde, thank you dermont and other guys who helped me, I'll make a conclusion to my process detailedly .
IDE: MSVS Team Suite 2005, Windows;
Ogre: Ogre1.8.0 unstable, got the source codes from SVN https://ogre.svn.sourceforge.net/svnroot/ogre/trunk
ODE: ode0.11.1, the latest one got from http://sourceforge.net/projects/opende/files/
OgreOde: got the source codes from SVN https://ogreaddons.svn.sourceforge.net/svnroot/ogreaddons/trunk/ogreode/

0. Get ode.sln(VS2005 ) and compile ODE:
0. Windows Start -> Run -> cmd
command: cd ODE'sHOME-DIRECTORY-HERE\build //ODE'sHOME-DIRECTORY-HERE is the directory of ODE you decompress the files to;
command: premake4 vs2005 //Create VS2005 solution with Premake4 which is located in ODE'sHOME-DIRECTORY-HERE\build;
command: premake4 --help //not necessary,just for help;
command: premake4 --with-demos --with-tests vs2005 //not necessary,just for demo/test;

1. Open ode.sln in ODE'sHOME-DIRECTORY-HERE\build\vs2005;
You can build the solution under all the configurations listed in the Solution Configurations ComboBox, but what should recommend to you depends on the precision of your Ogre built before. I.e. I am using dSINGLE precision , and others might be the same generally, you can refer to the following codes came from the CMake information when I CMaDe out my OGRE.sln at the beginning:
Build type: dynamic
Threading support: none
Use double precision: disabled
Allocator type: nedmalloc (pooling)
Thus I compile Ode under the configurations of debugsingle.dll/.lib and releasesignle.dll/.lib;


1. Get OgreOde.sln(VS2005 ) and compile OgreOde:
0. Copy all the subfolders and files in ODE'sHOME-DIRECTORY-HERE (i.e. mine is D:\ODE) to the folder of OgreOde where you check out files from SVN(i.e. mine is D:\OGRE\OgreOde), and overwrite them all.

1. Name environment variables, maybe this step is not necessary. ODE_HOME(D:\ODE); ODE_SOURCE(D:\ODE); OGREODE_SOURCE(D:\OGRE\OgreOde);

2.CMake, source --> D:/OGRE/OgreOde ; where to -->D:/OGRE/OgreOdeSdk (another new folder);

3.Configure, you will meet the notification as I mentioned before, and you need to ascertain 3 groups of configuration manually:
3.0. ODE involved:
ODE_INCLUDE_DIR : D:/ODE/include/ode
ODE_LIBRARY_DBG: D:/ODE/lib/debugsinglelib/ode_singled.lib
ODE_LIBRARY_REL: D:/ODE/lib/releasesinglelib/ode_single.lib
ODE_SOURCE: D:/ODE
3.1. OGRE involved:
OGRE_HOME: D:/OGRE/OGRE_SDK_1.8 //Shoue be D:/OGRE/OGRE_SRC_1.8 where places the source codes got from SVN, but it didn't work.
OGRE_BUILD: D:/OGRE/OGRE_SDK_1.8
3.2. OIS involved:
OIS_INCLUDE_DIR: D:/OGRE/OGRE_SDK_1.8/include/OIS //maybe others are different from mine.
OIS_LIBRARY_DBG: D:/OGRE/OGRE_SDK_1.8/Dependencies/lib/Debug/OIS_d.lib
OIS_LIBRARY_REL: D:/OGRE/OGRE_SDK_1.8/Dependencies/lib/Release/OIS.lib

4.Select OGREODE_DIST and INSTALL_OGRE_RUNTIME (Maybe unnecessary);

5.Since the version of my Ogre is 1.8.0(Byatis), I have to modify the main CMakeLists.txt in D:\OGRE\OgreOde like this:
IF (NOT (("${OGRE_VERSION_NAME}" STREQUAL "Cthugha") OR ("${OGRE_VERSION_NAME}" STREQUAL "Shoggoth") OR ("${OGRE_VERSION_NAME}" STREQUAL "Byatis") ))
MESSAGE(SEND_ERROR "You need Ogre version 1.6 or 1.7 to build OgreOde.")
ENDIF()

6.You may configure twice or triply to fix the issues listed above, and then Generate;

7.Open OgreOde.sln where you CMake to (D:\OGRE\OgreOdeSdk), and you have to set as follow then can compile well:
Debug/release respectively, add dSINGLE to the following projects:
Demo_GranTurismOgre
Demo_Landscape
Demo_SimpleScenes
OgreOde_Core (It's done when CMake's done)
OgreOde_Loader
OgreOde_Prefab
To do that via Project -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions.

8. Compile ALL_BUILD. ..Done.

Maybe there are some details that need to be corrected and improved probably during my process, please notify me and post here, Appreciations.
Benjamin.

hi all, I eventually set up Ogre 1.7.1 and Ode 0.11.1 with vs2008. but when i run Demo_GranTurismOgre.exe i get this window:

An exception has occurred: OGRE EXCEPTION(7:InternalErrorException): ../../media/packs/SdkTrays.zip - error whilst opening archive: Unable to read zip file. in ZipArchive::checkZzipError at ..\..\..\..\OgreMain\src\OgreZip.cpp (line 280)

i am lost and need your help!
thanks!

I use OgreODE Revision 2978 (Cloned with Tortoise from OgreAddons) from:

https://ogreaddons.svn.sourceforge.net/ ... k/ogreode/

Thanks all who contributed on this thread, and I finally make my OgreOde runs (ode 0.11 + Ogre 1.7.2 SDK + OgreOde r2978 with VS2008).
After some efforts, I make the demo run. At least I can see the Ogre configuration window pops out, but the demo program crashes with the error:
OGRE EXCEPTION(3:RenderingAPIException): Failed to DrawPrimitive : Invalid call in D3D9RenderSystem::_render at ..\..\..\ogre_src\RenderSystems\Direct3D9\src\OgreD3D9RenderSystem.cpp (line 3116)

DirectX9 crashes, but OpenGL works.
After I dig in for a while, I figure out what goes wrong. The hard crash just happens right after adding a mesh.
Mesh: Loading ball.mesh.
WARNING: ball.mesh is an older format ([MeshSerializer_v1.30]); you should upgrade it as soon as possible using the OgreMeshUpgrade tool

I also found this thread that talked about this issue
http://89.151.96.106/forums/viewtopic.php?f=4&t=56961&start=0

Solution: just use OgreMeshUpgrade.exe and that's it
This is actually irrelevant to OgreOde, but it's just because the mesh files come with the demo programs are too old. Perhaps we should also update the mesh files in SVN?

Edit:
The zombie still cause Ogre crash with the same error message even after the mesh upgrade. I suspect there's something wrong with the zombie.material, but I have no idea how to debug it
23:01:19: Parsing script zombie.material
23:01:19: Compiler error: reference to a non existing object in zombie.material(9)
23:01:19: Compiler error: reference to a non existing object in zombie.material(21)

i dont know if the zombiedemo is functional yet, as it wont work on my machine... but my machine behaves very strange anyways