Grain effect post-process

[nbohr1more]

I think they are more due to the fact that we provide the "clean" version of all textures (like a newly build brickwall) and the mapper needs to add dirt, cracks, etc etc. and this is very timeconsuming, and so often skipped. It would be better if we had a lot of run-down, old textures, so you don't have to dirty up every wall extra.

 

The grain-filter is a nice idea, tho.

 

It could technically work like an underwater-overlay, but as Mortem says, "detail textures" are much better than just a full-screen effect. Unfortunately, we don't have detail textures yet...

 

Did you try Mortem's demo above? I'm not sure it "technically" counts as detail textures but it is an enhancement akin to that technique at least (AFAIK). Look great!

[Bikerdude]

The dynamic ambient light has been in the mod a lot longer than the new ambient method.

oooh really, is this what your refering to..? or better still some example images..?

Edited December 9, 2010 by Bikerdude

[rebb]

Create tiny "zones" around the concave edges, or is that not possible?

 

You can't mask off specific areas from lights like that, unfortunately.

 

But a way to fake this might be using special darkening blend-lights placed carefully and strategically, with a low intensity.

It would still be a bit of a chore to place them tho - and they are likely more expensive rendering-wise compared to decals, altho they don't have the full performance impact of standard lights.

Also some other possible pitfalls, because they draw over everything they touch.

 

Heres some comparison images that use such blendLights.

 

( they look pretty harsh in the screenshots because the ingame Gamma isn't accounted for )

blendLights enabled

blendLights disabled

[nbohr1more]

Looks pretty good to me...

 

 

Fidcal would be the one to say whether that method saves any work verses griming but if I understand the method correctly it is "light reactive" so dynamic lights shouldn't look "wrong' with it correct? (Even if it isn't light reactive you'd be in no worse shape than with grimes, which aren't light reactive either...).

[rebb]

BlendLights don't care about lighting, this just multiplies over the lit/shaded surfaced that are touched by it's volume.

[nbohr1more]

Thanks Rebb.

 

Someday some mapper will create a beautiful map with Strombine lighting for the big coarse details, blendlights for the medium details and grimes for the fine details. Then STiFU will dmap that map in Sikkmod and wander around it with SSAO enabled. It will be a grand day

[7upMan]

...and then his gfx card will have a meltdown. Hopefully he'll have made some screenshots so at least it'll be totally worth it.

[nbohr1more]

Hopefully with all those AO techniques applied the screens wont be entirely black

[lost_soul]

My personal thoughts: I was never a fan of grain. While playing Silent Hill 3, I just had to turn that off. We've come so far from RF television connections (which exhibit these artifacts), only to consider simulating them in software? I always prefer a clean, perhaps hard image.

Edited December 9, 2010 by lost_soul

[STiFU]

oooh really, is this what your refering to..? or better still some example images..?

I think so. I am not familiar with the details myself though. Tels?

 

Then STiFU will dmap that map in Sikkmod and wander around it with SSAO enabled. It will be a grand day

Oh yeah. That'd be awesome!! I would probably alter the grime materials though, so that they are not drawn anymore. SSAO and grime together could really be too much depending on the settings.

 

I was looking into compiling Saint Lucia for Sikkmod, but it involved too much work. All those mod specific entities and stuff like that would have to be removed from the map and I'd have to make the assets available in Sikkmod etc.

[nbohr1more]

Actually it might not be too bad:

 

1) Copy all the TDM PK4's to the Sikkmod directory (excluding the ones that contains the gamex86.dll and the glprogs )

2) Open the FM in Dark Radiant

3) Filter Entities

4) Select all

5) Export as prefab

6) Import into new map

7) Caulk the holes

8) Save as new map

9) Pull hair out dmapping over and over again because something else TDM specific is still in there ???

[Tels]

I think so. I am not familiar with the details myself though. Tels?

 

The dynamic ambient light just enables the mapper to set a different "ambient base light" for different zones. So in a blueish moon light outside the ambient can be "0 0 5", while with a roaring fire inside it can be "5 3 1". The "ambient light" can even take into account local lights, so if you extinguish the fire, the ambient light fades (automatically) to "1 1 1". Ignite the fire, and it goes back. If you enter "fiery lava pits", the ambient can go to "8 3 0" etc. (The code also does soft fading between the colors, so you don't see the ambient light "jump" when you change zones).

 

However, this is just the color of the "ambient world" light modified - this light provides a basic color to your world avoiding the "pitch black shadows". It does neither "ambient occlusion", or any other special fancy things. It also has the problem that it modifies the entire ambient light, not just the current zone. (For that you would need multiple ambient lights, and that is poor performance). This means if you look back into the "old zone", the color there changed, too. To avoid this, you can add intermidiate zones, as well as "corners" so you can't look all the way from "fiery lava pit" to "bluish outside" and see that the forest is now reddish instead of bluish.

 

It is definitely a nice thing, but not the one-and-all-solution-up-to-radiosity.

[SneaksieDave]

I hope you'll (Tels) recall the recent request I made, to enable local ambient light entities' light levels be affected by targeted (or by your choice, nearby) lights.

 

For anyone else reading, an example:

Room has two torches in it and one ambient light entity. If the torches are fully lit, Room's ambient level should be bright. If only one torch is lit, it should be darker. If neither of the torches are lit, it should be quite dark. The request I made was that the local light entities would target (or be targeted by, or have some other relation to) the local ambient. So if both torches are lit, the ambient would have a light level of, for example, 20. If instead one was lit, the ambient's light level would be halved to 10 (or whatever the mapper specifies). If both torches are extinguished, the ambient's light level would be set to zero, or whatever bottom limit the mapper specifies.

 

One workaround to fake it now is simply to have two local ambients, each one targeted by one local light, so that the ambients are toggled on/off when the light is toggled on/off. Works well, but it has light level limitations (on or off, not specified levels or factored effect) and requires extra entities.

 

Tels wanted to take it one (huge) step further and make it automatic -- that the local ambient entity's level is automatically affected by lights within its vicinity.

 

Yes, in some sense, if this is implemented it makes the dynamic ambient system above a lot less relevant.

 

I think either of these would be a massive improvement and go a long way to some really cool faked radiosity.

[Noisycricket]

Anyone remember the "image sharpening" options in the old Nvidia control panel? I wish they didn't get rid on that, it works so well in games like TDM with lots of stone, dirt and wood texturing.

[nbohr1more]

It looks like Sharpening was designed with CRT signals in mind and once LCD became dominant they ditched it. Some folks say you can fiddle with ATI's digital vibrance controls and achieve a similar look...

[7upMan]

Anyone remember the "image sharpening" options in the old Nvidia control panel? I wish they didn't get rid on that, it works so well in games like TDM with lots of stone, dirt and wood texturing.

 

Do you have any screenshots as an example? I have an ATI 5770 card, so I could try to achieve a similar result with Niels' method.

[Noisycricket]

Tried to find some pics on google, no luck. The closest thing i found im not even sure its it, but it sort of looks like it. Its the 3nd set of screenshots down the page here. Might be easier to search for sharpening on that page. It was never enough to improve the game though, much like 60% of my graphical upgrades...

[ungoliant]

Tels wanted to take it one (huge) step further and make it automatic -- that the local ambient entity's level is automatically affected by lights within its vicinity.

 

Doesn't this have some serious drawbacks though? like guards carrying torches, or the player lantern.

You'd need to have dynamic lighting in every leaf to make things look consistent. as players/AI/whatever travel to different leafs. And even that consistency would be ruined by the relative size of each leaf. In a small corridor I can well imagine the surrounding surfaces might catch a little of the player lantern light, but to have surrounding surfaces lit by the same amount in a giant cave? madness.

[STiFU]

Anyone remember the "image sharpening" options in the old Nvidia control panel? I wish they didn't get rid on that, it works so well in games like TDM with lots of stone, dirt and wood texturing.

Haha, that takes me back. Back to the days, when I still excessively played Quake 3 Multiplayer. You could setup an enemy model and an enemy color, which I chose to be a very bright green. To raise the contrast even further I tweaked the RGB channels and put accentuation on the green one and also activated the edge enhancement technique. After that you got rid of texture details bei setting r_picmip 16, which made the engine apply the lowest mipmap layer (1x1) of all textures to every surface. The result was a mostly brownish greyish level and bright glowing enemys that directly drag your attention. One could nearly consider this cheating. But everyone did this back then.

 

Today, you can only tweak the color, gamma and brightness. Edge enhancement is limited to video-playback.

 

Re: Automatic Dynamic Ambient lighting

"Fake radiosity", well I'd probably rather call it dynamic diffuse lighting, especially since people around here seem to get confused so often how AO and radiosity and all that stuff in the end result actually look like.

[Tels]

Doesn't this have some serious drawbacks though? like guards carrying torches, or the player lantern.

You'd need to have dynamic lighting in every leaf to make things look consistent. as players/AI/whatever travel to different leafs. And even that consistency would be ruined by the relative size of each leaf. In a small corridor I can well imagine the surrounding surfaces might catch a little of the player lantern light, but to have surrounding surfaces lit by the same amount in a giant cave? madness.

 

It's nice when people tell you that things that are already implemented and working, will, in fact, never work

 

The ambient light consists of two parts:

 

* the static ambient light set by the mapper for each zone (or if not set, the map-wide ambient as default)

* to this is added a dynamic part, which is multiplied with a factor (per zone, or failing that a map-wide default), and then capped with a per-zone (or failing that, you guess it, with a map-wide default) limiter, so that the dynamic ambient doesn't overrule the main ambient.

 

In additin to that, the dynamic part also takes into account the distance to light sources. (Basically, the light is faded to the distance between player (where the ambient is computed) and the light source).

 

This means if you have a long hallway, lit by torches on the other end, the dynamic ambient light will get brighter when you go closer to the torches, and darker when you move away. Likewise, if there is a torch carrying guard, he will light the walls more if he comes closer. (It is not perfect, but it is very convincing).

 

The dynamic factor means you can "color" the dynamic part, so if you have a red lava cave, all light sources affect the ambient more in the red part. If you have a white, small room, the factor can be higher and more white, so light sources make the ambient more bright. If you have a dark huge cave, the dynamic factor would be very small, so a lone torch will not change the ambient at all. But light 100 torches and suddenly the cave walls get brighter.

 

http://wiki.thedarkmod.com/index.php?title=Location_Settings#.22ambient_light_dynamic_falloff.22

 

This article here is a stub: http://wiki.thedarkmod.com/index.php?title=Dynamic_ambient_light - my apologies I forgot to upload the nice info graphics I already made. Give me an hour and I update it.

 

What Sneaksie relates to is that the current method only modifies the "global ambient light". While this works around the player, it means things that are further away from the player (and maybe in the next room), are also getting brighter. The "local ambient lights" would only color the area around the player.

 

However, there are two problems with Sneaksies idea:

 

Consider you look from corridor 1 into corridor 2, each having its own local ambient light.

 

* First, performance (you need many local ambient lights, so the engine does a lot more rendering, in this case it renders stuff in 2 passes (2 lights!) instead of 1

* second: mapping work: You need to add a lot(!) local ambient lights and match their area really close to the mapping geometry. I did a small testmap and easily spent 20minutes on only a handful room. I don't think this will be ever popular...

* third: someone (me) needs to write the code to support it...(sorry, I didn't have time, my other project is still not finished yet).

 

The gains from this system would definitely that it is more correct - currently both corridors get the same ambient light, which depends in which corridor the player is, which is not correct, but passes so far as "good enough". However, the cost is not also quite high compared to our current simple system.

[SneaksieDave]

You say "many" local ambient lights, but the reality is you only need 2, instead of 1, per area. That's really not so bad, and I'd say very much worth the added benefits, as opposed to one light which lights up distant areas when it shouldn't, and grows brighter in cases when it should grow dimmer (pupil dilation).

 

I don't think the required mapping work is such a problem. Add an ambient light, and give it a "target" field (assuming simplest implementation, the only thing I was ever really requesting; your design took it to the moon ). That takes all of about 10 seconds per room. Not significant in comparison to the rest of work needed to create a full working mission.

 

For anyone who might be following along, you can still simulate it with a 1:1 balance between local lights and local ambients (the former targets the latter, and voila, it works! simulated radiosity) but it comes at some performance costs (since it is 1:1 as opposed to many:1).

[Tels]

You say "many" local ambient lights, but the reality is you only need 2, instead of 1, per area. That's really not so bad, and I'd say very much worth the added benefits, as opposed to one light which lights up distant areas when it shouldn't, and grows brighter in cases when it should grow dimmer (pupil dilation).

 

I don't think the required mapping work is such a problem. Add an ambient light, and give it a "target" field (assuming simplest implementation, the only thing I was ever really requesting; your design took it to the moon ). That takes all of about 10 seconds per room. Not significant in comparison to the rest of work needed to create a full working mission.

 

For anyone who might be following along, you can still simulate it with a 1:1 balance between local lights and local ambients (the former targets the latter, and voila, it works! simulated radiosity) but it comes at some performance costs (since it is 1:1 as opposed to many:1).

 

The "problem" I see is:

 

* if you have 100 zones, you need 100 extra entities

* these ambient lights need to cover *only* their zone. That is easy if you have rectangulare zones, but anything more complicated and it starts to get annoying

 

Anyway, I had the idea that if the D3 source is open, we could solve this much easier: for each zone, keep the ambient light in an array (e.g. not a real entity). When this zone is rendered, just render one extra, first pass with this info.

 

That way all polygons in one zone would be affacted, all in other zones wouldn't be, and thus you would save all the local ambient lights and still get the same effect.

 

Of course, one would first need to code the entire feature of dynamic local ambient lights, but heh, we have unlimited developer time, right?

[rebb]

Anyway, I had the idea that if the D3 source is open, we could solve this much easier: for each zone, keep the ambient light in an array (e.g. not a real entity). When this zone is rendered, just render one extra, first pass with this info.

 

That way all polygons in one zone would be affacted, all in other zones wouldn't be, and thus you would save all the local ambient lights and still get the same effect.

 

What happens if you see multiple of these zones at once ?

It sounds like it would be the exact opposite of the global dynamic ambient - which ambient-lights up everything - only ambient-lighting one zone and nothing else.

 

So much for a derailed thread - maybe some bits should be moved elsewhere.

[Tels]

What happens if you see multiple of these zones at once ?

 

with local per-zone ambients, it will work "correctly", with the current global ambient all zones you see are lit according to the ambient of the zone you are standing in (which is the problem the local ambient lights would solve).

 

It sounds like it would be the exact opposite of the global dynamic ambient - which ambient-lights up everything - only ambient-lighting one zone and nothing else.

 

No each zone has their own ambient light. (plus potential interfering, like light spilling through a portal, that will depend on the open/close (think door) and size of portal (archway, door, or small window)).

 

 

However, this is all far off...

[Tels]

Doen a first version of this wiki article and also uploaded my info graphic about the dynamic light part

 

http://wiki.thedarkmod.com/index.php?title=Dynamic_ambient_light