It should be possible to reduce world mesh and von traversal and buffer build up by a lot.
World mesh
For world mesh, we could set up all Indirect Args/instances after "World loaded" once and only issue the needed draw calls, completely removing any work on preparing everything.
If we do this, we could also create a single large texture2darray with all world mesh needed textures up front and update the shader to sample from that, further reducing any overhead.
VOBs
Addendum:
For static VOBs without animation, we could make use of modern hardware by making use of the available VRAM > 3GB and store all textures needed to draw them in a set of texture atlasses to allow for enhanced instancing.
By adding the atlas approach (possibly in the future with Tiles Resources on top) we can even further enhance rendering by doing the Culling of visible entities fully on the GPU using Compute Shaders and Indirect drawing.
But doing this gets complicated when VOBs are "animated" (i.e. changing meshlib or textures at runtime, after initial scene/world loading) as the overhead of re-creating or resources or doing additional separate CPU side culling may cause detrimental performance. We could initially provide this feature as an experiment, noting that it currently doesn't support "Animate Static VOBs" functionality.
For vobs we can do mostly the same
, but need to also implement instancing using a big StructuredBuffer where we store the per-frame instance data for all vobs, indexed by a on-world-load created Instance-Index (should then be stored in the VobInfo)
Also we could/should store all Vertex/Index buffers in two "big" Vertex buffers and index into them, when doing this we only ever need to update the per-frame data.
This all should also perfectly fit into memory without causing any trouble. And since DXVK loads these big buffers into the Vulkan runtimes own memory space, we could save even more system memory, directly reducing the chances of any Out of Memory errors.
This could immensely reduce CPU usage, leaving more for it for things like NPC AI and mods.
Especially since those buffers could be re-used across all stages (g-buffer, shadow maps, pointlights, transparency)
A negative would be missing compatibility for directx10 era hardware.
Though, DirectX12 has been out for 10 Years and DirectX (FL11.0) has been out for way longer. We should be able to make this optionally available to anyone providing FL11.0 support.
It should be possible to reduce world mesh and von traversal and buffer build up by a lot.
World mesh
For world mesh, we could set up all Indirect Args/instances after "World loaded" once and only issue the needed draw calls, completely removing any work on preparing everything.
If we do this, we could also create a single large texture2darray with all world mesh needed textures up front and update the shader to sample from that, further reducing any overhead.
VOBs
Addendum:
For static VOBs without animation, we could make use of modern hardware by making use of the available VRAM > 3GB and store all textures needed to draw them in a set of texture atlasses to allow for enhanced instancing.
By adding the atlas approach (possibly in the future with Tiles Resources on top) we can even further enhance rendering by doing the Culling of visible entities fully on the GPU using Compute Shaders and Indirect drawing.
But doing this gets complicated when VOBs are "animated" (i.e. changing meshlib or textures at runtime, after initial scene/world loading) as the overhead of re-creating or resources or doing additional separate CPU side culling may cause detrimental performance. We could initially provide this feature as an experiment, noting that it currently doesn't support "Animate Static VOBs" functionality.
For vobs we can do mostly the same
, but need to also implement instancing using a big StructuredBuffer where we store the per-frame instance data for all vobs, indexed by a on-world-load created Instance-Index (should then be stored in the VobInfo)
Also we could/should store all Vertex/Index buffers in two "big" Vertex buffers and index into them, when doing this we only ever need to update the per-frame data.
This all should also perfectly fit into memory without causing any trouble. And since DXVK loads these big buffers into the Vulkan runtimes own memory space, we could save even more system memory, directly reducing the chances of any Out of Memory errors.
This could immensely reduce CPU usage, leaving more for it for things like NPC AI and mods.
Especially since those buffers could be re-used across all stages (g-buffer, shadow maps, pointlights, transparency)
A negative would be missing compatibility for directx10 era hardware.
Though, DirectX12 has been out for 10 Years and DirectX (FL11.0) has been out for way longer. We should be able to make this optionally available to anyone providing FL11.0 support.