hasan-jawaheri / wasabi Goto Github PK

Need a multi-threaded worker-based system to support CPU-based computations/operations such as particle system simulation and physics simulation.

Functional requirements:

• Submission of work as just a function.
• Submission of work as a higher-level worker agent with more finely-controlled execution.
• Worker agents should be able to launch work, suspend themselves and continue when their submitted work is complete.
• Worker agents should be able to run in a thread indefinitely should they choose to do so (as if they were a submission of a function that infinitely loops).
• Worker agents should be able to "yield" in a way and continue later.
• Ability to make task callbacks (on completion) get called in the game loop (main thread), up to a maximum threshold per frame/iteration.
• (Optional) Threads manager should be able to spawn more threads should there be more demand.
• (Optional) Submitted works can have a priority.

Use cases to optimize for:

• Worker that does a time-based simulation as fixed time-steps. e.g. Every ~25ms it needs to run to update/create new state. State should be part of the worker agent class (user defined, inherited from some interface for the agent).
• Simple task with a callback. Callbacks execute in worker threads or in main loop.
• Long running tasks. Should be able to (optionally) be chunked into multiple execution slots in the worker manager to not hog the thread.

GLFW won't allow creation of windows in any threads other than the main thread. Further, it only wants on glfwPoll to happen. So Wasabi should have the main (first) thread run only window-related tasks, and run the rest of the rendering (and whatever else) starting in a new separate thread.
Functional requirements:

• Make wasabi start (main thread) by forking a new thread and running WInitialize over there.
• Make the main thread allow GUI plugins to operate.
• GLFW GUI plugin should have a queue of window creation requests, where GLFW window creation actually happens. GLFW window creation functions will simply submit to the thread and wait for completion.
• GLFW GUI plugin should poll events in the GUI thread, between window creations.

Render to texture has the following problems:

• Resizing the window causes weirdness (application hangs?)
• In debug mode, Vulkan throws lots and lots of errors during render

An FXAA implementation is desperately needed since no default AA is available.

Lighting needs to be reworked to have proper specular terms.

Functional requirements:

• Proper specular lighting
• Deferred and forward rendering should yield similar outputs
• SSAO needs a good diffuser texture
• GBuffer can be more neatly packed
• Need ability to set specular power, intensity and ambient light (in forward renderer)

Switching between different renderers during the demo (1 & 2 keys) causes rendered objects to randomly change properties like texture and color.

This is tested on a Mac with LightsDemo.

Instead of the current manual reflection, use the SPIR-V reflection API as it is cleaner, more feature-packed and a lot more convenient than manually reflecting.

Lighting:
Particles (internal) lighting could be done by supplying lights to the particle render (up to a maximum number) and performing the lighting in the pixel shader of the particle (similar to forward rendering lighting). Lights can be supplied to the particles per-frame depending on their distance and visibility to the particles.
Particles should also be able to compute normals to be able to be properly lit.

Soft particles:
Use depth-check to allow for soft particles.

Need to compile the doxygen documentation and add it as documentation.

Need to test compilation and running of the engine on Linux.

Requirements:

• Patch the CMake file for any linux-specific things
• Confirm that GCC is able to compile and run the code
• Confirm that all the tests run properly and all features are supported

Functional requirement:

• WError should be able to carry a string to explain the cause of the error
• Error strings are only used in debug mode (for performance)
• (Optional) WError should carry a vector of strings and errors can accumulate (i.e. in a nested function, the deepest error will keep bubbling up appending error strings to the vector

Particles system stop emitting after a while

Physics step rate should be decoupled from graphics frame rate and should be run in a separate thread:
1- this will save CPU time doing physics stuff making both physics and graphics threads faster and have more consistent rates
2- physics can run at a much lower rate (30 steps per seconds) saving CPU time
3- physics can be a lot more stable at fixed (and lower) rate

Need to check but some locking will likely be required as some operations (e.g. ray casting, or applying forces) cannot be done WHILE physics is stepping.

How will threads interact?

• Physics component should provide utilities to launch/stop the physics thread
• Main thread (graphics + logic) will read physics state (positions/orientations) every frame in the main loop
• Physics thread will write positions/orientations every frame (probably at lower FPS)
• Main thread will need to change interaction with physics such that:
  • Reading remains same from rigid body
  • Writing needs to be queued (this can be handled in rigid body implementation) and done in between the steps
  • Utilities (ray casting?) needs research/verification

The purpose of this split was mainly motivated by improving experience while implementing a game with physics. To get reliable motion via applyForce, a stable physics frame rate is important. It may be better to have the physics thread perform those motions (e.g. to guarantee 1 applyForce per step). This can be done by allowing the users to peek into the queue (it may be enough to implement a getQueueSize so users know not to insert more if already queued. Or be able to directly manipulate queue if its 1 queue for all actions)

There is a weird wobbling that happens when the camera moves. I suspect it has something to do with the buffering and camera matrices (perhaps push constants are ahead of their time?)

There is also a flickering issue when objects are spawned mid-loop, they seem to always render in center for one frame.

Implement tests using Catch2. Need to rewrite and restructure the whole testing framework.

Render fragments aren't able to render anything with custom effects. Sprites demo is missing the custom effect sprite due to this.

Need to test compilation and running of the engine on MacOS.

Requirements:

• Patch the CMake file for any mac-specific things
• Confirm that XCode is able to compile and run the code
• Confirm that all the tests run properly and all features are supported

Clean up repo to reduce its size.

Clean ups required:

• Useless files (ahem latex?)
• git history with binary files

Store last-edited time for shader files and dont re-compile them if not modified and compiled file still exists.

Changing code doesn't make the make system relink the wasabi library

All warnings in the library need to be addressed.

Complete the documentation doxygen pages in gh-pages branch.

Wasabi should ship with a sample application

Functional requirements:

• A simple ping-pong 2D game
• A more complex ping-pong with cool features

Vulkan error message:

0x0000011a29e2dc20 " [ UNASSIGNED-CoreValidation-Shader-InputNotProduced ] Object: 0x2c (Type = 15) | Vertex shader consumes input at location 5 but not provided"

Due to the vertex shaders expecting a second animation buffer

Geometry shaders are not supported on Mac, and generally not used frequently. Currently the only geometry shader in Wasabi is for converting particles vertices into billboards. This can be done on the CPU to eliminate the need for the geometry shader feature.

FBX SDK manual fiddling should be removed and replaced with the much larger library Assimp.

Minimal requirements:

• Remove FBX importer
• Implement loading of geometry
• Implement loading of skeletal animation

Nice-to-haves:

• Import and export Wasabi files
• Import and export material data

Integrate the repository with TravisCI

Consider doing particles simulation in a side thread, and doing just the view transformation in the main thread.

Create a basic map editor application to be shipped with Wasabi.

Functional Requirements:

• Integrate a new project into the build system
• New project creates an executable that is an IMGUI window, with a Wasabi engine running in a child window view
• Simple toolbar with any dummy functionality

Add support for a MessageBox on mac and linux (part of WWindowAndInputComponent)

Rendering is somewhat a mess right now: the stages are completely decoupled from objects and effects. This causes a lot of "guess work" for the render fragments and a confusing user experience.

Functional requirements:

• Make rendering indexed by effects, not objects/terrains/sprites/etc...
• Make effects bind to a render stage (which makes sense) instead of a render target
• Add the ability to override default rendering order
• This may eliminate the need for effect flags (for now?)

This opens up the door for massive optimizations (such as batching static objects together in one geometry or one (set of) materials/UBOs) and will clean up the code quite a lot.

Functional requirements:

• Add basic rendering of the terrain mesh
• Add ability to supply a set of textures to be tiled over the terrain
• Terrain should use a clip map for height and for texture/surface properties
• Height can be from a height map or a class can be overridden to supply X and Y coordinates at every point (or something similar to that) to allow creation of custom synthesizers
• (Optional) Brush-like editing features: edit height and texturing

Add ability to render text and sprites using a unit other than pixels such that they are more consistent across devices. The unit will rely on the DPI of the screen.

Need support for loading assets from worker thread(s).

Functional requirements:

• Data should be loadable separately from Vulkan-specific resources.
• An estimate on the loading time should be made based on the size/complexity of the data.
• Loaded data should be made available in Vulkan resources during the game loop slowly and per frame. The number of resources that can be processed by Vulkan per loop iteration should depend on the estimated loading times.
• There should be a user-specified priority to loading such that high-priority resources are loaded ASAP.
• Dependencies should be properly handled.
• Rules for custom (user-defined) dependencies may be required, in the form of callbacks on-load.
• All loading must be done this way. Application should be able to wait on loading to happen while running a splash screen or playing a mini-game.