This update takes the first step to make Bright Engine production ready with the introduction of scripting! We are proud to reveal the new Development Suite, where developers will spend their time writing scripts, designing user interfaces, and crafting the ultimate gameplay experience! We’ve also made some major improvements to lighting, grounding the engine’s visuals far closer to reality!
A Huge Thank you to our Patrons! Your contributions make Bright Engine Possible!
Cody Pryor • Massum Zaidi • Mark Makarainen
New Features
Script Editor
The last update, the structural reconfiguration of the rendering architecture, brought about massive improvements in rendering speeds, and yet, despite this, Bright Engine still felt clunky. While we focused all our attention on the viewport, we forgot to address the User Interface, which over time, has become loaded with new settings and editors, which were tacked on in a “bolt-on” fashion. The result is that the UI became slow and messy with inconsistent layouts, slow object selection, and some nasty visual artefacts (especially when scrolling).
Every engine needs an IDE for its scripting pipeline, and Bright Engine is no different. The engine now features a fully functional script editor featuring syntax highlighting, code folding, auto-completion, and debugging tools.
The script editor also marks the first attempt for a fully customisable interface where windows can be moved and docked to the preference of the user. Our goal is to use the Script Editor as a testing base for this system so that we can iron out the kinks here first before rolling out this feature to all the editors of the engine!
Input Manager
Beyond the script editor, we’ve created an Input Manager. This simple tool allows you to very quickly set up keybindings for your game which trigger certain script functions.
So far, we’ve only laid the groundwork for the scripting systems, and hence only console-based scripting is currently functional. However, it is far from finished, and we’re going to be expanding its capabilities at a rapid pace in future updates, including the development of an Interface Designer Suite!
Changes & Improvements
Physical Lights
We’ve long strived to achieve realistic and efficient rendering within Bright Engine. This is why we dedicated a large portion of the development time of this update to looking through scientific journals concerning the behaviour of light. Using our new understanding and knowledge within these research papers, we’ve made a giant overhaul on Bright Engine’s rendering and processing of light.
Let’s start with the light units. In earlier versions, Bright Engine used an arbitrary strength value to determine the intensity of light. Now it uses the photometric unit: Lumens and Lux. Lumens are a measure of the total quantity of visible light emitted by a source. Lux is the equivalent of the number of lumens over a surface area, or lumens per meter squared. If you ever look at the box of a lightbulb, you’ll notice it will give you the total Wattage and the Lumens value of the bulb. And this is precisely how Bright Engine now simulates light. It matches the intensity of a light source in reality with 5% accuracy, making the lighting system truly physically based!
Our pursuit of realistic lighting sent us down the path of a phenomenon called Blackbody Radiation. Simply put, it allows the user to use physically accurate colours for white light at different temperatures. Bright Engine now allows users to either define the light’s colour by sRGB colour codes or by Temperature measured in Kelvin.
We also took a look at our area light system. Up until now, Bright Engine has supported rectangular area lights. However, we’ve now expanded the engine’s capabilities to support both Disk and Sphere area lights as well.
These lights are certainly more demanding than a point or spotlight, but they are able to give some very nice results without being a drag on the framerate. Something which has long been a challenge is the specular reflection of light. Point lights have worked pretty well so far, but spotlights have not so much. We’ve now fixed the specular problems with spotlights, and the results are much nicer!
However, the greater challenge was getting area light specular reflections to give results which are believable. Since the light source is not emitting from a point but rather a surface, it creates a host of complications, which other engines have struggled to surpass. But because our fabulous Patreon supporters kindly supplied our engineers with much-needed caffeine (and because we wouldn’t let them outside until they worked it out), Bright Engine now fully supports specular reflections for all three Area Light shapes!
While these results are not perfect, they are close to expectations, and we will continue to improve them with time!
HDR Rendering
Beyond lighting, the engine was in need of attention in other areas of rendering. Most notably the HDR rendering pipeline. We were puzzled as to why lighting values still looked off despite the improvements made, it turns out the problem was staring us right in the face the whole time. HDR values from skyboxes were being clipped down to 8 bits despite the source being 32 bits. In other words, the HDR was not HDR since the data was gone! (bit of a problem, really). Needless to say, we’ve fixed this bug as well as updated the approximation of moving sRGB values into linear space for HDR rendering.
But this issue also resolved a long-standing problem within Bright Engine, where dark scenes always looked far too bright (no, that’s not a pun). With this HDR stuff fixed, it’s now possible to make really dark scenes, allowing for far better atmospherics to be achieved.
Reflectance
The PBR Material Node has also been slightly expanded with the introduction of a Reflectance parameter. Up until now, Bright Engine used a default reflectance of 4% which for most materials gives realistic results. However, there are specific materials, such as Gemstones, whose reflectance of light is much closer to 16%. We’ve exposed this value to the user within the material editor and also linearised it so that users can create a grayscale texture to control reflectance instead of a flat value for the whole material.
One final upgrade to the rendering shaders was the introduction of Specular Anti-Alising. A few of our testers were experiencing some intense white firefly artefacts in dark environments due to the reflection of light on metal surfaces. While these are, in fact, physically accurate, they can be quite a harsh effect on the eyes. So the specular antialiasing is added to mitigate this problem.
Physical Cameras
This just about summarises the lighting improvements made in this update, but we are far from finished. Cameras were next on our list of improvements. Camera Objects were introduced into the engine in v0.1.6b, and we’ve been making improvements over time, but drastic action needed to be taken to make them compatible with the new lighting system. After all, what use is a physically accurate lighting system if you haven’t got a physically accurate camera lens to capture it?
Originally camera exposure was a flat value set within the Post Processing Panel. If any photographers just read that sentence, they probably just facepalmed. When we first set up the camera system, our knowledge of the mechanics of physical cameras was very limited, and it resulted in poor implementation. Thankfully we were able to consult with a photographer who identified all the problems, and so we set out to fix them. The camera’s exposure is now set in the Camera Properties but is no longer an arbitrary value. Users set the value of the Camera’s Shutter Speed, Aperture, and Sensitivity (ISO) to determine the correct exposure.
Now a manual camera is all well and good, but what if you want to simulate the human eye adapting to light? Well, Bright Engine now has a long-awaited feature, Auto-Exposure. If enabled, the camera will automatically calculate the correct exposure value based on the current luminescence of the scene.
This method is an approximation and can sometimes lead to some extreme values causing weird and wonderful effects. Therefore, we’ve added minimum and maximum exposure values to limit the extent of sudden changes. It goes without saying that all of these settings will be exposed to scripting, so they can be modified on the fly while the game is running.
With a new Camera system in place, we turned our attention to the various Post Processing systems which rely on it. Most notably: bloom. Bloom is now calculated based on surface luminance rather than rgb brightness, which results in a significantly more realistic effect.
Tone Mapping
Tone mapping has also had some attention to really boost the colour values and make a scene far more immersive. Users now have a choice between three tone mapping methods: Reinhard, John Hable, and ACES, the last of which is now standard within the VFX industry. All have their advantages and disadvantages, and it’s up to the user to decide which works best for their project, but it makes a world of difference.
Colour Correction
The Color Correction post-processing effects are now gone. The old system had a nasty habit of creating artefacts and was quite a slow alternative to tone mapping. In its place, we have added a new Color Grading effect. Using LookUp tables, you can create stylized looks for your games without compromising the effects of tone mapping!
That concludes the last of the improvements rendering-wise, but we’ve also made a cluster of minor improvements throughout the editors. We’ve fixed all the problems users were experiencing with shortcut keys randomly not working in both the main editor and material editor. Furthermore, we’ve tweaked some default values of settings to give much better initial results when setting up new systems.
Bookmark Manager
Bookmarks now display a thumbnail of the destination for easier navigation.
Memory-wise, we’ve sealed up quite a few memory leaks during the loading process, as well as optimised the architecture of both Light data files and Material data files. Subsequently, both now consume about 20% less memory, and material files are loading 80% faster!
Object Selection
A final tweak was made regarding object selection. Existing users will be happy to know that when switching between objects, the currently selected tab remains selected. This makes life a lot easier when comparing settings and creates a more fluid experience.
Bug Fixes
World Editor
- Fixed a bug where cube maps were being clipped down to 8bit even if the source was 16 or 32bit, creating artefacts
- Fixed a bug where shortcut keys were being triggered twice, causing duplicate actions
- Fixed a bug where the duplicate shortcut key sometimes didn’t work
- Fixed a bug where the delete shortcut key sometimes didn’t work
- Fixed a bug where the deselect shortcut key sometimes didn’t work
- Fixed a bug where area lights did not fade out when reaching the maximum LOD range
- Fixed a bug where alpha was not being correctly used for SSAO
- Fixed a bug where alpha was not being correctly used for Directional Shadows
- Fixed a bug where alpha was not being correctly used for Point Light Shadows
- Fixed a bug where alpha was not being correctly used for Spot Light Shadows
- Fixed a bug where the directional shadow buffers were being generated at the wrong resolution
- Fixed a bug where the point light shadow buffers were being generated at the wrong resolution
- Fixed a bug where the spot light shadow buffers were being generated at the wrong resolution.
- Fixed a bug where adjustments made to a cameras transformation while in preview mode were not being saved correctly
- Fixed a bug where cloud colour was not being shifted into linear space and thus did not employ HDR rendering
- Fixed a bug where Prefilter Cubemaps were not being loaded correctly when switched, causing black artefacts
- Fixed a bug where memory was not being correctly cleared when changing a zones environment cube map
- Fixed a bug where memory was not being correctly cleared when changing a zones irradiance cubemap
- Fixed a bug where memory was not being correctly cleared when changing a zones prefilter cube map
- Fixed a bug where the cameras icon model was not correctly rotated when assigned to a target
- Fixed a bug where changing a setting within a drop-down box triggered key-down events when trying to move the editor camera
- Fixed a bug where material data was not being cleared correctly when switching zones (memory leak)
- Fixed a bug where skybox texture data was not being cleared correctly when switching zones (memory leak)
- Fixed a bug where material texture data was not being cleared between each pass (memory leak)
- Fixed a bug where entering text into a vector field caused a crash
- Fixed a bug where opening the diagnostics suite while editing a value caused a crash
What’s Next?
We’re pretty happy with where rendering currently stands, though there remains plenty of work to do. For now, however, we will begin focusing our attention on a far more important area of the engine: Scripting. We’ve laid out the foundations in this update, now comes the time to expand it and make the engine ready for production use. Over the course of the next three updates, scripting will be the primary focus, exposing object settings, creating an actor system and bringing in the user interface. We’ll still be making improvements to the rest of the engine as we go along to ensure that it continues its trend towards stability.
