adepke / vanguardengine Goto Github PK

When rendering the scene, we don't take into account the editor viewport, which causes any differences in aspect ratio to lead to stretching when viewing the scene. We need to compute the available content region of the viewport and pass it back to the renderer.

Having to manually navigate to third party headers outside of the IDE is a pain, they should instead be available directly inside the IDE.

Implement the new Agility SDK, separating new DirectX features from Windows updates. This will lighten the restriction on minimum Windows version in order to run the engine. Refer to this blog post for details.

Leverage ImGui docking to manage the tool windows in the editor, allowing for a much nicer UX.

Assert statements should use fmtlib to properly format any arguments passed, not c-style string formatting.

If more than one full GPU synchronizations are dispatched within a single frame, only the first synchronization will be obeyed. This is due to a lack of per-frame sync values, which is needed for multi-sync.

When hovering the mouse over the edges of the engine window, the resize cursor image only appears for a single frame, before returning to the default Windows cursor image. ImGui windows have the proper cursor behavior.

The existing engine-side system using an offline and online set of descriptor heaps, and copying when constructing descriptor tables works well. However, external systems such as ImGui aren't integrated with this descriptor system, which causes unbound resource errors when attempting to use a texture managed on the engine side within ImGui. An example of this is ImGui::Image(), where the image passed might be a texture from a material, which resides in an offline heap. In PIX, the texture binding will show up as "referenced but not bound to the pipeline stage".

Implement tone mapping to preserve detail in brightly lit areas of the scene, as well as dark regions.

Fmtlib has poor formatting of HRESULTs, so a custom formatter should be introduced for this. Ideally, format HRESULTs as unsigned hex with the 0x prefix, and as capital letters. See fmtlib/fmt#235. Look into stringifying the error code as well.

The render overlays in the editor only work if the scene window is docked and in view, otherwise things break down. The overlay proxy should be integrated differently and using less direct cursor offsets, following how the console window system works.

The current method of getting the scene output in the editor GUI is to use a separate fullscreen render target, which acts as a back buffer texture. This is very wasteful with respect to GPU memory bandwidth, so consider drawing the scene inline with the editor GUI using ImDrawCallbacks.

DXGI 1.3 allows for waitable swap chains, which can be used to reduce input latency. See this page for details.

Shaders are compiled once at engine startup, but we should allow for hot reloading and recompiling all affected pipeline states. This will allow for modifying shader sources while the engine is running, without having to restart in order to see changes.

In the existing render graph implementation, transient resources are recreated and destroyed every frame, which is a massive CPU bottleneck. Resources should be reused when possible to prevent huge wastes of CPU time.

There is a visual mismatch between the drawn cursor position and where ImGui believes the cursor is on screen. Additionally, as the physical cursor moves further from the window origin, the more the cursor desyncs. This can be seen when hovering over the resize icon on the bottom right of windows, if the window is near the top of the physical window it works fairly well, but if the window is near the bottom there is a significant offset.

Vertices are 56 bytes in size, which leads to bandwidth becoming the bottleneck in high-throughput renders. Vertices should be optimized and compressed to be 32 bytes in size. Look into: computing tangent/bitangent on the GPU from UVs, octahedron normal encoding.

Refer to this paper for details: https://blog.selfshadow.com/publications/turquin/ms_comp_final.pdf.

Currently, shaders are written as fully self-contained sources, leading to lots of duplication for common operations. Instead, sources should be modularized out into HLSL includes. An example of this would be introducing Mesh.hlsli for handling mesh-related operations, Vertex.hlsli for standardized programmable vertex pulling, and Color.hlsli for color space conversion utilities.

Buffers are not aligned properly, and cause the D3D12 validation layer to throw warnings when creating constant buffer views.

TracyServer requires the following two additional settings in the project file in order to build on Windows.

<ConformanceMode>true</ConformanceMode>
<Linkage-freetype>static</Linkage-freetype>

These settings are not exposed through premake (as of writing this), and will need to be manually implemented, possibly through a module.

When a fatal log occurs, it will cause the attached debugger to break in Logging.h, instead of the actual offending line. This requires the user to view the callstack and manually step out a frame to get to the proper line, which isn't the desired behavior.

The existing descriptor binding model tries to emulate D3D11, however this isn't the ideal solution. Instead of tightly coupling descriptors with resources, consider looking into a "resource binder" object, or potentially create descriptors on demand. For material textures, consider not even exposing the underlying resource, instead expose a collection of SRVs.

With shader model 6.6, resources can be accessed in shaders exclusively via bindless indices, without the need for multiple tables with overlapping unbounded arrays. Additionally, root signatures can have more root constant data than needed without issue. In theory one root signature with 64 DWORDs of root constants and nothing else should be all that's needed for every shader. Other notes: the runtime combines duplicate root signatures into one. Could use shader code generation for handling static samplers.

When logging, if data that has the same type as PlatformErrorType, it will be interpreted as a platform error (which may not be intended) due to the lack of context.

The engine processes every Windows input event, which is ideal for operations such as typing, where we don't want to lose keystrokes at low framerates or hitches, however this behavior is suboptimal for movement inputs, such as controlling a camera. When processing every input event, low framerates can lead to a large message stack that results in very latent movement and unresponsiveness.

I don't see a case where we won't be using programmable pulling for vertices, so exposing traditional vertex buffers is pointless. Removing them will reduce the existing bind flags for buffers.

Render passes all share the same zone name in Tracy due to the same SourceLocation being used for each pass (static). A unique source location should be able to be created for each pass without relying on macros.

Shaders should be considered engine source code, being stored with the rest of the code, rather than being grouped with asset files. This also allows for the shaders to appear in an IDE's project files, instead of having to open them via file explorer.

All pipelines can be created statically, having large portions of their description be inferred from the passes that use them.

The existing lighting uses incorrect normal mapping, where the normal map is sampled and given directly to the lighting equation, without any spatial correction.

Implement DirectX DRED for much easier debugging of device removals.

Add include guards to hlsl include files. Without these, including the same file multiple times will cause multiply-defined symbol errors.

When inspecting a depth texture in the editor, the depth should be linearized to allow for a more useful visual analysis. To do this, consider using a separate pipeline state for depth texture rendering that remaps the pixel values when drawing.

Using hardcoded root signature indices is extremely fragile and prone to issues. Analyze shader reflection data to get bind points via string name.

Tracy uses vcpkg, so we should invoke the shipped installation script in order to acquire the server's dependencies. Without this, attempting to build without manually fetching the dependencies results in a failed TracyServer build.

The existing camera movement utilities are very poor and quickly thrown in. A proper FPS-like movement system should be implemented, with delta times so movement is not frame rate dependent. Also there needs to be a way to reacquire control, such as when clicking on the viewport window.

The existing render output is not gamma-corrected, as it doesn't use sRGB. Refer to this page and this forum post for using sRGB.

Use the info queue to automatically break the program when an error or corruption is detected in the debug layer. This can help track down rendering issues where the application will continue to run in a partially broken state.

A large amount of objects are leaking in the DX12 runtime, guessing about one object per frame. All of the leaked objects have a refcount of 1, so I'm assuming these are leaked transient resources from the render graph.

The existing render graph is hardcoded and fairly rigid. The editor should expose tools to change the render graph, such as allowing for enabling and disabling passes in real time. This will need to be implemented after dynamic shader pipelines, where pipelines will need to be produced procedurally based off the render pass's info.

When double clicking an entity in the entity hierarchy, the property viewer should automatically open and be brought to focus.

Many materials use opacity mapping, which needs to take an alpha-testing path in a shader. A new render pass needs to be introduced for this, which would run after the opaque forward pass. In the Sponza model, the foliage and chain links use opacity mapping.

When writing to a texture, the source placed footprint resource (upload buffer) needs to be aligned to D3D12_TEXTURE_DATA_PLACEMENT_ALIGNMENT. This is normally the case, since power of two textures are commonly added, however if a buffer with static frequency is written to that isn't aligned to 512 bytes, it will cause the next texture write to be misaligned and throw an error.

Refer to Frostbite's implementation, do not implement volumetric cloud rendering until later.

Transparent materials are incorrectly drawn due to a lack of distance sorting. Consider order-independent transparency as well.

When waiting for a frame deadline, just sleeping until the objective is varyingly imprecise. A better solution is to modify the timer resolution, sleep until some small unit of time before the deadline, and then spin wait for the remaining time segment. This will significantly reduce frame time variations.

Refer to adepke/Jobs#6 for more information.

If a resource is selected for transient reuse within the render graph, the D3D12 name should be updated to aid debugging.

Command lists should record a list of the resources they use for later validation within the render graph to ensure all read/written resources within the pass are declared.