Tracker 3881: Cubemap Lighting Beta

[nbohr1more 2160]

Based on Rebb's work to make the Ambient light run it's own light interaction rather than piggy-back on

the main light interaction, I have made a patch that allows you to add the "cubicLight" token to light material defs

and switch lighting from the standard shaders to a new cubic_light.vfp shader that uses a cubemap as the projection

texture and falloff is done spherically.

 

This "new" shader (2011) was designed by Sikkpin before doom3world.org met it's demise.

 

It also has HL2 ambient style cubemap shading which takes an input cubemap and gives the environment

a sort of radiosity approximation based on the values in the input.

 

The main goals of this beta are:

 

1) Evaluate the functionality (look for bugs)

 

2) Evaluate the usefulness of each feature

 

3) Determine whether the current shader is sufficient or if it needs to be modified

 

4) Create new Light materials and textures to prepare for this feature

 

The shader doesn't have the same features that TDM's main interaction includes (Rim lighting, Fresnel, etc)

and instead appears to have been tailored to make the light look as much light HL2 as possible. This means if you

use this light type exclusively, your mission wont look like a normal TDM mission.

 

Over the course of the beta, I intend to attempt to fix that but I'm no ARB shader expert so no promises.

(If Rebb, SteveL, Revelator, Obsttorte, or JC Denton... etc wish to chime-in I will gladly accept any assistance).

 

In the absence of any help on the shader front, I still believe that this shader could prove useful paired with our normal lighting

as it would add more realistic light projections from Desk Lamps or could be used as an alternate outdoor ambient.

 

 

Here is the download package:

 

https://dl.dropboxusercontent.com/u/17706561/cubicLightPatch.zip

 

Overwrite your TheDarkMod.exe and gamex86.dll in your darkmod install folder.

Place the glprogs folder in your darkmod install folder.

Place the zzz_ambientcube.pk4 in your darkmod install folder. (This includes materials and cubemap images)

Place the maps folder in your darkmod install directory. (This includes a converted version of Sikkpin's demo map without Doom 3 AI)

 

Open the console and invoke: map ambientcube.map

 

You will see the initial area, illuminated by cubemap projected lights.

There is some sort of artifact there. I think it might be z-fighting or brush corruption but I couldn't

fix it by snapping to grid so this is one of the first things to examine.

 

If you noclip straight up into the sky above this area, you will see the other demo areas with HL2 style

lighting. I have found that spawning AI on the platform in these areas produces strange shadowing.

I suspect that the geometry of these zones is messing with the shadow calculation so I would like

to hear whether the same problem manifests in a map built for TDM.

 

Good luck!

 

(Spooks this is it! )

[Goldwell 2477]

Would it be possible to see some before and after pictures or videos of this in action please?

 

I'm curious about it but don't want to go messing with my game folder.

[NeonsStyle 585]

Yes me too, I would like to see some images or video please (corrected for gamma loss in video) please. (I can do that correction for you if you can't, so it's seen as it is in game)

[nbohr1more 2160]

I'll get some screens up tonight if someone doesn't beat me to it.

This patch won't change existing missions, it adds a new feature that you must include in your map design.

I did forget to mention that DR won't know how to render cubemap lights so the design process is:

1) Place normal TDM lights that approximate the intended look
2) Manually edit the light entity attributes to point to the cubicLight material def
3) Review the change in TDM

So you'll be flyin' blind until DR supports this feature.

One thing you could do to help with map design is attach a cubicLight to a moveable
Lantern (etc) then use the getviewpos cvar (and con_noprint 0 ) to gain the coordinates for light as you move around.

[Bikerdude 3741]

I would like to play with this, but need to understand exactly what it does.

[nbohr1more 2160]

I would like to play with this, but need to understand exactly what it does.

 

You know how the desk lamps have that weird looking circular projection above them?

 

This would be able to fix that by using six textures. Up, Down, Left, Right, In, Out. (All the sides of a cube.)

The light get's brighter as you go closer to the center in a natural way.

 

In short it behaves much more light a real light than the 1D + 2D setup the current lights use.

 

The example materials are in the pk4 if you wanna make your own textures.

[Spooks 703]

(Spooks this is it! )

 

Yay! I almost missed this thread. I'll be downloading this and playing around with it.

[nbohr1more 2160]

It occurred to me that one of the main reasons you mentioned this was for the HL2 radiosity component.

 

One thing I'll probably want to look at is making multiple cube stages with parm values that depend on your

distance to entities so you can get probe-fading effect from region to region.

 

A few notions come to mind...

[Spooks 703]

I did forget to mention that DR won't know how to render cubemap lights so the design process is:

 

1) Place normal TDM lights that approximate the intended look

2) Manually edit the light entity attributes to point to the cubicLight material def

3) Review the change in TDM

 

So you'll be flyin' blind until DR supports this feature.

 

I'd like some clarification on this, do you mean DR's lightning preview mode won't display them correctly? Putting the correct "texture" (shader) on a light should be enough to enable the cubelight lights in-game, right?

 

e: so far noticed that the player's viewmodel interacts with the lights and materials that already have a cubemap on them interact fine with cubemap lights, so looks promising.

 

Also found out the z-fighting looking artifact is caused by the cubicgrate6 light, something wrong with the shader there.

Edited August 17, 2016 by Spooks

[nbohr1more 2160]

Right, the texture will reference the material def and if the material def has the cubicLight token it will render this way.

 

You could even use the setShader script to switch to change the texture (material) just as you can with other light materials.

[Spooks 703]

I never got to find out what the difference between cubeMaps and cameraCubeMaps is, perhaps this thread is the right place to ask... At any rate, camera cubemaps seem to be a lot easier for making custom cubelights. I'm getting a wierd issue where image_right.tga from envshot is completely black, can I get anyone else to corroborate this?

[nbohr1more 2160]

I'll check that when I get home.

 

As I recall, cameraCubemap has a viewer based projection. These are typically used for reflections that fake parallax depth like our wiki example:

 

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

 

I think I should add an envshot cvar toggle to enable the old image generation behavior...

 

Here is a code description:

 

CF_NATIVE, // _px, _nx, _py, etc, directly sent to GL

CF_CAMERA // _forward, _back, etc, rotated and flipped as needed before sending to GL

[nbohr1more 2160]

 

Also found out the z-fighting looking artifact is caused by the cubicgrate6 light, something wrong with the shader there.

 

 

The images for that light are all using 0.0 Alpha (fully transparent) which is considered artist error as I recall.

I'll bet that removing the alpha (replace alpha with black) from those images will solve that one.

[Spooks 703]

OK before I go to sleep here's a couple last notes, on the grate6 image in particular too.

 

First, the projection (or should I say falloff?) always seems to be round, it'd be nice to have a couple of options like nofaloff or just being able to set up your own.

 

Second, all the cubemaps I've tried interact with bumpmaps and, like skyboxes, have parallax. Useful, but this doesn't actually do anything to improve our current cheese slice light method. Cubicgrate6, however, does appear to exhibit proper spherical projection and doesn't interact with bumpmaps the way regular cubemaps do, which is great. It's definitely how the image is saved, I've not tried to remove the alpha manually to see if I could get rid of the glitchy behaviour AND keep proper spherical projection, but that's definitely a thing to keep in mind.

 

edit: From testing, if the alpha channel in the cubemaps is either black, white or not present, they'll act like how cubemaps act right now. If the alpha has any grayscale in it, it will act like a projected image but with those artefacts.

Edited August 17, 2016 by Spooks

[nbohr1more 2160]

I was able to cure the z-fighting behavior by replacing the lights/sheen shader with the lights/cubecylinder shader. (for light_20)

 

Alternately, you can cure the z-fighting by making that light a conventional ambient_world (which I tried first) and the grate6 light works just fine then.

 

I suspect that the problem is that sheen is 64x64 and I think standard TDM lights are 1024x1024 (I tried to upscale it to 128 and got mostly the same results).

 

Edit: Nope, scaling up the image has no effect here. Strange.

 

As promised, here's a pic:

 

 

 

The ambient is an HL2 style cubemap light which is producing caustics on the shiny floor based on the cubemap image.

 

There are cubemap projected lights on the right wall where you can see the pattern in the circle is properly stretched per a spherical light emitter.

 

A traditional TDM street lamp is illuminating the center screen and the light types seem to get along OK.

 

Still, I'm gonna hack away at that shader 'till it has TDM enhancements as best I can.

[nbohr1more 2160]

 

 

First, the projection (or should I say falloff?) always seems to be round, it'd be nice to have a couple of options like nofaloff or just being able to set up your own.

 

 

You can't set a falloff Image in the material but you can add a "falloff" "0" argument for the light entity. That, however, is what triggers the HL2 style shading.

I can try to look into adding a falloff image back to the shader. (Or one of the shader gurus can show some pity on me and lend a hand ? )

[NeonsStyle 585]

I like the way the light arcs against the wall. It's not a spot isn't it?

[Spooks 703]

I was able to cure the z-fighting behavior by replacing the lights/sheen shader with the lights/cubecylinder shader. (for light_20)

 

Alternately, you can cure the z-fighting by making that light a conventional ambient_world (which I tried first) and the grate6 light works just fine then.

 

There are cubemap projected lights on the right wall where you can see the pattern in the circle is properly stretched per a spherical light emitter.

 

I wasn't able to get the z-fighting to go away. The only time I've seen it is when a cubemap's images have some sort of alpha. Here's a custom cubelight that does this:

 

 

(You can also see my cubemap_right image being pitch black, does it happen to you too?) Did you do something else to the grate6's or the shader? Because I don't think cubesheen is the problem.

 

Also how do you switch from projecting cubemaps to a spherically projected light? The only difference I've seen in the files is the alpha.

[nbohr1more 2160]

So here's the sequence of my tinkering last night:

 

1) I removed the alpha from the grate6 light

Result: The Z-Fighting went away, but so did the light ?!?

2) I returned some alpha to the light and added some alpha to the sheen light

Result: Z-Fighting returns

3) I commented out the zeroclamp args in the light material def

Result: Somewhat reduced Z-Fighting (probably placebo)

4) I opened the map in notepad++ and rounded all the ultra high precision coordinates like -81.07843519e-05 to 6 decimal places

Result: Some reduction in Z-Fighting

5) In DR I removed two of the grate6 lights that appeared to have contorted light centers

Result: No real change

6) Replaced the sheen light with a standard TDM ambient_world

Result: No Z-Fighting (cured!?!)

7) Replaced the sheen light with cubecylinder to see if the problem comes back

Result: No Z-fighting

 

So that's what I did before returning to tinker with the ARB code...

 

Edit:

 

It occurs to me that step 5 removed the point-light versions of grate6 and that the sheen light was also a point light.

Time to go back an examine point lights for this bug.... Still, step 7 shows that a point light with cubecylinder works

just fine. So strange. I wouldn't be surprised to see that this is some sorta driver bug.

[New Horizon 524]

Do these types of lights offer any type of performance improvement?

[nbohr1more 2160]

The only improvement on performance would be that you can achieve the look you want more easily and typically that means

you don't need as many lights. In most cases, this will be a wash so the main benefits are "correct projection" and "easier map design".

 

Well, I guess the HL2 ambient also counts as an optimization as you would need tons of ambient lights to achieve that look (if you even could)

but I kinda classify that as a sorta side topic. Once the basic cube projected lights are confirmed to be useable, I'll probably create yet another

token for the HL2 ambient (maybe "cubicAmbientLight" ? ) so it isn't tangled into the scope of this change.

[Spooks 703]

I too vote for separating the two things. Cubic projection can be used for a lot and it's important to delineate usage scenarios. Right now I can see it being useful for 2 things: easy cubemap placement without having to apply cubemaps per-material and light projection the current light entities can't do. Down the road it could be used for probes and radiosity and all that jazz too.

 

Here's an example of why - while useful - having the two things together isn't necessarily beneficial. Say you have a single cubicLight shining on a small part of a largely unlit cobblestone floor, intended to be used as diffuse lighting. If the cobblestone has a specular, the cubemap will show in the light but not in the shadow, giving the impression that the cobblestone is wet where the light shines, but nowhere else.

[nbohr1more 2160]

New executable patch:

 

https://dl.dropboxusercontent.com/u/17706561/envshotGL_patch.zip

 

Now we have the "envshotGL" command that outputs the old style cube images imagename_nx (etc).

 

envshotGL <basename> size blend

 

I also tested evnshot and the right images are working. The console doubles the up name at the end but the images come out as expected.

[Spooks 703]

Phew, I was afraid for a second there, because I still couldn't make _right images to show. Disabling my ReShade setup fixed it though. No idea why it happens but probably something to do with the OpenGL hook. Unfortunately, I still can't get the jaggies to go away. I've tried several material keywords to no avail. The only case where they've not shown is when I've made the light from an omni light to a projected light. That defeats the whole purpose of spherical projection though, as the light has to be omni for all the sides of the cubemap to show. Still, it might be a pointer to where this is going wrong. Are you running an SVN version of the game? Maybe that's why the z-fighting's fixed on your side and not mine. Or it could be all your lights are projected and not omni, which isn't a fix.

 

When you removed the alpha from grate 6 the light didn't disappear, it just turned into a regular looking cubemap, which is harder to see because it only shows on surfaces with specular. The trigger for turning a cubemap to a projected texture (like how we have it in the current pointlight system) seems to be the presence of alpha channels, but that really isn't logical. To hazard a guess, it's probably something in the shader program that does it and if there could be a clear switch from "project this as a cubemap" to "project this as a texture" it would be a good improvement. All I know is cubemaps get processed through the bumpyenvironment.vpf and that's about it I can provide for pointers.

Edited August 20, 2016 by Spooks

[nbohr1more 2160]

I have a different hunch. Our light uses texture coordinate 7 for sky direction while this shader uses it for something else. I'll try moving it to 8 in the new shader when I get some time.