Mogre development thread

GantZ

04-02-2010 21:42:33

Hello to all the mogre community. after some thought, I've decided to create a thread dedicated to the development of Mogre and some of it plugins (mainly the ones located on the svn and supported by the mogre team)

This thread is also there so that everyone know what happen and in which state is the Mogre project.

This thread is for development ONLY. Bug report, asking for help and request on a specific part of mogre or it plugins must stay in their own thread. For plugins like MogreNewt which already have a thread, the discussion and support will stay on their corresponding thread. only the todolist will stay here.

Also people who want to contribute can directly see what need development and pick up a task. I will update on a regular basis this post so that it stay up to date.

Announcement thread for each version will stay only for bug report and support on a specific version. For the SDK development, see this thread : http://www.ogre3d.org/addonforums/viewtopic.php?f=8&t=11703

If you want to contribute on a task listed here or any other one related to mogre development, feel free to ask here, or pm me to get svn access as a committer.

If you have suggestion, or question on the future of mogre, please post here.


The people who are in charge of a task got there name in bold next to it, task without a name are not assigned

Last Update 12.05.2010

Mogre
  1. Information
    1. current version 1.7.1
      [/list:u]
      Task list
      1. static linking of ogremain lib
        [/*:m]
      2. PCZ scene manager
        [/*:m]
      3. Multi Threading (test and demo)
        [/*:m]
      4. Ogre new Terrain plugin
        [/*:m]
      5. reworking the batch build process of mogre for more flexibility, use msbuild instead of devenv
        [/*:m]
      6. Mogre properties designer support http://www.ogre3d.org/addonforums/viewtopic.php?f=8&t=9897 (koirat, seregvan, zarfius)[/*:m]
      7. vs 2010 support (imi) [/*:m]
      8. Update autowrap to make it work with addons[/*:m]
      9. RT shader system[/*:m]
      10. 1.6 script compiler[/*:m]
      11. new compositor class (see this post : http://www.ogre3d.org/addonforums/viewtopic.php?f=8&t=11703&start=150#p70614)[/*:m][/list:u][/*:m][/list:u]
        MogreNewt
        1. Information
          1. current version 2.20 on Mogre 1.7.1
            [/list:u]
            Task list
            1. fixing bugs (available on knowbugs.txt on the svn)
              [/*:m]
            2. implement multithreading
              [/*:m]
            3. testing multithreading
              [/*:m]
            4. port missing part from ogrenewt[/*:m][/list:u][/*:m][/list:u]
              MOIS
              1. Information
                1. Current version 1.2
                  [/list:u][/*:m][/list:u]
                  Hydraxwrapper
                  1. Information
                    1. Current version 0.51 on Mogre 1.6.5[/list:u][/*:m][/list:u]
                      HikariWrapper
                      1. Information
                        1. Current version 0.3 on Mogre 1.7.1 , no further development for the moment.[/list:u][/*:m][/list:u]

Seregvan

06-03-2010 15:57:52

when can we wait 1.7 version? :)

GantZ

07-03-2010 17:34:46

I haven't a fixed release date for this one, but i working on it right now, i hope to release it before the end of the month, but don't hold your breath for it :)

Seregvan

08-03-2010 13:46:41

hope it will be done :)

GantZ

24-03-2010 17:12:36

some update on mogre 1.7 status.

right now, i have fixed the cpptojava and autowrap stage, which doesn't mean that everything work as it should, but at least, it doesn't crash. the autowrap stage is currently what cause me the most trouble. the compiler spit ton of error when compiling mogre, (ogre compile work fine).

here the list of various problems i have encountered on the mogre compiling stage.

  1. new container : Pool used for the new class ResourcePool,it need a new container wrapper.[/*:m]
  2. on a general note, STL containers need to be rechecked, since ogre switch to a custom implementation
    [/*:m]
  3. OgreGpuProgramParams.h have greatly change, i have problem with GpuNamedConstantsPtr that can't subclassing GpuNamedConstants

    wrapping problems :
    [/*:m]
  4. LodStrategy haven't been wrapped at all

    i got trouble with autowrapping of these files, i have fixed it manually[/*:m]
  5. MogreVertexIndexData.h[/*:m]
  6. MogreVertexIndexData.cpp[/*:m]
  7. MogreHardwareBufferManager.h[/*:m]
  8. MogreHardwareBufferManager.cpp
    [/*:m]
  9. in these files Mogre::HardwareBuffer::Usage is declared as Usage, which cause compilation error.

    [/*:m]
  10. HardwareBufferManager singleton now subclass HardwareBufferManagerBase, i have fix the implementation manually by removing all reference to HardwareBufferManagerBase.[/*:m][/list:u]


    Until now, i have run against a wall, and i lack time and knowledge about the internal of mogre/ogre to properly track down all error, and correct it. which mean that i will not be able to release a new version anytime soon. so if anyone can help, it will be more than welcome.

Seregvan

25-03-2010 05:57:52

maybe I can help. Write me in skype or Yahoo! to seregvan.

mzanin

29-03-2010 09:09:23

I might be able to help as well, just let me know what needs to be done etc...
I just built Ogre 1.7 without any dramas, I just don't know where to go from here...

GantZ

29-03-2010 17:27:42

the main problem is the new OgreGpuProgramParams.h / .cpp files that are incorrectly wrapped, here the description of what i have done to get to the compilation stage (it differ a little from the previous version of mogre)

  1. get svn branches 1.7 ogre (i have used the revision 9851)[/*:m]
  2. get new ogre dependencies[/*:m]
  3. compile ogre dependencies[/*:m]
  4. define config with cmake (i have define OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR to 0 to avoid trouble at the wrapping stage). i suggest you to remove all unecessary build step (like demos)[/*:m]
  5. patch ogre source with ogrepatches directory contents (don't use the OgreMain_vcproj patch)[/*:m]
  6. manually modify the ogremain.vcproj file in the build/ogremain folder of cmake to include the CLR files (see ogremain_vcproj.patch contents)[/*:m]
  7. copy the content of Mogre/Ogre folder into the OgreMain folder (the clr files). without this, all the source code will not be generated[/*:m]
  8. run build.bat of cpp2java[/*:m]
  9. compile, run autowrap and use the 'produce' button[/*:m]
  10. open Ogre_vc9[/*:m]
  11. update dependencies path in the ogremain and plugin_cgProgramManager projects[/*:m]
  12. open CLRConfig.h in OgreMain projetct and change "LINK_TO_MOGRE" to 0[/*:m]
  13. remove all reference to Mogre.lib and Mogre_d.lib[/*:m]
  14. Compile Ogre in debug/release mode[/*:m]
  15. Open Mogre_vc9[/*:m]
  16. compile Mogre in debug/release mode (stuck at this step)[/*:m]
  17. in OgreMain project change "LINK_TO_MOGRE" to 1[/*:m]
  18. add back references to Mogre.lib and Mogre_d.lib[/*:m]
  19. compile ogre once again[/*:m][/list:u]

    the main problem is the incorrect code produce by autowrap, here's the keys files to check :

    1. input.xslt in cpp2java\xslt, this is used to transform the all.xml file, with all the method signatures and class informations, into the meta.xml file that autowrap use to generate code[/*:m]
    2. Attributes.xml , thats a file which allow to change the autowrap configuration for producing code. it allow to ignore some unecessary files, and add custom code.[/*:m][/list:u]

      i have add some q&d code in autowrap to resolve some issue with stlcontainers. search for the "Mogre 1.7 "string

mzanin

06-04-2010 10:27:34

Hello,

Thanks for sharing the build process ...
I just started with trying this the other day but I ran into an issue which you might be able to help me with.

I'm using your revision (9851) and applied your patches but when I run the Autowrapper tool it throws an exception in DefExplicitTypes because it cannot wrap std::basic_string.
I know this shouldn't happen because of the OGRE_STRING_USE_CUSTOM_MEMORY_ALLOCATOR is set to 0.

If I check the meta.xml produced by cpp2java I can see the xml:

<typedef name="_StringBase" protection="public" includeFile="OgrePrerequisites.h"
basetype="std::basic_string">
<type>char</type>
<type>std::char_traits&lt; char &gt;</type>
</typedef>


Shouldn't this not be produced?

GantZ

06-04-2010 17:43:37

I have checked my meta.xml, and realize that i don't have any base type for _StringBase

<typedef name="_StringBase" protection="public" includeFile="OgrePrerequisites.h"
basetype="">
<type/>
</typedef>


it's weird you get std::basic_string since it's only when OGRE_STRING_USE_CUSTOM_MEMORY_ALLOCATOR is set. Just checked my build settings, and i see that i have no OGRE_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR defined, even at 0. Try to see if your build settings match this.

mzanin

09-04-2010 02:25:37

I managed to fix the issue.
I'm now quite far into getting Mogre to compile, hopefully in the next few days it will be fully compilable.
I will have to do a diff against the original sources and come up with a complete list of things that had to be changed.
It would be nice to not have to go through this every time a new Ogre version gets released.

What are your thoughts about moving Mogre over to mercurial and bitbucket?
As ogre is now using this I think it just makes sense to do this.

GantZ

09-04-2010 09:01:57

It would be nice to not have to go through this every time a new Ogre version gets released.

hopefully, it occur only when a major version of ogre is released, but we could avoid that by maintaining a version against the latest trunk, so we could deal with change as they occur rather than correct everything at once. Also, i have some plan to improve the existing batch script which take care of wrapping, and compiling everything automatically.

What are your thoughts about moving Mogre over to mercurial and bitbucket?

I have think about that, but until recently, i was the only developer involved, so they were not need :) but we could think about it when the 1.7 version come out, so we can reorganize the project (right now, it's a little messy ). btw, just pm me to get svn access, so you can commit your change.

thanks for what you have done so far, it will really help if you manage to make it work :)

mzanin

09-04-2010 09:32:10

Good news, I finally managed to get Mogre compiling :)
Took me all day but it's done. I've just got few Linker errors when I try and build Ogre with LINK_TO_MOGRE 1, but I think they shouldn't take me long to sort out.

On Monday I'll go over the required changes etc... I can then commit my changes and so on, I've got a Mercurial/Bitbucket setup for my Ogre/Mogre already so I'll check the changes into there as well.

GantZ

09-04-2010 13:22:58

cool ! :D

when your change are ready, you can commit it to the svn, and we could then think about creating an official bitbucket repository, and switching from svn.

imi

19-04-2010 21:31:13

I tried to compile the Mogre trunk as well, using your nice build description. To make it more.. err.. "interesting", I am using VS2010. :-D

I got the Ogre dependencies compiled, applied the patches, manually patched the VS2010 OgreMain.vcprojx (which looks completely different now), added the ogre cpp's and custom build headers..

Now, I am stuck at the Autowrap tool. After "Produce", I got an exception popup. The interesting part looks like this:


************** Exception Text **************
System.Exception: Unexpected
at AutoWrap.Meta.DefTemplateTwoTypes.CreateExplicitType(DefTypeDef typedef) in C:\Users\imi\Projekte\Mogre\AutoWrap\Meta\DefExplicitTypes.cs:line 328
at AutoWrap.Meta.DefTypeDef.CreateExplicitType(DefTypeDef typedef) in C:\Users\imi\Projekte\Mogre\AutoWrap\Meta\DefType.cs:line 1665
at AutoWrap.Meta.Producer.CreateExplicitContainerType(String container, String key, String val) in C:\Users\imi\Projekte\Mogre\AutoWrap\Meta\Producer.cs:line 145
...


That's the function in question:

public new static DefTypeDef CreateExplicitType(DefTypeDef typedef)
{
string baseTypeName = Mogre17.GetBaseType(typedef);

switch (baseTypeName)
{
case "::std::hash_map":
return DefStdHashMap.CreateExplicitType(typedef);
case "std::map":
return DefStdMap.CreateExplicitType(typedef);
case "std::multimap":
return DefStdMultiMap.CreateExplicitType(typedef);
case "std::pair":
return DefStdPair.CreateExplicitType(typedef);
default:
throw new Exception("Unexpected");
}
}


I debugged and baseTypeName is only "std::" - same as the parameter "typedef" :-O
What could that mean? I set the OGRE_CONFIG_CONTAINERS_USE_CUSTOM_MEMORY_ALLOCATOR to 0.

Just because mzanin wrote about this, I checked my meta.xml and the _StringBase - part looks fine:


<typedef name="_StringBase" protection="public" includeFile="OgrePrerequisites.h"
basetype="">
<type/>
</typedef>


Any help would be appreciated. :-)

Ciao, Imi.

mzanin

20-04-2010 03:13:57

Did you get the latest cpp2java? I had to fix a few things in input.xslt to get the autowrapper to work, I committed all the changes last week.

Look at your stack-trace the method CreateExplicitContainerType(...)
has the first line as


protected virtual DefType CreateExplicitContainerType(string container, string key, string val)
{
string stdcont = "std::" + container;
...
}


so for some reason container is an empty string.

If you do a search in meta.xml for container="" it should give you a hint what type/typdef is causing this to occur.
The problem can then be fixed in input.xslt or in the Ogre code (if it is a harmless change).

Note I noticed that the autowrapper has trouble dealing with ::types directly. Easy way to get around this is to just create a typedef for that type and replace it's type usage with the typedef.
eg.


vector<Vector3>::type extremityPoints;


can be replaced with:


typedef vector<Vector3>::type PointList;
PointList extremityPoints;

imi

20-04-2010 06:19:41

I got a couple of minutes to debug this morning.. As I understand it (I am completely new to [m]ogre), the error seems to be with Ogre::AnimationStateSet::DECLARE_CLRHANDLE. My meta.xml looks like this for this section:


<variable protection="public" static="no" passedBy="value">
<definition>Ogre::AnimationStateSet::DECLARE_CLRHANDLE</definition>
<name>DECLARE_CLRHANDLE</name>
</variable>


Looks like some type is missing here?

What should that look like?

Ciao, Imi.

imi

20-04-2010 06:24:57

whops. didn't recognize your posting.

No 'container="" ' found, I got the latest trunk from yesterday. The variable "container" is null in this part.

Ok, gotta get to work now.

Ciao, Imi.

imi

20-04-2010 06:32:47

All the DECLARE_CLRHANDLE - related tags in the meta.xml don't have a type tag. In the code, the DECLARE_CLRHANDLE is a define introduced by MOGRE.


Maybe..... erm.... Do I have to run cpp2java *before* patching the ogre sources? :-D

Ciao, Imi.

mzanin

20-04-2010 06:42:42

Hmmm interesting,

My meta.xml looks like this for the same line:


<variable protection="public" static="no" passedBy="value">
<type>CLRHandle</type>
<definition>CLRHandle Ogre::AnimationStateSet::_CLRHandle</definition>
<name>_CLRHandle</name>
</variable>


My meta.xml doesn't have any references of DECLARE_CLRHANDLE at all... they are all resolved to _CLRHandle.

The DECLARE_CLRHANDLE is added after you add the CLRObjects patch (indroduced by mogre). You run cpp2java after you apply the patches.

Are you referencing CLRConfig.h, CLRHandle.h/.cpp, CLRObject.h/.cpp in your project?

imi

20-04-2010 07:16:26

I've added the CLR* files to the project file. But maybe I did something wrong with item

  1. copy the content of Mogre/Ogre folder into the OgreMain folder (the clr files). without this, all the source code will not be generated[/*:m][/list:u]

    I just dumped the files into OgreMain folder. Guess I have to sort them better for cpp2java to find them (copy to src/ and include/ instead? Or link them somewhere else?).

    Now when I think of it... I wonder why the OgreMain.vcproj - patch reference the original files in Mogre/Ogre folder, when you have to copy them into OgreMain anyway... ;-)

    But I'm at work now - no C# environment here. But I'll look at this in a couple of hours. Thanks for the help so far. Thumbs up.

    Ciao, Imi.

mzanin

20-04-2010 07:47:18

Yeah you should definitely copy them into src/include folders.
If you have a look at the ogre4j.doxygen file in cpp2java it will have an input folders section. Mine is set to:


INPUT = "../Build/include" \
"../OgreMain/include" \
"../OgreMain/include/WIN32"


so if you have files not in those input folders I guess they won't be generated/resolved.

Btw I didn't run the 'OgreMain.vcproj - patch' because it isn't really suitable for 1.7 anymore anyway.

GantZ

20-04-2010 07:56:34

Also, which version of ogre do you use ? the one from the svn or hg ? because i have add some change to the build process posted earlier. i use the last revision on svn (before the switch to mercurial)

So far, here the change i have made:
  1. in the buildsettings, i have set OGRE_NO_PVRTC_CODEC to 0
    [/*:m]
  2. MogreMesh.cpp
    on Mesh::SoftwareVertexPoseBlend, i have change the type of o_vertexOffsetMap to std::map<size_t,Ogre::Vector3,std::less<size_t>,Ogre::STLAllocator<std::pair<const size_t,Ogre::Vector3>,Ogre::GeneralAllocPolicy>> to refer to the typedef of ogremap
    [/*:m]
  3. MogreCamera.cpp
    on Camera::ForwardIntersect, same thing, but with std::vector this time.[/*:m][/list:u]

    hope this help

imi

21-04-2010 07:30:24

I am using the latest Mercurial trunk (is it still called "trunk"? *g*). I thought the plan was to be "always bleeding edge" from now on? I can revert to the latest SVN revision as well, if you recommend...

At the moment, I am stuck at compiling mogre libs, maybe because I didn't do the changes you wrote. Can you commit them into the patch?

I didn't had time to do anything yesterday, but hopefully I get some spare hours today afternoon. I could clean up my vcprojx-files for VS2010 and send them to ... someone? If you are interested? It includes VS2010 project files for OGRE as well, so maybe I'll look into setting up one of these bitbucket repository thingies.. (haven't had experience with Mercurial yet). Does it help when I set up one for MOGRE too or are they conflicting with SVN?

Ciao, Imi.

GantZ

21-04-2010 08:17:58

Well, it *should* work with the latest version from mercurial, it's just that i have made the 1.7 version with the last version from svn, that's why.

I want to add that the change that i have listed occur on generated mogre source, and that mzanin don't have the problem, so its possible that it's fixed if you wrap the ogre source on mercurial. You can create your own repository for mogre on bitbucket if you want, there is already people who have done it, there is no risk of conflict. i will create an official repository soon :)

imi

28-04-2010 09:12:59

Got a bit spare time yesterday and continued on my attempt to make the whole stuff run under VisualStudio 2010.

My latest branch is at

http://bitbucket.org/imi/mogre2010 for the mogre-files (VS2010 solution for mogre and autowrap. I'm using an environment variable BOOST_ROOT for location of boost.)

http://bitbucket.org/imi/ogre for The patched ogre stuff, forked from ogre 6 days ago (rev. 2106). I directly included the mogre-specific patches (the CLR-stuff) and also all the dependencies directly into the repository.

My status: Dependencies compile well, cpp2java and Autowrap works. Now I am stuck compiling the patched Ogre. I guess I have similar problems like GantZ with HardwareBufferManager and HardwareBufferManagerBase.

GantZ: Can you commit the changes you made to make Mogre work with ogre? Or are they already available in http://bitbucket.org/gantz/mogre ? :-D

Ciao, Imi.

GantZ

28-04-2010 20:24:12

for the moment, the mercurial repo is still under test, it's better to use the latest trunk from svn.

Just checked out mogre config, the patch file is outdated. here the last patch file i have just use to compile ogre (i still have some linker error, but that come from my config, it should work on other config :))

[attachment=0]Mogre_patch.zip[/attachment]

Also, make sure that you don't use precompiled header for clrhandle.cpp and clrobject.cpp. i will setup a working repo ASAP.

imi

01-05-2010 23:07:47

This patch file (which is the same as the one in subversion revision 319) does not match neither the latest Ogre SVN state nor the latest Ogre Mercurial tip.
For example, the patch claims for OgreCompositorChain.h around line 46 to be

class _OgreExport CompositorChain: public RenderTargetListener, public CompositorInstAlloc

but it's first line 47 in the second in revision 9952 (as claimed in the comment by the patchfile too) it look like this:

class _OgreExport CompositorChain : public RenderTargetListener, public Viewport::Listener, public CompositorInstAlloc

What did you use as base for the patch file? Could you make a patch to some unmodified and accessable Ogre revision? Please? ;) (I am not so interested in this particular error, more interested in all the changes you might have made so it finally compiles for you. I've still no luck to get mogre running here :-( )

Ciao, Imi.

GantZ

02-05-2010 11:12:11

This is a patch for the 1.7 branch. it have been made against the last 1.7 revision on ogre svn (9937). I use it against the 1.7 branch of ogre in hg, and got no problem using hg import. for the moment, I have made no test using the ogre trunk, so it won't work out of the box.

imi

02-05-2010 21:50:06

Oh, ups. my fault, sorry. I always used the trunk of Ogre. Now the patch applies. :)

So I got Ogre compiled in Debug mode only. For release, it's spitting out lots of errors like "mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in OgreAlignedAllocator.obj" and the classic "'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library". I guess somewhere there are wrong settings about the include and link paths. I had to change a huge amount of include paths and everything already, so I guess I made some mistake there. I haven't figured out the directory structure and where to checkout what either. It seems that always either cpp2java or the project files disagree of where Ogre is relative to Mogre (e.g. whether to put mogre/trunk, mogre/trunk/mogre or mogre/trunk/mogre/mogre next to ogre directory).


Also, I get errors when trying to compile Mogre (in Debug settings). Ignoring the gazillion warnings about conversation from double to Mogre::Real, I am left with:


1>------ Build started: Project: Mogre, Configuration: Debug Win32 ------
1>c1xx : fatal error C1083: Cannot open source file: 'src\auto\MogreDefaultHardwareBufferManager.cpp': No such file or directory
1>src\auto\MogreGpuProgramManager.cpp(20): error C2678: binary '=' : no operator found which takes a left-hand operand of type 'const std::basic_string<_Elem,_Traits,_Ax>' (or there is no acceptable conversion)
1>src\auto\MogreAnimation.cpp(53): error C3892: 'Mogre::Animation::TrackHandleList::Iterator::_native' : you cannot assign to a variable that is const
1>src\auto\MogreCompositorManager.cpp(23): error C3892: 'Mogre::CompositorManager::UniqueTextureSet::Iterator::_native' : you cannot assign to a variable that is const
1>src\auto\MogreRenderSystemCapabilities.cpp(18): error C2678: binary '=' : no operator found which takes a left-hand operand of type 'const std::basic_string<_Elem,_Traits,_Ax>' (or there is no acceptable conversion)
1>src\auto\MogrePass.cpp(83): error C3892: 'Mogre::Pass::PassSet::Iterator::_native' : you cannot assign to a variable that is const
1>src\auto\MogreMesh.cpp(522): error C2440: 'return' : cannot convert from 'const Ogre::Mesh::SubMeshNameMap' to 'Mogre::Mesh::Const_SubMeshNameMap ^'
1>src\auto\MogreEntity.cpp(32): error C3892: 'Mogre::Entity::EntitySet::Iterator::_native' : you cannot assign to a variable that is const
1>c:\users\imi\projekte\mogre_svn\mogre\mogre\mogre\include\Marshalling.h(215): error C2440: 'type cast' : cannot convert from 'Ogre::ResourceManager::ResourceMap' to 'Mogre::ResourceManager::ResourceMap ^'
1>c:\users\imi\projekte\mogre_svn\mogre\mogre\mogre\include\Marshalling.h(209): error C2440: 'type cast' : cannot convert from 'Mogre::ResourceManager::ResourceMap ^' to 'Ogre::ResourceManager::ResourceMap'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


So I assume that in fact, I did not compile Ogre successfull? Or that the AutoWrapper/cpp2java chain still contains errors for me? Or maybe the conversation of Mogre to VS2010 went wrong.

Anyway, I am pretty fed up with all the stuff and I guess I wait until someone else step forward or at least until I get a better clue about the build process of Mogre (rather than the 19-point programm earlier in the thread). :-(

Ciao, Imi.

GantZ

03-05-2010 10:29:14

well, since no one have compile mogre with vs2010 yet (at least, i haven't heard about someone who has done it), i think that you get in front of errors no one as got yet :). the MogreDefaultHardwareBufferManager.cpp is normal, this file isn't generated anymore, it have been updated on the hg repo. I'm sorry that you got so much trouble compiling mogre, but the build process isn't fully fixed atm, so change are made on a regular basis which cause various break/incompatibilities.

imi

04-05-2010 00:06:09

Thanks Gantz. I've pushed the solution and project file for VS2010. (I've changed one setting: The include directory of Boost is now taken from the environment variable "BOOST_INCLUDE_DIRECTORY" instead of beeing hardcoded as "C:\Program Files (x86)\boost\boost_1.40" or something like that).

And I found the mistake of my unability to build the Release version of Ogre. I just forgot to build the Dependencies in Release mode which caused CMake to use the Debug libraries for Release mode (Doh!). Now I am left with the list of build errors from my old post.

Another question: What is mercurial.patch (http://bitbucket.org/gantz/mogre/src/ti ... rial.patch) and can I use it for something? From looking on the content, it may be the start of a fix to some of my problems? Yes? :-D. It seems to be a corrupt patch-file, though (e.g. line 19 and follows seems to miss some " " at start of line) - has it been tampered with? Maybe copy'n'pasted though an email client? :(

If you aren't working on it, I might look at fixing it tomorrow..


Ciao, Imi.

GantZ

04-05-2010 08:13:26

Mercurial.patch contains the changes made by mzanin to make mogre work with 1.7, it's not needed anymore, all you need for patching ogre is in the Mogre.patch on the ogre patches directory.

I suppose you use the same version of ogre than me as a basis, could you post the (mogre) files that cause theses errors ? this way, i could compare with what autowrap have generated for me. You should have the same code than me, otherwise, it could be an incompatibility with vs 2010

imi

04-05-2010 10:53:50

I suppose you use the same version of ogre than me as a basis, could you post the (mogre) files that cause theses errors ? this way, i could compare with what autowrap have generated for me. You should have the same code than me, otherwise, it could be an incompatibility with vs 2010

In my last post, I used the subversion 1.7 branch. Yesterday (the newer post), I used the Mercurial branch for 1.7. The file not found for MogreDefaultHardwareBufferManager.cpp is fixed now.

Some other concrete problems:

src\auto\MogreCompositorManager.cpp(23): error C3892: 'Mogre::CompositorManager::UniqueTextureSet::Iterator::_native' : you cannot assign to a variable that is const

Interesting code in the CPP around this line (the error is in the CPP_DECL...):


//Nested Types
#define STLDECL_MANAGEDTYPE Mogre::Texture^
#define STLDECL_NATIVETYPE Ogre::Texture*
CPP_DECLARE_STLSET( CompositorManager::, UniqueTextureSet, STLDECL_MANAGEDTYPE, STLDECL_NATIVETYPE )
#undef STLDECL_MANAGEDTYPE
#undef STLDECL_NATIVETYPE


Same problem for MogreAnimation.cpp, line 53 and a lot of other files:


#define STLDECL_MANAGEDTYPE Mogre::ushort
#define STLDECL_NATIVETYPE Ogre::ushort
CPP_DECLARE_STLSET( Animation::, TrackHandleList, STLDECL_MANAGEDTYPE, STLDECL_NATIVETYPE )
#undef STLDECL_MANAGEDTYPE
#undef STLDECL_NATIVETYPE


MogreGpuProgramManager.cpp has similar code place, but different error message:

1>src\auto\MogreGpuProgramManager.cpp(20): error C2678: binary '=' : no operator found which takes a left-hand operand of type 'const std::basic_string<_Elem,_Traits,_Ax>' (or there is no acceptable conversion)


//Nested Types
#define STLDECL_MANAGEDTYPE String^
#define STLDECL_NATIVETYPE Ogre::String
CPP_DECLARE_STLSET( GpuProgramManager::, SyntaxCodes, STLDECL_MANAGEDTYPE, STLDECL_NATIVETYPE )
#undef STLDECL_MANAGEDTYPE
#undef STLDECL_NATIVETYPE



An error in MogreMesh looks different:

1>src\auto\MogreMesh.cpp(522): error C2440: 'return' : cannot convert from 'const Ogre::Mesh::SubMeshNameMap' to 'Mogre::Mesh::Const_SubMeshNameMap ^'


Mogre::Mesh::Const_SubMeshNameMap^ Mesh::GetSubMeshNameMap( )
{
return static_cast<const Ogre::Mesh*>(_native)->getSubMeshNameMap( );
}

(The error is, of course, in the return statement line.)

This last error appears similar two times in Marshalling.h.

1>c:\users\imi\projekte\mogre_hg\main\include\Marshalling.h(215): error C2440: 'type cast' : cannot convert from 'Ogre::ResourceManager::ResourceMap' to 'Mogre::ResourceManager::ResourceMap ^'
1>c:\users\imi\projekte\mogre_hg\main\include\Marshalling.h(209): error C2440: 'type cast' : cannot convert from 'Mogre::ResourceManager::ResourceMap ^' to 'Ogre::ResourceManager::ResourceMap'



template <typename M, typename N>
inline M ToManaged(const N& value)
{
return (M)const_cast<N&>(value);
}
...
template <typename M, typename N>
inline N ToNative(M value)
{
return (N)value;
}


Hope it helps. I'm at work ATM and don't have much time today evening (my 9-year-old nephew comes to play computer games with me. That's pinned time and not disposable and not eligible for garbage collection! :-D). I can look at the stuff at late evening or tomorrow.

Ciao, Imi.

imi

04-05-2010 23:29:43

Just had time to look into the first thing only. It's the 'Mogre::CompositorManager::UniqueTextureSet::Iterator::_native' : you cannot assign to a variable that is const.

The offending statement is *(*_native) = ToNative<M,N>( value ); which assigns to _native, which is of type Ogre::set<>::type::iterator which is std::set<>::iterator and which is const in C++0x (and the current STL implementation of VS2010). :-(

Now although this is according to the standard, it's only there since VS2010. First difference found. Any ideas what to do with it? (Personally I have a strong opinion on const elements of ordered container where you can customize the ordering function anyway, but that doesn't help here - except that I wouldn't back before a const_cast just to show them! ;-) )

Well. Has to wait for tomorrow! Bedtime.

Ciao, Imi.

GantZ

05-05-2010 08:14:57

i have found this on the subject http://blogs.msdn.com/vcblog/archive/2009/05/25/stl-breaking-changes-in-visual-studio-2010-beta-1.aspx (see problem 3)

This give some possible workaround to overcome this problem. It would be needed to update the include/STLSet.h file to conform to the new vs2010 compiler.

imi

05-05-2010 09:08:42

I'll probably try out to erase / re-insert the value and hope that not too many places keep iterators on sets and then expect them to be still valid after calling to *::Iterator::Value::set.

Another question: Why do this stuff have to be huge macros? It seems to me they could be expressed by rather simple templates as well, which would make them a lot easier to debug and browse. Or is it something about linker symbols and exported classes? Or... I haven't worked with CLI/C++ before - is there an issue using templates in CLI why you fall back to macros?

Ciao, Imi.

GantZ

05-05-2010 15:47:42

here a extract of a message from bekas, the creator of mogre, it will shed some light on why it have been made like that :

The #defines define a template and the macros insert it in source code by changing some variables. The problem is that if something goes wrong it's very difficult to understand the issue and make necessary changes.

It'd be simpler to move the template into the Autowrapper that will change a few things based on types given and output "real" source code, not macros. Autowrap already does that in other parts, it's just the iterator stuff that were put in place before autowrap existed, thus never got integrated into autowrap.


In short, yes it would be better to refactor this, but until now, no one as taken the time to do so :)

imi

05-05-2010 21:24:55

I'll look into the macro thingie later. For now, all the const-related errors seem to go away when I remove the generation of the Set-function alltogether. Of course, if this function is not needed anyway, it would be the best solution to not generate it, as overwriting a value in a set-container indeed isn't what you expect most of the time (as it would have to erase/re-insert the element and so not really setting to a particular one. E.g. doing this in a loop over the container would be disastrous).

Now I am down to three errors:


1>c:\users\imi\projekte\mogre_hg\main\include\Marshalling.h(215): error C2440: 'type cast' : cannot convert from 'Ogre::ResourceManager::ResourceMap' to 'Mogre::ResourceManager::ResourceMap ^'
1>c:\users\imi\projekte\mogre_hg\main\include\Marshalling.h(209): error C2440: 'type cast' : cannot convert from 'Mogre::ResourceManager::ResourceMap ^' to 'Ogre::ResourceManager::ResourceMap'
1>src\auto\MogreMesh.cpp(522): error C2440: 'return' : cannot convert from 'const Ogre::Mesh::SubMeshNameMap' to 'Mogre::Mesh::Const_SubMeshNameMap ^'


I am right in the middle figuring out what these mean. Probably the same kind of problem, just for map this time. (whose keys are const now).

Ciao, Imi.

mstoyke

06-05-2010 00:56:14

Just in case anybody needs the property set function mentioned earlier, here is what I changed to satisfy the compiler. I think it's one of the workarounds mentioned in the MS KB article. This is untested code, I never needed to change a value so I never tested this code, it was just my first attempt to make it all compile in VS2010.

*const_cast<N*>(&(*(*_native))) = ToNative<M,N>( value );

Later I decided to remove the set method completely, usually there is a good reason to make something const and it's not to make a value to be changed easily...

I also ran into the cast errors in VS2010, so I decided to wait for somebody to fix the problems first. I would try it myself but my job keeps me too busy atm to try anything else.

PS: I managed to compile Ogre 1.6.5 and Mogre 1.6.5 with VS2010, completely for the .NET4 runtime. All my projects using Mogre 1.6 are also changed to the .Net4 runtime and I did not have any problems so far. If anybody is still interested in 1.6.5 for VS2010/.NET4 just leave a message and I can upload the project files.

imi

06-05-2010 01:04:35

Ok. These last three things were not about const keys. Instead, in Ogre hash maps point to the new std::unordered_set instead to stdext::hash_map for the new compiler. In the huge macro, it was using stdext::hash_map directly, so the conversion operator didn't kicked in. A simple change to the define "HashMap" (which is a define from Ogre) helped.

So.. finally it compiles. Now I get linker problems.

First, I think I got the intended Mogre directory structure now: OgreSrc/ogre holds the ogre source code checkout, but the CMake output directory should be OgreSrc/build, right? I kinda put the build into the same directory as ogre source. I commented about the directory structure in the readme.txt within OgreSrc.

But second, the library path for the boost lib's directory wasn't in the additional library paths. How the heck could this compile for VS2008? Or did you all enter boost libraries in the global directory settings? (Then the bad news would be: There aren't global directory settings under VS2010 anymore). Anyway, I introduced yet another environment variable BOOST_LIBRARY_DIRECTORY pointing to the boost lib install directory (e.g. C:\Program Files\boost\lib) and included it into the Mogre project file.

Now I get unresolved symbols. The linker took like 5 minutes before spiiting out a lot of warnings and 4 missing symbols:


1>------ Build started: Project: Mogre, Configuration: Debug Win32 ------
1>MogreZip.obj : warning LNK4248: unresolved typeref token (01000030) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreWireBoundingBox.obj : warning LNK4248: unresolved typeref token (01000058) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreWindowEventUtilities.obj : warning LNK4248: unresolved typeref token (01000048) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreViewport.obj : warning LNK4248: unresolved typeref token (0100005A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreVertexIndexData.obj : warning LNK4248: unresolved typeref token (01000031) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreVertexElement.obj : warning LNK4248: unresolved typeref token (01000070) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreUnifiedHighLevelGpuProgram.obj : warning LNK4248: unresolved typeref token (01000049) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreTextureUnitState.obj : warning LNK4248: unresolved typeref token (0100005C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreTextureManager.obj : warning LNK4248: unresolved typeref token (01000048) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreTexture.obj : warning LNK4248: unresolved typeref token (01000048) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreTextAreaOverlayElement.obj : warning LNK4248: unresolved typeref token (0100005D) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreTechnique.obj : warning LNK4248: unresolved typeref token (0100005E) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreTagPoint.obj : warning LNK4248: unresolved typeref token (01000062) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSubMesh.obj : warning LNK4248: unresolved typeref token (01000058) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSubEntity.obj : warning LNK4248: unresolved typeref token (01000070) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreStringVector.obj : warning LNK4248: unresolved typeref token (01000030) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreStringConverter.obj : warning LNK4248: unresolved typeref token (01000030) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreStaticGeometry.obj : warning LNK4248: unresolved typeref token (0100006B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSkeletonSerializer.obj : warning LNK4248: unresolved typeref token (01000049) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSkeletonManager.obj : warning LNK4248: unresolved typeref token (01000040) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSkeletonInstance.obj : warning LNK4248: unresolved typeref token (0100005A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSkeleton.obj : warning LNK4248: unresolved typeref token (01000059) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSimpleRenderable.obj : warning LNK4248: unresolved typeref token (0100006B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreShadowTextureManager.obj : warning LNK4248: unresolved typeref token (01000048) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreShadowCaster.obj : warning LNK4248: unresolved typeref token (01000069) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreShadowCameraSetupPSSM.obj : warning LNK4248: unresolved typeref token (0100006A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreShadowCameraSetupPlaneOptimal.obj : warning LNK4248: unresolved typeref token (01000069) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreShadowCameraSetupLiSPSM.obj : warning LNK4248: unresolved typeref token (0100006A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreShadowCameraSetupFocused.obj : warning LNK4248: unresolved typeref token (0100006A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreShadowCameraSetup.obj : warning LNK4248: unresolved typeref token (0100006A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSceneQuery.obj : warning LNK4248: unresolved typeref token (0100006B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSceneNode.obj : warning LNK4248: unresolved typeref token (01000069) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSceneManagerEnumerator.obj : warning LNK4248: unresolved typeref token (0100006E) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreSceneManager.obj : warning LNK4248: unresolved typeref token (0100006E) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRoot.obj : warning LNK4248: unresolved typeref token (01000069) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRibbonTrail.obj : warning LNK4248: unresolved typeref token (01000057) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreResourceManager.obj : warning LNK4248: unresolved typeref token (0100003F) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreResourceGroupManager.obj : warning LNK4248: unresolved typeref token (01000066) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreResourceBackgroundQueue.obj : warning LNK4248: unresolved typeref token (01000032) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreResource.obj : warning LNK4248: unresolved typeref token (0100003D) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderWindow.obj : warning LNK4248: unresolved typeref token (01000048) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderToVertexBuffer.obj : warning LNK4248: unresolved typeref token (0100006C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderTexture.obj : warning LNK4248: unresolved typeref token (01000046) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderTargetListener.obj : warning LNK4248: unresolved typeref token (0100005B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderTarget.obj : warning LNK4248: unresolved typeref token (0100005A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderSystem.obj : warning LNK4248: unresolved typeref token (0100005C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderQueueSortingGrouping.obj : warning LNK4248: unresolved typeref token (0100006C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderQueueInvocation.obj : warning LNK4248: unresolved typeref token (0100006B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderQueue.obj : warning LNK4248: unresolved typeref token (0100006C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderOperation.obj : warning LNK4248: unresolved typeref token (01000048) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderObjectListener.obj : warning LNK4248: unresolved typeref token (0100003B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRenderable.obj : warning LNK4248: unresolved typeref token (0100006C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreRectangle2D.obj : warning LNK4248: unresolved typeref token (01000058) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogrePVRTCCodec.obj : warning LNK4248: unresolved typeref token (01000031) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreProgressiveMesh.obj : warning LNK4248: unresolved typeref token (01000032) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreProfiler.obj : warning LNK4248: unresolved typeref token (01000038) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogrePose.obj : warning LNK4248: unresolved typeref token (01000031) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogrePixelCountLodStrategy.obj : warning LNK4248: unresolved typeref token (01000060) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogrePatchSurface.obj : warning LNK4248: unresolved typeref token (01000031) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogrePatchMesh.obj : warning LNK4248: unresolved typeref token (0100005B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogrePass.obj : warning LNK4248: unresolved typeref token (0100005E) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreParticleSystemRenderer.obj : warning LNK4248: unresolved typeref token (0100005E) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreParticleSystemManager.obj : warning LNK4248: unresolved typeref token (01000055) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreParticleSystem.obj : warning LNK4248: unresolved typeref token (01000067) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreParticleEmitterFactory.obj : warning LNK4248: unresolved typeref token (01000055) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreParticleAffectorFactory.obj : warning LNK4248: unresolved typeref token (01000055) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreParticleAffector.obj : warning LNK4248: unresolved typeref token (01000055) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreParticle.obj : warning LNK4248: unresolved typeref token (01000056) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogrePanelOverlayElement.obj : warning LNK4248: unresolved typeref token (0100006C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreOverlayManager.obj : warning LNK4248: unresolved typeref token (0100006A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreOverlayElementFactory.obj : warning LNK4248: unresolved typeref token (01000057) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreOverlayElement.obj : warning LNK4248: unresolved typeref token (0100006A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreOverlayContainer.obj : warning LNK4248: unresolved typeref token (01000069) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreOverlay.obj : warning LNK4248: unresolved typeref token (01000066) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreNode.obj : warning LNK4248: unresolved typeref token (01000057) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreMovablePlane.obj : warning LNK4248: unresolved typeref token (01000069) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreMovableObject.obj : warning LNK4248: unresolved typeref token (01000067) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreMeshSerializer.obj : warning LNK4248: unresolved typeref token (0100005B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreMeshManager.obj : warning LNK4248: unresolved typeref token (01000059) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreMesh.obj : warning LNK4248: unresolved typeref token (01000060) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreMaterialSerializer.obj : warning LNK4248: unresolved typeref token (0100004D) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreMaterialManager.obj : warning LNK4248: unresolved typeref token (0100005E) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreMaterial.obj : warning LNK4248: unresolved typeref token (01000068) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreManualObject.obj : warning LNK4248: unresolved typeref token (0100006E) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreLodStrategyManager.obj : warning LNK4248: unresolved typeref token (0100005F) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreLodStrategy.obj : warning LNK4248: unresolved typeref token (01000067) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreLodListener.obj : warning LNK4248: unresolved typeref token (0100005F) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreLight.obj : warning LNK4248: unresolved typeref token (01000068) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreKeyFrame.obj : warning LNK4248: unresolved typeref token (0100003A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreInstancedGeometry.obj : warning LNK4248: unresolved typeref token (01000069) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreImageCodec.obj : warning LNK4248: unresolved typeref token (01000032) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreImage.obj : warning LNK4248: unresolved typeref token (01000030) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreHighLevelGpuProgramManager.obj : warning LNK4248: unresolved typeref token (01000049) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreHighLevelGpuProgram.obj : warning LNK4248: unresolved typeref token (01000047) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreHardwareVertexBuffer.obj : warning LNK4248: unresolved typeref token (01000032) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreHardwarePixelBuffer.obj : warning LNK4248: unresolved typeref token (01000044) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreHardwareIndexBuffer.obj : warning LNK4248: unresolved typeref token (01000030) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreHardwareBufferManager.obj : warning LNK4248: unresolved typeref token (01000040) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreGpuProgramParams.obj : warning LNK4248: unresolved typeref token (01000032) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreGpuProgramManager.obj : warning LNK4248: unresolved typeref token (01000049) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreGpuProgram.obj : warning LNK4248: unresolved typeref token (01000049) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreFrustum.obj : warning LNK4248: unresolved typeref token (0100006B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreFontManager.obj : warning LNK4248: unresolved typeref token (01000045) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreFont.obj : warning LNK4248: unresolved typeref token (0100004C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreFileSystem.obj : warning LNK4248: unresolved typeref token (01000030) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreEntity.obj : warning LNK4248: unresolved typeref token (0100006A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreEdgeListBuilder.obj : warning LNK4248: unresolved typeref token (0100003C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreDistanceLodStrategy.obj : warning LNK4248: unresolved typeref token (01000060) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreDDSCodec.obj : warning LNK4248: unresolved typeref token (01000031) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreDataStream.obj : warning LNK4248: unresolved typeref token (01000030) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreConfigOptionMap.obj : warning LNK4248: unresolved typeref token (01000032) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreConfigFile.obj : warning LNK4248: unresolved typeref token (01000031) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCompositorManager.obj : warning LNK4248: unresolved typeref token (01000062) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCompositorInstance.obj : warning LNK4248: unresolved typeref token (01000057) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCompositorChain.obj : warning LNK4248: unresolved typeref token (01000061) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCompositor.obj : warning LNK4248: unresolved typeref token (01000052) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCompositionTechnique.obj : warning LNK4248: unresolved typeref token (01000049) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCompositionTargetPass.obj : warning LNK4248: unresolved typeref token (0100005B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCompositionPass.obj : warning LNK4248: unresolved typeref token (0100005F) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCommon.obj : warning LNK4248: unresolved typeref token (01000057) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCodec.obj : warning LNK4248: unresolved typeref token (01000031) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreCamera.obj : warning LNK4248: unresolved typeref token (0100006A) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreBorderPanelOverlayElement.obj : warning LNK4248: unresolved typeref token (0100006C) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreBone.obj : warning LNK4248: unresolved typeref token (01000050) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreBillboardSet.obj : warning LNK4248: unresolved typeref token (0100006B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreBillboardParticleRenderer.obj : warning LNK4248: unresolved typeref token (01000061) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreBillboardChain.obj : warning LNK4248: unresolved typeref token (0100006B) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreBillboard.obj : warning LNK4248: unresolved typeref token (01000053) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreArchiveManager.obj : warning LNK4248: unresolved typeref token (01000034) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreArchive.obj : warning LNK4248: unresolved typeref token (01000030) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreAnimationTrack.obj : warning LNK4248: unresolved typeref token (01000045) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreAnimation.obj : warning LNK4248: unresolved typeref token (01000062) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogreAnimable.obj : warning LNK4248: unresolved typeref token (01000035) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>ManagedDataStream.obj : warning LNK4248: unresolved typeref token (01000037) for 'boost.detail.win32._SECURITY_ATTRIBUTES'; image may not run
1>MogrePVRTCCodec.obj : error LNK2028: unresolved token (0A000318) "public: static void __cdecl Ogre::PVRTCCodec::shutdown(void)" (?shutdown@PVRTCCodec@Ogre@@$$FSAXXZ) referenced in function "public: static void __clrcall Mogre::PVRTCCodec::Shutdown(void)" (?Shutdown@PVRTCCodec@Mogre@@$$FSMXXZ)
1>MogrePVRTCCodec.obj : error LNK2028: unresolved token (0A000319) "public: static void __cdecl Ogre::PVRTCCodec::startup(void)" (?startup@PVRTCCodec@Ogre@@$$FSAXXZ) referenced in function "public: static void __clrcall Mogre::PVRTCCodec::Startup(void)" (?Startup@PVRTCCodec@Mogre@@$$FSMXXZ)
1>MogrePVRTCCodec.obj : error LNK2019: unresolved external symbol "public: static void __cdecl Ogre::PVRTCCodec::startup(void)" (?startup@PVRTCCodec@Ogre@@$$FSAXXZ) referenced in function "public: static void __clrcall Mogre::PVRTCCodec::Startup(void)" (?Startup@PVRTCCodec@Mogre@@$$FSMXXZ)
1>MogrePVRTCCodec.obj : error LNK2019: unresolved external symbol "public: static void __cdecl Ogre::PVRTCCodec::shutdown(void)" (?shutdown@PVRTCCodec@Ogre@@$$FSAXXZ) referenced in function "public: static void __clrcall Mogre::PVRTCCodec::Shutdown(void)" (?Shutdown@PVRTCCodec@Mogre@@$$FSMXXZ)
1>lib\Debug\Mogre_d.dll : fatal error LNK1120: 4 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


Any ideas?

Ciao, Imi.
PS: Don't hesitate to throw out any checkin that now might break your code. I don't have VS2008 installed (can't coexist with 2010 :-(, so I couldn't test for backward compability. But I believe I didn't do anything mallicious and in theory it should still work.)

GantZ

06-05-2010 08:36:14

@mstoyke

having a working vs2010 solution for 1.6 would be useful, could you share it here ?, i could commit it to the svn so that everyone can access it.

@imi

You right about the directory structure, thanks for editing the readme file, it's much clearer now :)
the boost dependency for mogre have been introduced with 1.7, so it have been manually resolved. About your linker error, could you try to use
#define BOOST_USE_WINDOWS_H in MogreStableHeaders.h ? I have use this solution for a similar problem with another project linked to boost.
otherwise, you can also see this thread, same error here http://comments.gmane.org/gmane.comp.lib.boost.threads.devel/415

Just a question, which problem have you encountered with 2 install of vs ? , atm, i have an install of vs2008 with vs2010, each of them in express version (the c++ version), i haven't see specific problem for now, but i have just install it. :) (not using it much) could it be related to the version of vs used ?

I will take time this week end to test your change with vs2008, to see if everything work as intended, shouldn't cause any problem, but you never know until you test it.

imi

06-05-2010 11:04:56


Just a question, which problem have you encountered with 2 install of vs ? , atm, i have an install of vs2008 with vs2010, each of them in express version (the c++ version), i haven't see specific problem for now, but i have just install it. :) (not using it much) could it be related to the version of vs used ?
test it.


Don't remember exactly, but it spit out something like "You have an other version of Visual Studio installed. Uninstall this first". Maybe it was that I tried to install 2008 on top of 2010-RC1. I'll try again later with the 2008 install.

The #defines define a template and the macros insert it in source code by changing some variables. The problem is that if something goes wrong it's very difficult to understand the issue and make necessary changes.

It'd be simpler to move the template into the Autowrapper that will change a few things based on types given and output "real" source code, not macros. Autowrap already does that in other parts, it's just the iterator stuff that were put in place before autowrap existed, thus never got integrated into autowrap.


In short, yes it would be better to refactor this, but until now, no one as taken the time to do so :)


Well, actually he was suggesting something else (or I was - whatever ;) ). His approach is to move code generation into AutoWrapper and have it spit out plain cpp files without any big macros. My approach would be to implement the iterators in C++ templates and have AutoWrap spit out just the template instantiations. Actually I haven't worked with neither - Mogre nor C++/CLI nearly long enough to judge which approach would be better in the end.

Ciao, Imi.

imi

06-05-2010 20:31:55

OK. Got the stuff compiled and linked. The last link problem wasn't about BOOST_WINDOWS_H stuff, but it seems that Mogre needs the Ogre-CMake-setting OGRE_CONFIG_ENABLE_PVRTC set to true.

I two other things: I modified the CLRConfig to include mogre.lib there (depending on LINK_TO_MOGRE). Its much more stable and easier than to use yet another patch-file for a project-file that is even autogenerated by CMake and can be totally different for different circumstances. I hope you like it ;).

And second, I changed the ogre.patch file to include the CLR* files as I suggested earlier. If we have a pre-patched ogre fork later, this won't be necessary anymore but until then..... ;)

So. What's next on agenda? :-D


Oh, I've added a BUILD into root dir with the building steps. That probably should be copied and linked into a wiki as well and explained much more, but I don't know where to put it (and I've read the wiki is in progress of changing, right?)

Ciao, Imi.

GantZ

07-05-2010 07:59:54

I modified the CLRConfig to include mogre.lib there (depending on LINK_TO_MOGRE)
This step have also been added in clrobject.cpp see http://bitbucket.org/gantz/mogre/src/tip/Main/Ogre/CLRObject.cpp, we can keep it in the clrconfig, seem more logical that way, just think about removing it where it's not needed

I've read the wiki is in progress of changing, right?

That's right, the switch from mediawiki to tiki should be made in the near future by the ogre team, so we can update the wiki at this moment.

So. What's next on agenda?

There's always so much things :) Well, since we are on the 1.7 version, if you have time, you can check if new class and addition have been correctly wrapped. there also a todo list on the first page, with some of the things that could need some work.

thanks for your work so far !

mstoyke

07-05-2010 17:36:48

I uploaded Mogre 1.6.5 for Visual Studio 2010 with .NET4 binaries and sources/projects to my webspace:

Mogre 1.6.5 VS2010 / .NET4 compiled binaries
Mogre 1.6.5 VS2010 / .NET4 projects and sources

I will have to remove these files after some days, because I have limited bandwidth available, so if anybody is interested please download these files soon.

EDIT: I have removed the files from my server, because Gantz uploaded them to sourceforge where you can get them now.

imi

11-05-2010 20:12:25

Ok, now the Visual Studio 2010 stuff runs smoothly. The last problem with the boost was twofolded: First the define from Gantz and second, I had to recompile boost using VS2010. My current installation was from 2008. Doh! I've checked all the stuff in and pushed it to bitbucket.

Anyway, the samples are running. Now I can finally start to learn how Ogre and Mogre works and start to use it. :D

Thanks Gantz for your help.

Ciao, Imi.

GantZ

12-05-2010 07:58:32

@mstoyke

Thanks, i will make it available in the old ogre 1.6 svn in the next days. In the meanwhile, i think about uploading binaries in sourceforge, you're ok with that ?

@imi

Thanks for the work made on vs2010, i think about making an sdk for vs2010 later. what you have done greatly help :)

mstoyke

12-05-2010 10:49:04

You are free to do whatever you want with the stuff ;) Just don't call it stable without further testing, better stick with the "beta" tag :)

Please be aware that I used the more up-to-date Ogre 1.7 dependencies to compile it, not the older Ogre 1.6 dependency package, so I can't be 100% sure that there are no unknown side effects. For me the Ogre 1.7 dependencies work fine with Ogre/Mogre 1.6, but I'm only using a small subset of Ogre functions in my projects.

PS: please PM me when the files are available on sourceforge, so I can take down the files on my server where I have limited bandwith available.

mstoyke

14-05-2010 00:34:17

I have created repositories on bitbucket where I'm currently uploading mogre 1.7.x and ogre 1.7.x project repositories for Mogre 1.7.1 VS2010/.NET4
http://bitbucket.org/mstoyke

They are both based on existing repositories (mogre from Gantz, Ogre official mercurial repo)
Both have a branch called MST where my changes are tracked

@Gantz: it should be possible for you to pull my mogre repository into yours, because the repository I uploaded to bitbucket is based on yours. (I just l*ve mercurial for making this kind of development possible :) )

Please be aware that I got it compiling without error but I did not have the time to test the compiled version at all. It may work, but it may also just blow up in your face or worse :)

I might be able to upload compiled binaries at the weekend, but it depends on the time I can find to test it. If somebody likes to volunteer to help testing just leave me a PM and I can send you a download link for the binaries.

mstoyke

18-05-2010 00:32:34

I found some time testing the Mogre 1.7.1 version that I compiled at the weekend. What I could test so far is a set of basic functions that worked without any code changes in my Mogre 1.6.5 based codebase. Initialization, basic scene management with few object and most object types worked flawless. I could even get MyGUI to work with its provided C++/CLI wrapper after I recompiled it to link again Ogre 1.7.1.

Until somebody else can mirror these files I will provide compiled binaries of Mogre 1.7.1 for VS2010/.NET4 here:
Mogre 1.7.1 VS2010 .NET4 binaries
This link will stay up for some time, but my bandwith is limited so I will have to remove it again later.

The sourcecode that I used to compile these files can be found in my bitbucket repositories, I posted them in my last post up ^ there somewhere :)

If anybody uses these binaries, please drop me a note (PM) if you encounter any problems (or maybe even if it works for you).

As mentioned before, these files can be used with MyGUI's managed wrapper and I also have a managed PhysX wrapper working with this version (eyecm-physx in case you want to know which one I use) and very soon I will have some very basic bindings for Particle Universe for .NET ready.

The physx wrapper works almost out-of-the box, but MyGUI required some little changes that I will also publish later. I'm not sure yet if I can publish the Particle Universe wrapper, just PM me if you're interested in a release and I will consider it if demand is high enough. I also have to contact the author of PU to check if he has any complaints about me releasing the wrapper code (PU code itself can not be published as the code is closed source, but at less than €10 it's a no-brainer to just buy it, and its worth every single cent).

EDIT: I had to finally remove the download again, this file was downloaded more than 1.100 times in May...

token

18-05-2010 14:55:08

Just as some feedback: Switching my prog to VS2010 on debug with your debug binaries worked without problems.

only thing i noticed, even though i am not currently using it, is, i think the HWBuffer is screwed again. At least i cant get a singleton ref to the HWBufferManager. Just mentioning it as many ppl complained after gantz' switch to 1.7.0. But maybe the usage has changed.

Still, Thank you. Very useful stuff :)

mstoyke

19-05-2010 23:45:59

Thank you for the feedback. I can use any help in testing this version, because it's a lot of code and features in ogre that I'm not yet using in my code (and probably never will). Even though I'm not a mogre maintainer (and have no intention to be one at the moment), I'm interested in a stable codebase, because I'm planning to use this (1.7.x) for my codebase for a long time to do a lot of rapid prototyping to test my ideas. I really can't afford too much trouble with debugging unstable or non-working stuff in mogre when I want some stuff working after only a few hours.

I didn't check for any problems with the HWBufferManager, because I'm not using it in my current codebase (yet). There might be a problem with it, but then it's also in the code that is in the official mogre repository, because that is what my version is based on. I only made sure that some compile problems with VS2010 got fixed that did not occur with VS2008.

If somebody really needs it working urgently, I might be able to fix it later, just leave me a note. Currently I'm right busy in getting all my "external" stuff working in 1.7 again. What really bothers me at the moment is, I had a module running with 1.6 that allowed me to "hook" into the ogre render queue (D3D only, not OGL) and access the device from "outside" with slimdx to do some magic on my own. This is not working with 1.7 anymore and until I got that fixed I won't have time to fix anything else.

GantZ

20-05-2010 08:02:00

Just want to add that i have test this code : (http://www.ogre3d.org/wiki/index.php/MO ... atingAMesh) with 1.7.1 (the vs2008 binaries) and it work without problems. HardwareBufferManager work as it should. I have just setup vs2010 on my config, and i will test you binaries with it later.

mstoyke

01-06-2010 18:21:07

Sorry everybody, I had to finally remove the compiled version of Ogre 1.7.1 for VS2010/.NET4 from my website. The file got downloaded exactly 1.149 times in May. It seem there is a much bigger interest in Mogre than somebody would assume from looking at these forums.

@Gantz: Could you upload the file to sourceforge, please? In case you did not download it before, just PM me and I can send you the file.

koirat

01-06-2010 19:03:14

Sorry everybody, I had to finally remove the compiled version of Ogre 1.7.1 for VS2010/.NET4 from my website. The file got downloaded exactly 1.149 times in May. It seem there is a much bigger interest in Mogre than somebody would assume from looking at these forums.


That's good to hear I was not very happy when I realized number of people that voted in a pool about switching to mercurial was something like 9.

xerios

01-06-2010 19:28:24

The file got downloaded exactly 1.149 times in May. It seem there is a much bigger interest in Mogre than somebody would assume from looking at these forums.

Actually it was me who redownloaded that file 1.148 times

j/k :D

Mogre has plenty of users using it, probably more than a thousand, it's just that most of them prefer to stay silent or just don't visit this section much.
Either way I'm really glad that this project is still alive and breathing, GantZ did an excellent job making this all happen and I'm really thankfull, cause this was the only best ( and obviously a much better ) alternative I could find to XNA :D

C# is getting more and more popular each year so I expect to see more people use Mogre for their projects

GantZ

01-06-2010 20:18:20

@Gantz: Could you upload the file to sourceforge, please?

Done ! Sorry about that, i somehow forget about it :) . I have updated the mogre 1.7 thread with the link to the file.

Seem a lot of people have adopt (or at least try out) vs2010, your file got download as much as the 1.7 mogresdk for vs2008. That pressure me to add a vs2010 sdk. :)

Beauty

04-06-2010 13:03:00

I could even get MyGUI to work with its provided C++/CLI wrapper [...]
As mentioned before, these files can be used with MyGUI's managed wrapper and I also have a managed PhysX wrapper working with this version (eyecm-physx in case you want to know which one I use).
[...] that I will also publish later.


I wasn't much here in the last months. If there is no or less information about the wrappers, it would be nice if you add it to the wiki. Maybe also you could provide little demos for the Mogre SDK or stand-alone? Sharing the information and code would be great for our community :)

mstoyke

26-06-2010 01:56:29

The mogre repository at bitbucket is now updated with my latest fixes for VS2010/.NET4. It will compile with either VS2008 for .NET 2.0 or VS2010 for .NET 4.0. Just follow the (updated) instructions in file "BUILD" in the repository. I also enabled the issue tracker for this repository, so bug reports and feature requests should go there.

I also created new binary releases for testing. I could not test them at all, so they might work or crash or eat your cake. Both releases were built from the same sources that you can find in the repository.

This time I've split the binary releases, there are the libraries in one file and all debug-info file in a separate file. That made sense, because the debug-infos are really big and not everybody needs them.

Please send us feedback if you try any of these files, we are currently working towards stable releases and every kind of feedback will help.

The binary releases can be downloaded here:
Mogre 1.7.1 for VS2010 .NET 4.0 libraries (13,6 MB)
Mogre 1.7.1 for VS2010 .NET 4.0 debug-infos (31,1 MB)

Mogre 1.7.1 for VS2008 .NET 2.0 libraries (13,6 MB)
Mogre 1.7.1 for VS2008 .NET 2.0 debug-infos (31,2 MB)

Edit: finally managed to upload VS2008 binaries.

Beauty

05-07-2010 15:23:27

I got a message.
One point I want to publish here, because I think it's related to the developers.
I don't know enough details.
I have some ideas/remarks concerning the wiki of Mogre and because you are the maintainer I directly send them to you:
[...]

3) maybe it's usefull to add a roadmap link to the main wiki page with status of each version what is implemented
example 1.6 100% ok
1.7 everything wrapped except for the classes ..
=> this could also be used as the overview for the remaining work (i saw a list in a forum thread, but for developers it's nice to get fast access to what can be used ..)
=> can also be used to give overview of the compatibility (example 1.7 supports .net 4.0, 2.0, ..)

manski

10-07-2010 15:45:21

I've been working on my MOGRE environment and while doing so, I've updated AutoWrap's GUI and added a readme with some explanations about how to use AutoWrap and "Attributes.xml". You can find the updated source in my Hg repository:

http://bitbucket.org/manski/mymogre

It would be nice if they could be integrated in the official repository.

Beauty

14-07-2010 19:52:21

If you do further development - maybe you can get write access to the "official" Mogre repository. (Just ask for access.)
This could be better than improved versions on different places.

manski

15-07-2010 08:36:09

If you do further development - maybe you can get write access to the "official" Mogre repository. (Just ask for access.)
This could be better than improved versions on different places.


This could be a solution. However, I'm not sure whether all of my "improvements" are liked by the community. I'd suggest the following solution: I will treat my MOGRE (btw: what's the official capitalization of "MOGRE"? Is it "MOGRE" or "Mogre" or "mogre"?) repository as a development branch and then, if I'm finished with something of which I think it should be in the official repository, I could push it there (perhaps after discussing it in the forums, if prudent). What do you think?

mstoyke

15-07-2010 23:29:29

I usually prefer patches in unified diff format for this. I usually have 2-3 different clones of the main repository that I use for "experiments" when I'm not sure if everything I try should be in the main repository. The big advantage is that the main repository will stay "clean" without too much abandoned side branches with obsolete code.

Mercurial, as much as I like it, has one disadvantage: if you commit big changes or files (e.g. compiled binaries) the repository tends to grow fast. And because every clone of the repository contains all revisions it can also contain a lot of unnecessary overhead. That's the reason why I did not just merge my old mstoyke/Mogre repository, because I committed a lot of binary dependencies. I only merged the source code changes that really mattered for the new revision (some RCS also call this cherry-picking).

We can handle this in one of two ways. Either you provide patches in unified diff format that I can merge into the main repository or I pull changes from your repository and merge them whenever you tell me to. If you prefer to work on the main repository directly I can also give you write access and you can merge changes yourself whenever new features or changes are ready. All I ask is that you don't push obsolete change sets and help me to keep the main repository clean from unnecessary overhead.

I saw that you checked in the auto-generated code for the wrapper in your repository, like I did in my old repository. That's a good example for commits that can help in a development branch to build Mogre with less pains, but these commit don't need to be in the main repository where only the necessary files should be committed that are not automatically created by following the build instructions.

I also like the idea of having a repository that contains the sources, project files and maybe even the compiled binaries of the dependencies that are needed to build Ogre and Mogre. But like I said before that should be kept in a separate development repository and not in the main repository. Not everybody has a broadband internet connection and I don't want to scare away users with slow internet access because it takes them hours to clone the repository.

I hope and could explain this in a way that you can see how I like the main repository to be organized. If you have any further questions just let me know. Also, if anybody disagrees with the way I see this, just let me know so that we can discuss alternatives here.

manski

16-07-2010 06:46:25

I totally agree. I'm in the business of software development for quite some time and I've always tried to avoid unnecessary files in my version control system repositories (which was Subversion before I switched to Mercurial). I had to check-in the auto-generated files in my repository because I was planning to patch them directly (rather than using AutoWrap for this) because I wasn't (and still am not) sure whether AutoWrap can apply the changes I want. However, I then decided to see whether the AutoWrap source code can be updated (in a clean way) to support what I want. For now I'm using the checked-in auto-generated sources for regression tests (i.e. whether the sources stay the same when I change something on the AutoWrap code).

As for the changes to the main repository: As I said earlier I'm coming from Subversion and am still learning Mercurial. So I'm not sure whether this is possbile but the best way would be to only merge specifiec changes/directories into the main repository without losing the history of the changes (which would be lost when using a patch). Of course, this depends on the size of the changes and for small changes I'd also prefer patches. But there must also be a way to merge larger changes (like the ones I'm doing on the AutoWrap code for example, when they're finished and if they're accepted by the community).

As for the slow internet connection: This may be a valid point but I doubt it's one that we can cling to forever. The repository will definitely grow and since Mercurial is a DVCS its (downloadable) size will never shrink. (See OGRE's repository which is already over 100 MB in size.) But I think as long as we don't check-in unnecessary files into the repository (especially unnecessary binary files) there should not be a problem.

mstoyke

16-07-2010 15:21:43

As for the slow internet connection: This may be a valid point but I doubt it's one that we can cling to forever. The repository will definitely grow and since Mercurial is a DVCS its (downloadable) size will never shrink. (See OGRE's repository which is already over 100 MB in size.) But I think as long as we don't check-in unnecessary files into the repository (especially unnecessary binary files) there should not be a problem.

It's OK for the repository to grow, that's a fact we can't change. But I've seen repositories grow by as much as 80-100 MB a week because they contained compiled binaries. That's something I don't want to see happen here.

I think we should use patches in unified diff format and try how it works for this project. If you don't know how to create them I'm happy to explain it to you, just let me know.

Beauty

20-07-2010 19:03:22

But I've seen repositories grow by as much as 80-100 MB a week because they contained compiled binaries. That's something I don't want to see happen here
The MogreSDK does contain binary and ressource files. It's one aim of it.
So this is one more reason to add it to a separate repository of out bitbucket account.


By the way - how we handle when add-on authors wants to add their projects to our bitbucket account?
Currently we have one repository MogreAddons for all add-ons together.
Maybe it would be better to create a new repository for each new add-on?
(Some of them could contain an amount of ressource files.)
For example smiley80 seems to be thinking about to move his Miyagi GUI system to our bitbucket account.
So maybe we create a repository called MogreAddon_Miyagi?
Nice would be a directory calles MogreAddons which contains different repositories. But I suppose this is not possible on bitbucket. Is this right?

mstoyke

20-07-2010 22:46:59

I can create any number of repositories in the Mogre account. All together with a 1GB limit, but we are still under 100MB so no problem there so far...

If it simplifies the organization of the addons I can create repositories for each of them separately, but still under one account so they can easily be found.

manski

21-07-2010 06:08:28

Currently we have one repository MogreAddons for all add-ons together.
Maybe it would be better to create a new repository for each new add-on?


It hink this would be nice. However, in this case, the addon maintainers should try not to grow their repositories too large (i.e. don't add binaries, unless they are very small and don't change very often), as otherwise we might run out of space someday. (On the other hand this day could be that far into the future that by then bitbucket would allow more than 1 GB for a free account.)

Unfortunately this means that we can't migrate the MogreSDK to the bitbucket account; but I think the MogreSDK works better with Subversion than with Hg (or any other DVCS) as you only check out one version of the binaries in their repository (and not all of them as when using Hg).

Beauty

28-04-2011 13:05:30

The function Ogre::Quaternion::getYaw() is wrapped
as property Mogre.Quaternion.Yaw.

Generally this is a good idea instead of using get/set functions.

On the other hand the getYaw() function has an optional parameter called reprojectAxis.
By default the method returns the 'intuitive' result that is, if you projected the local Z of the quaternion onto the X and Z axes, the angle between them is returned. If set to true though, the result is the actual yaw that will be used to implement the quaternion, which is the shortest possible path to get to the same orientation and may involve less axial rotation.

Source of documentation:
http://www.ogre3d.org/docs/api/html/cla ... 5e57873f5e


Currently there is no way in Mogre to use this switch.

My proposal:

* Keep the property Mogre.Quaternion.Yaw as it is.
* Add the new method Mogre.Quaternion.GetYaw(Boolean reprojectAxis).

The same apply for GetPitch() and GetRoll().

umityildiz

31-05-2011 18:39:28

mogre 1.7.3 will be ready when?

Cygon

02-08-2011 20:30:50

If I may make a small suggestion for the next Mogre release regarding autobild:

I was able to substantially reduce the size of Mogre.dll simply by disabling managed mode for the compiler while processing the native Ogre headers. The x86 build went from 12.3 MiB to 8.0 MiB, an experimental x64 build I undertook even went from 20.8 MiB to 9.0 MiB -- all for the cost of having AutoWrap add two lines around the Ogre headers.

The changes I made are detailed in this thread:
http://www.ogre3d.org/addonforums/viewtopic.php?f=8&t=14645

Beauty

02-08-2011 21:58:58

Hi cygon,

welcome to our Mogre (sub)community. :D

I'm very impressed.
Your first posts are no common newcomer questions.
Instead you looked deeply into the code, researched how it works, tried to apply improvements and published a detailled feedback. :shock:

It's very nice to see that you seems to be a well known programmer.
The current people which have such deep knowledge have less free time and were inactive for a while (or are online without posting).
So we are happy about each kind of support.

Did you use the Mogre.Builder project or did you build everything by our own?

I've done some builds of Mogre with Ogre 1.7.3 targeting x64. I also decided to build all dependencies from scratch to achieve a homogenous build
I think it's good to have a homogenous build.
Most great would be to have a bundle of Mogre and add-ons which are build by one hand.
(It can cause problems, if somebody uses binaries which were not build for the same Mogre version.)
So if you like to play around with add-ons, feel free to publish the result as bundle.
The binaries of the current MogreSDK are older than one year.
If you solve the build problems, we could use your binary bundle to fresh up the MogreSDK.

Well, I don't want to force you to do anything what you don't like to do.
But in the case you enjoy to support our small Mogre (sub) community your efforts are very welcome.

I will invate a few (mostly inactive) users with deep Mogre experience to this topic. Perhaps they will support your improvement work by answering your questions.

Did you read a little bit in our forum?
If not I can give you a few forum links, which can search for some posts and topics which could be interesting for your. (related to the Mogre development)


How long time do you use Mogre? Was your last weekend the first time?
Did you use C++ Ogre before?
Do you want to use Mogre for a hobby project or in relation with your working place?
Where did you get your programming experiences?
In general - I'm just interest to know a little bit more of you. :wink:

Beauty

02-08-2011 22:05:26

Related to the Mogre maintainers:
All posted bug reports (which I found) I added to the Mogre bugtracker.
So if anybody touches the Mogre core code, feel free to have a look to it and perhaps fix some bugs. Some of them seems to be easy to fix.

Beauty

02-08-2011 22:10:22

I've been working on my MOGRE environment and while doing so, I've updated AutoWrap's GUI and added a readme with some explanations about how to use AutoWrap and "Attributes.xml". You can find the updated source in my Hg repository:

http://bitbucket.org/manski/mymogre

It would be nice if they could be integrated in the official repository.

It's one year ago, but I'm not shure.
Were Manskis improvements added to the official repository?
If not I would be happy if you found any way to do so.
It would be sad if Manskis improvements were done for nothing.

Cygon

03-08-2011 20:44:55

Did you use the Mogre.Builder project or did you build everything by our own?
For now, I've built everything on my own. I'm all for automation, but for now I wanted to know exactly what libraries my build uses, so I have to admit that I didn't even look at Mogre.Builder yet.

If you solve the build problems, we could use your binary bundle to fresh up the MogreSDK.
I'd feel honored if you think you can use them!
I'll see if I can figure out the OpenGL issue, probably it's just some double-delete or wrapper shutdown order thing.

How long time do you use Mogre? Was your last weekend the first time?
Did you use C++ Ogre before?
Do you want to use Mogre for a hobby project or in relation with your working place?
Where did you get your programming experiences?
In general - I'm just interest to know a little bit more of you. :wink:


Heh, I didn't expect such a warm welcome :) - I only checked out Mogre over the weekend and haven't done much with it yet.

Right now, I'm playing the engine shopping game for a hobby project -- I own a SunBurn license for XNA, but considering all the work still necessary to create a decent infrastructure for a game, I wanted to see if I could skip some of that by using Ogre/Mogre with its integrated scene management. My primary concerns right now are simple scene loading (the dotScene format sounds interesting), character animation and a smooth import path from Blender.

I do know my way around C++ and Boost and I've had the, erm, pleasure of wrapping a huge commercial project via C++/CLI before. 'been a professional developer for the past 12 years (not games-related), hobbyist before that and self-employed for the past 2 years.

Beauty

04-08-2011 10:55:42

Thanks for your detailled answer.

On Tuesday I wrote messages to 6 or 7 inactive Mogre developers and asked them to support you if they have time. (All the writing took about 2 hours! But I think it's for a good aim. So I like to do that job. We are a community and communication is an important point.)

I got answers that they are happy to see that there is still an interest in Mogre and perhaps by your work we get a project fresh up. Most of them are very busy, especially by their jobs or universities. But they want to try to help you with your problems.
Here is a sub part of an answer:
I'd be happy to help Cygon out, please let him know that he can contact me directly at any time.

Well, now I have to return to my work. See you later. :D

umityildiz

15-10-2011 23:54:11

I think about the months of development Mogre v1.8 binary file can be prepared.

McDonte

17-10-2011 11:08:20

This is because there is no maintainer at the moment... and so far there was nobody willing to take up the work.

Pyritie

04-11-2011 13:54:02

I dunno where to put this, but BillboardSet.SetTextureCoords wants a pointer, which is rather un-C#-like

for now I'm using an unsafe {} block, though it still bugs me a little