DRD Team

ibm5155 wrote:Also, why theres no sound under your build? I only hear midi sound but nothing else :S

My build isn't an official build and only has enough of the sound compiled in to make the OpenAL part work on my computer. Same for the issues you screenshot - this was just a test to allow people to see roughly how a SSAO pass would look like in gzdoom. The SSAO darkening on top of the sprite actually looks exactly as expected at this stage.

imb5155 wrote:and, the dynamic lights weren't showing under my map ( I belive it's because my mod has a modified main.vp/fp [used for a custom fog shader] inside of it but idk)...

You really shouldn't modify main.vp/fp (or any of the other bundled shaders) and expect any of it to continue working except for that specific build of gzdoom you did it in. They aren't meant to be modified by mods and could change at any time.

I wish the main.fp parser could just overwrite the changes that you did and not fully replace the original file :S (since I only changed the R_DoomLightingEquation logic)...
but still, I mixed that code with the new main and it looked like cool (except for the flash light that looks weird in high detail and for a weird glitch that I saw)...

Spoiler:

---

Talking about the weird glitch, It looks like I've found another weird bug (also happens with the latest oficial gzdoom commit)


warp -9383 -7226 0

EDIT: and using the intel gpu, ,it goes even more crazy O_o

LINK

EDIT2: Yeah, it's going to be another thread but I'm kinda sleepy now for doing that

If it's not related to SSAO can you make a separate thread? :)

ibm5155 wrote:I wish the main.fp parser could just overwrite the changes that you did and not fully replace the original file :S (since I only changed the R_DoomLightingEquation logic)...
but still, I mixed that code with the new main and it looked like cool (except for the flash light that looks weird in high detail and for a weird glitch that I saw)...

And how do you expect this to work? The shader source is just a text file, the engine does no parsing of it, it gets fed directly into the compiler after prepending the global definitions and the specific texture getter functions. This file is also to be considered an internal part of the engine, not subject to user-side change because it can be altered without notice between releases.

Here's an updated build of my SSAO branch: https://github.com/dpjudas/zdoom/releases/tag/ssao2

It has the following changes:

• Fixes the shader so that there are no large artifacts as you pan the camera around
• Fixes SSAO when scene has a status bar
• Moves the SSAO pass to be in between the opaque and translucent rendering
• Depth aware blur
• 32 bit and 64 builds
• All the latest goodies from the master branch

Note: multisampling has to be off in this build or you will get some artifacts from the SSAO pass.

dpJudas wrote:Here's an updated build of my SSAO branch: https://github.com/dpjudas/zdoom/releases/tag/ssao2

It has the following changes:

• Fixes the shader so that there are no large artifacts as you pan the camera around
• Fixes SSAO when scene has a status bar
• Moves the SSAO pass to be in between the opaque and translucent rendering
• Depth aware blur
• 32 bit and 64 builds
• All the latest goodies from the master branch

Note: multisampling has to be off in this build or you will get some artifacts from the SSAO pass.

So, I confirmed that multisampling is off, but I'm getting horizontal and vertical stripes in the shadows:

The lines are far more evident at higher resolutions - I just went with a lower resolution for this screenshot to save bandwidth.

Ironically, if I turn multisampling on, and iterate through the settings, the problems becomes far less visible, but is still there.

I can confirm that. By the way, sky sectors and skyboxes also suffer the problem that the occlusion happens but isn't wanted.

There's a reason why this is currently just an experimental build.

AFADoomer wrote:Ironically, if I turn multisampling on, and iterate through the settings, the problems becomes far less visible, but is still there.

Funny how it differs between computers. For me, they didn't show up when the setting was off. It is related to a math precision issue that sometimes makes the reconstructed normal of a fragment point in a wrong direction.

About the sky, that's expected behavior in this build. I still need some way to detect that something was depth/stencil filled so the linear depth shader can set that depth value to some far far away value.

I think I found a solution to the portal problem. I changed it so that when the stencil shader seals off a portal it clears the alpha channel to zero (but keeps RGB intact as before). That changes the scene color buffer to look like this (note that RGB data for the sky is still there):


That in turn allows the linear depth shader to do this: The end result is that anything behind a sealed portal will appear to be far far away not cause any incorrect ambient occlusion. We can even run the SSAO pass multiple times this way (for each entered portal), or only do it for the main camera.

But will that do proper SSAO across the portal boundary? With skies it's not an issue, but if you actually link two corridors together it may be.

dpJudas wrote:Here's an updated build of my SSAO branch: https://github.com/dpjudas/zdoom/releases/tag/ssao2

Many thanks dpJudas!

Graf Zahl wrote:But will that do proper SSAO across the portal boundary? With skies it's not an issue, but if you actually link two corridors together it may be.

No, the SSAO would fade out at the boundary because it would think there's nothing nearby. For someone looking for it, that can definitely be spotted. But will it be obvious enough for the player to notice in most cases?

I should probably test it. Anyone know a good portal map for this?

Pretty much anything made for GZDoom by Tormentor667.

Seriously, that man and portals go hand in hand.

Almost everything on this page will use portals - but some good ones include The City of the Damned - Apocalypse, The Refinery, The Ultimate Torment and Torture - as far as I am aware, all of these mapsets use portals galore. The majority of maps in Stronghold will also use portals.

Blade of Agony also uses a crapload of portals, even on the first map... https://github.com/Realm667/WolfenDoom

EDIT: Here's a very simple and minimal portal demo that uses portals in the way Graf Zahl describes: http://forum.zdoom.org/viewtopic.php?f= ... ry#p909587 (download the file by Arookas)