aleksigron / kokko Goto Github PK

Currently, all rendering happens on the main thread. Rendering should be moved to another thread to take advantage of multicore performance.

Prerequisite #29

One complication to creating command buffers in multiple threads is how to manage resource creation and destruction across threads. Each thread can create new resources and therefore needs new IDs generated for the resources. Threads can also destroy existing resources and the resources can be accessed at the same time from other threads.

• Creation of IDs should happen locally on the thread. Each thread should have a thread-local store for created IDs that will be merged to the main ID store at the end of the frame. Main ID store is otherwise read-only during the frame.
• Newly created resources can only be accessed from the thread that created it. This guarantees that there are no other threads trying to access the resource while its ID is only registered to the thread-local ID store. I still need to think about how to make sure the created ID can't be passed to another thread.
• Destruction of resources should be deferred to the end of the frame. This guarantees that any thread can still access the resource while one of the threads might have requested to destroy the resource.
• Each thread should have a thread-local store of resources that have been requested to be destroyed. All the requests are merged and destroyed at the end of the frame.

• Implement loading glTF models with node hierarchy, multiple meshes and mesh primitives (#63)
• Implement model removal and storage reuse (#66)
• Rename mesh primitive to mesh part (#65)
• Support selecting a specific mesh from a model with multiple meshes to be used in a mesh component (#67)
• Support setting a material for each mesh part (#68)
• Support rendering mesh parts with different transparency types from the same mesh (#68)
• Support creating a hierarchy of nodes in the scene from a model (#69)

Currently we running unit tests as part of the startup of the editor. This is good for engine and editor development, but it would be nice to have a separate runner executable for CI.

There is currently an internal material that is used for terrain rendering. This should be replaced with properties in the terrain component. The terrain material should be removed.

This is required for basic editing of terrain. It is also required for large and high detail terrain, because we can't keep everything in memory at once.

This needs some new editor UI so the user can create terrain data and select which data to use for a component.

It would be very good to catch potential runtime issues with sanitizers. Probably easiest to add another Linux GCC config to do that. Only downside for now is that we don't have good test coverage. The sanitizer can only catch problems in code that is being run.

Currently we are not casting shadows from terrain and we need to fix that. This requires the ability to add commands to the shadow viewports from graphics feature. It also requires separate culling pass for each of the shadow views. Should the shadows render the same tile same shadow detail as the main view?

If you have an object in the scene that has children, you can delete the object, but that doesn't delete its children. These children are still left behind in some way. This can be reproduced at least with mesh components.

1. Create an entity with a mesh component with a mesh
2. Create another entity with a mesh component with a mesh
3. Move the second entity to be a child of the first entity in the scene
4. Delete the parent entity
5. Observe that the child entity's mesh is still drawn

In order to support higher detail and larger terrain, we need to stream tiles into memory as the player/view moves around the level.

Prerequisite #36

Currently the different detail level tiles leave small gaps between them. We want modify the edges of higher detail tiles to match the vertex count and position of the lower detail tiles. We need to create 8 new index buffers to have the topologies available to be able to match any combination of neighbor tiles.

CustomRenderer was the first idea of how to render custom graphics features. It turned out, the abstraction level was not correct for the purpose. It was hard to implement different kinds of features, other than a simple callback to run some external code in between other render commands.

GraphicsFeature implements the same basic idea, but with more structured inputs. It supports all the use cases CustomRenderer supports, and more. So we should convert the remaining features to the single system.

Currently the only way to select an object, is to do it from the entity list view. This is clumsy as the list order isn't relevant spatially so it is hard to find the object that you want. For non-mesh objects, this implementation depends on #70.

To make sure we don't break rendering features, we should add render tests.

• Add a runner executable to run the tests
• Design how to describe a render test (in code or a text file)
• If tests are described in text files, implement discovery of tests by iterating through a directory structure
• Encode and decode of the render results and expectations
• Compare test result to the expectation and calculate a difference metric
• Output a test report

As we are already using UIDs to reference most assets, it should be easy to rename assets without breaking references.

The render and dispatch stages, as I will call them here, are currently combined into one procedure. I will give short description of what I mean with the stages.

• Render stage here means to figure out what render state needs to be set and what data is needed in order to draw an object.
• Dispatch stage would be where we actually upload our resources, set render state and dispatch the draw calls.

There is also an earlier stage in Renderer, where objects and control commands are added to a command list to be sorted in the right order relating to viewports and render passes. This stage does not need to change to complete this task.

Here are some notes for the technical implementation.

• Render stage would build an internal representation of the actual to render commands we are going to do.
• The command representation needs to contain all data needed to submit the commands to the GPU.
• The separation of stages also needs to be done for debug drawing and GUI drawing.
• Any data that is uploaded to buffers or textures also needs to be copied or moved to the internal representation.
• We might want to have some threshold for what size of data is copied directly into the command stream and what is stored separately.
• When executing commands, the executor could contain the previously bound state to not unnecessarily bind the same state again.

Any information coming back from the render command calls are a complication. For example creating any resources (buffers, textures, framebuffers, samplers), return the IDs of the created resources. These IDs need to be able to be used immediately after encoding the command. The normal use case is to create a resource, and immediately update its properties and data. This means that we need to create some kind of ID immediately when the command is encoded and then map that ID to the actual ID assigned by the driver.

Another issue are shader compilation and uniform location retrieval. It might be necessary to have a method of running GPU commands synchronously, since these tasks would otherwise be incredibly hard to accomplish. For now, it is possible to just use existing RenderDevice interface for that. In the future, though, we would need a way to run these synchronous command blocks on the correct thread.

Separating the render and dispatch stages is a prerequisite to moving rendering to another thread. The data can be built on multiple threads if needed, since we are not yet calling any GPU commands. Then we can move the data to a separate render thread where it is a very simple job to submit the actual GPU calls from the command data. Using multiple threads to build or execute the data is not part of this task.

Takes about 0,25 ms on Ryzen 7950X.

Visualize entities with components such as lights, cameras, environments and particle systems in scene view. Currently these objects don't have a concrete representation in the scene view. This would be especially useful for lights, that hard quite hard to locate currently, unless you have the object selected.

(removed description)

In order to support the modern graphics features Kokko might want to use on macOS, we need to implement support for the Metal rendering API. When running on Metal, Xcode also provides very good graphics debugging tools that are better than anything found on OpenGL or Vulkan, which could make debugging and profiling much easier. Metal fits somewhere between OpenGL and Vulkan when it comes to abstraction level, so supporting Metal makes it slightly easier to implement support for Vulkan in the future.

• Basic support: project builds and renders a background color to the screen
• Basic shader & vertex buffers: a fixed shader can be compiled and rendered using a fixed vertex buffer
• Mesh support: glTF meshes can be loaded from assets and rendered with a fixed shader
• Shader support: shaders can be loaded, cross-compiled from GLSL and rendered
• Texture support: textures can be loaded and used in shaders
• ImGUI support: editor UI works
• Environment map can be loaded and rendered to scene view
• Render scene entities to scene view
• Post-process effects: SSAO and Bloom