Howto move from 1.7 to 1.8?

[mkultra333]

I'm using 1.7.4, and I'm a long way into my project. I've been considering updating to 1.8, not for any great need but just so my project doesn't fall too far behind the current state of ogre. I'm undecided, I might do it now, or I might leave it for the next project.

I was looking for any info on upgrading a project from 1.7 to 1.8, but haven't found any. Are there any pages on doing such an update?

[bstone]

I don't think there were major interfaces broken in 1.8 compared to 1.7 - mainly new features added and some fixes. I would try compiling your project with Ogre 1.8 right away.

[mkultra333]

The prereq page suggests boost 1.49.

I just want to download the boostpro installers to make things simple, but there's no 1.49 one, the lastest is 1.51. Would it matter if I use that instead?

[syedhs]

Just compile, if there are any unfathomable errors, then search the forum

[Kojack]

Boost 1.50 and above added another dependency or two, you'll need to link with one or two more boost libraries. So some info on using ogre 1.8 (specifically library list in the linker) may be slightly different depending on which boost version it was intended for

[mkultra333]

I ended up using my pre-existing boost 1-44. The boostpro 1.5.1 installer hit a malfunction toward the end. (Plus I'm trying to save space on my poor 128 gig SSD drive, and a new Boost eats up 4 gig or so.) Most other stuff I have is using 1-44. Think I'll leave it at that till there's good reason to update boost.

So, done the whole cmake thing, environment variables thing, forgot to update the headers folders so had ok compiles but crashes on starting the exe for a while. Think I finally sorted all that. So the first issue that pops up is the following error.

Code: Select all

1>.\OgreFramework.cpp(28) : error C2039: 'ms_Singleton' : is not a member of 'Ogre::Singleton<T>'
1>        with
1>        [
1>            T=OgreFramework
1>        ]
1>.\OgreFramework.cpp(28) : error C2998: 'OgreFramework *ms_Singleton' : cannot be a template definition

which is triggered by this line here,

Code: Select all

template<> OgreFramework* Ogre::Singleton<class OgreFramework>::ms_Singleton = 0;

I started this project back in 1.6, and it's built around the OgreFramework from that period.

Edit: Sorry, should have searched the forums first. Just needed to change ms_Singleton to msSingleton.

[mkultra333]

Had a crash because of some problem with OgreOggSound, so I removed the sound code and recompiled it.

My game ran, but it's messed up badly. No geometry is rendering, although entities showup. Log doesn't seem to show up anything. I'm using a custom deferred shading system and custom lighting and shadommap methods. No compositors. First thing that comes to mind is maybe the Multiple Render Targets stuff isn't working anymore. Will have to look into it.

Edit: Probably isn't an MRT thing, since geometry doesn't show on wireframe renders either.

[bstone]

Hmm. Custom stuff... That sure could be affected. But can you compile and run a few samples including the standard deferred shading sample? Just to see if something global is messed up.

[mkultra333]

The ogre demo programs run fine, including the def shading sample.

I think it's probably something trivial, since the methods and shaders for the world geometry and the methods and shaders for the entities (monsters and items) aren't very different, and the entities are rendering fine. My guess is some little thing like bounding boxes or visibility flags or something in 1.8 is subtly different from 1.7. Both 1.7 and 1.6 had various issues with the bounding boxes of entities that I'd worked around. So my guess is that for some reason or other the engine is deciding that the world geometry isn't visible even though it is.

Won't be able to work on it again until Sunday, but I'll be systematic and try to see if I can create and show any geometry at all, then work out what the difference is. Fortunately it isn't a critical problem. Worst case I can just stick with 1.7.4, since I'm not actually updating for any good reason, just didn't want to fall to far behind.

[bstone]

I guess for your game a few good reasons could be the improved HW instance rendering and support for depth buffer management available in 1.8.

[mkultra333]

Yeah, the hardware instancing is one of the things I'm interested in. I've already done so much work with my "pseudo-instancing" that there might not be a lot of gains to be had from it at this stage, but I'd like to run some tests and see. I was also thinking of keeping my pseudo-instancing for the core monsters, but adding a hardware instanced zombie or something that occasionally crops up in really large numbers.

I don't know anything about the depth buffering in 1.8. Does that mean more access to and control of the zbuffer? If so, that could be very handy for my 3DVision compatible render path (an alternative to the main render path), since it requires I re-render a z several times due to an inability to use my MRT depth texture in 3DVision mode. So while the fps is still acceptable, it isn't as good for batching as the main renderer.

[bstone]

I don't know anything about the depth buffering in 1.8. Does that mean more access to and control of the zbuffer?

Yeah, take a look at OgreDepthBuffer.h/cpp from v1.8. That looks like a major improvement to me.

[mkultra333]

Got home from work Saturday afternoon, and decided to have a quick look and see if I could spot the problem, based on my suspicion is was some AABB or visibility flag problem.

A given entity for some geometry mesh has a bounding box of (-5, -5, -5) (5, 5,5 ) and EXTENT_NULL, which is the ogre default. I don't know if it should be that. The entity's mesh has the correct min/max, but is also EXTENT_NULL. I think that is the cause of the problem.

In my code I was setting the bounding box of the different bits and zones of geometry with code like this:

Code: Select all

			// set axis aligned bounding box of this mesh
			AABB.setMinimumX(flMinX) ; 
			AABB.setMinimumY(flMinY) ; 
			AABB.setMinimumZ(flMinZ) ;
			AABB.setMaximumX(flMaxX) ; 
			AABB.setMaximumY(flMaxY) ; 
			AABB.setMaximumZ(flMaxZ) ;

			m_pZoneMesh[nMOIndex]->_setBounds(AABB, false) ;

where the flMin and flMax values had already been worked out as the bounds. This worked fine in the versions prior to 1.8, but not now. I changed it to the following:

Code: Select all

			AABB.setExtents(flMinX, flMinY, flMinZ, flMaxX, flMaxY, flMaxZ) ;
			m_pZoneMesh[nMOIndex]->_setBounds(AABB, false) ;

and then the bounding box started working properly, and the world geometry rendered. The entity still stayed as a default EXTENT_NULL AABB, but this doesn't seem to matter.

Weird, since I had a look at the 1.7.4 and 1.8.1 setMaximum code and it's the same, just a simple inlined function that puts the value into the AABB and doesn't do any updating of the EXTENT type. I'm a bit perplexed, I guess my old code should probably never have worked in the first place, but something in 1.7.4 got around to fixing the EXTENT type on it's own, while 1.8.1 doesn't.

I'll have to check all the other AABBs in my code and check they still work. I think most other places I already use setExtents.

[bstone]

Yeah, AABB.setExtents() resets the extent field to EXTENT_FINITE while AABB.setMinimumX() and the likes never touch it. By default it's EXTENT_NULL as you mentioned. I think that some piece of code in 1.7.4 does not honor the extent flag and works as if it were EXTENT_FINITE while in 1.8 that's been fixed and it properly handles EXTENT_NULL now.

[mkultra333]

That explains it. Fortunately I only use the setMaximumX etc functions in a few places. Most others I used setExtents or setMaximum/setMinimum which, unlike the specific XYZ variants, also update the EXTENT type.

So preliminary results seem to indicate the project is working again. Didn't have to do too much to get it moved from 1.7.4 to 1.8.1.

Change ms_Singleton to msSingleton in one place.
Add an Ogre::Quaternion::IDENTITY to all my billboardchain addChainElement calls.
Change all AABB.setMaximumX,Y,Z etc calls to either setExtents or setMaximum, setMinimum.

Using boost 1.44 seems to be working ok too.

Will report anything else if it crops up.

Edit: Rebuilt OgreOggSound.dll using latest version and against Ogre 1.8.1, sound works again.