Shadow Mapping in Source

[-=Biohazard=-]

Textures with $selfillum crashes for me, even in the build on the SVN.

Code: Select all

Unhandled exception at 0x0DB0EE80 (shaderapidx9.dll) in swarm.exe: 0xC0000005: Access violation reading location 0x0000000C.

It points me to line 423 in \materialsystem\swarmshaders\defpass_composite.cpp
Specifically at
pShaderAPI->SetPixelShaderConstant( 10, params[ info.iSelfIllumTint ]->GetVecValue() );

The callstack can be found here.
http://pastebin.com/t0HqjQ41

Did you use it on a brush?
It looks like I forgot to copy the self illum vars to deferred_brush (only tested it on models actually...).

[ScarT]

Yes, it was used on a brush. I added the variables and that fixed it.

[ScarT]

Bump.
I'm having some odd problems with this.

I compiled the map with the light entities, some added in the ingame editor, and some in Hammer. I load up the map, and it seems the light settings from the light_deferred_global aren't applied.



I load the VMF, same as the compiled one, and the light_deferred_global settings are applied. Any ideas?

(Its a dark map, so spotting the difference is hard in the down scaled version of the images)



Also, I've noticed that materials that's using the deferred_brush shader falls back to lightmappedgeneric if they've got $translucent specified and not having $decal at the same time, but I'm having a hard time seeing the difference that'd make. So why is this even done? Materials falling back will be fully lit up.

[AniCator]

Is there anyone that can maybe help me integrate fetch4 code into the shaders. I haven't done a lot of shader programming yet but I really need this to work on ATI since I'm making a small mod for a community.

Here's a video of what I've been working on (running on NVIDIA):
http://www.youtube.com/watch?v=Zj4SwA76qhE

[Gary]

Its one line of code to switch over to software shadow filtering. I've been busy, so I haven't had time to look it up.

[-=Biohazard=-]

I compiled the map with the light entities, some added in the ingame editor, and some in Hammer. I load up the map, and it seems the light settings from the light_deferred_global aren't applied.

Compile in debug mode and try to start debugging at 'static lightData_Global_t GetActiveGlobalLightState()'.

Also, I've noticed that materials that's using the deferred_brush shader falls back to lightmappedgeneric if they've got $translucent specified and not having $decal at the same time, but I'm having a hard time seeing the difference that'd make. So why is this even done? Materials falling back will be fully lit up.

There's a huge difference because the decals are ignored by anything lighting related, they are just rendered in the second pass. It's simply not possible to light alpha blended geometry alongside with the rest, there are solutions that are either more costly or don't really work well to begin with so alpha blended geometry is simply unlit for now...

[Gary]

I think there should be a tad more explanation so people can understand exactly what the "deferred mod" does. We don't need something super detailed. Just a basic idea on what your mod does and how it works.

As far as I understand it(which isn't much, I'm no graphics programmer), this mod adds a new pass, the deferred lighting pass, to the rendering of the scene. You skip all other lighting methods(light mapping and such). You take the scene, load it to a render target( of course there are other render targets for shadows ), get all the new light entities information and position, do the lighting based on that. And send it back to be processed in the framebuffer. Of course you need new shaders and materials that will accept this new method of lighting objects(VertexLitGeneric/LightMappedGeneric doesn't make sense in this new pipeline, hence the new deferred_brush and stuff which properly accepts the new lighting information).

So, the deferred mod, is adding the deferred lighting pass and shaders, skipping the old stuff, and adding new light entities. If I'm wrong, Bio, or someone, correct me please.

[Epifire]

So basically any models or textures running on the deferred mod would have to refer to different shaders entirely? That would mean a lot of recompiling existing models if you were using a lot of them with this technology?

[Carbon14]

This looks incredible, but I am guessing that at the moment its a very solid proof of concept rather than something usable? I mean, Source without working 3d skyboxes and semi transparent materials is not going to really be usable for an actual mod right?

[ScarT]

Compile in debug mode and try to start debugging at 'static lightData_Global_t GetActiveGlobalLightState()'.

So far I've found nothing useful. It doesn't happen on all maps, which is odd.

There's a huge difference because the decals are ignored by anything lighting related, they are just rendered in the second pass. It's simply not possible to light alpha blended geometry alongside with the rest, there are solutions that are either more costly or don't really work well to begin with so alpha blended geometry is simply unlit for now...

Pardon me for being ignorant. I tried disabling the checks for $decal and $translucent in the shader code, and the output looks fine. What am I missing?

This looks incredible, but I am guessing that at the moment its a very solid proof of concept rather than something usable? I mean, Source without working 3d skyboxes and semi transparent materials is not going to really be usable for an actual mod right?

Get on IRC or Steam. You have access to our SVN with this.

[MrTwoVideoCards]

This looks incredible, but I am guessing that at the moment its a very solid proof of concept rather than something usable? I mean, Source without working 3d skyboxes and semi transparent materials is not going to really be usable for an actual mod right?

3d skyboxes work bro.

[-=Biohazard=-]

@Gary You are basically right. But it may be important to point out that 'deferred lighting' means rendering data like depth and normals to a RT first, writing the lighting to another RT (like you said) and then rendering the complete scene a second time where the lighting is applied (albedo wasn't read before at all etc). The first pass with normals and depth as output skips unlit stuff and decals.

You can also find some general info on wikipedia btw.

So basically any models or textures running on the deferred mod would have to refer to different shaders entirely? That would mean a lot of recompiling existing models if you were using a lot of them with this technology?

The shaders just get replaced at runtime.

Pardon me for being ignorant. I tried disabling the checks for $decal and $translucent in the shader code, and the output looks fine. What am I missing?

Your material is either being lit based on the data that was written by the geometry 'behind' your material or the partially visible geometry behind your material isn't lit at all. One of those is the case, depending on whether you're drawing it during the first pass too or not. It may look good enough depending on your material/scene, but that's not always the case.

[Epifire]

I know the question has gone around a lot in this thread, but I have not read any direct answer on it yet. Is this kind of technology limited to use in the ASW engine or is there a chance to see it working in 2007 as well? If it does not currently work on '07 is there work being done to make it compatible, or is it just not practical with that build?

The Centrifuge team and I could really use this in our Ravenholm mod, since our night levels would benefit much from it. We have been building on the 2007 engine so that is where my question comes into play.

[nub]

Biohazard released it:

"Enable Volumetrics."

Oh...my...god...


I fucking love you, Bio.

[-=Biohazard=-]

I know the question has gone around a lot in this thread, but I have not read any direct answer on it yet. Is this kind of technology limited to use in the ASW engine or is there a chance to see it working in 2007 as well? If it does not currently work on '07 is there work being done to make it compatible, or is it just not practical with that build?

The Centrifuge team and I could really use this in our Ravenholm mod, since our night levels would benefit much from it. We have been building on the 2007 engine so that is where my question comes into play.

It can definitely be ported to 2007 (porting != copying); however, I am not planning to do that myself at any point.