It's not perfect (double fog on translucent surfaces, the
scatter/absorption isn't right, and no local lighting on the fog
itself), but it at least seems to look ok.
I think has been one of the biggest roadblocks to breaking free of
quake, so having dual render paths and thus the different new scene load
sequence has proven to be unexpected helpful. There's a lot more to be
done to make the render graph actually usable by anyone but me, but just
making scene load configurable frees up a lot. I think there needs to be
renderer startup/shutdown configuration too, but this seems to be enough
for now.
Other than decoupled lightmap support, I think that has the vulkan
forward renderer feature complete (though a little buggy with its
lightmap updates and fisheye gets validation errors).
It's just lightmap vs lighting (scene load and bsp rendering) and
compose (attachments or no) that need sorting out, and, of course, a way
to select between the two.
Missing any possibility for fullbrights or colors (only because no
attempt is made to load such), and more deferred breakage, but it acted
as a nice proof of concept for cleaner skin loading (taking advantage of
resources and QFV_PacketCopyImage).
QFV_PacketCopyImage is quite handy, but when used before
QFV_GenerateMipMaps, the final image barrier is not wanted as
QFV_GenerateMipMaps expects the image to be transfer_dst, so skip the
barrier if dstBarrier is null.
In a quake context, I suspect iqm models should use the same skin
concepts as alias models. I'll probably be proven wrong, but it should
make things nicer for now, especially with forward lighting. However,
Mr Fixit is too bright because the skin isn't set up correctly.
Deferred is getting more and more smashed, but I'll fix that up when
I've got forward "done".
The output framebuffers array is dynamic, so trying to index it before
it has been created results in a segfault (which is rather inconvenient
during shutdown).
The lightmaps aren't updated at all yet, so everything is static.
Figuring out how lightmap data gets to the gpu was a chore thanks to the
spaghetti in the bsp data, and then I'd forgotten that I was
pre-expanding the light data to rgb so wound up with weird lightmaps,
but without water or particles, demo1 is getting 5000fps at 800x450, and
it seems to be CPU limited.
Finally, quakeworld gets its *ahem* fancy skins. I'm not happy with how
skin loading is handled, but the whole model and skin support needs a
redesign.
Closes#74.
This takes care of the double free and also cleans up a lot of the skin
api. However, the gl renderer lost top/bottom colors (for now). Vulkan
skins still don't work yet.
That is, those with more than 65520 vertices. Not properly supported for
sw or gl, and glsl isn't rendering properly for some reason (renderdoc
does see the meshes, though, so maybe depth or winding issues).
I suspect I may have done the incorrect offset for color to get a
gradient for some testing, but forgot to put it back. Or, of course, I
just completely and utterly brain-farted when writing the attribute.
Some of them were actual leaks, but tracking memory should be a lot
easier now. However, there's a lot of room for optimization of
allocations (eg, recylcling of hierarchies. There is now 1 active
allocation (according to tracy) when nq exits: Qgetline's string buffer
(I think an api change is in order).
The main goal of this change was to make it easier to tell when a
hierarchy has been deleted, but as a side benefit, it got rid of the use
of PR_RESMAP. Also, it's easy to track the number of hierarchies.
Unfortunately, it showed how brittle the component side of the ECS is
(scene and canvas registries assumed their components were the first (no
long the case), thus the sweeping changes).
Centerprint doesn't work (but it hasn't for a while).
It was a little off-putting getting an incorrectly clipped console when
using non-unitary scale (especially since I was trying to show abbator
something).
Seems to work well. The other renderers have stubs because I don't feel
like implementing clipping for them. The gl and glsl wouldn't be too
difficult (need to handle the draw queues), but sw needs a fair bit of
work and I'm not sure it's worth the effort.
This makes a possible improvement to e1m3, only barely affects ad_tears,
but makes about 30% difference to gmsp3v2 (21fps to 27, and from 3300
leafs to 2700).
The cascade_shadow and cube_shadow names are no longer relevant thanks
to the staging images, and the output field for render passes is
optional in general and irrelevant for shadow maps.
The rendering of the shadow maps now takes the culling information into
account resulting in a drastic reduction of work. There's still more
work to be done, but demo1 peaks at over 1000fps at 640x480, gmsp3v2 now
gets 14fps (1920x1080) near the front gate (used to be 3, then 6),
ad_tears is up to 3fps, but marcher is still unhappy, but it has
infinite radius lights, so needs more culling work (clipped light
volumes will help, I think). Also, culling lights for which nothing has
moved within their volumes will help somewhat (though not as much for
most id maps, I suspect).
Using the translucency pass made it easy to have depth-tested
translucent "solid" light volumes instead of always visible lines (which
are still an option as that's useful too). Most importantly, being able
to see the surfaces helped no end in figuring out that my hulls were
created with counter-clockwise windings instead of quake's usual
clockwise windings and thus my hulls were being rendered inside-out in
the occlusion pass.
The results of the occlusion queries give the lights that don't have a
visible hull, but unfortunately that includes any lights which the
camera is inside, but simple distance checks sort that out (with a
fudge-factor for the icosahedron vertices (1.583 (3(2+p)/(2+3p), p is
golden ratio)).
