Open tritonas00 opened 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.
Caelum script loading works fine if we load the terrain from a folder (unzipped)
@paroj maybe its related to the new zip codec Ogre 13 uses?
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.
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.
@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
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
RTSS materials are broken in videocameras, overview map and reflections:
RTSS materials are broken in videocameras, overview map and reflections:
that happens with both render systems?
RTSS materials are broken in videocameras, overview map and reflections:
that happens with both render systems?
Yes, OpenGL has the same problem.
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:
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.
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.
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:
It happens because of this it seems:
Reminder https://github.com/tritonas00/rigs-of-rods/blob/ogre13/cmake/DependenciesConfig.cmake#L33-L50