Final SR 2.7 with Ogre 1.13 resources issue fixing (Critical)

[cryham]

Hi all I didn't have much time last month. But this one issue is holding the 2.7 release.

BTW I updated compiling wiki, got more complicated, hope it's all true. So latest git master version works great with Ogre 1.9 (needs 1 line changed). It builds fine with Ogre 1.13 but it crashes on next (or first?) track loading.

So I guess I have few questions, for @paroj or anyone who was updating own sources after Ogre 1.11 resources change.

• For SR, now Ogre 1.13 needs to be built with variables in cmake: OGRE_NODELESS_POSITIONING set to ON and OGRE_RESOURCEMANAGER_STRICT set to 0 (deprecated old) but I still need to make SR build and work without those right? So with defaults. Which is what will be available in various distros with Ogre 1.13, correct?
• What do I need to do to change SR code for this new RESOURCEMANAGER setting? I started fixing this and it's not going easy. The only way I have is to add try catch blocks around any resource destroy or create (Entity etc) and if it crashes on track load there it means resource group is wrong set (default) or so. Is there any better way? E.g. I added if here:

	if (TextureManager::getSingleton().resourceExists(sTex))
	    TextureManager::getSingleton().remove(sTex);

And also changed:

	TextureManager::getSingleton().remove(sName);

to:

	if (!TextureManager::getSingleton().resourceExists(sName))
		return;
	try
	{
		TextureManager::getSingleton().remove(sName);
	}
	catch (Exception ex)

And another change to with if:

	MaterialPtr mat = MaterialManager::getSingleton().getByName(matName);
	if (mat)
		MaterialManager::getSingleton().remove(matName);

• Next BTW I have some warnings in code, for isNull(). So I'm changing from:

	try {
	TexturePtr tex = TextureManager::getSingleton().getByName("waterDepth.png");
	if (!tex.isNull())
		tex->reload();

to:

	if (tex)
	    tex->reload();

Is this right now?

I think I had some group names wrong in SR and it is crashing now. Also I had a crash in shiny dtor in: OgreMaterial::~OgreMaterial(). IDK if my fault.

Any suggestions would be welcome. I mean how should this be done the proper way now in Ogre 1.13 default?

[paroj]

The only way I have is to add try catch blocks around any resource destroy or create (Entity etc) and if it crashes on track load there it means resource group is wrong set (default) or so. Is there any better way

yes, remove the resource by Ptr. This way it is uniquely identified and the manager does not have to search for it in the groups, which is also faster.

For resource creation, you can also register a ResourceLoadingListener, to ignore duplicate names as before.

Next BTW I have some warnings in code, for isNull(). So I'm changing from:

yes, this is correct.

[cryham]

Thanks @paroj, but could you answer my first question about OGRE_NODELESS_POSITIONING and OGRE_RESOURCEMANAGER_STRICT from first post? So, do I need to deal with this resources bug, and can't set those flags because Ogre 1.13 got from repositories (not built from sources) will have it this new way, right?

So far I found out that CarModel creation is faulty with its resource groups and vegetation models. So in void CarModel::Create(), using resGrpId = sCarI; for group name. This is like ancient code and I don't remember it much. We duplicate car body for changing colors, and have groups for cars to have more of them IIRC.

I tried fixing it but IDK if I made it better or worse. I do have white glass and and ext/interior, only car body has color. Ah and minimap is yellow black. Can someone test latest master 58bd82c5f98f7f16afe93ee59c5ec07ac555c602 ? @AsciiWolf? When testing set trees = 0.000000 in game.cfg. I didn't look into that yet.

I'm testing on Debian 11 with Ogre 1.13 and MuGui build from sources now. Bu so far I can't get it to look okay and behave normally, loading next track, just first loads. Editor seems to work a bit better, at least I see trees.

Honestly this issue is pissing me off too much to continue. I still don't have any intelligent way of telling me in logs what was wrong. And trying a change by loading just to get a crash is annoying.

[AsciiWolf]

I have tested the latest master and the game still crashes on next track loading.

[cryham]

Do you see all car materials normally? Or any of the problems like white glass etc or yellow minimap too?

[AsciiWolf]

I have noticed one small glitch:

glitch.webm

The green line gets displayed inside the car. But everything else seems to look fine.

[paroj]

So, do I need to deal with this resources bug, and can't set those flags because Ogre 1.13 got from repositories (not built from sources) will have it this new way, right?

this is up to the package maintainer to decide. If there are many legacy applications that break, the flags are there as a last resort. For new code, the default flags make more sense though and I expect the distros to follow that.

However, with flatpack and snap formats it really not that important anymore IMO.

I still don't have any intelligent way of telling me in logs what was wrong.

If you are building Ogre from source anyway, just search for OGRE_RESOURCEMANAGER_STRICT in it. It does not change all that much. There you can replace the asserts and exceptions with logError. It will log everything thats wrong at once like this.

[cryham]

@AsciiWolf :smile: that's not a glitch, it's how things work. Same happens with water, mud, will be in car. Only grass won't since I wrote hiding it in shader. Anyways If you have car and minimap then I'd assume you have this OGRE_RESOURCEMANAGER_STRICT set to 0 (not 1 or 2, I got 2 which is STRICT).

Ok, great thanks, I will do it. I suspect I need to rebuild MyGui too, after changing Ogre sources right?

I tried game without car or wheels, no change. So I suspect either textures or materials, especially those dynamic.

In editor I can reload tracks fine and load others too, if I set use_imposters = off in editor.cfg. But with on there is a bug now, probably some group inconsistency or sth worse IDK. Crash happens in: ImpostorTexture::~ImpostorTexture() on either TextureManager::getSingleton().remove(texName, "BinFolder"); or TextureManager::getSingleton().unload(texName, "BinFolder"); I added "BinFolder" here, but it didn't fix it. I also added if resourceExists and try catch block before, but strangely it didn't help either, now crashes somewhere else with all this.

Other issues: Do we need some extra plugin or something to save screenshots as jpg now? Why on earth do I see now some darker lines on terrain from weird skirt self shadow issue, that wasn't before.

[AsciiWolf]

Yup, I have OGRE_RESOURCEMANAGER_STRICT set to 0. :-)

Here are more details.

[AnotherFoxGuy]

Do we need some extra plugin or something to save screenshots as jpg now?

I believe that Codec_FreeImage adds support for jpegs

[paroj]

Crash happens in: ImpostorTexture::~ImpostorTexture()

you might want to take a look on upstream: https://github.com/OGRECave/ogre-pagedgeometry/commit/3d0c61d3641f43873e783f681b2df8369f600e6d

The fix is likely removing by Ptr as suggested earlier.

Ok, great thanks, I will do it. I suspect I need to rebuild MyGui too, after changing Ogre sources right?

Only if you make changes to the headers. If your changes are limited to the cpp, then no rebuild is needed. (aka ABI is comaptible)

Do we need some extra plugin or something to save screenshots as jpg now?

you are likely using Codec_STBI, which currently does not expose jpg writing. For that you need Codec_FreeImage. Here, using try catch to fall back to png would actually work.

Some final notes for a quick and dirty OGRE_RESOURCEMANAGER_STRICT porting:

// changing all instances in your code from
ResourceGroupManager::getSingleton().createResourceGroup(name);
MeshManager::getSingleton().getByName(name);
MeshManager::getSingleton().unload(name);

// to
ResourceGroupManager::getSingleton().createResourceGroup(name, true);
MeshManager::getSingleton().getByName(name, RGN_AUTODETECT);
MeshManager::getSingleton().unload(name, RGN_AUTODETECT);

will enable most of the legacy behavior and make it explict

[cryham]

Great, thanks for help. I will be investigating further. I didn't even realize there are changes in pagedgeometry.

[cryham]

But, on the other hand, @AnotherFoxGuy, can we specify for Ogre build: OGRE_RESOURCEMANAGER_STRICT to 0 OGRE_NODELESS_POSITIONING to ON or fork that Ogre build with these options maybe? Just to have at least windows release earlier if it fixes it.

[AnotherFoxGuy]

The conan build is already set to build OGRE with ogre3d:nodeless_positioning=True and ogre3d:resourcemanager_strict=off https://github.com/stuntrally/stuntrally/blob/master/cmake/DependenciesConfig.cmake#L19

[cryham]

Ah okay, thanks. Right, so there seems to be another issue causing crashes on next track loading. I've set back OGRE_RESOURCEMANAGER_STRICT to 0 in my CMakeCache for Ogre 1.13 building. I can finally see normal car materials and drive. I think I'll postpone this STRICT 2 fixing for future, when it'd be necessary to fix it. Seems 0 is the default anyway.

But I do have a crash on like 3rd or other track load. So far I didn't catch anything useful, I don't see callstack, code is in unknown location, log has nothing bad. Or even worse, debugger says error: can't read instructions at that address. I can't even. And this is Debug build.

So, I was going yet again through the list of changes in Ogre notes for 1.11, 12 and 13 in docs. And I'm pretty sure we need to deal with one thing that was done in SR and is now not allowed: declaring a texture in material, and then creating it in code later. This is: Textures must not be declared in an Ogre Script and be manually created. in 1.11-Notes.md I can't remember which textures were so, probably few, will look closer. But what would happen in such case? Will it crash, or throw, is the behavior defined, always the same?

[paroj]

one thing that was done in SR and is now not allowed: declaring a texture in material, and then creating it in code later. This is: Textures must not be declared in an Ogre Script and be manually created. in 1.11-Notes.md I can't remember which textures were so, probably few, will look closer. But what would happen in such case? Will it crash, or throw, is the behavior defined, always the same?

yes, the fallback warning texture will be used (e.g. your minimap turns yellow-black).

Note that you still can manually create those textures, if you do so before any materials are loaded. I think I fixed some of these instances when doing the initial 1.12 porting.

[cryham]

Wow, I think I fixed this now. Checked on Debian 11 and on Windows 10 from autobuild https://github.com/stuntrally/stuntrally/actions/runs/3405036887 Doesn't crash on loading tracks for me. Still needs those: OGRE_NODELESS_POSITIONING set to ON and OGRE_RESOURCEMANAGER_STRICT set to 0