Skip to content

Latest commit

 

History

History
100 lines (72 loc) · 7.65 KB

1.10-Notes.md

File metadata and controls

100 lines (72 loc) · 7.65 KB
Raw

New and Noteworthy in OGRE 1.10

For a detailed overview of the changes, see the git changelog. For an overview of the changes compared to the bitbucket version see here.

Core Improvements

  • Unified documentation API reference, manual and some of the wiki tutorials are now all available through Doxygen and editable using Markdown. Now there is syntax highlighting in the snippets and automatic links to corresponding function documentation. To locally build the docs, just do make OgreDoc. The sources are in Docs/src/.
  • by default Ogre will now automatically fetch and build its core dependencies. This way your deps have the same compile options like Ogre and you do not have to track the separate OgreDeps repository.
  • FileSystemLayer: use $XDG_CACHE_HOME as base path on Linux
  • allow using std::thread (with c++11) for background resource loading
  • OSX: externalWindowHandle expects a NSWindow* by default. macAPICocoaUseNSView=false switches to old behaviour.
  • using a duplicate resource name is an error now and throws an exception
  • upgraded embedded TinyXML from 2.5.2 to 2.6.2
  • STBICodec using an embedded stb_image copy for image reading/ writing. No need using the bloated freetype. However you should not use this in a security critical environment.
  • the nedmalloc allocator is now deprecated and disabled by default due to memory leaks. Use the default STL allocator.
  • several functions were deprecated and will be dropped in the next major release. See the deprecation list here.

CMake Config-File support

A CMake config-file package is now installed making it easy to discover OGRE for third-party projects. This means that you no longer have to copy paste the FindOGRE.cmake script into your project. Instad you can specify OGRE_DIR to point to the installed OGREConfig.cmake and thats it. On Linux CMake will even automatically find OGRE if it is installed in one of the default system paths like /usr/local/.

The config also provides the following variables for a better OGRE integration:

  • OGRE_CONFIG_DIR - the resources.cfg and plugins.cfg are located here
  • OGRE_MEDIA_DIR - path to the sample media and RTShaderLib

Plugins

  • the EXRCodec can now be build again by setting OGRE_BUILD_PLUGIN_EXRCODEC=TRUE
  • the BSPSceneManger now works when using the RTSS: i.e. it can be used with GLES2/ GL3Plus/ D3D11.

Testing / Continuous Integration

  • PlayPen and Visual Tests are up and running again. They must pass if you want to get your code into Ogre now.
  • similarly all warnings were eliminated from the code base and -Werror was turned on the GCC and MSVC builds.

Emscripten

In case you want to bring your existing code-base to the web or just continue using a familiar development environment, there is now Emscripten/ HTML5 support with Ogre. You can see it live here.

The sources are in Samples/Emscripten and build instructions in BuildingOgre.md.

RenderSystems

GLSupport

This module includes the platform specific parts that are needed to create a GL Context. (i.e. GLX, WGL, Cocoa, EGL) They had been copy/ pasted but stayed largely the same across the different GL Rendersytems.

The result is the GLNativeSupport API that can be plugged in the exiting GL*Support classes (e.g. GL3PlusSupport) to handle the context creation.

Furthermore the API was extended to allow specifying a context profile. This way the GL3Plus RS creates a core profile, while the old GL RS uses the compatibility profile. Additionaly you can create a GLES context using GLX/WGL on a desktop machine and use/ test the GLES2 RenderSystem there. In case you are in the embedded world or on Wayland/ Mir already it can also use EGL to be compatible with those.

GLES2

Due to the ubiquitious availability of GLES2 this RenderSystem got a large overhaul. All legacy workarounds without justifications were removed from the code which makes it behave the same on all platforms and also fixing several VTests. The extension handling was fixed, which allows running in GLES2 mode on GLES3 cotexts which previously would crash on Android. Furthermore 3D textures are now also available in GLES2 mode.

Components

OgreBites

The reusable parts of the SampleBrowser were factored out forming the new OgreBites Component. It handles Ogre startup/ tear down (including Overlay, RTShaderSystem) and also includes the SdkTrays and SdkCameraManager.

This is useful if all you want is to get a Scene with a FPS counter up and running (i.e. rapid prototyping). If available it also uses SDL2 for input - you now just have to implement the callbacks.

By making the SampleBrowser code useful by third-party apps, both benefit.

Furthermore the Android specific parts of SampleBrowser were merged into OgreBites. This eases porting your application to Android if it uses the ApplicationContext.

Python

After python bindings are now SWIG based with the corresponding siwg interfaces being part of ogre. This means that if you checkout the git version you can have up-to-date bindings for it. The work took some inspiration by the ruby-ogre project. This means that it would be trivial to bring up an Ogre-Ruby component if needed by someone. As there is some demand for it a Ogre-C# (Mono) component was prototyped. However some help is needed here.

Currently the OgreMain, RTShaderSystem, Overlay and OgreBites Components are covered. However most iterator APIs are broken, as the way they are implemented in Ogre is rather exotic.

For usage see the code in Samples/Python.

RTShaderSystem

The duplicated GLSL, GLSLES and GLSL150 shaders were merged into one common GLSL codebase. Furthermore the lighting equations were fixed such that they produce the equal light intensity as fixed function GL. This allows pixel perfect replication of the fixed function pipeline in some cases.

In general the GLSL support was improved:

  • Environement Map (reflection) shaders no longer produce a flipped reflection
  • The hardware skeletal animation support was finished. See the skeletal animation sample for how to enable it in your code.

High Level Material System (HLMS)

This component is a backport from the 2.1 branch and is a different take to shader management. Basically it solves the same problem like the RTShaderSystem, but instead of relying on C++ classes generating the final shader it rather uses a custom preprocessor language. Currently the HLMS only implements a PBS material which is not compatible with the legacy Ogre materials that implement fog, diffuse_color etc. .

If you want to implement your own materials and use custom shaders all the way, this is the way to go. If on the other hand you like the flexibility and convenience of the legacy Ogre materials, you should keep with the RTSS.

MeshLodGenerator

This code was factored out from OgreMain and is now a separate Component.

SampleBrowser

As the SampleBrowser is now based on the OgreBites component it also uses SDL2 for input, which finally means a modern input system instead of OIS. The drawback is that the WinRT and NaCL Platforms are currently broken due to missing bits in OgreBites. However updating them should be straightforward.

Furthermore the following Samples were updated/ added:

  • ComputeShader: shows how to use ComputeShaders with the GL3+ RS
  • ShaderSystemMultiLight: ported to GLES3
  • VolumeTerrain: fixed the triplanar texturing part
  • HLMS: shows how to use the new HLMS in combination with the RTSS