gamefoundry / bsf Goto Github PK

Currently only the "standard" shading model can be applied to surfaces, which is suitable for most, but not all surface types. Add the models for at least the following models:

• Subsurface scattering (skin, vegetation)
• Clear coat
• Hair

Add built-in support for IK that integrates with the animation system. Components for feet placement that adjust based on terrain, as well as hand placement on objects, perhaps others.

Many of the member functions in UUID.h can be marked as constexpr.

Would a pull request to do this be welcome?

On a more generic subject, what are the project policies about :

• default keyword for constructors.
• noexcept keyword for functions
• providing default values in-line with class member declarations
• constexpr for functions and variables where it doesn't require large changes
• c++17 features. I assume currently this project only wants to use c++14 for compatibility with popular compilers
• A bsf::StringView class (similar to std::string_view). It can significantly reduce accidental creation of temporary std::string objects

void MessageHandler::unsubscribe(UINT32 handleId)
{
    UINT32 msgId = mHandlerIdToMessageMap[handleId];

    auto iterFind = mMessageHandlers.find(msgId);
    if (iterFind != mMessageHandlers.end())
    {
        Vector<MessageHandlerData>& handlerData = iterFind->second;

        handlerData.erase(
                std::remove_if(handlerData.begin(), handlerData.end(),
                [&](MessageHandlerData& x)
                {
                    return x.id == handleId;
                }));
    }
    mHandlerIdToMessageMap.erase(handleId);
}

Note that the call to handlerData.erase() is resolving to the single argument version of the function.

Need to pass handlerData.end() as the second argument, else you're only erasing a single element, and risk undefined behavior if std::remove_if returns handlerData.end().

Ability to enable camera-wide, or per-object motion blur. Per-object motion blur will require the velocity buffer that is also required for temporal AA.

Currently the textures are either fully loaded or fully unloaded. Enhance the system so it can stream different texture mip-levels one by one. This way textures that are further away can have their higher quality mip levels unloaded, saving on memory. And as the player moves through the world new textures can be easily loaded in as required. This feature is very important for large open world projects.

Need to add a set up a separate repository, containing examples that show the functionality of most major systems, that can also serve as tests.

Temporal anti-aliasing is significantly cheaper performance-wise than techniques as MSAA, yet often yields a very close level of quality. Additionally it also solves the problem of temporal aliasing, which is not solved by MSAA or other similar anti-aliasing methods. The framework already has a general purpose temporal filtering shader, it is just a matter of applying that filter to the whole scene. Currently the filter is only being used for stohastic screen-space reflections. Note that the velocity buffer is currently not set up or being written to, meaning only camera movement is accounted for - moving objects should write to the velocity buffer in order to be properly filtered.

Currently BsTypes.h's typedefs are defined as such.

namespace bs
{
    typedef char INT8;
    typedef unsigned char UINT8;
    typedef short INT16;
    typedef unsigned short UINT16;
    typedef int INT32;
    typedef unsigned int UINT32;

#if BS_COMPILER == BS_COMPILER_MSVC
    typedef unsigned __int64 UINT64;
    typedef __int64 INT64;
#else
    typedef unsigned long long UINT64;
    typedef long long INT64;
#endif
}

We can replace these with the types in

namespace bs
{
    typedef std::int8_t INT8;
    typedef std::uint8_t UINT8;
    typedef std::int16_t INT16;
    typedef std::uint16_t UINT16;
    typedef std::int32_t INT32;
    typedef std::uint32_t UINT32;
    typedef std::int64_t UINT64;
    typedef std::uint64_t INT64;
}

GUISkin can currently only be defined from code. This results in some very large blocks of code for the built-in skin in BuiltinResources, and also prevents easy modification. It would be better to establish a JSON format for GUISkin and then import all the properties from there.

Integrate a solution like Recast/Detour in order to be able to generate and use navigation structures for AI pathfinding.

Few manuals still need work, and majority of images need updating or are just plain missing.

Renderable component should be enhanced so it supports multiple levels of detail for a mesh. This way the further away the mesh is, the simpler version of the mesh is used. Ideally we also provide a tool that performs automatic mesh simplification.

Objects and lights can be defined as static, but these properties are currently not used by the shadowing system. Instead shadows are re-rendered every frame, which can be prohibitively expensive. When generating shadow maps for static objects and lights, it would be best to group such static objects into a shadow map of their own, which remains static throughout the light's lifetime. All other objects should be rendered into a separate shadow map which is updated per-frame.

Bison/Flex are only required for generating the parser and lexer for BSL. And the reason these need to be generated is because they contain some absolute paths specific to the user's machine. There should be command line options in Bison/Flex that allow the files to be generated without absolute paths, allowing them to be redistributed. This way normal user doesn't need to worry about installing Bison/Flex (on macOS Bison is especially problematic and macOS comes with an ancient version that needs to be overridden).

Ability to cull objects that are currently occluded by another object. This saves the GPU from rendering an object that wouldn't otherwise have been seen. This will likely include using object bounding boxes, or even separate collision meshes. Needs research whether a full GPU, or software rasterized CPU solution is better. Or perhaps even a baked solution like Umbra?

Mostly functional but some rendering effects still need fixing, and it needs further testing.

Complete volumetric lighting by ray stepping and applying the phase function. This effect should allow for localized volumetic effects like dust particles, localized fog and similar.

Currently for every lights all visible objects are packed into a single shadow map for that light. However some objects need more detail (e.g. character faces during a cutscene). In such cases it can be beneficial to allow the user to pack the shadow map for that particular object into a texture of its own, using a higher resolution.

Implement the cheap post-processing god-ray effect (not full volumetric lighting)

Ability to apply decals on 3D surfaces. Initially it should be the fairly basic decal support where they are rendered every frame (e.g. a projector that writes to the gbuffer). But later it would be nice to support baked decals that can be baked into textures (remains to be seen what's the memory cost of this approach). Decals need to have bounding geometry generated and culled same as renderables and lights.

Add support for virtual reality headsets by integrating their SDK's, and adjust the renderer so it outputs stereoscopic data.

bs::f currently comes with an automated script binding generator that generates bindings for the Mono runtime and outputs C# binding code. This binding generator should be extended to support Lua, Python and Java. Scripting plugins that know how to communicate between bs::f and runtimes for those languages should also be added.

The scripting API might need to be extended so an app can be created fully from a scripting language. Currently the systems allows the user to create custom components, in which a majority of engine functionality is exposed. But initial start-up and window creation is not currently exposed.

An alternative approach to scripting language support is to use the script binding generator to generate SWIG interface, which can then output bindings for a variety of languages. However SWIG only allows for one-way method calls, making some bs::f operations like auto-serialization not possible. However this approach does allow the user to just use bs::f as a plain library in their scripting language.

It remains to be seen which approach is best.

Add an emissive texture slot to the default materials that can be used for glowing surfaces. When used in combination with the Bloom effect it can result in visually pleasing glow effect, often suitable for modern/sci-fi themes.

Another way of handling global illumination. This time by completely backing the lighting information into a lightmap texture. Only works on fully static objects, making it even more restrictive than light volumes. However they are very easy to evaluated and yield high quality lighting. The lightmapped object would have to have a separate UV generated in-engine, but there are libraries to integrate which do just that. Similarly AMD's RadeonRays could be used for actual lightmap rendering.

Currently the depth buffer is stored in range [0, 1], where 0 is nearest and 1 is furthest. Depth buffer loses precision the father away an object is, which can cause artifacts when depth is compared (e.g. shadow acne). If depth buffer uses a floating point type this problem is compounded as floating point format itself loses precision with larger numbers. However by reversing the depth buffer range to [1, 0], where 1 is nearest, and by using a floating point buffer, we can make these precision errors basically cancel out. This would involve adjusting projection matrix, as well as any shader that reads the depth and adjusting its usage.

Add a new GUI element that uses HTML-like commands to let the user control the font family, style, size and text color. Allowing each piece of text to use its own style, instead of using a singular style for the entire element. Also allow the user to easily insert images within the text.

Add an easy way to navigate GUI elements by using the gamepad, as well as activate input elements.

Ability to render the scene "upside-down" in order to generate real-time planar reflections. These reflections are very expensive but are essential for real-time reflections in surfaces like mirrors or water.

Traditional bloom post-processing effect that adds a glow to very bright areas.

There's no comments in the bsfServiceLocator.h file indicating that this utility class can or can't be used in a multi-threaded way.

By wrapping the storage for ServiceLocator::mService in std::atomic<>, the class gains multi-threaded safety very cheaply.

macOS currently uses an OpenGL render backend. This isn't an ideal solution as its OpenGL version is 4.1, meaning compute cannot be used. This requires a variety of rendering effects to be implemented in 4.5 and 4.1 variants, which isn't ideal (although this is something we likely also require for mobile, so maybe not that bad either). Ideally we should add a MetalRenderAPI plugin, and extend XShaderCompiler so it can output Metal shading language code.

Add support for 2D animation using sheets and bones. Support for Spine and Spriter exported animations.

Heightmap based terrain system with continuous level of detail. Texture splatting and detail textures. Ability to remove chunks so that it can be integrated with custom 3D models. Ability to use displacement mapping (tesselation) for fine grained details on the surface (e.g. rocks, grooves, etc.).

Terrain vegetation system:

• High performance and high quality grass rendering
• Tree rendering with level of detail (SpeedTree integration and/or custom open source system, to be decided)

Water rendering shader.

Likely for a later feature: Separate voxel based terrain system (or a generic voxel based system)

Ability to control directional light and ambient light (skybox light) using some curve that simulates a day-night cycle.

Integrate a library like RakNet. Add support for remote procedure calls for simple communication. Add ability to automatically replicate objects over clients (using the built-in RTTI system). Allow bs::f to run head-less, without any rendering or audio, so it can be ran as a server. This would involve creating a NullRenderAPI, NullRenderer and NullAudio systems that simply ignore all method calls, and return resonable values when asked for something, but under the hood don't do anything.

Perhaps also add support for higher-level features like lobbies, chat and matchmaking. But this is likely best left as a separate feature, to be done after the networking foundation is established.

Add a clang format file to enforce code style rules.

Currently GPU programs are stored a GLSL or HLSL and then converted to necessary bytecode at runtime. This has become a problem since the renderer has grown with a variety of shader permutations - it takes a while to compile and evaluate everything (reflecting shader code seems to take the bulk of the time). Additionally on Windows, this requires the redistribution of d3dcompiler_47.dll, which feels hacky.

A better approach would be to compile the shaders when they are first imported, then share the bytecode and reflection data. This is possible for DirectX as it by default outputs in an intermediate bytecode format. For Vulkan something similar can be done by caching SPIR-V. For OpenGL this isn't possible unless we use SPIR-V extensions - it remains to be seen how widely are they supported.

However OpenGL can cache binary shaders, but they are not machine independant and cannot be distributed. So a separate shader caching mechanism could be introduced, that generates the required cache on first run (or during an install step) and then just reads them on following runs.

Need CI across Window, Linux and macOS. Otherwise it is easy to work on one platform and break others. Also make sure the builds output an installed version of the framework to serve as binary downloads of the latest version.

Full blown particle system with the following features:

• Billboard particles with a variety of blend modes, as well as 3D mesh "particles"
• Texture sheet and generic sprite animation (related to the 2D system changes)
• Variety of emitter types, including all basic shapes, as well as meshes (including animated meshes)
• A set of evolvers that control particle life-time and properties
• Ability to set constant values, random range or value curves for majority of properties
• Both CPU and GPU particle systems. GPU system will likely allow for a limited sub-set of evolvers but a much higher particle count.
• Particle collisions, including collisions with basic shapes and screen space collisions
• Soft particle rendering
• Ability to emit in bursts
• Ability to nest and spawn emitters by other emitters (complex effects)
• Research for anything more?

Likely a simple extension of the 3D particle system

Traditional lens flare post-processing effect, aimed for simulating the effect of lens flares in real world cameras.

Integrate Box2D, Chipmunk or similar

Make the framework mobile ready:

• Render backend using OpenGL ES is required. We already have an OpenGL 4.1 backend, which is fairly close to OpenGL ES 3.1, but will likely require some tweaks to get it running. XShaderCompiler might also have to be adjusted so it outputs GLSL readable by GLES.
• Extend the input system with touch and sensors
• Port to Android and iOS. Should be just the matter of porting the main message loop, input handling, window creation and file-system.

Console ports:

• Need to add a plugin for the native render backend
• PS4 and XBONE at least, others to be considered. Similar to mobile should be just the matter of porting the main message loop, input handling, window creation and file-system.

WebGL port:

• Use Emscripten to convert the code. What adjustments will be needed remains to be seen.

Currently only the traditional depth-of-field effect is supported. Bokeh and similar effects yield a better looking depth-of-field effect but are often prohibitive performance-wise to use during normal gameplay, however they can be very useful during cinematic sequences.

Currently importing assets block the main thread. This means only one asset can be imported at a time, and it also doesn't allow the GUI to neatly update during that time (for example, if you wish to show a progress bar). The system should be enhanced so it supports async import. On its own this should be a fairly simple task, however all resource initialization methods need to be verified for thread safety.

This is due to the fact that the vision behind async resource load was lost at some point and threading concerns were ignored. This should hopefully be simple as most resource initialization methods do nothing but forward the call to the core thread, where threading concerns are taken care of.

Extend all GPU objects with methods to calculate their memory usage on the GPU (estimated if functionality not provided by render backend), so this information can be used for profiling and similar purposes.

Add the ability to easily define 2D sprites from textures, and add support for pixel perfect rendering (requires enhancement of the scene object system). (Sprites are also required by the particle system, so it might be implemented there).
Tile map rendering (with import from Tiled app)
Layer rendering (for parallax)

When writing custom shaders the user can currently override the surface data that gets written, but cannot control the lighting or other parts of the rendering. Custom shaders should allow the user to change how is lighting evaluated, both for deferred and forward paths. Unlit shading model should also be added.

Global illumination ensures higher lighting quality by accounting for indirect (bounced) light. bs::f supports this in the form of light volumes, but they don't react to lighting changes, and are approximate. A fully dynamic solution would be explored. Light-propagation volumes seem to be most promising but this requires more research.