Implement Soft Particles (and capturing depth buffer), based on old The Dark Mod code - #578
Conversation
|
Potential problem with this implementation: DeclParticle.h is part of the SDK, so adding RenderSystem.h is also in the SDK, but glConfig_t really shouldn't be used by game DLLs (they can't really access it anyway, the global |
|
what would be the best map/location to test the soft particles? |
|
I tested them in Mars City Underground, here (near "Listen Scotty, I've done this a million times"): and here (where you go outside): (note that those "stripes" from particles "cutting" into the geometry are gone with r_useSoftParticles 1) |
|
this will be available on the 1.5.3 version or upcoming release? so i imagine that features only can be tested for those people that can "compile" the code pointing to these experimental "branchs"? i'm not sure about what i'm saying, but i thinks is some near to the right. |
|
1.5.3 was released three months ago, so it doesn't contain the the feature of this pull request from two weeks ago. A pull request still being open (not merged) means that this code is not part of the official dhewm3 code yet. |
|
ok i understand, i need to wait for that feature merge to the official branch. |
|
there are test binaries for windows at #585 (comment) |
don't really work, though
thanks to https://community.khronos.org/t/cannot-read-from-depth-buffer-in-fs/76169/8 apparently the default doom3 texture filter was something using mipmaps, which doesn't work so well for textures without mipmaps.. no idea why those two lines in idImage::CopyDepthbuffer() were commented out, but they're needed (and also un-commented in TDM, I just missed that when merging -_-)
cleaner than only setting it in CopyDepthbuffer()
needs SDL2 and GL_ARB_debug_output
before it displayed the float values from the depth buffers as byte-wise RGBA values, which looked weird and wasn't super helpful.. now it's displayed as luminance float (i.e. one float representing greyscale), and transformed in the same way the TDM particle shader transforms the depth values to doom units (and then scaled back to 0..1, with 1 representing 3000 units)
so when the shader writes a debug value as a color, I get to see that color
turned out the whole problem with soft particles what that the vertex shader used vertex.attrib[8] instead of vertex.texcoord (and with nvidia drivers those are equivalent) I integrated the shader source into the c++ code so I don't have to ship glprogs/soft_particles.vfp
r_skipDepthCapture is now called r_enableDepthCapture, and instead of being a bool it's now an int with -1 meaning "enable if soft particles are used"
if this is not set, using fminf() actually calls that libm function, if it is set, a CPU instruction that calculates the minimum is generated instead. likely similar for other functions. not sure if this causes trouble anywhere, but I don't think we rely on NaN or INF?
by default it's still compiled into the executable
this avoid breaking the game DLL ABI (framework/DeclParticle.h is part of the SDK), and for now doesn't make a difference, because that keyword was introduced by TDM and thus is only used in their particle defs. When we break the game ABI/API anyway (probably for high FPS support), this commit can just be reverted
82d3565 to
49a3b27
Compare
49a3b27 to
7e772f0
Compare
|
I modified the code to avoid breaking the game API/ABI (by disabling the "softRadius" particle stage keyword in particle definitions, which was introduced by TDM and thus isn't used by any gamedata relevant for dhewm3 anyway), so I can merge this now. I plan to release dhewm3 1.5.4 for Doom3's 20th birthday on August 3rd, and release a release candidate today or tomorrow or so. The big features in that release will be the soft particles and the ImGui-based menu. High-FPS support will not make it into the release, as there's no chance that it'll be done and sufficiently tested in 9 days (currently it still has some physics bugs in SinglePlayer at high framerates, and Multiplayer is still completely broken with > 60fps). |
|
@Sol1vaN: there's a new dhewm3 release candidate (including soft particles), that could use some testing: https://github.com/dhewm/dhewm3/releases/tag/1.5.4_RC1 |
3 participants
Now (view-aligned) particles don't "cut" into geometry anymore, but fade instead
Can be disabled with
r_useSoftParticles 0