synodic-software/soul-engine

Physically based renderer and simulation engine for real-time applications.

soul-engine's Issues

Support plaintext and xml serialization of Settings

Settings currently only supports plaintext serialization. Investigate adding xml serialization as an option to the user, and implement this so the user can choose which way to serialize the data structure.

Optimization

Shaders

Look into the state of the art in shaders (i.e. research papers on the subject) and then implement the shaders.

Creating multiple windows causes hang

When creating two windows:
''' WindowManager::CreateWindow(WINDOWED, "test1", 0, 0, 0, 300, 300);
''' WindowManager::CreateWindow(WINDOWED, "test2", 0, 0, 0, 300, 300);

The engine SOMETIMES hangs in the construction of the second window. Multi threading and window callback related

Dependency Management

Create a cmakelists file for all the required dependencies. Investigate conan.io and the ability to automatically handle certain packages.

Settings

Boost::PropertyTree is currently (successfully) being used for settings. However, it is very resource intensive. Another data structure should be designed to replace it, assuming such a data structure can be reasonably found in a library or developed. In the case it cannot, the functionality of the settings with property tree should be expanded as appropriate.

Create Storage for all Library Binaries/Dependancies

For example, we do not want our repository to contain all our static dependencies, but we want to be able to share them on demand. Options include, creating a separate repository for the library files, create a public Google Drive account and store/update libraries from there, or use Git LFS. More options can be explored and accounts can be made on demand.

Optimize Settings

The current settings functionality is around 25x faster than the boost implementation we previously relied on! (Thank you Anthony). However, the current code base could be refactored and optimized even further.

GPUBuffer Implementation

All CUDA buffers are sent to kernels with a pointer. All these should be abstracted into GPUBuffer objects. Find and replace all instances

Fiber Scheduler: Two Awaken Calls (Unnecessary)

When adding a task to the scheduler variables are added via the custom properties. Because the scheduler runs across multiple threads, the fibers are not guaranteed to modify their properties before being submitted. Therefore, when the are run, they change the properties, then yield, causing the values to update at the potential expense of two more context switches.

Check out the Boost/Fiber repository by olk

Message Passing System

A message passing system, somewhat similar to other graphics engines should be implemented. This should be a centralized system for the entire engine, and allow modules of the engine to communicate indirectly, thereby lowering coupling between modules. Such a system should be designed, implemented, tested, and documented.

Scheduler

currently inoperable, should be a priority if we wanna get multithreading working

Introducing SoulEngine to the Community

In order to get more community exposure for SoulEngine, maybe we could set up a google account (gmail/youtube) for demo videos and then sign up for a reddit account (post about the project in the opensource and github subreddits). Maybe we can get interested people to help contribute.

Color Class

Set up the framework for and develop a color class that internally represents colors as different wavelengths and tries to maintain that color despite displaying to a external monitor of any variety.

atomicAdd() undefined

atomicAdd() is undefined on line 376 in RayEngine.cu. Have not made changes to the ray engine.

atomicAdd(&(pt->x), col.x); atomicAdd(&(pt->y), col.y); atomicAdd(&(pt->z), col.z);

Only the first one is marked undefined, although putting my cursor over the second two does not show a type signature.

Disgusting Repo

remove all visual studio dependent code and add CMake files for platform building

Improved Fiber Scheduler

The current fiber scheduler shares a job to a global queue which is locked whenever it updates. Each thread tries to lock this queue to remove a job. This creates tension on the lock. All threads trying to access it at the same time. To minimize the amount of locks used, implement a 'work stealing' algorithm (There is one in the Boost::Fiber repo). This algorithm maintains a local job list for each thread. Only when it runs out does it access another thread's list.

Constrained/constricted Delauney Triangulation on the GPU

This algorithm would take a mesh which is made out of triangles and return a mesh that
is made out of tetrahedrons, but the visible triangles would remain untouched.

GPU Quicksort

Needs implementation, will use CUDA most likely

Create Default Editor State

Geometry Wrapper

Implement a templated and generic wrapper for storing/looking up geometry such that different mesh options are available, making adjacency queries fast at the cost of memory or performance.

Replace Camera Management

The Engine stores a single camera at the core level. This is akin to hard coding a solution and should be removed. Instead, store a camera in a scene and treat it as you would any other object.

Memory Allocation

Custom memory allocation

Compute Backend

All compute code should be called once from any Soul Engine file. Under the hood, this code should run on primarily a CUDA device and fallback to OpenCL. Truly, large compute tasks should use everything, even the CPU

Implement Custom Memory Allocator

Since using malloc/new has a significant amount of overhead and is generally slow, a custom allocator must be created to improve performance and reduce the frequency of new/delete function calls. The implementation should be a simple linear allocator, since it is fast, easy to implement and suits the needs of the engine. A template for this allocator already exists within the "Soul-Engine/Soul Engine/ Source Files/Engine Core/Allocator" directory.

Server Setup

Think of and implement a server setup that logs player inputs, distributes them so they execute concurrently, but does not actually run the simulation. Without running the simulation, the server has no idea what is false input or real input, how should this be solved?

Scripting Language

Run-time scripting is a powerful tool for updating values in a project without waiting for a compilation stage. However, we do not want to stray from the performance C++ gives. Either create a scripting layer for per-file c++ compilation (Each file has its own .dll) or find a scripting library that barely strays from the C++ standard.

No comments in many of the files

Hard to work with as is, gonna go through them and piece together what things do...

Website

A website is needed for this project which can automatically build and display Doxygen generated code. Additionally, module documentation (in the form of a webpage) that is hand created would override the Doxygen content, allowing high quality documentation to exist where effort is applied, and a backup where it is not.

Replacing Thrust

Thrust is functional but we can improve overall performance by replacing it with custom algorithms specifically suited to this project.

Tidying Up Code

The existing code could use some cleaning up/refactoring.

Object Importer

Create a generic backend that imports objects files (obj, collada, ect.) and places them in the engine's format.

Implementation of a Particle Wrapper for the Current Ray Engine

Particles are merely rays which progress (and react to forces, so it should execute with the physics engine)
with time instead of occurring immediately.

Create cmakelists.txt

Create a cross-platform build solution for all operating systems and all building tool flavors with Cmake. Target all recent build tools and do not worry about backwards compatibility. For example, Visual Studio 2017, not 2015.

Add Camera into the Geometry Pipeline

Treat a camera as a non-existing particle that will be queried as the initial ray starting point

Add Parallel For with the Fiber Schedular

The "ParallelFor" function should divide a for loop into chucks which are each their own job. These jobs then execute through the fiber scheduler. Take a look at Soul Engine\Source\Parallelism\Fiber\Scheduler.h/.cpp at ForEachThread which executes a callable on each thread. You can implement different varieties of the "ParallelFor" function. Maybe one would be for std conforming containers like https://en.cppreference.com/w/cpp/algorithm/for_each. Maybe for pure iteration, you would take a parameter such as iterationCount and another for taskCount. Maybe the given callable would require a value i as its first parameter, allowing it to make use of its ID.

This is a smaller task, but heavy on C++ knowledge.

Dynamic Resolution when Min. Sample Count Reached

When the minimum sample count is reached (1.0f), start dynamically scaling resolutions to achieve the desired framerate.

Very little documentation

we need to fix up a lot of the spaghetti code left lying around

Raster Backend

Removing the gl core and its dependencies and replacing it with a slimmed down vulkan

Move WindowManager Files

Move WindowManager.cpp and .h to the directory above their current resting place. 'Display'

Documentation

In order to make the code more accessible to others, we should add some more comments to the code (existing and future), and work on writing up a formal documentation.

Buffer Indexed Reads

TODOs in 'CameraManager.cpp'

The GPUBuffer object should have the option to intercept any read or write operations. As they are all internally represented as a 1D array, the ability to interface the data with a arbitrary pattern is useful for a good deal of things. For example, all the ray data is stored in a GPUBuffer. Memory coherency could be increased if all spatially similar indices on a 2D representation (lets say n, n+1, n+21, n+ 531, n + 532) were located next to each other in memory. Thus, bugger[0] would read a different value depending on a pattern/pre-processing step

Settings Not Compiling

the settings would not compile after a refactoring in the main branch

Input.cpp

needs to be implemented

OpenGL shader Compilation Error

On a Intel system with no discrete GPU, shader compilation crashes. This does not happen on a system with a discrete GPU.

JIRA link: https://synodic.atlassian.net/rest/api/2/issue/10000

OpenGL shader Compilation Error

On a Intel system with no discrete GPU, shader compilation crashes. This does not happen on a system with a discrete GPU.

Serialization

Investigate texture and object serialization. We don't want to load a slow object from file every time, just hot swap the already loaded binary file.

Replace Includes With Forward Declarations

Headers should not be included when a forward declaration suffices. If an #include is used for just a signature such as

• void PushBack(const Dog$);
• Dog* dog

and not as a storage requirement such as

• Dog dog;

then the #include can be moved to the *.cpp file and a forward declaration used in its place class Dog;

Update Camera Structure

• Separate the Camera class into a lens, a film, and a camera.
• Sample the camera with normalized values, not explicit pixels. This will help extensions for future camera work and allow for some deprecated code to be removed.

Update Documentation for Custom Allocator

Add a page that contains the following information to the Soul Engine Wiki:

• A description of the custom allocator and why it is being used for this project.

• Function calls necessary to utilize the allocator

• Example usage