XWA Upgrade

There are also some bad news though. There are limitations on the depth buffer that I didn't really notice until SSAO was enabled. I believe this is an inherent limitation with the game because I've also seen this using Jeremy's ddraw. The problem is that whenever you're too close to a big surface, the depth will flip in certain areas and SSAO brings up this difference. This is how it looks:
I don't think there's much we can do about this right now. On the lighter side I'm also adding plumbing to further extend SSAO. I'm either thinking about SSDO or using bent normals. So, I'm hoping that in a couple of months we might have single bounce diffuse reflections as well or something close to that.

SSDO? you mean SSDIR? (" have single bounce diffuse reflections as well ")

I really cannot wait for DIR, and of course, if you implement shading within ddraw (including shadow casting) we would finally have a XWA for 2019 hahah.

As for ZB, I always wondered about things "sinking" on the ISD's etc
Do we know what the near and far z is for xwa? is it possible to move this to ddraw too?

Trev

I think "Diffuse Inter-reflections" is the generic term, and SSDO is an extension to SSAO that adds those reflections:

https://people.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf

From looking at the formulas, I suspect the indirect lighting component in MXAO is at least partially inspired by SSDO or something similar. The thing is, once you have the infrastructure in place to compute SSAO, it's relatively easy to extend it to SSDO. There are some challenges -- as always. SSDO requires the normals and light positions. We don't have neither of these things. I do have the reconstructed normals but they look faceted and I can have a guess at the light sources because I have the diffuse illumination component in the pixel shader; but unfortunately this game computes the diffuse illumination in a weird way. I tried all the settings for light sources and they all have some illumination on areas that should be dark. This looks nice, and I understand why they did it; but unfortunately this means I can't really guess where the light sources are in-game.

Of course, I could ditch the in-game illumination altogether; but then we would have to use faceted normals... which looks ugly.

When I tried enabling IL in MXAO... I only got weird blotches... nothing that looked like what I was expecting. Anyway, some approximation of DIR should still be possible and I'll be working on that next (but I'll release the next version of SSAO first!)

This game uses a logarithmic Z Buffer. The last time I checked the far plane was at 30Km away or something like that and the near plane was close to 0m. The other source of this problem may be that the game uses fixed-point arithmetic and maybe some precision is lost no matter what. However, I can probably come back to this problem later and see if it can be fixed by either increasing the precision of the z-buffer or by using a different z-buffer formula. However, it will still have to be logarithmic because of the scale of the objects.

you know what would really be cool, just as a once off debug feature, to export the current frame as an obj so we can see how xwa renders in 3d.
Think along the lines of the VRML export plugin for many N64 emulators, it exports the current view (all triangles drawn and textures used) to a vrml file
(http://www.emutalk.net/threads/21092-Th ... post207626)
https://youtu.be/pKvB2bozJZ0?t=193

This would allow me to see things like "scale" and ZB compare with onscreen result

Trev

Yes, this can be done. When I was doing the research for how to implement VR, I was already exporting the current frame as a point cloud in OBJ format. With some effort I guess I could do a full OBJ export. That at least would help us see if the z-buffer rendering can be fixed. Yes, that's a good idea. Maybe later.

Forgot to mention: shadow maps can be implemented; but they probably won't work very well since the geometry is already clipped when it reaches ddraw. So, we would see gaps in the shadows where the geometry stops. Still... maybe this can be solved in the future...

Alright, here's the next release:

https://www.dropbox.com/s/xe0jnv99cgyx7 ... 8.zip?dl=0

EDIT: There was a typo in OpenVR_API.dll, I fixed the typo in the ZIP files and re-uploaded it.

In this version I've fixed the halos and the blur is now depth-aware. I've also fixed all the artifacts reported here (and others).

Moving on to the next effect... I'll try to enable Diffuse Inter-Reflections in the next release...

WOW looking great!!!!
I tweeked my settings a bit and am using 32 samples, also with this version perspective correction just makes the image look wrong so I disabled it. (which you recommend anyway) and also the unfiltered image is almost good enough to not even need blur - however now that blur is depth aware it works so I have it enabled

If you already have an obj of verticies I would like to see it.

But yeah, now that you are re-writing the drawing api you do definatly need to disable frustum culling and backface culling etc. preferably maybe not even using the ingame ZB but make your own with higher precision.

Trev

Thanks for your comments Trevor -- I'm glad you're enjoying the effect. Yes, the unfiltered image is pretty good even without blur -- we've got to thank Pascal Glicher for that since he's the original author of that.

Just to be clear, I'm not rewriting the whole rendering engine. We would still need to reverse engineer the game's engine to figure out how to disable frustrum culling, for instance. However, replacing the Z-Buffer is something that is doable at the level of ddraw.

Did some testing with the WIP Victory SD and, combined with the bloom it looks absolutely fantastic!

General_Trageton wrote: ↑

Wed Oct 16, 2019 10:36 pm

Did some testing with the WIP Victory SD and, combined with the bloom it looks absolutely fantastic!

Thank you sir! I'm glad you're enjoying these effects (BTW, it's going to get even better...) Please, feel free to post some pictures!

On my side, I’ll just drop these screenshots from the Suprosa mission here:
https://imgur.com/a/aUylK43

I am following developments very closely. The quality of the game has improved in all scenarios. Even the atmospheric missions are great thanks to these improvements in glare. I'm updating all the planetary opt, and above all the skies, to reach a standard that was previously unimaginable. I can anticipate that the new skies will be made with a unique texture, without any interruption of continuity. Soon I will open a topic specifically to present these upgrades.

Oh those look amazing.

You know this brings up an idea, we could start a thread dedicated screenshot showcasing, maybe even hold a contest of sorts.

DarHan wrote: ↑

Thu Oct 17, 2019 9:49 am

On my side, I’ll just drop these screenshots from the Suprosa mission here:
https://imgur.com/a/aUylK43

These look absolutely amazing.

Am I right in thinking that this isn't solely due to blue_max's updated ddraw, though?

Does this use some customised ReShade settings on top?

Only reason I ask is that I never managed to get ReShade working on my setup, let alone figure out optimum settings.

And which effects are you using? Those ion effects and explosions don't look like native or the ones currently installed with the XWAU craft pack.


Either way, I love what you guys are managing to achieve here.

Next chance I get, I'm going to try and give this a go. Is it just one ddraw file for the SSAO and bloom effects, or do I need to combine them somehow?

Only one ddraw. The SSAO and bloom come with their respective dlls and cfgs.

@Will T, yes, that is ReShade on top of blue_max’s bloom and SSAO. I shared my ReShade config here (just make sure to adjust the file paths to your setup). Rather than allow ReShade to download the shaders during setup, I’d suggest it’s more practical to download all the shaders and textures from the official repo and store them in a folder made for that purpose, as I did.

Experimenting SSAO with atmospheric missions:

without SSAO


With SSAO


The overall effect is extraordinary, but as you can see there is a problem with the trees. Trees are simple 3d faces with an applied texture that has an Alpha channel. It appears that the Alpha channel blocks the SSAO effect. Is there a way to solve this problem?

Nice DTM. See what you mean. Off topic, is that an actual implementation of a ground level base hangar? Can your player craft start on the ground?

wow, your surface now has depth to it (rather than looking flat/not connected)

Trev

Yes, shadow effects are fantastic...but the trees really don'work with it
If there is not a solution, I have to think about another way to have trees...unfortunatly there are not many other solutions than Alpha Channel to create a great number of objects without using a great number of vertex. Any idea...?

@Bman. The hangar is inside tje bulding, but obviously it's possible to set up the hangar outside...

DTM wrote: ↑

Sat Oct 19, 2019 4:37 pm

Yes, shadow effects are fantastic...but the trees really don'work with it

This has a solution and it's not too hard. Can you point me in the direction of the OPT so I can test this? I can download it from your webpage, right? Is that Yavin IV?

The problem is simply that the shaders have to be told when a texture has transparency. If not, they assume it's a solid texture. I can either look at the "color-transparency" tag and see if that works, or I'll have to provide a way to add texture names externally.

Thanks! Yes, download Yavin from my site. I'm updating the sky, but trees and surface will not be changed.

DTM wrote: ↑

Sat Oct 19, 2019 8:56 pm

Thanks! Yes, download Yavin from my site. I'm updating the sky, but trees and surface will not be changed.

Check your PMs, DTM. I've got an experimental fix for the trees in Yavin IV:
The problem was that the trees were being rendered as solid textures without transparency -- from the perspective of the SSAO buffer. There are a couple of ways this can be fixed; but either way, I think people will have to specify which textures need to be "SSAO-transparent" in an external text file. Maybe one such file per OPT to keep things manageable.

Could the text file per opt just be coded to scan the existing craft ini files for a new definition section related to the ssao hook where relevant?

hmm... so now the trees are not casting shadows, I guess they wouldn't since they are 0 thickness from the perspective of the ground looking up.

Trev