qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-12-20 17:41:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/libs/video/renderer/vulkan/vulkan_lighting.c

732 lines
21 KiB
C
Raw Normal View History

[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
/*
vulkan_lighting.c
Vulkan lighting pass pipeline
Copyright (C) 2021 Bill Currie <bill@taniwha.org>
Author: Bill Currie <bill@taniwha.org>
Date: 2021/2/23
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
*/
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
#ifdef HAVE_STRING_H
# include <string.h>
#endif
#ifdef HAVE_STRINGS_H
# include <strings.h>
#endif
#include <stdlib.h>
#include "qfalloca.h"
[vulkan] Add some more debug stack contexts
2021-12-02 13:48:50 +00:00
#include "QF/cvar.h"
[vulkan] Load the map's lights into an array It's not used yet as work needs to be done to better support generic entities, but this is the next step to real-time lighting (though, to be honest, I expect it will be too slow to be usable).
2021-03-03 09:14:16 +00:00
#include "QF/dstring.h"
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
#include "QF/heapsort.h"
[util] Rename qfplist.[ch] The name is a hold-over from before the current quakeforge tree and the QF include directory.
2021-03-21 07:13:03 +00:00
#include "QF/plist.h"
[vulkan] Load the map's lights into an array It's not used yet as work needs to be done to better support generic entities, but this is the next step to real-time lighting (though, to be honest, I expect it will be too slow to be usable).
2021-03-03 09:14:16 +00:00
#include "QF/progs.h"
#include "QF/script.h"
[model] Remove 64k limit on visible leafs Modern maps can have many more leafs (eg, ad_tears has 98983 leafs). Using set_t makes dynamic leaf counts easy to support and the code much easier to read (though set_is_member and the iterators are a little slower). The main thing to watch out for is the novis set and the set returned by Mod_LeafPVS never shrink, and may have excess elements (ie, indicate that nonexistent leafs are visible).
2021-07-26 02:15:51 +00:00
#include "QF/set.h"
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
#include "QF/sys.h"
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
#include "QF/va.h"
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
#include "QF/scene/scene.h"
[vulkan] Add light count display Enabled by 'developer lighting'. It was good for confirming that the lights in ad_e1m1 (Doom Hangar 16) were actually being output (over 600 of them sometimes, ouch). Turned out to be the color scale ambiguity.
2022-05-27 01:19:15 +00:00
#include "QF/ui/view.h"
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
[vulkan] Add light count display Enabled by 'developer lighting'. It was good for confirming that the lights in ad_e1m1 (Doom Hangar 16) were actually being output (over 600 of them sometimes, ouch). Turned out to be the color scale ambiguity.
2022-05-27 01:19:15 +00:00
#include "QF/Vulkan/qf_draw.h"
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
#include "QF/Vulkan/qf_lighting.h"
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
#include "QF/Vulkan/qf_texture.h"
[vulkan] Clean up buffer barriers a bit This even fixes a couple of minor issues that snuck past validation.
2021-04-24 06:47:31 +00:00
#include "QF/Vulkan/barrier.h"
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
#include "QF/Vulkan/buffer.h"
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
#include "QF/Vulkan/debug.h"
#include "QF/Vulkan/descriptor.h"
#include "QF/Vulkan/device.h"
#include "QF/Vulkan/image.h"
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
#include "QF/Vulkan/instance.h"
#include "QF/Vulkan/projection.h"
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
#include "QF/Vulkan/renderpass.h"
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
#include "QF/Vulkan/staging.h"
#include "compat.h"
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
#include "r_internal.h"
#include "vid_vulkan.h"
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
static void
update_lights (vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
lightingctx_t *lctx = ctx->lighting_context;
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
lightingdata_t *ldata = lctx->ldata;
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
lightingframe_t *lframe = &lctx->frames.a[ctx->curFrame];
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
Light_FindVisibleLights (ldata);
[vulkan] Implement real-time lighting Light styles and shadows aren't implemented yet. The map's entities are used to create the lights, and the PVS used to determine which lights might be visible (ie, the surfaces they light). That could do with some more improvements (eg, checking if a leaf is outside a spotlight's cone), but the concept seems to work.
2021-03-20 07:08:44 +00:00
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
dlight_t *lights[MaxLights];
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
qfv_packet_t *packet = QFV_PacketAcquire (ctx->staging);
qfv_light_buffer_t *light_data = QFV_PacketExtend (packet,
sizeof (*light_data));
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
float style_intensities[NumStyles];
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
for (int i = 0; i < NumStyles; i++) {
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
style_intensities[i] = d_lightstylevalue[i] / 65536.0;
[vulkan] Implement light styles Other than dealing with shader data alignment issues, that went well :). Nicely, the implementation gets the explicit scaling out of the shader, and allows for a directional flag.
2021-03-22 04:13:26 +00:00
}
[vulkan] Implement all the extended light models Standard quake has just linear, but the modding community added inverse, inverse-square (raw and offset (1/(r^2+1)), infinite (sun), and ambient (minlight). Other than the lack of shadows, marcher now looks really good.
2021-04-25 01:01:57 +00:00
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
light_data->lightCount = 0;
[renderer] Move a couple functions to using vec4f_t Makes for a few less FIXMEs and better consistency with vectors.
2022-03-30 14:50:12 +00:00
R_FindNearLights (r_refdef.frame.position, MaxLights - 1, lights);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
for (int i = 0; i < MaxLights - 1; i++) {
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
if (!lights[i]) {
break;
}
light_data->lightCount++;
VectorCopy (lights[i]->color, light_data->lights[i].color);
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
// dynamic lights seem a tad faint, so 16x map lights
light_data->lights[i].color[3] = lights[i]->radius / 16;
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
VectorCopy (lights[i]->origin, light_data->lights[i].position);
[vulkan] Ensure dynamic lights are positional I'm not sure what's up with the weird lighting that results from dynamic lights being directional (sunlight works nicely in marcher, but it has a unit vector for position).
2022-05-05 10:55:35 +00:00
// dlights are local point sources
light_data->lights[i].position[3] = 1;
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
light_data->lights[i].attenuation =
(vec4f_t) { 0, 0, 1, 1/lights[i]->radius };
[vulkan] Ensure dynamic lights are positional I'm not sure what's up with the weird lighting that results from dynamic lights being directional (sunlight works nicely in marcher, but it has a unit vector for position).
2022-05-05 10:55:35 +00:00
// full sphere, normal light (not ambient)
light_data->lights[i].direction = (vec4f_t) { 0, 0, 1, 1 };
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
}
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
for (size_t i = 0; (i < ldata->lightvis.size
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
&& light_data->lightCount < MaxLights); i++) {
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
if (ldata->lightvis.a[i]) {
light_t *light = &light_data->lights[light_data->lightCount++];
*light = ldata->lights.a[i];
light->color[3] *= style_intensities[ldata->lightstyles.a[i]];
[vulkan] Implement real-time lighting Light styles and shadows aren't implemented yet. The map's entities are used to create the lights, and the PVS used to determine which lights might be visible (ie, the surfaces they light). That could do with some more improvements (eg, checking if a leaf is outside a spotlight's cone), but the concept seems to work.
2021-03-20 07:08:44 +00:00
}
}
[vulkan] Add light count display Enabled by 'developer lighting'. It was good for confirming that the lights in ad_e1m1 (Doom Hangar 16) were actually being output (over 600 of them sometimes, ouch). Turned out to be the color scale ambiguity.
2022-05-27 01:19:15 +00:00
if (developer & SYS_lighting) {
Vulkan_Draw_String (vid.conview->xlen - 32, 8,
va (ctx->va_ctx, "%3d", light_data->lightCount),
ctx);
}
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
[vulkan] Clean up buffer barriers a bit This even fixes a couple of minor issues that snuck past validation.
2021-04-24 06:47:31 +00:00
qfv_bufferbarrier_t bb = bufferBarriers[qfv_BB_Unknown_to_TransferWrite];
bb.barrier.buffer = lframe->light_buffer;
bb.barrier.size = sizeof (qfv_light_buffer_t);
dfunc->vkCmdPipelineBarrier (packet->cmd, bb.srcStages, bb.dstStages,
0, 0, 0, 1, &bb.barrier, 0, 0);
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
VkBufferCopy copy_region[] = {
{ packet->offset, 0, sizeof (qfv_light_buffer_t) },
};
dfunc->vkCmdCopyBuffer (packet->cmd, ctx->staging->buffer,
lframe->light_buffer, 1, &copy_region[0]);
[vulkan] Clean up buffer barriers a bit This even fixes a couple of minor issues that snuck past validation.
2021-04-24 06:47:31 +00:00
bb = bufferBarriers[qfv_BB_TransferWrite_to_UniformRead];
bb.barrier.buffer = lframe->light_buffer;
bb.barrier.size = sizeof (qfv_light_buffer_t);
dfunc->vkCmdPipelineBarrier (packet->cmd, bb.srcStages, bb.dstStages,
0, 0, 0, 1, &bb.barrier, 0, 0);
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
QFV_PacketSubmit (packet);
}
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
void
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
Vulkan_Lighting_Draw (qfv_renderframe_t *rFrame)
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
{
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
vulkan_ctx_t *ctx = rFrame->vulkan_ctx;
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
qfv_renderpass_t *renderpass = rFrame->renderpass;
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
lightingctx_t *lctx = ctx->lighting_context;
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
if (!lctx->scene) {
return;
}
[vulkan] Don't update lights that don't exist However, the lighting pass still needs to be run in order to generate the solid color image.
2022-05-05 12:24:22 +00:00
if (lctx->scene->lights) {
update_lights (ctx);
}
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
__auto_type cframe = &ctx->frames.a[ctx->curFrame];
lightingframe_t *lframe = &lctx->frames.a[ctx->curFrame];
VkCommandBuffer cmd = lframe->cmd;
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
DARRAY_APPEND (&rFrame->subpassCmdSets[QFV_passLighting], cmd);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
dfunc->vkResetCommandBuffer (cmd, 0);
VkCommandBufferInheritanceInfo inherit = {
VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO, 0,
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
renderpass->renderpass, QFV_passLighting,
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
cframe->framebuffer,
0, 0, 0,
};
VkCommandBufferBeginInfo beginInfo = {
VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO, 0,
VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT
| VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT, &inherit,
};
dfunc->vkBeginCommandBuffer (cmd, &beginInfo);
[vulkan] Label the drawing command buffers
2021-04-18 11:40:43 +00:00
QFV_duCmdBeginLabel (device, cmd, "lighting", { 0.6, 0.5, 0.6, 1});
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
dfunc->vkCmdBindPipeline (cmd, VK_PIPELINE_BIND_POINT_GRAPHICS,
lctx->pipeline);
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
lframe->bufferInfo[0].buffer = lframe->light_buffer;
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
lframe->attachInfo[0].imageView
= renderpass->attachment_views->a[QFV_attachDepth];
lframe->attachInfo[1].imageView
= renderpass->attachment_views->a[QFV_attachColor];
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lframe->attachInfo[2].imageView
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
= renderpass->attachment_views->a[QFV_attachEmission];
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lframe->attachInfo[3].imageView
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
= renderpass->attachment_views->a[QFV_attachNormal];
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lframe->attachInfo[4].imageView
[vulkan] Support multiple render passes Multiple render passes are needed for supporting shadow mapping, and this is a huge step towards breaking the Vulkan render free of Quake, and hopefully will lead the way for breaking the GL renderers free as well.
2021-12-02 12:58:29 +00:00
= renderpass->attachment_views->a[QFV_attachPosition];
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
dfunc->vkUpdateDescriptorSets (device->dev,
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
LIGHTING_DESCRIPTORS,
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
lframe->descriptors, 0, 0);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
VkDescriptorSet sets[] = {
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lframe->attachWrite[0].dstSet,
lframe->bufferWrite[0].dstSet,
lframe->shadowWrite.dstSet,
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
};
dfunc->vkCmdBindDescriptorSets (cmd, VK_PIPELINE_BIND_POINT_GRAPHICS,
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lctx->layout, 0, 3, sets, 0, 0);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
[vulkan] Move viewport and scissor into qfv_renderpass_t This makes much more sense as they are intimately tied to the frame buffer on which a render pass is working. Now, just the window width and height are stored in vulkan_ctx_t. As a side benefit, QFV_CreateSwapchain no long references viddef (now just palette and conview in vulkan_draw.c to go).
2022-04-01 11:34:41 +00:00
dfunc->vkCmdSetViewport (cmd, 0, 1, &rFrame->renderpass->viewport);
dfunc->vkCmdSetScissor (cmd, 0, 1, &rFrame->renderpass->scissor);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
[vulkan] Switch to full screen triangle instead of quad While I have trouble imagining it making that much performance difference going from 4 verts to 3 for a whopping 2 polygons, or even from 2 triangles to 1 for each poly, using only indices for the vertices does remove a lot of code, and better yet, some memory and buffer allocations... always a good thing. That said, I guess freeing up a GPU thread for something else could make a difference.
2022-04-01 10:50:41 +00:00
dfunc->vkCmdDraw (cmd, 3, 1, 0, 0);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
[vulkan] Label the drawing command buffers
2021-04-18 11:40:43 +00:00
QFV_duCmdEndLabel (device, cmd);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
dfunc->vkEndCommandBuffer (cmd);
}
static VkDescriptorBufferInfo base_buffer_info = {
0, 0, VK_WHOLE_SIZE
};
static VkDescriptorImageInfo base_image_info = {
0, 0, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL
};
static VkWriteDescriptorSet base_buffer_write = {
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET, 0, 0,
0, 0, 1,
VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER,
0, 0, 0
};
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
static VkWriteDescriptorSet base_attachment_write = {
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET, 0, 0,
0, 0, 1,
VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT,
0, 0, 0
};
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
static VkWriteDescriptorSet base_image_write = {
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET, 0, 0,
0, 0, 1,
VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER,
0, 0, 0
};
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
void
Vulkan_Lighting_Init (vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
qfv_devfuncs_t *dfunc = device->funcs;
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
[vulkan] Add some more debug stack contexts
2021-12-02 13:48:50 +00:00
qfvPushDebug (ctx, "lighting init");
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
lightingctx_t *lctx = calloc (1, sizeof (lightingctx_t));
ctx->lighting_context = lctx;
[vulkan] Move projection matrix code to its own file And move more stuff over to simd.
2021-04-25 06:47:50 +00:00
DARRAY_INIT (&lctx->lightmats, 16);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
DARRAY_INIT (&lctx->lightlayers, 16);
DARRAY_INIT (&lctx->lightimages, 16);
DARRAY_INIT (&lctx->lightviews, 16);
[vulkan] Load the map's lights into an array It's not used yet as work needs to be done to better support generic entities, but this is the next step to real-time lighting (though, to be honest, I expect it will be too slow to be usable).
2021-03-03 09:14:16 +00:00
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
size_t frames = ctx->frames.size;
DARRAY_INIT (&lctx->frames, frames);
DARRAY_RESIZE (&lctx->frames, frames);
lctx->frames.grow = 0;
[vulkan] Add support for compute shaders This needed changing Vulkan_CreatePipeline to Vulkan_CreateGraphicsPipeline for consistency (and parsing the difference from a plist seemed... not worth thinking about).
2021-12-16 14:00:17 +00:00
lctx->pipeline = Vulkan_CreateGraphicsPipeline (ctx, "lighting");
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
lctx->layout = Vulkan_CreatePipelineLayout (ctx, "lighting_layout");
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lctx->sampler = Vulkan_CreateSampler (ctx, "shadow_sampler");
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
__auto_type lbuffers = QFV_AllocBufferSet (frames, alloca);
for (size_t i = 0; i < frames; i++) {
lbuffers->a[i] = QFV_CreateBuffer (device, sizeof (qfv_light_buffer_t),
VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT
| VK_BUFFER_USAGE_TRANSFER_DST_BIT);
QFV_duSetObjectName (device, VK_OBJECT_TYPE_BUFFER,
lbuffers->a[i],
va (ctx->va_ctx, "buffer:lighting:%zd", i));
}
VkMemoryRequirements requirements;
dfunc->vkGetBufferMemoryRequirements (device->dev, lbuffers->a[0],
&requirements);
[vulkan] Fix lighting size calculation It turns out the required memory size is not guaranteed to be aligned.
2021-12-15 01:45:25 +00:00
size_t light_size = QFV_NextOffset (requirements.size, &requirements);
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
lctx->light_memory = QFV_AllocBufferMemory (device, lbuffers->a[0],
[vulkan] Add function to compute next offset When allocating memory for multiple objects that have alignment requirements, it gets tedious keeping track of the offset and the alignment. This is a simple function for walking the offset respecting size and alignment requirements, and doubles as a size calculator.
2021-11-30 12:00:33 +00:00
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT,
[vulkan] Fix lighting size calculation It turns out the required memory size is not guaranteed to be aligned.
2021-12-15 01:45:25 +00:00
frames * light_size, 0);
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
QFV_duSetObjectName (device, VK_OBJECT_TYPE_DEVICE_MEMORY,
lctx->light_memory, "memory:lighting");
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
__auto_type cmdSet = QFV_AllocCommandBufferSet (1, alloca);
__auto_type attach = QFV_AllocDescriptorSetLayoutSet (frames, alloca);
__auto_type lights = QFV_AllocDescriptorSetLayoutSet (frames, alloca);
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
__auto_type shadow = QFV_AllocDescriptorSetLayoutSet (frames, alloca);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
for (size_t i = 0; i < frames; i++) {
attach->a[i] = Vulkan_CreateDescriptorSetLayout (ctx,
"lighting_attach");
lights->a[i] = Vulkan_CreateDescriptorSetLayout (ctx,
"lighting_lights");
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
shadow->a[i] = Vulkan_CreateDescriptorSetLayout (ctx,
"lighting_shadow");
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
}
__auto_type attach_pool = Vulkan_CreateDescriptorPool (ctx,
"lighting_attach_pool");
__auto_type lights_pool = Vulkan_CreateDescriptorPool (ctx,
"lighting_lights_pool");
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
__auto_type shadow_pool = Vulkan_CreateDescriptorPool (ctx,
"lighting_shadow_pool");
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
__auto_type attach_set = QFV_AllocateDescriptorSet (device, attach_pool,
attach);
__auto_type lights_set = QFV_AllocateDescriptorSet (device, lights_pool,
lights);
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
__auto_type shadow_set = QFV_AllocateDescriptorSet (device, shadow_pool,
shadow);
[vulkan] Add function to compute next offset When allocating memory for multiple objects that have alignment requirements, it gets tedious keeping track of the offset and the alignment. This is a simple function for walking the offset respecting size and alignment requirements, and doubles as a size calculator.
2021-11-30 12:00:33 +00:00
VkDeviceSize light_offset = 0;
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
for (size_t i = 0; i < frames; i++) {
__auto_type lframe = &lctx->frames.a[i];
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
QFV_duSetObjectName (device, VK_OBJECT_TYPE_DESCRIPTOR_SET,
attach_set->a[i],
va (ctx->va_ctx, "lighting:attach_set:%zd", i));
QFV_duSetObjectName (device, VK_OBJECT_TYPE_DESCRIPTOR_SET,
lights_set->a[i],
va (ctx->va_ctx, "lighting:lights_set:%zd", i));
QFV_duSetObjectName (device, VK_OBJECT_TYPE_DESCRIPTOR_SET,
shadow_set->a[i],
va (ctx->va_ctx, "lighting:shadow_set:%zd", i));
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
QFV_AllocateCommandBuffers (device, ctx->cmdpool, 1, cmdSet);
lframe->cmd = cmdSet->a[0];
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
lframe->light_buffer = lbuffers->a[i];
QFV_BindBufferMemory (device, lbuffers->a[i], lctx->light_memory,
[vulkan] Add function to compute next offset When allocating memory for multiple objects that have alignment requirements, it gets tedious keeping track of the offset and the alignment. This is a simple function for walking the offset respecting size and alignment requirements, and doubles as a size calculator.
2021-11-30 12:00:33 +00:00
light_offset);
[vulkan] Fix lighting size calculation It turns out the required memory size is not guaranteed to be aligned.
2021-12-15 01:45:25 +00:00
light_offset += light_size;
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
QFV_duSetObjectName (device, VK_OBJECT_TYPE_COMMAND_BUFFER,
lframe->cmd, "cmd:lighting");
for (int j = 0; j < LIGHTING_BUFFER_INFOS; j++) {
lframe->bufferInfo[j] = base_buffer_info;
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lframe->bufferWrite[j] = base_buffer_write;
lframe->bufferWrite[j].dstSet = lights_set->a[i];
lframe->bufferWrite[j].dstBinding = j;
lframe->bufferWrite[j].pBufferInfo = &lframe->bufferInfo[j];
}
for (int j = 0; j < LIGHTING_ATTACH_INFOS; j++) {
lframe->attachInfo[j] = base_image_info;
lframe->attachInfo[j].sampler = 0;
lframe->attachWrite[j] = base_attachment_write;
lframe->attachWrite[j].dstSet = attach_set->a[i];
lframe->attachWrite[j].dstBinding = j;
lframe->attachWrite[j].pImageInfo = &lframe->attachInfo[j];
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
}
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
for (int j = 0; j < LIGHTING_SHADOW_INFOS; j++) {
lframe->shadowInfo[j] = base_image_info;
lframe->shadowInfo[j].sampler = lctx->sampler;
lframe->shadowInfo[j].imageView = ctx->default_black->view;
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
}
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lframe->shadowWrite = base_image_write;
lframe->shadowWrite.dstSet = shadow_set->a[i];
lframe->shadowWrite.dstBinding = 0;
[vulkan] Make lighting samplers configurable My VersaPro doesn't support more than 32 per-stage samplers (lavapipe). This is a small part of getting Vulkan to run on lavapipe and even in itself is rather incomplete.
2021-12-06 05:21:10 +00:00
lframe->shadowWrite.descriptorCount
= min (MaxLights,
device->physDev->properties.limits.maxPerStageDescriptorSamplers);
[vulkan] Start work on shadows This gets the shaders needed for creating shadow maps, and the changes to the lighting pipeline for binding the shadow maps, but no generation or reading is done yet. It feels like parts of various systems are getting a little big for their britches and I need to do an audit of various things.
2021-04-24 01:40:39 +00:00
lframe->shadowWrite.pImageInfo = lframe->shadowInfo;
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
}
[vulkan] Plug some memory leaks I still can't find the run-time leak. I suspect something that accumulates but gets freed on exit.
2022-05-12 15:55:37 +00:00
free (shadow_set);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
free (attach_set);
free (lights_set);
[vulkan] Add some more debug stack contexts
2021-12-02 13:48:50 +00:00
qfvPopDebug (ctx);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
}
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
static void
clear_shadows (vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
lightingctx_t *lctx = ctx->lighting_context;
if (lctx->shadow_memory) {
dfunc->vkFreeMemory (device->dev, lctx->shadow_memory, 0);
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
lctx->shadow_memory = 0;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
}
for (size_t i = 0; i < lctx->lightviews.size; i++) {
dfunc->vkDestroyImageView (device->dev, lctx->lightviews.a[i], 0);
}
for (size_t i = 0; i < lctx->lightimages.size; i++) {
dfunc->vkDestroyImage (device->dev, lctx->lightimages.a[i], 0);
}
lctx->lightimages.size = 0;
lctx->lightviews.size = 0;
}
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
void
Vulkan_Lighting_Shutdown (vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
lightingctx_t *lctx = ctx->lighting_context;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
clear_shadows (ctx);
[vulkan] Implement deferred lighting for dlights Static lights are yet to come (so the screen is black most of the time), but dynamic lights work very nicely (and look very good) despite the falloff being incorrect.
2021-02-25 06:51:54 +00:00
for (size_t i = 0; i < lctx->frames.size; i++) {
lightingframe_t *lframe = &lctx->frames.a[i];
dfunc->vkDestroyBuffer (device->dev, lframe->light_buffer, 0);
}
dfunc->vkFreeMemory (device->dev, lctx->light_memory, 0);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
dfunc->vkDestroyPipeline (device->dev, lctx->pipeline, 0);
[vulkan] Move projection matrix code to its own file And move more stuff over to simd.
2021-04-25 06:47:50 +00:00
DARRAY_CLEAR (&lctx->lightmats);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
DARRAY_CLEAR (&lctx->lightimages);
DARRAY_CLEAR (&lctx->lightlayers);
DARRAY_CLEAR (&lctx->lightviews);
[vulkan] Implement lighting and compose passes Lighting doesn't actually do lights yet, but it's producing pixels. Translucent seems to be working (2d draw uses it), and compose seems to be working.
2021-02-24 10:58:31 +00:00
free (lctx->frames.a);
free (lctx);
}
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
static vec4f_t ref_direction = { 0, 0, 1, 0 };
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
static void
create_light_matrices (lightingctx_t *lctx)
{
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
lightingdata_t *ldata = lctx->ldata;
DARRAY_RESIZE (&lctx->lightmats, ldata->lights.size);
for (size_t i = 0; i < ldata->lights.size; i++) {
light_t *light = &ldata->lights.a[i];
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
mat4f_t view;
mat4f_t proj;
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
int mode = ST_NONE;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
if (!light->position[3]) {
mode = ST_CASCADE;
} else {
if (light->direction[3] > -0.5) {
mode = ST_CUBE;
} else {
mode = ST_PLANE;
}
}
switch (mode) {
[vulkan] Fix an uninitialized variable warning semi-bogus, but I prefer false positives to false negatives.
2021-06-01 10:09:03 +00:00
default:
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
case ST_NONE:
case ST_CUBE:
mat4fidentity (view);
break;
case ST_CASCADE:
case ST_PLANE:
Fix a bunch of issues for clang One *actual* error (wrong enum type), and some memory alignment issues. The rest just clang being lame.
2022-07-26 12:36:56 +00:00
(void)0;//FIXME for clang
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
//FIXME will fail for -ref_direction
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
vec4f_t dir = light->direction;
dir[3] = 0;
mat4fquat (view, qrotf (dir, ref_direction));
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
break;
}
VectorNegate (light->position, view[3]);
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
switch (mode) {
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
case ST_NONE:
mat4fidentity (proj);
break;
case ST_CUBE:
QFV_PerspectiveTan (proj, 1, 1);
break;
case ST_CASCADE:
// dependent on view fustrum and cascade level
mat4fidentity (proj);
break;
case ST_PLANE:
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
QFV_PerspectiveCos (proj, -light->direction[3]);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
break;
}
mmulf (lctx->lightmats.a[i], proj, view);
}
}
static int
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
light_compare (const void *_li2, const void *_li1, void *_ldata)
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
{
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
const int *li1 = _li1;
const int *li2 = _li2;
lightingdata_t *ldata = _ldata;
const light_t *l1 = &ldata->lights.a[*li1];
const light_t *l2 = &ldata->lights.a[*li2];
[vulkan] Use absolute light intensity/radius for size Many modders use negative lights for interesting effects, but vulkan doesn't like the result of a negative int treated as unsigned when it comes to texture sizes.
2022-05-11 04:29:17 +00:00
int s1 = abs ((int) l1->color[3]);
int s2 = abs ((int) l2->color[3]);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
[vulkan] Use absolute light intensity/radius for size Many modders use negative lights for interesting effects, but vulkan doesn't like the result of a negative int treated as unsigned when it comes to texture sizes.
2022-05-11 04:29:17 +00:00
if (s1 == s2) {
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
return (l1->position[3] == l2->position[3])
&& (l1->direction[3] > -0.5) == (l2->direction[3] > -0.5);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
}
[vulkan] Use absolute light intensity/radius for size Many modders use negative lights for interesting effects, but vulkan doesn't like the result of a negative int treated as unsigned when it comes to texture sizes.
2022-05-11 04:29:17 +00:00
return s1 - s2;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
}
static VkImage
create_map (int size, int layers, int cube, vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
if (layers < 6) {
cube = 0;
}
VkImageCreateInfo createInfo = {
VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO, 0,
cube ? VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT : 0, VK_IMAGE_TYPE_2D,
VK_FORMAT_X8_D24_UNORM_PACK32,
{ size, size, 1 }, 1, layers,
VK_SAMPLE_COUNT_1_BIT, VK_IMAGE_TILING_OPTIMAL,
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT
| VK_IMAGE_USAGE_SAMPLED_BIT, VK_SHARING_MODE_EXCLUSIVE,
0, 0,
VK_IMAGE_LAYOUT_UNDEFINED,
};
VkImage image;
dfunc->vkCreateImage (device->dev, &createInfo, 0, &image);
QFV_duSetObjectName (device, VK_OBJECT_TYPE_IMAGE, image,
va (ctx->va_ctx, "image:shadowmap:%d:%d",
size, layers));
return image;
}
static VkImageView
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
create_view (VkImage image, int baseLayer, int mode, int id, vulkan_ctx_t *ctx)
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
int layers = 0;
VkImageViewType type = 0;
const char *viewtype = 0;
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
switch (mode) {
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
case ST_NONE:
return 0;
case ST_PLANE:
layers = 1;
type = VK_IMAGE_VIEW_TYPE_2D;
viewtype = "plane";
break;
case ST_CASCADE:
layers = 4;
type = VK_IMAGE_VIEW_TYPE_2D_ARRAY;
viewtype = "cascade";
break;
case ST_CUBE:
layers = 6;
type = VK_IMAGE_VIEW_TYPE_CUBE;
viewtype = "cube";
break;
}
VkImageViewCreateInfo createInfo = {
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO, 0,
0,
image, type, VK_FORMAT_X8_D24_UNORM_PACK32,
{
VK_COMPONENT_SWIZZLE_IDENTITY,
VK_COMPONENT_SWIZZLE_IDENTITY,
VK_COMPONENT_SWIZZLE_IDENTITY,
VK_COMPONENT_SWIZZLE_IDENTITY,
},
{ VK_IMAGE_ASPECT_DEPTH_BIT, 0, 1, baseLayer, layers }
};
VkImageView view;
dfunc->vkCreateImageView (device->dev, &createInfo, 0, &view);
QFV_duSetObjectName (device, VK_OBJECT_TYPE_IMAGE_VIEW, view,
va (ctx->va_ctx, "iview:shadowmap:%s:%d",
viewtype, id));
[qwaq] Create a commandline-only version of qwaq qwaq-curses has its place, but its use for running vkgen was really a placeholder because I didn't feel like sorting out the different initialization requirements at the time. qwaq-cmd has the (currently unnecessary) threading power of qwaq-curses, but doesn't include any UI stuff and thus doesn't need curses. The work also paves the way for qwaq-x11 to become a proper engine (though sorting out its init will be taken care of later). Fixes #15.
2021-07-06 02:55:29 +00:00
(void) viewtype;//silence unused warning when vulkan debug disabled
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
return view;
}
static void
build_shadow_maps (lightingctx_t *lctx, vulkan_ctx_t *ctx)
{
qfv_device_t *device = ctx->device;
qfv_devfuncs_t *dfunc = device->funcs;
qfv_physdev_t *physDev = device->physDev;
int maxLayers = physDev->properties.limits.maxImageArrayLayers;
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
lightingdata_t *ldata = lctx->ldata;
light_t *lights = ldata->lights.a;
int numLights = ldata->lights.size;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
int size = -1;
int numLayers = 0;
int totalLayers = 0;
int *imageMap = alloca (numLights * sizeof (int));
size_t memsize = 0;
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
int *lightMap = alloca (numLights * sizeof (int));
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
for (int i = 0; i < numLights; i++) {
lightMap[i] = i;
}
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
DARRAY_RESIZE (&lctx->lightlayers, numLights);
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
heapsort_r (lightMap, numLights, sizeof (int), light_compare, ldata);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
for (int i = 0; i < numLights; i++) {
int layers = 1;
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
int shadow = ST_NONE;
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
int li = lightMap[i];
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
if (!lights[li].position[3]) {
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
shadow = ST_CASCADE;
} else {
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
if (lights[li].direction[3] > -0.5) {
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
shadow = ST_CUBE;
} else {
shadow = ST_PLANE;
}
}
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
if (shadow == ST_CASCADE || shadow == ST_NONE) {
// cascade shadows will be handled separately, and "none" has no
// shadow map at all
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
imageMap[li] = -1;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
continue;
}
if (shadow == ST_CUBE) {
layers = 6;
[vulkan] Implement all the extended light models Standard quake has just linear, but the modding community added inverse, inverse-square (raw and offset (1/(r^2+1)), infinite (sun), and ambient (minlight). Other than the lack of shadows, marcher now looks really good.
2021-04-25 01:01:57 +00:00
}
[vulkan] Use absolute light intensity/radius for size Many modders use negative lights for interesting effects, but vulkan doesn't like the result of a negative int treated as unsigned when it comes to texture sizes.
2022-05-11 04:29:17 +00:00
if (size != abs ((int) lights[li].color[3])
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
|| numLayers + layers > maxLayers) {
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
if (numLayers) {
VkImage shadow_map = create_map (size, numLayers, 1, ctx);
DARRAY_APPEND (&lctx->lightimages, shadow_map);
numLayers = 0;
}
[vulkan] Use absolute light intensity/radius for size Many modders use negative lights for interesting effects, but vulkan doesn't like the result of a negative int treated as unsigned when it comes to texture sizes.
2022-05-11 04:29:17 +00:00
size = abs ((int) lights[li].color[3]);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
}
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
imageMap[li] = lctx->lightimages.size;
lctx->lightlayers.a[li] = numLayers;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
numLayers += layers;
totalLayers += layers;
}
if (numLayers) {
VkImage shadow_map = create_map (size, numLayers, 1, ctx);
DARRAY_APPEND (&lctx->lightimages, shadow_map);
}
numLayers = 0;
size = 1024;
for (int i = 0; i < numLights; i++) {
int layers = 4;
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
int shadow = ST_NONE;
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
int li = lightMap[i];
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
if (!lights[li].position[3]) {
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
shadow = ST_CASCADE;
} else {
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
if (lights[li].direction[3] > -0.5) {
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
shadow = ST_CUBE;
} else {
shadow = ST_PLANE;
}
}
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
if (shadow != ST_CASCADE) {
continue;
}
if (numLayers + layers > maxLayers) {
VkImage shadow_map = create_map (size, numLayers, 0, ctx);
DARRAY_APPEND (&lctx->lightimages, shadow_map);
numLayers = 0;
}
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
imageMap[li] = lctx->lightimages.size;
lctx->lightlayers.a[li] = numLayers;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
numLayers += layers;
totalLayers += layers;
}
if (numLayers) {
VkImage shadow_map = create_map (size, numLayers, 0, ctx);
DARRAY_APPEND (&lctx->lightimages, shadow_map);
}
for (size_t i = 0; i < lctx->lightimages.size; i++) {
memsize += QFV_GetImageSize (device, lctx->lightimages.a[i]);
}
lctx->shadow_memory = QFV_AllocImageMemory (device, lctx->lightimages.a[0],
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT,
memsize, 0);
QFV_duSetObjectName (device, VK_OBJECT_TYPE_DEVICE_MEMORY,
lctx->shadow_memory, "memory:shadowmap");
size_t offset = 0;
for (size_t i = 0; i < lctx->lightimages.size; i++) {
dfunc->vkBindImageMemory (device->dev, lctx->lightimages.a[i],
lctx->shadow_memory, offset);
offset += QFV_GetImageSize (device, lctx->lightimages.a[i]);
}
DARRAY_RESIZE (&lctx->lightviews, numLights);
for (int i = 0; i < numLights; i++) {
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
int li = lightMap[i];
if (imageMap[li] == -1) {
lctx->lightviews.a[li] = 0;
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
continue;
}
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
int mode = ST_NONE;
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
if (!ldata->lights.a[li].position[3]) {
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
mode = ST_CASCADE;
} else {
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
if (ldata->lights.a[li].direction[3] > -0.5) {
[vulkan] Rework lighting model to be more algebraic This leaves only the one conditional in the shader code, that being the distance check. It doesn't seem to make any noticeable difference to performance, but other than explosion sprites being blue, lighting quality seems to have improved. However, I really need to get shadows working: marcher is just silly-bright without them, and light levels changing as I move around is a bit disconcerting (but reasonable as those lights' leaf nodes go in and out of visibility).
2022-05-04 23:40:02 +00:00
mode = ST_CUBE;
} else {
mode = ST_PLANE;
}
}
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
lctx->lightviews.a[li] = create_view (lctx->lightimages.a[imageMap[li]],
lctx->lightlayers.a[li],
mode, li, ctx);
[vulkan] Create shadow maps and basic data I will definitely need to look into sparse images later (2.3GB for marcher) but the shadow map images, views and matrices are created.
2021-04-29 11:54:38 +00:00
}
Sys_MaskPrintf (SYS_vulkan, "shadow maps: %d layers in %zd images: %zd\n",
totalLayers, lctx->lightimages.size, memsize);
}
[vulkan] Load the map's lights into an array It's not used yet as work needs to be done to better support generic entities, but this is the next step to real-time lighting (though, to be honest, I expect it will be too slow to be usable).
2021-03-03 09:14:16 +00:00
void
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
Vulkan_LoadLights (scene_t *scene, vulkan_ctx_t *ctx)
[vulkan] Load the map's lights into an array It's not used yet as work needs to be done to better support generic entities, but this is the next step to real-time lighting (though, to be honest, I expect it will be too slow to be usable).
2021-03-03 09:14:16 +00:00
{
lightingctx_t *lctx = ctx->lighting_context;
[vulkan] Move non-specific lighting code out of Vulkan The parsing of light data from maps is now in the client library, and basic light management is in scene. Putting the light loading code into the Vulkan renderer was a mistake I've wanted to correct for a while. The client code still needs a bit of cleanup, but the basics are working nicely.
2022-05-05 05:58:47 +00:00
lctx->scene = scene;
[vulkan] Clear lights when the scene is cleared Fixes a segfault when shutting down my test program.
2022-05-07 03:12:02 +00:00
lctx->ldata = scene ? scene->lights : 0;
[vulkan] Resurrect the shadow map resource creation However, this time it doesn't modify the light array when it sorts the lights by size since the lights are now located before the renderer gets to see them, and having the fix up the light leafs array would be too painful (and probably the completely wrong thing to do anyway: the light array should be treated as constant by the renderer). 1.6GB of memory for gmsp3v2's lights (a little better than marcher: more smaller lights?). For reference: gmsp3v2: shadow maps: 8330 layers in 29 images: 1647706112 marcher: shadow maps: 2440 layers in 11 images: 2358575104
2022-05-10 02:15:52 +00:00
clear_shadows (ctx);
if (lctx->ldata && lctx->ldata->lights.size) {
build_shadow_maps (lctx, ctx);
create_light_matrices (lctx);
}
[vulkan] Load the map's lights into an array It's not used yet as work needs to be done to better support generic entities, but this is the next step to real-time lighting (though, to be honest, I expect it will be too slow to be usable).
2021-03-03 09:14:16 +00:00
}
Reference in a new issue Copy permalink