OGRE-Next
4.0.0unstable
Object-Oriented Graphics Rendering Engine
|
We're trying to make OgreNext and Ogre able to be installed side-by-side.
This is particularly important in Linux systems which rely on shared, centralized packages managed by package managers.
However this also benefits affect Windows apps that are able to select between Ogre and OgreNext at runtime.
One of the main issues is that DLLs are the same. i.e. OgreMain.dll
or libOgreMain.so
may refer to either Ogre or OgreNext.
That's why we added the CMake option OGRE_USE_NEW_PROJECT_NAME
When enabled, the project names will be OgreNext
instead of Ogre
. e.g. the following projects are affected (enunciative):
Old Name | New Name |
---|---|
OgreMain.dll | OgreNextMain.dll |
OgreHlmsPbs.dll | OgreNextHlmsPbs.dll |
OgreHlmsUnlit.dll | OgreNextHlmsUnlit.dll |
OgreMeshLodGenerator.dll | OgreNextMeshLodGenerator.dll |
OgreOverlay.dll | OgreNextOverlay.dll |
OgreSceneFormat.dll | OgreNextSceneFormat.dll |
libOgreMain.so | libOgreNextMain.so |
libOgreHlmsPbs.so | libOgreNextHlmsPbs.so |
libOgreHlmsUnlit.so | libOgreNextHlmsUnlit.so |
libOgreMeshLodGenerator.so | libOgreNextMeshLodGenerator.so |
libOgreOverlay.so | libOgreNextOverlay.so |
libOgreSceneFormat.so | libOgreNextSceneFormat.so |
We understand this change can wreak havoc on our users who have scripts expecting to find OgreMain instead of OgreNextMain.
Which is why this option will be off by default in OgreNext 3.0; but will be turned on by default in OgreNext 4.0
The CMake option is scheduled for removal in OgreNext 5.0
EmptyProject
's and Android's scripts have been updated to autodetect which name is being used and select between Ogre and OgreNext and CMake config time.
Make sure to upgrade to latest CMake scripts if you're using them; to be ready for all changes.
Default material BRDF settings have changed in 3.0; thus materials will look different.
See PBR / PBS Changes in 3.0 to how make them look like they did in 2.3 and what these changes mean.
The piece block LoadNormalData
got split into LoadGeomNormalData
& LoadNormalData
in order to support Decals in Terra.
If you were overriding LoadNormalData
in a custom piece, make sure to account for the new LoadGeomNormalData
.
Creating Root changed slightly. One must now provide the Ogre::AbiCookie:
The ABI cookie is a verification step to validate the version of OgreNext your project was compiled against is the same one as the library being loaded. This includes relevant CMake options that would cause the ABI to change and cause subtle runtime corruption (e.Debug vs Release, OGRE_BUILD_COMPONENT_PLANAR_REFLECTIONS
, OGRE_FLEXIBILITY_LEVEL
, OGRE_CONFIG_THREAD_PROVIDER
, etc).
See Ogre::testAbiCookie for information of what to look for if the ABI cookie fails.
The AbiCookie may not catch all possible ABI mismatch issues, but it will catch the most common known ones.
Note that Ogre::generateAbiCookie is FORCEINLINE
because it must see your project's settings.
Lots of dead & long-deprecated code was removed. See Resolving Merge Conflicts in Ogre-Next 3.0 for more help with C++11 changes.
( void )
from empty functionsDeprecated/
folders__cplusplus
that uses < 201103L
>= 201103L
or numbers below 201103Loverload
keywordHardwareUniformBuffer
, HardwareCounterBuffer
set( CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld" )
OgreShadowVolumeExtrudeProgram.cpp
SceneManager::setFog
getShadowCasterVertex