search

RigsOfRods / rigs-of-rods

Main development repository for Rigs of Rods soft-body physics simulator
https://www.rigsofrods.org
GNU General Public License v3.0
1.01k stars 175 forks source link

Upgrade to Ogre 13 #2943

Open tritonas00 opened 1 year ago

tritonas00 commented 1 year ago

Closes https://github.com/RigsOfRods/rigs-of-rods/issues/2599 Closes https://github.com/RigsOfRods/rigs-of-rods/issues/2351 Fixes https://github.com/RigsOfRods/rigs-of-rods/issues/2353 Fixes https://github.com/RigsOfRods/rigs-of-rods/issues/2921

Known issues:

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

ohlidalp commented 1 year ago

WTF? https://github.com/OGRECave/ogre-caelum/blob/master/main/include/CaelumScriptTranslator.h#L16-L31 That's the cause of 22:30:47: [RoR] Exception while loading sky script: Ogre::RuntimeAssertionException::RuntimeAssertionException: !resourceName.empty() failed. resourceName is empty string Caelum has some concept of "proxy resource" which tells you the name of the config script, instead of having programmer pass it directly. I have no clue why it worked till now. We've basically used it wrong all the time.

This line is the troublemaker: https://github.com/OGRECave/ogre-caelum/blob/master/main/src/CaelumPlugin.cpp#L99 - Resource::getOrigin() returns empty string.

@paroj Can you help me understand how to correctly load Caelum script? There's https://github.com/OGRECave/ogre-caelum/blob/master/samples/resources/TestSkyScript.os in the samples but neither CaelumDemo nor CaelumLab seem to load it.

This is where we call loadCaelumSystemFromScript() https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/gfx/SkyManager.cpp#L89 and I checked that the parameter is valid resource name. I also checked we have #define CAELUM_SCRIPT_SUPPORT 1

EDIT: Sorry for my chaotic posting, I figured it out and it's quite hilarious... in this case, both the file and the caelum_sky_system element had the same name (31.os) 😆 The problem is that somehow the script wasn't parsed this time so the resource search for "31.os" didn't give out the dummy Caelum resource as expected but the actual file.

tritonas00 commented 1 year ago

Caelum script loading works fine if we load the terrain from a folder (unzipped)

screenshot_2022-09-23_18-20-52_1

@paroj maybe its related to the new zip codec Ogre 13 uses?

ohlidalp commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

Tried building this branch using https://github.com/RigsOfRods/ror-dependencies with this PR https://github.com/RigsOfRods/ror-dependencies/pull/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: https://github.com/CuriousMike56/ror-dependencies/commit/c77f0ee6a9c7c3b266f15f809e1fd37ca305ac29

CuriousMike56 commented 1 year ago

RTSS materials are broken in videocameras, overview map and reflections: screenshot_2022-11-28_20-54-55_1 screenshot_2022-11-28_21-27-44_1

tritonas00 commented 1 year ago

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

that happens with both render systems?

CuriousMike56 commented 1 year ago

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

that happens with both render systems?

Yes, OpenGL has the same problem.

CuriousMike56 commented 1 year ago

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: screenshot_2022-11-30_01-46-47_1 screenshot_2022-11-30_01-47-02_1

ohlidalp commented 1 year ago

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 commented 1 year ago

With Ogre latest master https://github.com/RigsOfRods/rigs-of-rods/blob/cbebeeb3a6f7bfc15381c5af97123c43e792bf33/source/main/terrain/TerrainGeometryManager.cpp#L468 is not an issue anymore it seems.

screenshot_2023-01-02_22-33-25_1