Ogre Procedural [v0.2 officially out]

Mikachu · Post by **Mikachu** » Tue Sep 18, 2012 10:10 am

Falarys wrote:When looking at the attached screenshot, you can see that the shading of top is alright.
But the extruded part seems to merge the normals of vertices at the same position so that edges disappear.
Any clues what I might do wrong?

I don't think you're doing anything wrong.
Actually, the normals of each vertex is an average between the normals of the adjacent segments.
This is an usual technique to have "smooth borders", but I think that what you want is to have almost "flat shading", ie normals perpendicular to the triangle.
The first workaround that comes to my mind would be to use a RoundedCornerSpline2 instead of Shape, with a low radius, and a low numSeg (could be respectively 0.0 and 1, increase these if you want more smoothness).

.. or I could also create a new function for TriangleBuffer that would recalculate normals.

Falarys · Post by **Falarys** » Tue Sep 18, 2012 12:26 pm

Thanks for your fast reply!
Tried the workaround with RoundedCornerSpline2 and it works quite well

Big thanks!

Klaim · Post by **Klaim** » Tue Sep 18, 2012 2:15 pm

Hi, i finally am integrating Ogre Procedural in my game project but I'm having some trouble making CMake works correctly.
I'm using Ogre 1.8.1, Ogre Procedural last change (6f73c9326921)
My setup looks like this:

my_game/dependencies/ogre
my_game/dependencies/ogre_dependencies
my_game/dependencies/ogre_procedural

These directories contain sources only of the projects.
In the CMakeList.txt file hat is in my_game, I just call add_subdirectory( dependencies) and in dependencies I do the same for ogre projects, in the following order:
ogre dependencies, then ogre, then ogre procedural. Before each add_subdirectory() call I set some options for my project.
Ogre Procedural requires that the variable OGRE_HOME have been set to Ogre SDK directory.
However, is it supposed to work if I set OGRE_HOME to my folder containing Ogre sources?

It don't looks like it works. I get this error:

Code: Select all

Looking for OGRE...
Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE) 
Could not locate OGRE
CMake Error at dependencies/ogre_procedural/CMake/Utils/FindPkgMacros.cmake:117 (message):
  Required library OGRE 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):
  dependencies/ogre_procedural/CMake/Packages/FindOGRE.cmake:215 (findpkg_finish)
  dependencies/ogre_procedural/CMakeLists.txt:31 (find_package)

It seems that the FindOgre script don't work in my case?

Any idea how to fix this? I've been reading the FindOgre script but it don't look like it's looking for the data generated by the Ogre CMake script...

Klaim · Post by **Klaim** » Tue Sep 18, 2012 2:52 pm

So I figured that in my case it should not even be necessary to call FindPackage( Ogre) as it will anyway look for the SDK but never the sources (which appears not very useful to me...).

I did a quick fix that is not correct because it should check for some Ogre variables to be set, but it seems to work for me.
In Ogre Procedural root CMake file I just replaced

Code: Select all

find_package(OGRE REQUIRED)

by

Code: Select all

if( NOT DEFINED OGRE_HOME )
	find_package(OGRE REQUIRED)
endif()

Which as I said is not enough checks but should work for cases like mine. Maybe adding checks to basic Ogre CMake file definitions should be enough.

However, I now hit another more difficult problem which is all include directive using "OGRE/" prefix to ogre files. It would be fine to me if it was how the source directory is organized, but it is not. I just checked with with Ogre 1.9 branch and it isn't organized like that too. I never use the SDK so I suppose it's only with the SDK that it works like that.
Anyway these include directive makes it apparently impossible to use Ogre sources with Ogre Procedural.

Or am I missing something?
Any suggestions?

One solution to this problem for me would be to just take the OgreProcedural code and put it in my project but it will become a maintenance nightmare so I'd like to have a simple to install library instead...

Falarys · Post by **Falarys** » Tue Sep 18, 2012 3:10 pm

I hate to be annoying, but I just encountered another interesting behaviour of the normals I guess.
I changed my material shading mode to flat and as you can see in the screenshot the extruded object has a strange shading. In this scene I have a single directional light.
Do you know any way to come around this? Or might this be a lighting issue of the scene?

Many thanks in advance!

screenshot_3.jpg

Klaim · Post by **Klaim** » Tue Sep 18, 2012 4:27 pm

Following of my last post: I replaced all "OGRE/Ogre*.h" to "Ogre*.h" but it fails because the include directory of Ogre(Main) was not set for the project.

After searching why, I found that includes rely on OGRE_INCLUDE_DIRS variable, which I believe is not generated by Ogre source Cmake scripts... But is certainly generated by FindOgre script.

Maybe I'm wrong on doing it this way, but I'm getting the feeling again that CMake makes this harder than it should...

Edit> By the way, I don't understand why OIS is a dependency of OgreProcedural library itself, not only tests?

Edit2> I fixed my compilation problems by providing OGRE_INCLUDE_DIRS and OGRE_LIBRARIES myself.

Also, I found that there is no mention to OIS in OgreProcedural code (at least searching using vs source search don't reveal anything.
So I think it would be good to remove OIS as dependency of the library part.

Mikachu · Post by **Mikachu** » Tue Sep 18, 2012 6:00 pm

@Klaim : I never tried using a setup like this (linking directly to Ogre Sources) and I'm not sure that Ogre was thought to be used this way.

Even when using Ogre from source, I generally first call INSTALL target from the Ogre project, and then I set OGRE_HOME as the 'sdk' subfolder where Ogre is installed.

In the sdk directory layout, you have "sdk/include/OGRE/<ogre headers..>", and the FindOgre cmake script is adding the "include' directory to OGRE_INCLUDE_DIRS.

The library itself sould not depend on OIS, so I'm filing it as a bug.

Klaim · Post by **Klaim** » Tue Sep 18, 2012 6:18 pm

Mikachu wrote:@Klaim : I never tried using a setup like this (linking directly to Ogre Sources) and I'm not sure that Ogre was thought to be used this way.

Well it has always been recommended (by Sinbad and the Ogre team) for important developments using Ogre to use the source instead of the SDK, in particular when you work on cross-platform stuffs.
There are good reasons to this, like, if there is a problem in Ogre code, it is clear enough for you to make a quickfix. I'm in this kind of case where I need the source anyway, as a lot of other Ogre users actually.
Also, custom Ogre build require using the source code (like static build or changing the threading mode for example).

Mikachu wrote: Even when using Ogre from source, I generally first call INSTALL target from the Ogre project, and then I set OGRE_HOME as the 'sdk' subfolder where Ogre is installed.

In the sdk directory layout, you have "sdk/include/OGRE/<ogre headers..>", and the FindOgre cmake script is adding the "include' directory to OGRE_INCLUDE_DIRS.

Can you explain how exactly you do this? (not a Cmake expert yet ;__; ) You call some kind of function into your project's CMake file to do the install or you have to call it from outside?
If you have to call it from outside, then I suppose it forces you to have a global Ogre install, right?
I can't do this because I need my project to use this specific Ogre version that is associated with it. So I need to just provide to OgreProcedural (or any Ogre addon) where the headers and library files are located for Ogre. I have other projects using other versions of Ogre, all modified at some point (so not just Ogre's version, but patched). Also I don't want to polute my environnement with anything other than general libraries like boost.

I think if OgreProcedural just take them if they are already provided, it would work better, as I did after my modifications.

However, what do you think about the OGRE/OgreBlah.h problem? It's not directly related as far as I understand. If only the SDK have this OGRE directory, then OgreProcedural should make sure source files don't force you to have this directory too. At least that's my current opinion. Shouldn't OGRE_INCLUDE_DIRS already provide directly the content of the OgreMain include directory with the SDK?

The library itself sould not depend on OIS, so I'm filing it as a bug.

Ok, next time I'll do this. I forgot about the issue tracker.

Mikachu · Post by **Mikachu** » Tue Sep 18, 2012 7:30 pm

Klaim wrote:Well it has always been recommended (by Sinbad and the Ogre team) for important developments using Ogre to use the source instead of the SDK, in particular when you work on cross-platform stuffs.
There are good reasons to this, like, if there is a problem in Ogre code, it is clear enough for you to make a quickfix. I'm in this kind of case where I need the source anyway, as a lot of other Ogre users actually.
Also, custom Ogre build require using the source code (like static build or changing the threading mode for example).

There's nothing wrong in building Ogre from source, it's just that I wouldn't include ogre sources in my own cmake project.
I'd rather build Ogre from source, then use the sdk I just built.

To build an Ogre SDK from source, first do the configure/generate in CMake-gui to create the VS solution.
Then open the VS solution and build the "INSTALL" project.
It will build all required projects (including OgreMain) and copy them in the "sdk" subfolder.

Klaim wrote:Can you explain how exactly you do this? (not a Cmake expert yet ;__; ) You call some kind of function into your project's CMake file to do the install or you have to call it from outside?
If you have to call it from outside, then I suppose it forces you to have a global Ogre install, right?
I can't do this because I need my project to use this specific Ogre version that is associated with it. So I need to just provide to OgreProcedural (or any Ogre addon) where the headers and library files are located for Ogre. I have other projects using other versions of Ogre, all modified at some point (so not just Ogre's version, but patched). Also I don't want to polute my environnement with anything other than general libraries like boost.

I also have several Ogre sdks in my computer, but that's not a problem.
With CMake gui, you can define variables with the "+" button. Just define OGRE_HOME to the Ogre SDK you want to use (that can be the sdk you just built).
The FindOgre script looks for OGRE_HOME in both system env vars and CMake vars, so you don't need to define a system wide OGRE_HOME.

Klaim · Post by **Klaim** » Tue Sep 18, 2012 7:49 pm

I understand how to add variables to CMake, I did say so before. What you describe, the install target, is ok sometime but no in my case.
My problem is that I can't use the SDK anyway, it's far simpler in my project to just generate CMake targets and use them in my own project's CMake targets. One of the reasons is that I want to see all the dependencies in the generate solution file. There are other advantages to this, but not everybody need this, obviously.

Ogre CMake does support both cases actually, as all my other dependencies that rely on CMake. I mean that if I have Ogre dependencies as compiled files, I just can set the right CMake variables and it will find it. If I use Ogre dependencies sources, I add it to CMake scripts and then Ogre and it will find them automatically.

I think the modifications required to Ogre Procedural to allow this setup are minimal and won't impact the SDK usage. I think I can provide a patch tomorrow which would work with both SDK and CMake-target style setup. It would be better for me (for future upgrade) if it is in the root directory though.
Let me do it and then you'll see if you like it? It might also clarify what I meant about the include directory, I think I was not clear.

Transporter · Post by **Transporter** » Tue Sep 18, 2012 7:51 pm

Klaim wrote:
Mikachu wrote:The library itself sould not depend on OIS, so I'm filing it as a bug.
Ok, next time I'll do this. I forgot about the issue tracker.

I think this "dependency" is not an ogreprocedural bug. OIS is linked to every application by OGRE, because it is a main dependency of OGRE.

Mikachu · Post by **Mikachu** » Tue Sep 18, 2012 8:23 pm

Klaim wrote:I think the modifications required to Ogre Procedural to allow this setup are minimal and won't impact the SDK usage. I think I can provide a patch tomorrow which would work with both SDK and CMake-target style setup. It would be better for me (for future upgrade) if it is in the root directory though.
Let me do it and then you'll see if you like it? It might also clarify what I meant about the include directory, I think I was not clear.

I changed the way I include OGRE headers after this request from the forums :

awishformore wrote:1) OGRE includes are direct instead of having the folder. I include all OGRE files like this:

#include <OGRE/OgreXxx.h>

As I use a lot of external libraries, that makes it easier to keep track of all includes and the structure of my project.

I easily solved this issue by adding OGRE/ to all the includes in your file; I think it would be following conventions more if you changed this, too.

Now I'm starting to wonder what to choose...
But FindOgre is looking for already built libs, so modifying the way headers are included doesn't solve the whole problem.. awaiting for your patch to see

Transporter wrote:I think this "dependency" is not an ogreprocedural bug. OIS is linked to every application by OGRE, because it is a main dependency of OGRE.

OIS is only a dependency in Ogre Samples, AFAIK.
I would just remove the dependency towards OIS in the core OgreProcedural library, which is not used anyway.

Klaim · Post by **Klaim** » Tue Sep 18, 2012 10:13 pm

Transporter wrote:
Klaim wrote:
Mikachu wrote:The library itself sould not depend on OIS, so I'm filing it as a bug.
Ok, next time I'll do this. I forgot about the issue tracker.
I think this "dependency" is not an ogreprocedural bug. OIS is linked to every application by OGRE, because it is a main dependency of OGRE.

Ogre itself and it's plugins don't need OIS, only the sample does. Ogre procedural don't need it either, but the sample does.

Klaim · Post by **Klaim** » Tue Sep 18, 2012 10:17 pm

Mikachu wrote:
Klaim wrote:I think the modifications required to Ogre Procedural to allow this setup are minimal and won't impact the SDK usage. I think I can provide a patch tomorrow which would work with both SDK and CMake-target style setup. It would be better for me (for future upgrade) if it is in the root directory though.
Let me do it and then you'll see if you like it? It might also clarify what I meant about the include directory, I think I was not clear.
I changed the way I include OGRE headers after this request from the forums :
awishformore wrote:1) OGRE includes are direct instead of having the folder. I include all OGRE files like this:

#include <OGRE/OgreXxx.h>

As I use a lot of external libraries, that makes it easier to keep track of all includes and the structure of my project.

I easily solved this issue by adding OGRE/ to all the includes in your file; I think it would be following conventions more if you changed this, too.
Now I'm starting to wonder what to choose...

I also prefer to use a directory like that for my dependencies, it's a bit a paint that ogre sources aren't organized like that. Same thing for Ogre plugins and other related stuffs, OIS included.
At least all these libraries use prefixes.

I would have prefered Ogre and it's plugins to just have an additional directory in the include directory, with the name of the library.

But FindOgre is looking for already built libs, so modifying the way headers are included doesn't solve the whole problem.. awaiting for your patch to see

I'll see what I can do yes.

dermont · Post by **dermont** » Wed Sep 19, 2012 2:58 am

Mikachu wrote:
Klaim wrote:I think the modifications required to Ogre Procedural to allow this setup are minimal and won't impact the SDK usage. I think I can provide a patch tomorrow which would work with both SDK and CMake-target style setup. It would be better for me (for future upgrade) if it is in the root directory though.
Let me do it and then you'll see if you like it? It might also clarify what I meant about the include directory, I think I was not clear.
I changed the way I include OGRE headers after this request from the forums :
awishformore wrote:1) OGRE includes are direct instead of having the folder. I include all OGRE files like this:

#include <OGRE/OgreXxx.h>

As I use a lot of external libraries, that makes it easier to keep track of all includes and the structure of my project.

I easily solved this issue by adding OGRE/ to all the includes in your file; I think it would be following conventions more if you changed this, too.
Now I'm starting to wonder what to choose...

If it were me I would remove the OGRE/. I was stung with this when creating the python bindings.

Mikachu wrote: But FindOgre is looking for already built libs, so modifying the way headers are included doesn't solve the whole problem.. awaiting for your patch to see

Since I'm on Linux I don't really need/use "FindOgre" so could be wrong but doesn't FindOgre already handle the scenario your are discussing by passing the source and build paths to CMake?

Code: Select all

cmake . -DOGRE_SOURCE:PATH=/home/dermont/Development/OGRE/src/v1-9 -DOGRE_BUILD:PATH=/home/dermont/Development/OGRE/build/v1-9

Other than using ExternalProjects I'm not sure how this would work in Klaim's case.

Klaim · Post by **Klaim** » Wed Sep 19, 2012 8:44 am

OGRE_SOURCE works perfectly for me, but I don't see in the FindOgre file of Ogre Procedural the part that is supposed to detect it. Maybe it's an old version?
I'll check.

Mikachu · Post by **Mikachu** » Wed Sep 19, 2012 8:58 am

Klaim wrote:OGRE_SOURCE works perfectly for me, but I don't see in the FindOgre file of Ogre Procedural the part that is supposed to detect it. Maybe it's an old version?
I'll check.

"OGRE_SOURCE" occurs 7 times in the FindOgre.cmake included in OgreProcedural.
It also occurs 7 times in the most up-to-date version.
But anyway, it's becoming old so I'll update it.

Klaim · Post by **Klaim** » Wed Sep 19, 2012 9:13 am

I should have missed it or it didn't follow the logic I assumed before reading it. I'll get back to this in few hours.

dermont · Post by **dermont** » Wed Sep 19, 2012 9:15 am

Klaim wrote:OGRE_SOURCE works perfectly for me, but I don't see in the FindOgre file of Ogre Procedural the part that is supposed to detect it. Maybe it's an old version?
I'll check.

It's in the current FindOgre.cmake. I've never built using OGRE_BUILD and OGRE_SOURCE before but it appears to to work for me.

<edit> Seems you have already found it, I should learn to type faster </edit>

Code: Select all

..
# If both OGRE_BUILD and OGRE_SOURCE are set, prepare to find Ogre in a build dir
set(OGRE_PREFIX_SOURCE ${OGRE_SOURCE} ${ENV_OGRE_SOURCE})
set(OGRE_PREFIX_BUILD ${OGRE_BUILD} ${ENV_OGRE_BUILD})
..

I'm not sure it will work in your set-up since it may need to find the Ogre library before it's been built(??). If that's the case you could try using ExternalProjects, the following may not be strictly correct since my CMake knowledge is limited and I prefer to use shell scripts on Linux.

Code: Select all

### CMakeLists.txt
### /v1.8
### /procedural-default
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.2)
INCLUDE(ExternalProject)
project(YOUR_PROJECT)

ExternalProject_Add(v1-8
                PREFIX "${CMAKE_CURRENT_BINARY_DIR}/build_v1-8"
                SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/v1-8"
                CMAKE_ARGS 
                    -DOGRE_BUILD_SAMPLES=FALSE 
                    -DOGRE_FULL_RPATH=TRUE 
                    -DOGRE_UNITY_BUILD=TRUE 
                    -DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/sdk
                "-DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/sdk"
                INSTALL_DIR "${CMAKE_CURRENT_BINARY_DIR}/sdk"
) 

ExternalProject_Add(procedural-default
                DEPENDS v1-8
                PREFIX "${CMAKE_CURRENT_BINARY_DIR}/build_procedural"
                SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/procedural-default"
                CMAKE_ARGS 
                    -DOGRE_SOURCE:PATH==${CMAKE_CURRENT_SOURCE_DIR}/v1-8
                    -DOGRE_BUILD:PATH=${CMAKE_CURRENT_BINARY_DIR}/build_v1-8
                    -DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/sdk 
                "-DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/sdk"
                INSTALL_DIR "${CMAKE_CURRENT_BINARY_DIR}/sdk"
)

If you are doing a local/build install you will need to remove the following from the main CMake file:
#install(FILES Packages/FindOgreProcedural.cmake DESTINATION ${CMAKE_ROOT}/Modules)

def87 · Post by **def87** » Wed Sep 19, 2012 4:42 pm

Have you considered using the freetype library to offer extruded 3d text meshes?
It should be pretty straight forward getting the splines from freetype and using Ogre Procedural to extrude...

FooxMusa · Post by **FooxMusa** » Wed Sep 19, 2012 5:07 pm

Seriously!

Mikachu · Post by **Mikachu** » Wed Sep 19, 2012 5:34 pm

def87 wrote:Have you considered using the freetype library to offer extruded 3d text meshes?
It should be pretty straight forward getting the splines from freetype and using Ogre Procedural to extrude...

Assaf Raman already created a libraryfor that.

Yet, I thought such a feature would be useful, so I've registered an issueto generate some kind of 3d text using freetype.
Didn't have time to implement it yet.

Now, I'm not sure whether freetype is optional library in Ogre, but if so, it should also be optional in OgreProcedural..

Klaim · Post by **Klaim** » Wed Sep 19, 2012 5:51 pm

I'm back on this right now, I couldn't before.

Mikachu wrote:
Klaim wrote:OGRE_SOURCE works perfectly for me, but I don't see in the FindOgre file of Ogre Procedural the part that is supposed to detect it. Maybe it's an old version?
I'll check.
"OGRE_SOURCE" occurs 7 times in the FindOgre.cmake included in OgreProcedural.
It also occurs 7 times in the most up-to-date version.
But anyway, it's becoming old so I'll update it.

My mistake comes from OGRE_SOURCE_DIR that is defined when Ogre CMake files are processed. OGRE_SOURCE isn't generated at this point. I compared the current Ogre 1.8.1 FindOgre script with the one used by Ogre Procedural, they are not different on that point (most changes are IOS related and refactoring of the component search code).

I'll try some things related to this before providing the patch.

Transporter · Post by **Transporter** » Wed Sep 19, 2012 5:55 pm

Mikachu wrote:Now, I'm not sure whether freetype is optional library in Ogre, but if so, it should also be optional in OgreProcedural..

See:

-- The following OPTIONAL packages could NOT be located on your system.
-- Consider installing them to enable more features from this software.
+ zlib: Simple data compression library <http://www.zlib.net>
+ freeimage: Support for commonly used graphics image formats <http://freeimage.sourceforge.net>
+ freetype: Portable font engine <http://www.freetype.org>
+ cg: C for graphics shader language <http://developer.nvidia.com/object/cg_toolkit.html>
+ boost: Boost (general) <http://boost.org>
+ boost-thread: Used for threading support <http://boost.org>
+ boost-date_time: Used for threading support <http://boost.org>
+ POCO: POCO framework <http://pocoproject.org/>
+ tbb: Threading Building Blocks <http://www.threadingbuildingblocks.org/>
+ GLSL Optimizer: GLSL Optimizer <http://github.com/aras-p/glsl-optimizer/>
+ HLSL2GLSL: HLSL2GLSL <http://hlsl2glslfork.googlecode.com/>
+ OIS: Input library needed for the samples <http://sourceforge.net/projects/wgois>
+ Doxygen: Tool for building API documentation <http://doxygen.org>
+ Softimage: Softimage SDK needed for building XSIExporter <FALSE>
+ CppUnit: Library for performing unit tests <http://cppunit.sourceforge.net>

This output of cmake said that freetype is optional, but there is an other msg:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
FREETYPE_FT2BUILD_INCLUDE_DIR (ADVANCED)
used as include directory in directory E:/Work/OGRE/ogre/OgreMain
used as include directory in directory E:/Work/OGRE/ogre/RenderSystems/Direct3D9
used as include directory in directory E:/Work/OGRE/ogre/RenderSystems/GL
used as include directory in directory E:/Work/OGRE/ogre/PlugIns/OctreeSceneManager
used as include directory in directory E:/Work/OGRE/ogre/PlugIns/BSPSceneManager
used as include directory in directory E:/Work/OGRE/ogre/PlugIns/ParticleFX
used as include directory in directory E:/Work/OGRE/ogre/PlugIns/PCZSceneManager
used as include directory in directory E:/Work/OGRE/ogre/PlugIns/OctreeZone
used as include directory in directory E:/Work/OGRE/ogre/Components/Paging
used as include directory in directory E:/Work/OGRE/ogre/Components/Terrain
used as include directory in directory E:/Work/OGRE/ogre/Components/RTShaderSystem
used as include directory in directory E:/Work/OGRE/ogre/Components/Volume
used as include directory in directory E:/Work/OGRE/ogre/Tools/XMLConverter
used as include directory in directory E:/Work/OGRE/ogre/Tools/MeshUpgrader

Freetype is a dependency for Ogre.

Klaim · Post by **Klaim** » Wed Sep 19, 2012 6:25 pm

Ok so before I do something wrong, let's review some points:

1. My mistake I explained in my previous point drove me to simply set OGRE_SOURCE to the root of the Ogre source directory and OGRE_BUILD to the directory of the CMake build (which in my case is the same as OGRE_SOURCE). This totally fix the CMake related problem, so I think it's better this way and it will work for any other additional dependencies that need to find Ogre and use FindOgre.
It would be good, I think to add to Ogre Procedural documentation that in case you have sources of Ogre and want to do as I did ( do add_subdirectory( ogre) then add_subdirectory( ogre_procedural) , then you should just set OGRE_SOURCE and OGRE_BUILD.

2. On the include problem, I can't see any good solution to keep everybody happy (without modifying Ogre itself). There are basically two ways:

A. Don't use the OGRE/ folder. This is the simple way because unfortunately sources directories don't match SDK directories on this point, so there is only one other way to make it work in both case, that is...

B. Use a macro for Ogre includes. Something that would allow you to do:

Code: Select all

#include OGRE_HEADER(Ogre.h)

With OGRE_HEADER defined in a specific header that is generated at the CMake processing (using the configure() CMake function).
Then OGRE_HEADER would be defined as either :

Code: Select all

#define OGRE_HEADER( header_path__ ) "header_path__"

or

Code: Select all

#define OGRE_HEADER( header_path__ ) "OGRE/header_path__"

Depending on if CMake detected that it was a OGRE_SOURCE-based Ogre find, or an OGRE_HOME-based one.

So before putting more efforts in this, Mikachu, what do you prefer? I can easily do both obviously.
The problem is that the first solution don't ease users doing OGRE/blah, as said previously, but we can't change Ogre itself on this point AND I think the user of OgreProcedural should have an independent way of including Ogre, so in his code he should be able to use "OGRE/blah.h" while OgreProcedural use "blah.h".
The second solution, if you add an option on CMake, will be interesting for users as they will be able to choose, but frankly I don't think it's good for developers, maintenance and clarity. But that solves the problem too.

I'm fine if you prefer one or the other solution, I just want to be able to upgrade OgreProcedural without having to patch it.

What do you think?

Ogre Forums

Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Turbin

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]

Re: Ogre Procedural [v0.2 officially out]