Effects (Bloom, SSAO, SSDO) and VR/TrackIR Installers

[blue_max]

Found one issue with stuttering during battles, fps comes to a crawl when you hit a craft with your laser, turned off the hit effect option in the settings and that fixed it,. You dont seem to miss much now except a strange red glow when laser impacted. Maybe useful info for someone else..

I've noticed this as well sometimes, thanks for sharing. You disabled it using the XWAUP installer, right?

[MichelangeloS]

I didn't had those performance issues, or didn't realized about it.
What I did noted is that in the "Effects by Blue Max's Version 2020-08-06 " version some small explosions are all around the ship, I installed the previous version to fix that.
Also I added full voice control with VoiceAttack and HCS VoicePacks, fixed the aspect ratio.
I cannot set a way to see the mirrored view like in full screen to use the entire screen space, but here is the better version I have so far:

https://youtu.be/85ui6Asny5w

[blue_max]

I cannot set a way to see the mirrored view like in full screen to use the entire screen space, but here is the better version I have so far:

At the moment it probably won't be possible to cover the full desktop with the mirror window because the aspect ratio on the per-eye SteamVR resolution is probably different from your desktop aspect ratio. If you're really interested in that, I can consider modifying how the code behaves in this area to cover the whole screen though.

BTW, I'm curious about how you fixed the aspect ratio. Would you mind sharing your SteamVR per-eye, in-game, and desktop resolutions as well as the final aspect ratio setting you used to fix the image in the mirror window?

[m0rgg]

What I would suggest blue_max is to just crop the top and bottom of the SteamVR buffer to achieve the monitor real aspect.

[nuttyapprentice]

Found one issue with stuttering during battles, fps comes to a crawl when you hit a craft with your laser, turned off the hit effect option in the settings and that fixed it,. You dont seem to miss much now except a strange red glow when laser impacted. Maybe useful info for someone else..

I've noticed this as well sometimes, thanks for sharing. You disabled it using the XWAUP installer, right?

No, just in the in-game settings, the effect was instantly noticeable. Great work on the latest 1.1.4 release by the way!

[Luke_Skywalker]

Wow, almost a month with no new posts. D:

So about that TrackIR business not closing properly... If you start and quit without launching a mission, it takes a second or two but the camera exits game mode like it should. However, if you launch a mission and quit, it remains stuck. I dunno if that changes anything or not- I just wanted to clarify after realizing this.

[AngeI]

So I've had quite a few comments now on the various recent TFTC videos that the bloom is too excessive, particularly on lasers. By default now I think the bloom settings on installing are set to the maximum as a default (which is what I was on). I would recommend you set this to high rather than maximum by default instead.

[Trevor]

I've had a go at toneing them down a little though these need looking at again

Code: Select all

lasers_strength 		 = 2.0
turbolasers_strength	 = 1.5
light_map_strength 		 = 1.0
cockpit_lights_strength  = 1.0
background_suns_strength = 0.02
lens_flare_strength 	 = 0.02
engine_glow_strength	 = 2.5
explosions_strength		 = 5.5
sparks_strength			 = 0.5
cockpit_sparks_strength	 = 0.5
missile_strength		 = 2.5
hyper_streak_strength	 = 1.0
hyper_tunnel_strength	 = 1.0
skydome_light_strength	 = 0.1

background_suns_strength = 3.0

Once ships have their own materials (and maybe more map types supported) some of these problems should disappear but for now, when I try to make ships windows bloom, the hangar is excessively bloomed. This is a consequence of the hangar having more "white" than ships, and since we don't have HDR yet, there currently isn't any way to tell the shader that "The ship windows are really bright despite their size"

Trev

[Bman]

Also the TFTC uses a totally different laser systems (all new textures) vs. XWAUPG and/or DSUCPv2.6+... so right now it won't mean much to most peeps until a "recommended settings" is posted later.

[AngeI]

Bman and I also have a question why the lasers don't seem to be lighting up the cockpit when firing but ions do.

[blue_max]

Bman and I also have a question why the lasers don't seem to be lighting up the cockpit when firing but ions do.

The way laser lights work is by attaching a small light to the laser's texture at UV coordinate (1,1). If your laser OPT isn't using this UV coordinate, it won't light up. My guess is that your ions are using this coordinate, but other lasers are not.

[AngeI]

Ah that might explain it since TFTC is using custom laser OPTs. Bman will have to modify this as a result. Thanks!

[Bman]

Yep. BlueMax, are you referring about having a file like ImpTurboLong.opt ==> ImpTurboLong.mat in the XWA\Materials folder? Not sure what you mean by attaching a small light to the texture's UV coordinate (1,1). Don't have any ions files yet. Using XWAUP/DSUCP version for now. Off topic, I was just testing the AG, and when you fire the ion cannons from above the cockpit, it lights up the cockpit from the right side ion blast more than the alternating left side ion blast. Is there something in the .mat file that is driving that? Or would it be a texture map issue in the cockpit.opt file that is affecting this? Thanks.

[Trevor]

Yep. BlueMax, are you referring about having a file like ImpTurboLong.opt ==> ImpTurboLong.mat in the XWA\Materials folder? Not sure what you mean by attaching a small light to the texture's UV coordinate (1,1). Don't have any ions files yet. Using XWAUP/DSUCP version for now.

No, the lasers are a quad with a texture on it.
The quad should be using the texture co-ords
0,1 1,1
X
|
|
|
|
0,0 1,0

if your co-ords are less than 1, it will not draw the light.

however, having now looked at the laser, Blue, would it not be better to use 0.5, 1 so the light is in the "middle" of the laser.

another way to do lasers - and my first assumption before opening the file - would be to have a quad with a mirror texture on it using the co-ords
0,1 2,1
>
|
|
|
|
|
0,0 2,0

Trev

[keiranhalcyon7]

however, having now looked at the laser, Blue, would it not be better to use 0.5, 1 so the light is in the "middle" of the laser.

Would the middle of the laser not be uv = (0.5, 0.5)?

[Trevor]

well, yes, but the brightest point is at the "head", so if you really want to be accurate it would be more 0.5, 0.9

Trev

[blue_max]

I think in this case it's easier to explain using an image. I got this one from RebelTurboLong.opt (the version that gets installed in XWAUP 1.6 when selecting battlefront-like lasers):

Laser-1-1.png

Assuming that the U coordinate is 0 on the left and 1 on the right, and that V is 0 on the top and 1 on the bottom, then ddraw.dll will attach a light where I put the green dot in the image above. Which, now that I think about it, isn't quite right. At the moment this is hard-coded in the logic inside ddraw.dll. If I remember correctly, the laser .mat files only specify the color and intensity of the light. Because the light isn't positioned at the tip of the lasers, there will be small differences in the illumination when firing from the left or the right (as Bman pointed out). At the time, I didn't think anyone would really notice because lasers are too thin and fast -- I obviously underestimated you guys!

Anyway, Trevor is (almost) right. The correct place to put the lights would be at U = 0.1 and V = 0.5 (approximately). This would put the light on the following spot:

Laser-0.1-0.5.png

If it helps, I could add another setting to the mat files to specify where the lights are placed in uv coords.

[Bman]

Yes, that would be fantastic. Because different texture maps obviously will have different relative positions of the light spot tagged to it, like your above pic. I think I understand the UV coordinates, but I'm not clear how you manifest it. What file does ddraw.dll read the UV coordinates? I was assuming it was read from the *.Mat files. My apoloiges, I haven't read up on the materials thread yet, so I"m a little behind. Thanks.

[keiranhalcyon7]

On the one hand, yes. On the other hand, why is this texture-driven (as opposed to opt-coordinate-space-driven)?

[blue_max]

What file does ddraw.dll read the UV coordinates.

This is not implemented yet, but yes, it will most likely be in the .mat file for the laser type.

On the one hand, yes. On the other hand, why is this texture-driven (as opposed to opt-coordinate-space-driven)?

Because the 3D coordinate doesn't have any information regarding what bit of the laser it's related to. This aren't OPT coordinates, these are view-space 3D coordinates which have already been transformed from object to world to view space. Also, even if I managed to do that, we still have the same problem anyway: where do I attach the light?

[blue_max]

Yep. BlueMax, are you referring about having a file like ImpTurboLong.opt ==> ImpTurboLong.mat in the XWA\Materials folder?

This feature is now implemented. I haven't had much time to test it, so it might be buggy. Please download the latest beta (Oct 21). The uv coord where the laser light is attached can now be specified with a "light_uv_coord_pos" setting in the .mat files for each laser. For example, this is what my "LaserImpTurbo.mat" looks like now:

Code: Select all

[Tex00000,TEX00000]
Light = 0.0, 1.0, 0.0
light_uv_coord_pos = 0.1, 0.9

[Tex00001,TEX00001]
Light = 1.0, 0.0, 0.0
light_uv_coord_pos = 0.1, 0.9

[Tex00002,TEX00002]
Light = 1.0, 0.0, 1.0
light_uv_coord_pos = 0.1, 0.9
...

"Light" is the color of the light.
"light_uv_coord_pos" specifies the uv coord of the laser texture where the light will be attached. If this setting isn't specified, it will default to (0.1, 0.9)

[Bman]

Great, will test in near future. Thanks! Had another idea too. What if you could specify a specific x,y pixel location in the FG texture map(s) to anchor the "light" attribute? Say a typical map is 1024 wide x 128 height?

Different topic, in XWAOptEditor we have the ability to assign "illumination" to each FG texture map, whether in 32bpp or 8-bit indexed map. Would this make any value-added difference or interfere with the your special effects ?

[blue_max]

What if you could specify a specific x,y pixel location in the FG texture map(s) to anchor the "light" attribute? Say a typical map is 1024 wide x 128 height?

That's pretty much what the light_uv_coord_pos setting does, only it's in normalized (0..1) coordinates. That way it isn't tied to any texture size.

Different topic, in XWAOptEditor we have the ability to assign "illumination" to each FG texture map...

I need to check the code, but I think that for lasers the illumination attribute is ignored altogether and the whole texture glows. This was necessary because in 32-bit mode, the lasers became a bit dull -- if I remember correctly.

[Bman]

I see now. It's a different metric system, more broad. So moving from left to right, top to bottom, would 0.1 increments represent about 10% of the pixels in a broad sense? And if the texture is applied to both sides of mesh would we need to reference other side with same u,v coordinates or is it global? Laser textures are on top of a black background which made transparent. I tested the new uv light coordinates 0.1 and 0.9 but didn't seem to work.

[blue_max]

I see now. It's a different metric system, more broad. So moving from left to right, top to bottom, would 0.1 increments represent about 10% of the pixels in a broad sense? And if the texture is applied to both sides of mesh would we need to reference other side with same u,v coordinates or is it global? Laser textures are on top of a black background which made transparent. I tested the new uv light coordinates 0.1 and 0.9 but didn't seem to work.

These are literally UV coordinates. The details depend on the geometry of the 3D model itself. The creator of the OPT decides where to assign the UV coordinates and how they behave (how much they increase, in which direction, what direction is "up", "down", "right", "left", etc). The (0.1, 0.9) UV coordinates will only work if your OPT contains those UV coordinates. If you can send me a sample laser OPT, I can take a look to see what's going on