🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Bright Engine C++ check out now

Started by
2 comments, last by Shaarigan 4 years, 12 months ago

Hello there's a new engine called Bright Engine, Here is what the specs of Bright Engine. And here is the link https://www.indiedb.com/engines/bright-engine

Looking for more engine testers.

RENDERING        

    HDR Lighting
    Physically Based Rendering (BDRF)
    Specular IBL & Diffuse Irradiance
    Reflection Probes
    Physical Camera
    Instanced Rendering
    Dynamic Lighting

    Dynamic Soft Shadows
    Cascade Shadow Mapping
    Occlusion Query & Culling
    Blended Model LODs
    Custom Shader Support
    Emissive Lighting
    Volumetric Effects

DEVELOPMENT TOOLBOX

    WYSIWYG Editor
    Interface Editor
    Terrain Editor
    Particle Editor
    Cutscene Editor
    Scripting Editor
    Material Editor

    Animation Editor
    Shader Editor
    In-Editor Baking
    In-Editor Game Testing
    In-Editor GPU Diagnostics
    Asset Inspector
    Visual Studio C++ SDK

             

New Features

As the title might suggest, this update was not focused on adding new features so there is not much to discuss here. However we did add an object locking system!

1.3.thumb.jpg.c39ff0f80831237020ab5fd1074be3cd.jpg

Whenever an object becomes locked, it can no longer be transformed or selected using the mouse click (it can still be selected via the hierarchy panel). This is a small useful tool for preventing edits to objects that you are happy with it’s settings, for example, terrain. Locked objects when selected have a yellow bounding box as opposed to the normal green so if you try moving it and isn’t working, you won’t be tearing your hair out wondering why, plus if you decide you do want to edit the transformations of that object again in the future then it can simply be unlocked at anytime.

Changes & Improvements

The primary focus of this update was improving performance while fixing the large plethora of bugs that have accumulated over the past few updates. But before we dive down that rabbit hole, other improvements to the rendering pipeline and Editor were made.

2.5.gif.022d051fc3cee00b50959657408dac3e.gif

In addition, we fixed the LOD system which was causing strange rendering problems in regards to shadows, while also adding a new button to reload the selected models textures, if they have been edited outside of the Editor.

1.8.gif.bf3de93392af7e226384d94065478c70.gif

3.5.gif.810dd17fd11370b753bfc75a8b05db3f.gif

Animated Models have long been a problem within the engine so we made some strides forward here as well. FBX skeletal animated models are now fully supported with no more weird and random glitches. Sadly there are still some issues with the DAE format but its a relatively new addition to the engine, so we’re aiming to have these fixed up pronto!

4.4.gif.cccac360f0ab730b6aadfc280cf57fd9.gif

Next we took a look at terrain and found a bountiful collection of ideas on how to improve it further. Sadly only two made it into this update, but more will be introduced in future. First is the introduction of Parallax Occlusion Mapping onto terrain objects, to create even more realistic environments!

4.2.thumb.jpg.8506af8a35f133fc66f0f1c056155049.jpg

Second was a minor update to Dynamic Foliage which now snaps itself to the terrain, preventing floating patches of grass on a sloped section.

3.thumb.jpg.5353b32b6729706365af47a4fbb4359c.jpg

Screen Space Ambient Occlusion has long since had some issues when it came to transparency. Much like Shadows in v0.1.5a, the SSAO effect uses geometry based calculations since it is significantly faster approach. But in v0.1.5b we introduced alpha consideration into the shadow rendering pipeline and in this update we actually just took the same concept and applied it for SSAO as well.

2.3.thumb.jpg.8c88c51b97e45d2d60df3f5167e7108e.jpg

We also added a new setting to control the kernel size of the calculations for SSAO. While this is a quite advanced feature in terms of knowledge, the general principle is the greater the kernel size, the more accurate the effect at the cost of performance. Originally this was fixed at 64 but now you have complete control over it within each zone.

5.4.gif.80afda60db0825902b021ab813c05a9c.gif

Last set of improvements before we talk about the performance related stuff is changes made to the Editor. We’ve moved a few things around for a more fluid workflow while adding in a few minor new features. There is now an FPS counter in the bottom left corner so you can see general performance without having to enter diagnostics mode, we’ve added a shortcut button within the animation settings of a model object to quickly open the animation manager, moved the view filters from the Render Panel to the Menu bar under View and adjusted a few default values of some settings to more sensible starting values.

5.thumb.jpg.2bd1538c09f74823c9fe9ff85132b916.jpg

As the continued UI improvements, the World Panel and the Animation Manager have now had their UI updated to the new components resulting in a much nicer looking interface for both!

3.3.thumb.png.c95b4f1338b256098ffb3be2d507d5ed.png

Now let's talk performance. This has been something that has steadily been declining with each update despite our best efforts, and we felt it time that we did something about it. After having the privilege of talking with some leading software engineers within the game development industry, we have begun our drastic improvements to the rendering pipeline starting with the rework of Occlusion Query. The introduction of Frustum Culling, next frame comparison and adding clip planes into the pipeline, saw a performance increase of over 170%!

Drawcalls.png.685dc837ca2272e6aed9614df541dac4.png

FPS.png.54ccacc4e03cf9924539a16633638ee6.png

But it wasn’t all GPU upgrades, we moved our attention towards how the data was being extracted from RAM and then passed between the CPU and GPU. Sometimes it can be quite horrifying how badly something was originally created, but given we are in the business of constantly improving our code as we learn more it's always fun to see how far we’ve come. So we have optimised the data handling of:

  • Skeletal Animation
  • Instanced Model Rendering
  • Render Panel Settings
  • OpenGL Viewport Resizing
  • Real-time Shadows

Performance is still far from where we want it to be, though that’s always going to be the case as we aim for the best results with the best performance. For now however, our community can enjoy a good boost, improving their experience within Bright Engine.

Website will be up soon :)

Heres a sneak peek at Vertex Color painting

Vertex Color painting is in! and works nicely!

 

 

 

 

 

 

 

0dc1c1c301f3045b2903971617f4135d.mp4
Advertisement

First impression
Lots of features can be nice, but the long list of fixed bugs is quite scary without knowing which were exposed in a recent stable release and not just an early alpha. Having maintained the project for 8 years in a row sounds reassuring thou. ? Too many open source projects are scrapped or put on ice when the fun part is over.

How to become more appealing
Engine users want someone else to do the boring parts for them, so show all the dirty jobs you've done and all the portability issues you've solved. Handling device lost exceptions from GPU drivers? Validation against invalid input in debug builds? Some neat build/scripting system removing linker errors? Hardware abstraction systems?

If you're making long code freezes with code inspections, regression tests, usability experiments, billion case brute-force tests and formal verification, you should probably write about it in the presentation to show that it won't let them down.

An important thing when I look into an engine to decide for or against it is how clean is the code base.Can I easily add my gameplay features or have I to dig through a mass of third-party libraries just ebcause the vendor was too lazy to embedd some features by themselfes, how are the performance impacts for example when processing input (Godot uses OS System Messages so their Input is damn lazy) and most important what licenses have I to respect, can I publish my game without the source or did some component use the GPL or any other similar license that forces me to publish my work or give credits to people I don't know?

Open Source projects by the way have the advantage that I can fix game breaking bugs by myself instead of waiting months to get a fix from the vendor ?

This topic is closed to new replies.

Advertisement