Patch-Thread

Hi,

I'll list all my patches in this thread.

1. Rename LUA_DIR to LUA_HOME to make it conform to the other CMake scripts of OGRE[/*:m]
   
2. Move FindFreetype to main CMake script, so only one search is required now[/*:m]
   
3. Add getPointCount() to Procedural::Shape to get the size of the point list[/*:m]
   
4. Fix typo in triangulator api doc[/*:m]
   
5. Fix warning in triangulator because there was a return value missing[/*:m]
   
6. Fix signed-unsigned-warning in font searching function[/*:m]
   
7. Add TextShape (ProceduralMultiShapeGenerators) to create a shape collection from a text (can extrued to a 3d text mesh)[/*:m][/list:u]
   
   https://dl.dropbox.com/s/0rvrpoidk8tul4 ... patch?dl=1

Thanks, I applied it

By the way, could you create your own public clone, then issue pull requests? (there's a command for this)
It's a bit easier to track and less error prone than patches.

Thanks, I applied it

By the way, could you create your own public clone, then issue pull requests? (there's a command for this)
It's a bit easier to track and less error prone than patches.
You're welcome! I'll try a clone. You're right, that's more comfortable.

I've created a new patch and commited it to my clone. What I have to do now?

1. Update FindOGRE to detect GL3+ rendering subsystem (https://ogre3d.atlassian.net/browse/OGRE-133).[/*:m]
   
2. Update configuration templates for DirectX and GL rendering subsystems.[/*:m]
   
3. Update illustrations to use first available rendering subsystem instead of GL.[/*:m][/list:u]

Oops, looks like I don't receive forum post notifications anymore...
What I have to do now?
Just letting me know when you have some changes in your clone that have to be pulled (a post in this thread is fine)

http://code.google.com/r/ogretransporte ... fe9e1a9242
http://code.google.com/r/ogretransporte ... 8dce893a2c

Maybe it is a good idea to move to bitbucket. I can create pull requests there.

http://code.google.com/r/ogretransporter-procedural/source/detail?r=4e65867bfceca3f9058478f185a315fe9e1a9242
http://code.google.com/r/ogretransporte ... 8dce893a2c
Ok, applied.
Maybe it is a good idea to move to bitbucket. I can create pull requests there.
Not my priority right now, but if bitbucket continues to evolve and google code continues to stay still, it might become an interesting move.

http://code.google.com/r/ogretransporte ... 6c951d2bc9

Thanks!
Just applied it.

Update FindFreetype.cmake

1. http://code.google.com/r/ogretransporter-procedural/source/detail?r=8542db8a97c6c8888935a0898a64c3fcc0550a3f[/*:m]
   
2. http://code.google.com/r/ogretransporter-procedural/source/detail?r=b53a2c4c7704a8c4f93aea1c44ff2247cd4fd28a[/*:m][/list:o]

Update FindFreetype.cmake

1. http://code.google.com/r/ogretransporter-procedural/source/detail?r=8542db8a97c6c8888935a0898a64c3fcc0550a3f[/*:m]
   
2. http://code.google.com/r/ogretransporter-procedural/source/detail?r=b53a2c4c7704a8c4f93aea1c44ff2247cd4fd28a[/*:m][/list:o]

Applied.

About your previous patch, I don't understand why you set /Zm256, since the default value is /Zm1000 ? (VS2012 express x64 here..)

About your previous patch, I don't understand why you set /Zm256, since the default value is /Zm1000 ? (VS2012 express x64 here..)
The default value here is /Zm100 (VS 2010 Pro). If you like you can set it to /Zm1000.

I just installed DoxyGen for the first time on my laptop and I got an error because apparently in my CMake-based dependency projects of my game, there are several which generate a 'doc' target. As it's the same name for several targets, it generate an error.

So I cloned the repo, and added to changes:

- an option to NOT generate the doc target (set to TRUE for retro-compatibility): https://bitbucket.org/klaim/ogre-proced ... 364458cc54
- I changed the target name to OgreProceduralDoc to avoid collision and also to make it more obvious in the generated solution (I have all my dependencies targets visible in my solution and I don't want doc generation targets): https://bitbucket.org/klaim/ogre-proced ... 4f604a2bc3

You can get both from my clone.


EDIT: looks like the modified code was inspired by Ogre, I got the 'doc' target from there too. I'll also provide a change to add a prefix to the Illustration target in OgreProcedural and make it optional.

EDIT2: here is the patch for Ogre, basically the same changes: https://bitbucket.org/sinbad/ogre/pull- ... matically/

EDIT3: also renamed Illustrations target to OgreProceduralIllustrations to avoid collision again.

EDIT4: my change for Ogre has already been merged.

http://code.google.com/r/ogretransporte ... 4a533135f3

Patch for ogre 1.9.0 (SharedPtr, see Ghadamon Notes).

The ScriptInterpreter is not working with Ghadamon! Because the generated code of SWIG doesn't contains the static casts of the new SharedPtr.

I'm somehow getting this error working with Ogre 1.9 latest - OgreProcedural builds fine.

error LNK2019: unresolved external symbol "public: class Ogre::MeshPtr __thiscall Procedural::TriangleBuffer::transformToMesh(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)const " (?transformToMesh@TriangleBuffer@Procedural@@QBE?AVMeshPtr@Ogre@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0@Z)

When Ogre is configured to use TBB for threading, OgreProcedural don't add the TBB include directories. Ogre does this by calling include_directories( ${TBB_INCLUDE_DIRS} ) once TBB have been found, so I guess you could add the same?

I'm not using TBB, using default Boost config.

I'm not using TBB, using default Boost config.

Sorry I wasn't replying to you, just suggesting an unrelated quick fix (I didn't provide a patch myself). It's the patch thread.

I'm somehow getting this error working with Ogre 1.9 latest - OgreProcedural builds fine.

error LNK2019: unresolved external symbol "public: class Ogre::MeshPtr __thiscall Procedural::TriangleBuffer::transformToMesh(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)const " (?transformToMesh@TriangleBuffer@Procedural@@QBE?AVMeshPtr@Ogre@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0@Z)
Do you get that error when building an app against Ogre+OgreProcedural?
Are the libs and dlls coming from the same revision?

When Ogre is configured to use TBB for threading, OgreProcedural don't add the TBB include directories. Ogre does this by calling include_directories( ${TBB_INCLUDE_DIRS} ) once TBB have been found, so I guess you could add the same?
It should not be required, because, as you can see in FindOgre.cmake :
if (OGRE_CONFIG_THREADS)
if (OGRE_CONFIG_THREAD_PROVIDER EQUAL 1)
find_package(Boost COMPONENTS thread QUIET)
if (NOT Boost_THREAD_FOUND)
set(OGRE_DEPS_FOUND FALSE)
else ()
set(OGRE_LIBRARIES ${OGRE_LIBRARIES} ${Boost_LIBRARIES})
set(OGRE_INCLUDE_DIRS ${OGRE_INCLUDE_DIRS} ${Boost_INCLUDE_DIRS})
endif ()
elseif (OGRE_CONFIG_THREAD_PROVIDER EQUAL 2)
find_package(POCO QUIET)
if (NOT POCO_FOUND)
set(OGRE_DEPS_FOUND FALSE)
else ()
set(OGRE_LIBRARIES ${OGRE_LIBRARIES} ${POCO_LIBRARIES})
set(OGRE_INCLUDE_DIRS ${OGRE_INCLUDE_DIRS} ${POCO_INCLUDE_DIRS})
endif ()
elseif (OGRE_CONFIG_THREAD_PROVIDER EQUAL 3)
find_package(TBB QUIET)
if (NOT TBB_FOUND)
set(OGRE_DEPS_FOUND FALSE)
else ()
set(OGRE_LIBRARIES ${OGRE_LIBRARIES} ${TBB_LIBRARIES})
set(OGRE_INCLUDE_DIRS ${OGRE_INCLUDE_DIRS} ${TBB_INCLUDE_DIRS})
endif ()
endif ()
endif ()

then OGRE_INCLUDE_DIRS and OGRE_LIBRARIES are used everywhere in OgreProcedural...

Indeed! I think it's because in my setup I have overloaded OGRE_INCLUDE_DIRS (for some reasons specific to my context). I'll fix this on my side, thanks.

EDIT> Actually no, the problem is because I'm using Ogre sources and in this case something is messed up( like OGRE_INCLUDE_DIRS isn't defined for some obscure reasons for both for Ogre and OgreProcedural). I'll try to identify the source of the issue later.

Ah yeah, that was it, I linked against 2 different Ogre's. I thought I checked for that but oh well thanks. Unfortunetly I still get the crash I posted in this post - http://www.ogre3d.org/forums/viewtopic. ... 82#p492613 and I get a slew of link errors when trying to link against latest Ogre 1.8, is OgreProcedural Ogre 1.8 friendly?

is OgreProcedural Ogre 1.8 friendly?
It is working with Ogre 1.9.0 and should work with 1.8.x.

I'm somehow getting this error working with Ogre 1.9 latest - OgreProcedural builds fine.

error LNK2019: unresolved external symbol "public: class Ogre::MeshPtr __thiscall Procedural::TriangleBuffer::transformToMesh(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)const " (?transformToMesh@TriangleBuffer@Procedural@@QBE?AVMeshPtr@Ogre@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0@Z)
Do you get that error when building an app against Ogre+OgreProcedural?
Are the libs and dlls coming from the same revision?

I'm getting this error when linking with Ogre 1.8 from repo now. I've double checked that both my app and OgreProcedural are linking against the same Ogre 1.8 libs. Dll files should have nothing to do with the linking error right?

UPDATE: 1.8 from main Ogre3d.org source page works just fine. Why is the repo busted for me?

https://code.google.com/r/ogretransport ... 35909879df

Small bugfix for wrong map iterator.

https://code.google.com/r/ogretransporter-procedural/source/detail?r=7446722b9fbd2b5034079afcb9b82435909879df

Small bugfix for wrong map iterator.
Sorry for the long delay, I finally merged it.

Sorry for the long delay, I finally merged it.
It's ok, I used my locale repository Btw, could you copy FindFreetype.cmake from Ogre to ogre-procedural? There is a new version available and also a small change to detect freetype headers in the new folder structure.

http://code.google.com/r/ogretransporte ... 4d1f49f240

Macro to enable building ogreprocedural with OGRE 2.0.

Fixes for my previous post to allow samples working with Ogre 2.0:

http://code.google.com/r/ogretransporte ... 58d95f5824
http://code.google.com/r/ogretransporte ... f0634a0260

I finally merged your changes.
Sorry for the long delay, I've had very little time for open source developpement these days...

@Transporter : I've granted you commit access on the main repository, to reduce such delays in the future

Since we now have a brand new bitbucket repository (https://bitbucket.org/transporter/ogre-procedural), with all the pull request fancy stuff, I've made this topic non-sticky.

Pull request is now the preferred way to contribute code.