Ambient cubemap support for sikkmod

[nbohr1more]

Well, I figured out a better generalized solution. Let mappers define which ARB programs are used by which lights
via the program definition in the material and a new "customLight" keyword.

Code Select Expand



if ( backEnd.vLight->lightShader->IsCustomLight() ) { // custom light defined by material
qglBindProgramARB( GL_VERTEX_PROGRAM_ARB, newStage->vertexProgram );
qglBindProgramARB( GL_FRAGMENT_PROGRAM_ARB, newStage->fragmentProgram );



Now you can have infinite variety of light interactions. You could even use LOD to reduce the program count with distance by doing a shader definition swap.

Edit: not so fast, gotta find a way to exclude ARB processing "before" it's sent to the light code. Probably a keyword exclusion check in draw_common.

[motorsep]

Lights are culled like anything else in the engine already (not visible to player, considering occluding brushes)

Now this is what would be needed for IBL: http://seblagarde.wordpress.com/2012/09/29/image-based-lighting-approaches-and-parallax-corrected-cubemap/

[nbohr1more]

Well, I figured out a better generalized solution. Let mappers define which ARB programs are used by which lights
via the program definition in the material and a new "customLight" keyword.

Code Select Expand



if ( backEnd.vLight->lightShader->IsCustomLight() ) { // custom light defined by material
qglBindProgramARB( GL_VERTEX_PROGRAM_ARB, newStage->vertexProgram );
qglBindProgramARB( GL_FRAGMENT_PROGRAM_ARB, newStage->fragmentProgram );



Now you can have infinite variety of light interactions. You could even use LOD to reduce the program count with distance by doing a shader definition swap.

Edit: not so fast, gotta find a way to exclude ARB processing "before" it's sent to the light code. Probably a keyword exclusion check in draw_common.

OK, here's the fix (as I suspected it's in draw_common) just treat the stage preparation step like it's being
passed to low-spec hardware or to a config where shaders are disabled via a boolean check:

draw_common.cpp

Code Select Expand



    // completely skip the stage if we don't have the capability
if ( tr.backEndRenderer != BE_ARB2 ) {
continue;
}
if ( r_skipNewAmbient.GetBool() ) {
continue;
       // nbohr1more skip ARB shaders for custom lights so that they are not processed twice
if ( backEnd.vLight->lightShader->IsCustomLight() ) {
continue;
}



I'll add this to my Git when I get a chance

[nbohr1more]

Changes added to Revelator's "Revelation branch" so you can use a more modern build with more optimizations:

https://github.com/nbohr1more/Revelation

you can now simply add "customLight" to your material def then define the program, fragmentProgram or vertexProgram
that the material points to using the conventional Doom 3 syntax.

I will update my vanilla too eventually.

Edit: vanilla too

https://github.com/nbohr1more/Doom3_divide

[revelator]

Also we finally nailed how to access the depthbuffer in vanilla with some help from the darkmod guys
This gives a whole slew of new options for vanilla like soft particles / real SSAO / SSIL and is generally a requirement for doing shadowmaps.
I went a bit further and completed the interface code for use with mods also and stevel at the darkmod forums has allready made quite some shader
work using this.

The revelation engine on github was the last with the editor code intact, i since branched off my code into a version with no editors and even more fixes.
Sadly its not on github as i plan on merging my current work with my github version when we have a proper crossplatform version of the editor code (WxWidgets most likely). But if anyone wants a look at my current code ill be happy to upload it.

[BielBdeLuna]

it would be cool to also add these developments to d3BFG

[nbohr1more]

it would be cool to also add these developments to d3BFG

OK, I took a few looks at this for BFG. The main place for changes would be in tr_backend_draw.cpp

We'd alter this conditional:

Code Select Expand



if ( lightShader->IsAmbientLight() ) {
if ( surf->jointCache ) {
renderProgManager.BindShader_InteractionAmbientSkinned();
} else {
renderProgManager.BindShader_InteractionAmbient();
}
} else {
if ( surf->jointCache ) {
renderProgManager.BindShader_InteractionSkinned();
} else {
renderProgManager.BindShader_Interaction();
}
}



to do a bind from newstage kinda the way I did it in vanilla:

Code Select Expand


renderProgManager.BindShader( newStage->glslProgram, newStage->glslProgram );


Since I'm a little fuzzy on how the BindShader command distinguishes between Fragment and Vertex programs, I'll
probably just write a proposal and see if Treb can clean it up.

[nbohr1more]

Ok, changes are in my RBDOOM-3-BFG branch:

https://github.com/nbohr1more/RBDOOM-3-BFG

https://github.com/nbohr1more/RBDOOM-3-BFG/commit/4dcd3dc91ebb5fbfe40301d6ce9469dfd065f859

https://github.com/nbohr1more/RBDOOM-3-BFG/commit/2662eb3b31e31a91afa9b08a4a2608564e0ce89a

https://github.com/nbohr1more/RBDOOM-3-BFG/commit/ae77732bc9c70b97be640e03021e34a8f012d0f0

https://github.com/nbohr1more/RBDOOM-3-BFG/commit/78ba9135416af00aa6f2ac60a757e4a4e1d0a075

https://github.com/nbohr1more/RBDOOM-3-BFG/commit/e081a56660ef5e87ce71ff420e16ced01dc65c06

[BielBdeLuna]

this is cool! it's a special shader for a special light stage isn't it?

so we could extrapolate from this to special stages for like global illumination lights or screen space reflections, all in case we could get a GLSL shaders for such cases, isn't it?

[nbohr1more]

This allows you to make every light in your map use a different interaction.vfp depending on what's defined in your light material.
The most obvious use cases are new projection types like Cubemaps or 3D textures but you could even do crazy stuff like animating the falloff image, making lights with complex shader based animations (twinkling, TV static, etc), or hacky things like having a bound light entity with the spectrum keyword constantly move it's light center depending on the closest brightest light and project a custom interaction like POM or Fur on just one AI with the same spectrum.

That last one brings me to part two... Making material GLSL\ARB programs light reactive by making a custom interaction pass for them. Still trying to figure that one out but I have some clues.

[Sir Blackington]

Wow. Didnt expect anyone to get this kind of thing done anytime soon. Let alone this quick after discussing it.

[nbohr1more]

Wow. Didnt expect anyone to get this kind of thing done anytime soon. Let alone this quick after discussing it.

I mostly just copied Rebb's changes from The Dark Mod and expanded on them.
The hard part would be re-writing Sikkpin's cubemap light shader in GLSL (etc) for BFG.
I have very scant GLSL knowledge.

[BielBdeLuna]

I added the texgen cubemap generator from dhewm3 to d3BFG which could be used to test this new shader capability and a GLSL cubemap light shader ( non-existent at the moment )

a GLSL cubemap light shader could be the basis for GI-like lightning and a grid/cube of probes, and even generate them on the fly when needed.

[motorsep]

Doom 3 BFG shaders are Cg, not GLSL. Cg is very similar to HLSL, but not to GLSL.

I am almost certain it's nothing but easy what you have been proposing, nbohr1more. We have been working with BFG for a while now and there is nothing easy with renderer. We still trying to figure out how to skip calculation of silhouettes for surfaces with noShadows flag. The engine was never designed with that in mind, because it was only suppose to run Doom 3 BFG assets. Just as an example.

[nbohr1more]

Not that I wish to get into a big discussion on this but:

http://fabiensanglard.net/doom3_bfg/renderer.php

Says the shaders are GLSL 1.5 and there's a code block named RenderProgs_GLSL.cpp so you'll forgive me if I didn't see the cg component here. To my knowledge ATI drivers won't parse native cg so this would be quite a change in that preconception. Are you sure that the real situation isn't "we wrote the shaders in cg then exported them as GLSL from nvidia's shader studio"? From an operational standpoint it doesn't matter for my work since I'm using the same bind syntax used elsewhere in the engine.