XWA Upgrade

I may be getting ahead of myself, but would it be possible to make that technique work with engine glows as well?

If yes, this would mean we could(in theory) texture the engine nozzles in their "natural" metallic color instead of painting the illumination onto them, and then let the engine glow do the lighting... Well I can dream can I ?

blue_max wrote: ↑

Sun Mar 22, 2020 5:36 pm

Bman wrote: ↑

Sun Mar 22, 2020 8:56 am

I did try tweaking some settings as you suggested but the frame rate is still a little choppy and edges are still a little jagged.

Try setting "MSAACount = 8" in ddraw.cfg (this is probably the default when using Jeremy's ddraw)

Did you try "ssao_type = Deferred" in SSAO.cfg? That option shouldn't have any noise.

Hi BlueMax. Where is "MSSACount = 8" ? Don't see it in the ddraw.cfg. I've posted some videos under the Weapons Slot thread for TFTC you see what I"m talking about. As you'll see, the original Corvette2.opt filmed without SSAO.cfg runs very smoothly then the frames drop when using SSAO.cfg and I did select "Deferred" and even reduced my samples down from 8 to 4 and downgraded a few other lines. Thanks.

I would assume this is as true as also requiring pre-baked specular reflections to be wiped off and returned to "base" colours.

So, I assume this requires "Local Light sources" to be set to off (since XWA already has laser glows when set to All)

The new effect of course looks way better than the old, but just wanted to check.

Trev

@GT: Yes, it's possible to attach lights to the engines; but it's impractical. As keiranhalcyon7 pointed out earlier, each additional light incurs a small performance penalty. I limited it to the 8 closest lasers on-screen so that the impact is minimal and temporary. Now, consider that just the Corellian Corvette has 11 (20?) engines on the back... Of course, we could probably limit these lights to the capital ships; but the engine glow would probably make the effect of these lights invisible. The only place where I think it would have an noticeable effect would be in the Calamari capital ships because the back "fins" would catch a lot of this light; but, again, I'm not sure the engine glow would let us see the effect anyway.

@Bman: you need to add "MSAACount=8" to ddraw.cfg. You can also set it to 16 or 32 if you want. However, I've been looking at the MSAA problem and I think you'll still notice some jaggies around the edges of the ships where they block the background. I've been trying to fix this; but there's a few technical problems that are hard to solve. So, you're probably better off activating FXAA as well (Add "EnableFXAA = 1" to ddraw.cfg). I would probably try "MSAACount = 4" and "EnableFXAA = 1" in ddraw.cfg. Either way, you can expect some performance penalty for the new effects. The Deferred Shader ignores the samples in SSAO and it's the fastest shader. If you enable SSAO/SSDO, you can also try setting "ssao_buffer_scale_divisor = 2" to speed up those effects.

@Trevor: I totally forgot about the local light sources! You can have them on and combine the effects (I have them off all the time); but I just checked and XWA's light sources seem to have a negligible effect when firing lasers.

I think GT's engine lighting suggestion was intended not to enhance the effect of a ship's own engines casting light into itself, but to cast light into other nearby ships. Imagine the engine glows of starfighters showing on the hull of the ISD they're skimming, or the fighters getting lit up like a flare going through the ISD's engine wash.

Probably prohibitively expensive, though, particularly since there lights would need shadows (or somehow be implemented as cone lights) in order to look correct.

As to the light count and distance, could those parameters be made user-configurable?

keiranhalcyon7 wrote: ↑

Mon Mar 23, 2020 5:33 pm

I think GT's engine lighting suggestion was intended not to enhance the effect of a ship's own engines casting light into itself, but to cast light into other nearby ships. Imagine the engine glows of starfighters showing on the hull of the ISD they're skimming

Ah! That's a good idea! Now I want to try that. Shadows probably won't work very well; but I can see this working OK-ish anyway.

As to the light count and distance, could those parameters be made user-configurable?

The distance is configurable; but not the count. The count has to be hard-coded in the pixel shader because I'm sending the light information in a constant buffer. I could probably increase the maximum to, say, 20 and then make the number of lights configurable within this range. The downside to this is that the GPU architecture may still execute the instructions for all 20 lights even if only a few of them are active because *GPU architecture*, so the performance penalty will be paid regardless. Maybe I could have additional passes to add more lights in batches of 8 or so... Yeah, that could work...

keiranhalcyon7 wrote: ↑

Mon Mar 23, 2020 5:33 pm

I think GT's engine lighting suggestion was intended not to enhance the effect of a ship's own engines casting light into itself, but to cast light into other nearby ships. Imagine the engine glows of starfighters showing on the hull of the ISD they're skimming, or the fighters getting lit up like a flare going through the ISD's engine wash.

Probably prohibitively expensive, though, particularly since there lights would need shadows (or somehow be implemented as cone lights) in order to look correct.

As to the light count and distance, could those parameters be made user-configurable?

Eh well I actually was thinking of an engine lighting its casing or surrounding area (like the Calamaris or the Executor or Dominance). But I can see the problem with performance. I like your idea, too

Oh. Sorry, I just assumed that you meant ship-to-ship, since any ship self-lighting could be improved just with better baking.

Blue_max, is it really impossible to store the light info in a heap-allocated buffer?

AFAIK (and I'm happy to be corrected here) the GPU and CPU don't share the same physical memory. So any information that lives in the CPU has to be transferred to the GPU explicitly. DX11 offers two ways to do this: constant buffers or textures. Either way, programmers are encouraged to send as few data as possible because the transfer itself incurs a small performance penalty. The constant buffers are faster if the information is updated frequently in the CPU and it's a small chunk of data; but you have to define the size of these buffers beforehand (in multiples of 16 bytes). I can define a bigger constant buffer to include more lights; but that'll incur a bigger performance penalty, so I have to juggle both things.

That's why I was thinking of doing perhaps multiple passes and rendering a constant number of lights (8) per pass. The number of passes can be configured in the CPU or they can be dropped if no lights are present at all. Then, people with more computing power may increase the number of lights if they want without impacting the overall performance for everyone else. I think this approach would probably work; but it would have to wait a little bit.

Thanks Blue Max for info. Didn't know those optional statements exist for ddraw.cfg. Will do! Those effects are awesome, but a/t/m, I'm leaning a tad more toward performance since I have an older GPU for now, and the TF missions are/will be more resource intensive especially battles 8 through 13.
On different note, what are your thoughts if for example a pure transparent egg shape mesh was encircled around say a Calamari cruiser model to represent it's shields like in Episode 8, so you see the laser hits splash against the mesh? Just throwing that concept out there.

I added those statements to ddraw.cfg, they don't exist in Jeremy's version. If you want speed and effects, then you should stick to the Deferred shader, or just shut down all the effects and leave Bloom on.

I'm not sure about a shell surrounding the ships, that will most likely mess up the hit boxes the game uses and I don't know if that's even possible at this moment.

Blue Max, I know I have nothing constructive to add, but I still check this thread a few times a week just to get excited at your amazing your new shaders are. You've truly transformed a game that I've been playing since I was a kid (turning 30 this year). I've been holding off on a new game because you seem to be outdoing yourself every week, and I can't wait to play with all the new effects.

blue_max wrote: ↑

Sat Mar 21, 2020 8:35 pm

St@rkiller wrote: ↑

Sat Mar 21, 2020 8:28 pm

I've installed the "xwa_cockpitlook-1.0.2" and I can't look to the left with the joystick hat

Try using the new hook I just posted above (just rename it to "Hook_CockpitLook.dll"), there was a bug in the mapping of the keypad keys.

Thanks again blue_max ! That fixed it! Thanks a lot for all the amazing work and giving the game to new life!

Thanks for your comments Kampher and St@rkiller!

I went back to the MSAA problem and started reading how this is solved in professional games. Turns out I'm doing it wrong; but the full fix is probably going to incur in additional performance penalties. I'm trying to work around the main issue by softening some of the hard edges around the ships and the bloom; but I'm afraid it still looks better when MSAA and FXAA are combined. Anyway, my next release will have better MSAA support.

blue_max wrote: ↑

Tue Mar 24, 2020 1:22 am

I added those statements to ddraw.cfg, they don't exist in Jeremy's version. If you want speed and effects, then you should stick to the Deferred shader, or just shut down all the effects and leave Bloom on.

I'm not sure about a shell surrounding the ships, that will most likely mess up the hit boxes the game uses and I don't know if that's even possible at this moment.

Yeah, this I think could only be done one of two ways, as an additional mesh (that will add a ton of faces) that is transparent surrounding the model, and set to I believe 1, 2, explosion type. After the shield hits zero this mesh would take damage and degrade, once hitting zero it would explode and the hull/components underneath would then take damage.

I don't know how well this would work, or how this would look, or what performance hits may occur however.

The other way would be to have a second ship opt that is set in mission (that is just the shield mesh) that would encompass and shadow (or be carried by I suppose) the ship in question. Also dunno how well this would work.

Personally I'm not overly inclined either way, but I am curious more in the context of a cloaking field.

Hi Blue_max, those FXAA statements and other suggestions with MSAA are working great. It's a lot smoother performance wise and still has the shading effects. Thanks!

blue_max wrote: ↑

Sun Feb 09, 2020 9:16 pm

Yeah, this could apply to water too. Making animations would be a different project; but I think it would be doable in a PixelShader (just like the hyperspace effect). Transitions from atmosphere to space may also be possible with pixel shaders.

Also, the Dynamic Cockpit elements have proper shading now too, thanks to DTM and Jeremy:

specular-24.jpg

specular-25.jpg

Hey Blue_Max,

Are these shades in colors too!? or is it just the white option? :O they look amazing!

The specular reflections get the tint of the incident light, and that includes the DC elements. So yes, for instance, if the light is red, the specular reflections will also be red -- but everything else will also look reddish. Unfortunately, at this point, only 1 global light is supported in the shaders; but I'll add support for more lights in future releases.

blue_max wrote: ↑

Sun Mar 29, 2020 7:06 am

The specular reflections get the tint of the incident light, and that includes the DC elements. So yes, for instance, if the light is red, the specular reflections will also be red -- but everything else will also look reddish. Unfortunately, at this point, only 1 global light is supported in the shaders; but I'll add support for more lights in future releases.

Nice! Is this working right now? Can I get a link to check the shaders out!?

So here's a vid I just uploaded show casing how this SSDO looks along with Bman's work on the laser texture/weapon mesh alterations in action along with my own attempts at reimagining the TIE Fighter missions - some of which are large scale alterations to suit the mission/story idea, whereas others are small scale changes. This mission is heavily WIP and unbalanced, but I wanted to showcase what the XWA engine is really capable of now with all the alterations this awesome community has made to it over the years and how it can benfit the TIE Fighter campaign if it had this kind of scope back in the early-mid 90s!

https://youtu.be/VDY1TRuwTGY