Jump to content
The Dark Mod Forums
Sign in to follow this  
nbohr1more

Tracker 3881: Cubemap Lighting Beta

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

(Spooks this is it! ;) )

 

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

  • Like 1

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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 by Spooks
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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. :)

Share this post


Link to post
Share on other sites

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 by Spooks

Share this post


Link to post
Share on other sites

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:

 

post-3763-0-63488900-1471490579_thumb.jpg

 

 

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.

  • Like 3

Share this post


Link to post
Share on other sites

 


 

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 :) ? )

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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:

 

post-37271-0-96844500-1471521392_thumb.jpg

 

(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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Spooks

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...