Upgrade to Ogre 13

[tritonas00]

Closes #2599
Closes #2351
Fixes #2353
Fixes #2921

Known issues:

• full cache generation is slower than before (zzip vs zip) but we can live with it
• caelum has several issues: moon is misplaced near the sun, time from terrains that specify time (f1 testtrack for example) doesn't work, "Time of day" slider goes by steps (hacked around it tritonas00@110474e#diff-c4f465bb94cfed5385e4065b2906a0857b3819501dcc5e68ffadda5863963d9b but its not correct), extra weather (like snow/rain) doesn't work. fixed with Main: Zip - correctly forward filename to opened datastream OGRECave/ogre#2597
• Imgui has inverted colours on DirectX 9
• Load aspen, then back to menu and load nhelens
• https://sim-monsters.com/files/file/3734-orlando-2021/ crashes if you load it directly after opening RoR. If you load another map first (like f1 testtrack) and then orlando, it works. This causes the crash https://github.com/tritonas00/rigs-of-rods/blob/ogre13/source/main/terrain/TerrainObjectManager.cpp#L642-L645
• Load Semois then RoR Compound:

Thread 1 "RoR" received signal SIGSEGV, Segmentation fault.
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign (this=0x90, __str="31.os") at /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:279
279	/usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc: No such file or directory.
(gdb) bt
#0  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign (this=0x90, __str="31.os")
    at /usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:279
#1  0x00007ffff759f2be in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign (__str="31.os", 
    this=<optimized out>) at /usr/include/c++/12.2.0/bits/basic_string.h:1571
#2  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator= (__str="31.os", this=<optimized out>)
    at /usr/include/c++/12.2.0/bits/basic_string.h:805
#3  Ogre::Resource::_notifyOrigin (origin="31.os", this=<optimized out>)
    at /home/babis/Downloads/ror-dependencies/Dependencies_Linux/include/OGRE/OgreResource.h:412
#4  Caelum::CaelumSystemScriptTranslator::translate (this=0x555555fd9d38, compiler=0x555555c8f9a0, node=...)
    at /home/babis/Downloads/ror-dependencies/Source/caelum/main/src/CaelumScriptTranslator.cpp:410
#5  0x00007ffff78aec7a in Ogre::ScriptCompiler::compile (this=0x555555c8f9a0, nodes=..., group=...)
    at /home/babis/Downloads/ror-dependencies/Source/ogre/OgreMain/src/OgreScriptCompiler.cpp:363
#6  0x00007ffff78af100 in Ogre::ScriptCompilerManager::parseScript (this=0x555555c8f960, stream=..., 
    groupName="bundle /home/babis/.rigsofrods/mods/RoRCompound-0.4.zip")
    at /home/babis/Downloads/ror-dependencies/Source/ogre/OgreMain/src/OgreScriptCompiler.cpp:1614
#7  0x00007ffff7876d64 in Ogre::ResourceGroupManager::parseResourceGroupScripts (this=0x555555c7a470, grp=0x55555c6e3af0)
    at /home/babis/Downloads/ror-dependencies/Source/ogre/OgreMain/src/OgreResourceGroupManager.cpp:835
#8  0x00007ffff78771aa in Ogre::ResourceGroupManager::initialiseResourceGroup (this=0x555555c7a470, 
    name="bundle /home/babis/.rigsofrods/mods/RoRCompound-0.4.zip")
    at /home/babis/Downloads/ror-dependencies/Source/ogre/OgreMain/src/OgreResourceGroupManager.cpp:112
#9  0x00005555558db013 in RoR::CacheSystem::LoadResource (this=0x555555c1c6f0 <RoR::App::g_content_manager+16>, t=...)
    at /home/babis/Downloads/ror-dependencies/rigs-of-rods/source/main/resources/CacheSystem.cpp:1143
#10 0x0000555555627da9 in RoR::GameContext::LoadTerrain (this=0x555555c1ac60 <RoR::App::g_game_context>, filename_part="RORC3d.terrn2")
    at /home/babis/Downloads/ror-dependencies/rigs-of-rods/source/main/GameContext.cpp:114
#11 0x00005555555ec5cf in main (argc=<optimized out>, argv=<optimized out>)
    at /home/babis/Downloads/ror-dependencies/rigs-of-rods/source/main/main.cpp:546

It happens because of this it seems:

14:24:42: Parsing script 31.os
14:24:42: [RoR|ContentManager] Skipping resource with duplicate name: '31.os' (origin: '')

Reminder https://github.com/tritonas00/rigs-of-rods/blob/ogre13/cmake/DependenciesConfig.cmake#L33-L50

[ohlidalp]

Purpose: To finally catch up with OGRE development.

Estimate: We're waiting for OGRE 13.5 to be released as it contains some fixes for our use cases. Then, IDK, let's say 3 man days.

[ohlidalp]

Builds OK on my desktop, but crashes on Caelum init (main.cpp, line 140). Having or not having Caelum in 'plugins.cfg' has no effect.

Exception thrown at 0x00007FFB5B20D97D (OgreMain.dll) in RoR.exe: 0xC0000005: Access violation reading location 0x00000000000000A0.

My Debug tools are showing something I don't really understand - both debug and release binaries seem to be loaded at once:

MODULE         | PATH                                                   | SYMBOL STATUS                                   | SYMBOL FILE                  
OgreMain_d.dll	C:\Users\Petr\builds\rigs-of-rods\bin\OgreMain_d.dll	Symbols loaded.	                                   C:\Users\Petr\.conan\data\ogre3d\13.5.1\anotherfoxguy\stable\build\406faf6c0e2d6cbd5ae2f27cf88c6546e6e0a2ba\build\bin\Debug\OgreMain_d.pdb	
OgreMain.dll	C:\Users\Petr\builds\rigs-of-rods\bin\OgreMain.dll	Binary was not built with debug information.		

In the stacktrace, I see only the non-_d modules employed so I can't investigate

 	OgreMain.dll!00007ffb5b20d97d()	Unknown
 	OgreMain.dll!00007ffb5b3724b6()	Unknown
 	Caelum.dll!00007ffb5cbbec20()	Unknown
 	Caelum.dll!00007ffb5cbbc84f()	Unknown
>	RoR.exe!main(int argc, char * * argv) Line 140	C++
 	RoR.exe!WinMain(HINSTANCE__ * hInst, HINSTANCE__ * __formal, char * strCmdLine, int __formal) Line 1063	C++
 	[External Code]	

PS: I clicked the "Close issue" by mistake, I'm sorry.

[ohlidalp]

@AnotherFoxGuy It looks like OGRE is built with /fp:fast on Debug and as result, I get this assert from OgreMath.h triggered:

        static inline bool isNaN(Real f)
        {
#if defined(__FAST_MATH__) || defined(_M_FP_FAST)
            assert(false && "not available with fast math");
#endif
            // std::isnan() has non-portable behaviour on MSVC
            // However NaN always fails this next test, no other number does.
            return f != f;
        }

__FAST_MATH__ is a GCC flag (I googled https://stackoverflow.com/questions/43140581/how-to-use-the-gcc-preprocessor-macro-fast-math), _M_FP_FAST is a visual studio flag ( I googled https://stackoverflow.com/questions/67852966/check-what-compiler-flag-is-set-within-c-code)

ROR is built with /fp:precise on Debug but /fp:fast on Release which I suspect is wrong, let me check master.

UPDATE: I checked with #2965 and it builds Release with /fp:fast

UPDATE2: I looked into conan data and OGRE 1.11x also builds with /fp:fast on Debug. I looked to the sources and obviously Paroj added that assert in between (OgreMath.h, line 548):

        static inline bool isNaN(Real f)
        {
            // std::isnan() is C99, not supported by all compilers
            // However NaN always fails this next test, no other number does.
            return f != f;
        }

UPDATE3: I built OGRE 13.5 fresh with cmake ... -D "CMAKE_BUILD_TYPE=Debug", then built all as Debug in my VisualStudio 2022, started SampleBrowser and got the assert triggered. This means Ogre is shooting itself to the foot on Debug by default. The commit which added the assert: OGRECave/ogre@e4c82fe

[CuriousMike56]

Tried building this branch using https://github.com/RigsOfRods/ror-dependencies with this PR RigsOfRods/ror-dependencies#56 applied. Dependencies build fine but attempting to build RoR (Release) fails:

11>C:\Users\Mike\Documents\GitHub\ror-dependencies\build\Dependencies_Windows_Visual-Studio-17-2022\include\fmt\core.h(1757,7): error C2338: static_assert failed: 'Cannot format an argument. To make type T formattable provide a formatter<T> specialization: https://fmt.dev/latest/api.html#udt' (compiling source file C:\Users\Mike\Desktop\builds\rigs-of-rods-terrain-rtss\source\main\physics\ActorSpawner.cpp)
11>C:\Users\Mike\Documents\GitHub\ror-dependencies\build\Dependencies_Windows_Visual-Studio-17-2022\include\fmt\core.h(1776): message : see reference to function template instantiation 'fmt::v9::detail::value<Context> fmt::v9::detail::make_value<Context,RigDef::DifferentialType&>(T)' being compiled
11>        with
11>        [
11>            Context=fmt::v9::format_context,
11>            T=RigDef::DifferentialType &
11>        ] (compiling source file C:\Users\Mike\Desktop\builds\rigs-of-rods-terrain-rtss\source\main\physics\ActorSpawner.cpp)
11>C:\Users\Mike\Documents\GitHub\ror-dependencies\build\Dependencies_Windows_Visual-Studio-17-2022\include\fmt\core.h(1895): message : see reference to function template instantiation 'fmt::v9::detail::value<Context> fmt::v9::detail::make_arg<true,Context,fmt::v9::detail::type::custom_type,RigDef::DifferentialType&,0>(T)' being compiled
11>        with
11>        [
11>            Context=fmt::v9::format_context,
11>            T=RigDef::DifferentialType &
11>        ] (compiling source file C:\Users\Mike\Desktop\builds\rigs-of-rods-terrain-rtss\source\main\physics\ActorSpawner.cpp)
11>C:\Users\Mike\Documents\GitHub\ror-dependencies\build\Dependencies_Windows_Visual-Studio-17-2022\include\fmt\core.h(1917): message : see reference to function template instantiation 'fmt::v9::format_arg_store<fmt::v9::format_context,RigDef::DifferentialType>::format_arg_store<RigDef::DifferentialType&>(RigDef::DifferentialType &)' being compiled (compiling source file C:\Users\Mike\Desktop\builds\rigs-of-rods-terrain-rtss\source\main\physics\ActorSpawner.cpp)
11>C:\Users\Mike\Documents\GitHub\ror-dependencies\build\Dependencies_Windows_Visual-Studio-17-2022\include\fmt\core.h(1918): message : see reference to function template instantiation 'fmt::v9::format_arg_store<fmt::v9::format_context,RigDef::DifferentialType>::format_arg_store<RigDef::DifferentialType&>(RigDef::DifferentialType &)' being compiled (compiling source file C:\Users\Mike\Desktop\builds\rigs-of-rods-terrain-rtss\source\main\physics\ActorSpawner.cpp)
11>C:\Users\Mike\Documents\GitHub\ror-dependencies\build\Dependencies_Windows_Visual-Studio-17-2022\include\fmt\core.h(3205): message : see reference to function template instantiation 'fmt::v9::format_arg_store<fmt::v9::format_context,RigDef::DifferentialType> fmt::v9::make_format_args<fmt::v9::format_context,RigDef::DifferentialType&>(RigDef::DifferentialType &)' being compiled (compiling source file C:\Users\Mike\Desktop\builds\rigs-of-rods-terrain-rtss\source\main\physics\ActorSpawner.cpp)
11>C:\Users\Mike\Desktop\builds\rigs-of-rods-terrain-rtss\source\main\physics\ActorSpawner.cpp(2516): message : see reference to function template instantiation 'std::string fmt::v9::format<RigDef::DifferentialType&>(fmt::v9::basic_format_string<char,RigDef::DifferentialType &>,RigDef::DifferentialType &)' being compiled

EDIT: Turns out conan uses fmt version 8.0.1 while ror-dependencies currently is set to 9.1.0: CuriousMike56/ror-dependencies@c77f0ee

[CuriousMike56]

RTSS materials are broken in videocameras, overview map and reflections:

[tritonas00]

RTSS materials are broken in videocameras, overview map and reflections:

that happens with both render systems?

[CuriousMike56]

RTSS materials are broken in videocameras, overview map and reflections:

that happens with both render systems?

Yes, OpenGL has the same problem.

[CuriousMike56]

RTSS demo terrain: https://drive.google.com/file/d/1uJj7Igbu4r9-AQSJx7am9l8jDR3GUymn/view?usp=drivesdk

It seems RTSS textures do appear in reflections right after loading the terrain, but goes black once you spawn a vehicle:

[ohlidalp]

OGRE has 2 methods of updating RTT textures: automatically when rendering main camera, and manually. We use the manual method for everything. This is how it's controlled: https://github.com/RigsOfRods/rigs-of-rods/search?q=setAutoUpdated

On related note:
Our dynamic reflections are global, there is a single envmap always rendered from the active vehicle. On loading terrain it's initialized by rendering the middle of the map. Technically it's not hard to make envmap per-actor, but performance is an obstacle. It's not the GPU cost of rendering but the CPU cost of sorting out the scene before rendering. Even with a lo-res render you still need to do all the work and the same batching issues apply.

[tritonas00]

With Ogre latest master

rigs-of-rods/source/main/terrain/TerrainGeometryManager.cpp

Line 468 in cbebeeb

// Fix for OpenGL, otherwise terrains are black

is not an issue anymore it seems.