Visportals and fog

[nbohr1more]

Another option is to unpack the tdm_base01.pk4 and copy the glprogs into it then repack it. : )

[DeTeEff]

2 hours ago, nbohr1more said:

Just add the spawnargs “noPortslFog” “1” to any foglight entity.

I can only build Linux binaries so perhaps @AluminumHaste can get you a Windows build if you want to check it out before the next dev build release.

Ahh, installed and noPortslFog didn't work...so I spelled it noPortalFog and we are up and running!

Thanks boys

[AluminumHaste]

And it's working?

 

[DeTeEff]

Yes, the portal stays open now, when I'm looking at it, as normal and as it "should" be which means all the stuff beyond it renders fine.

[DeTeEff]

Hmm, don't know if this is related to the dev build, but as I take damage, the screen slowly transitions to a green/blue psycodelic hue. Is this intentional?

[nbohr1more]

Doesn't sound right. I'll check to see whether any materials were changed in dev in relation to that...

[nbohr1more]

Yep, add this to your darkmod/materials folder:

tdm_decals_misc.mtr

[DeTeEff]

Working Thanks

[AluminumHaste]

So if fog keeps all visportals in the same visleaf open, doesn't that cause performance issues?

[DeTeEff]

3 minutes ago, AluminumHaste said:

So if fog keeps all visportals in the same visleaf open, doesn't that cause performance issues?

No, I'm always building with bends and vision breaking visuals in mind so the mission will not get bogged down. This "portal function" gives me more control over when and why a portal stays open as I would like it to, when there is sections where there is stuff beyond the portal that pops in, when using the auto closing function.

[nbohr1more]

45 minutes ago, AluminumHaste said:

So if fog keeps all visportals in the same visleaf open, doesn't that cause performance issues?

The noPortafog light doesn’t inherently force portals open. Instead is just disables the fog optimization which prematurely closes portals at the fog opaque radius. I suppose a more clever thing to do would be culling any non-lit and non-emissive  objects past the fog radius but that’s a pretty tough thing to do especially since shadows can sometimes get made by offscreen objects (etc). Before something like that we would probably want something like Quake’s func_occluder as a generic line-of-sight culling feature.

[AluminumHaste]

Ok that makes sense, so without the fog there the visportal would be open anyways.

[DeTeEff]

23 minutes ago, AluminumHaste said:

Ok that makes sense, so without the fog there the visportal would be open anyways.

Yes, the only difference is that the fog doesn't interfere with the portals in any way. 

[VanishedOne]

Presumably func_portal control is an option if you can determine a distance at which the portal can be safely closed.

[DeTeEff]

On 4/5/2023 at 4:42 PM, VanishedOne said:

Presumably func_portal control is an option if you can determine a distance at which the portal can be safely closed.

Yes, you can use func_portals to control when to open/close portals through triggers/scripts, but this "fog occlusion" thing takes precedence over that, meaning that the portal shuts close as the fog gets to dense, ie you reach the number in the spawnarg shaderParm3 on the foglight.

[nbohr1more]

Thus far, we have created spawnargs for noFog, noPortalFog, noFogBoundary, and spectrum variants. I am tempted to move all light attributes to entity args (which is what id Software themselves were considering according to the code comments). Material keywords make sense for surfaces with lots of different material regions and alpha blending but for lights it's easier to control their appearance via DR (etc) so entity flags work better.

[DeTeEff]

I'm glad that some of us are coders and others' are designers. I'm sitting here in my room nodding and smiling

[stgatilov]

2 hours ago, nbohr1more said:

I am tempted to move all light attributes to entity args (which is what id Software themselves were considering according to the code comments).

I think it is better to decide on case by case basis.