My Shenanigans

[GameDevGoro]

OooOOoh snap, people.

 

(For someone who didn't check out my status update this might be a fairly confusing topic.)

 

 

D:

[Mortem Desino]

I noticed the word "Gobo" when you were working with multiplicative lighting. I've only seen that word used in one industry. Are you familiar with theatre/concert lighting?

[GameDevGoro]

I noticed the word "Gobo" when you were working with multiplicative lighting. I've only seen that word used in one industry. Are you familiar with theatre/concert lighting?

 

Well- I've seen it used in the 3d quite a few times (cinema and 3d do cross paths in more than a few areas). It's not really technically correct, I guess it's more of a simile to the real thing?

I feel it's close enough to what it's supposed to simulate so I stuck with Gobo.

 

I can't say I'm specifically familiar with theater lighting and such. My knowledge is more general, but that generality fortunately covers these things too, so I'm not completely in the dark. (I hope)

[OrbWeaver]

I remember the term "gobo" from doing the lighting for school plays. As I recall it's a piece of metal with a shape cut out of it (like a stencil) which fits over a light and casts a particular pattern.

[nbohr1more]

The basics:

 

Which parts of your renderer are deferred verse immediate?

 

How are your light projections handled (shape, input, etc)?

[GameDevGoro]

@OrbWeaver: That's absolutely correct, but to my understanding sometimes it can be a transparent film or something with silhouette pictures on it that is placed in front of a light. Old school zombie movies used these for shadows from tree branches and things.

Or I could be remembering it all wrong, that has happened before.

The basic idea is still the same, something that obstructs a lights path, creating "controlled" shadows.

 

@nbohr1more: Well. Right now, all of the lighting is deferred except spotlights that cast shadows and directional lights.

The choice to put directional lighting into forward rendering is based on the idea that directional lights always affect everything in the scene equally as it has no falloff. It's slower to invoke the deferred shader onto the entire screen for something that can just as well be put in before the actual deferred shading begins.

I know that people who are interested in a "pure" deferred renderer frown at the idea of this, but I don't. It makes perfect sense to me.

 

I will also at one point replace shadowing with deferred shadowing, simply because it's a bit of a pain to deal with shadow-casting spotlights separately.

 

Now for your second question... I'm a bit confused by what you mean by "light projection"... :S

[nbohr1more]

Alright, I am starting out with a presumption of an Id Tech 4 style light projection arrangement.

 

This is probably a mistake as the light directionality and volume characteristics can be arrived at

via any math that can determine vectors from an origin.

 

@@@@

 

That's interesting. I was thinking that the directional lighting would be the best candidate for immediate mode rendering

because it produces more sharp surface detail. Thus it would degrade more if packed into G-Buffers along with ambient lighting.

 

I was speculating on a scenario where even some directional lights were still deferred and only the closest directional lights

were immediate mode. A sort of LOD for lights if you will. Not sure if that would be possible though...

[GameDevGoro]

That's interesting. I was thinking that the directional lighting would be the best candidate for immediate mode rendering

because it produces more sharp surface detail. Thus it would degrade more if packed into G-Buffers along with ambient lighting.

 

Well. Directional lights are in fact forward rendered.

How I do it right now is I draw ambient first, then directional light blended onto that. None of these are ever put into the GBuffer.

The GBuffer only contains diffuse color, normal direction, specular shift and some things in the alpha channels like specular gloss and linear scene depth.

Does that make sense?

 

 

I was speculating on a scenario where even some directional lights were still deferred and only the closest directional lights

were immediate mode. A sort of LOD for lights if you will. Not sure if that would be possible though...

I fear we may be speaking of two different things here then...

I'm talking about lights that only have a direction in 3d space, no location. No location = no possible attenuation.

Everything gets lit equally from this one direction.

 

But regarding the LOD for lights, that would work actually. But I'm not sure if it actually would be faster in the end. It's all about scene complexity, not wanting to draw a 56k triangle character more than once.

[nbohr1more]

The LOD for lights idea was less about performance (per se) and more about conserving G-Buffer space (and retaining surface quality).

 

Is your Deferred Method something like "Light Indexed" or "Forward +" then? (using the scene depth)?

[GameDevGoro]

The LOD for lights idea was less about performance (per se) and more about conserving G-Buffer space (and retaining surface quality).

 

Is your Deferred Method something like "Light Indexed" or "Forward +" then? (using the scene depth)?

 

I'm intrigued by this "surface quality" you speak of. You shouldn't technically get any surface quality degradation unless you use formats that are of lesser bit range than you require?

For example: using 8 bits per channel on the normal buffer has banding artifacts whilst 16 bits per channel hasn't.

Point being, if you manage your buffers neatly then there's no visible difference with forward lighting and deferred.

 

Well, it's not Light Indexed. But yes, I use scene depth to reconstruct the positions of lights, using linear depth(not exponential) as to not compromise floating point accuracy at long distances.

And since this depth is stored linearly I can also use this buffer for soft particles and depth fog in water and other neat stuff.

[Baddcog]

hmm, sounds complicated.

 

 

I guess you are figuring out a way to optimize and minimize light passes.

[GameDevGoro]

hmm, sounds complicated.

 

 

I guess you are figuring out a way to optimize and minimize light passes.

 

Absolutely.

I have enough draw passes to deal with on the material side: cubemap reflections, emissive term, fresnel term and a few more things.

In a very worst case some models tend to draw up to 5 times because of different material passes that get applied to them.

I'm actively looking for ways to minimize this, but I'm also aware that not all of the rendered geometry needs to have all the material passes applied.

Combining shaders is probably a good start.

 

I expect that for all generalized geometry that only need normalmapping, specular shift and gloss draw 2 times at most. Once for ambient fill and one more time for GBuffer.

Edited April 16, 2012 by GameDevGoro

[nbohr1more]

Yeah, based on my abstract knowledge, your setup seems to be akin to "Forward +" but I presume you aren't using

Compute shaders to make the light position determinations from the depth pass.

 

AFAIK, if your lighting were accumulated in the G-Buffer along with all those other components then you'd either need a HEFTY

buffer or you'd need to sacrifice format precision to pack data (as is the standard practice).

 

Does your ambient method accept irradiance volumes or other baked ambient methods?

[GameDevGoro]

Yeah, based on my abstract knowledge, your setup seems to be akin to "Forward +" but I presume you aren't using

Compute shaders to make the light position determinations from the depth pass.

Nope. No compute shaders. Just standard approach with plain ol' vector math. (My engine is also targeted for DX10 hardware so, compute shaders are DX11.)

 

AFAIK, if your lighting were accumulated in the G-Buffer along with all those other components then you'd either need a HEFTY

buffer or you'd need to sacrifice format precision to pack data (as is the standard practice).

Oh. I don't actually use an accumulation buffer in that regard. I don't really see the point nor do I think it really applies in my situation.

All of the lighting right now is blended additively onto the rendered scene, doesn't matter what light it is, deferred, forward or just emissive term.

Works fine for me. Though for a pure deferred approach this isn't a possibility since to my knowledge you wouldn't have anything to blend it on per se.

As far as I know, a pure deferred approach has ALL of the data in the GBuffer and doesn't leave anything rendered "traditionally" in the backbuffer.

So realistically, if you just turn on additive blending and draw the light results you get nothing, it'd just blend the lighting onto the clear color and you'd just see your deferred scene rendered on top of that (again, with no lighting).

But I draw the lights after I've drawn the ambient term into the backbuffer, which means that when I draw the light results it just blends with the ambient pixel that's already there.

So I don't really need to bother with a light accumulation buffer, I just render the deferred lights as I do the forward rendered ones, with the same blending.

Unless I've totally misunderstood what a light accumulation buffer is for, and in that case, please enlighten me if you can.

A pure deferred approach is of course better in the regard that you really do just draw every piece of geometry once per frame, I realize this. But it also makes it more limited and in order to gain more control over how things are rendered you'd end up creating more buffers. More buffers = more memory and bandwidth consumption.

 

Does your ambient method accept irradiance volumes or other baked ambient methods?

Hmm not currently. But it's "upgraded" from just using constant, flat ambient values to using a diffuse cubemap. This way one can emulate sky and ground pretty efficiently, getting the reflected colors from the general atmosphere in the dimples and cracks of the normalmap. (looks TONS better in my opinion)

(Bonus: I'll also admit this idea popped into my head the first time I watched the Overgrowth videos )

I really should support baked ambient though... Maybe I'll put that in, won't take that much work.

Edited April 16, 2012 by GameDevGoro

[nbohr1more]

Pretty neat stuff you've got going on with voxels to calculate light volume intersections

 

I was thinking about the old lightmap \ lightprobe paradigm and had a thought that the

light probe could have it's origin right inside the actual lights. Rather than lots of spacial

interpolation for a "light probe grid" you are instead just doing reverse spherical attenuation.

A light and and anti-light so to say where the anti-light is dimmer and blurred ala convolved ambient behavior.

Even though it wouldn't be completely accurate, if you simply brightened and dimmed the "anti-light"

in relation to the dynamic light value it would approximate dynamic radiosity pretty cheaply.

Multiple light sources behaving this way should interact to produce some pretty convincing radiant caustics.

Of course it would be cooler still if the probes were constantly updating their data to reflect the in scene

radiance but that would be pretty expensive (but maybe a tad cheaper than the Battlefield 3 "gun all the probe grid

updates to a spare CPU" approach...).

[jay pettitt]

I've no idea what you're talking about. But this creepy hand thing is creepy.

 

http://www.youtube.com/watch?v=fAsg_xNzhcQ

Edited May 8, 2012 by jay pettitt

[GameDevGoro]

Pretty neat stuff you've got going on with voxels to calculate light volume intersections

 

I was thinking about the old lightmap \ lightprobe paradigm and had a thought that the

light probe could have it's origin right inside the actual lights. Rather than lots of spacial

interpolation for a "light probe grid" you are instead just doing reverse spherical attenuation.

A light and and anti-light so to say where the anti-light is dimmer and blurred ala convolved ambient behavior.

Even though it wouldn't be completely accurate, if you simply brightened and dimmed the "anti-light"

in relation to the dynamic light value it would approximate dynamic radiosity pretty cheaply.

Multiple light sources behaving this way should interact to produce some pretty convincing radiant caustics.

Of course it would be cooler still if the probes were constantly updating their data to reflect the in scene

radiance but that would be pretty expensive (but maybe a tad cheaper than the Battlefield 3 "gun all the probe grid

updates to a spare CPU" approach...).

 

Yeeees. I see your point. And it just might work... I'm not sure how much work it would be to put that into a deferred rendering pipeline, as you'd need a new type of light for the 'anti-light'.

For ambient behavior in lights it can often be enough to deploy the so called 'half-lambertian' shading which essentially wraps the standard N•L into a full range which lets the light roll off the surface smoother.

Of course I'm not sure if that's enough to give the effect you're speaking of, but the properties of the half-lambert is akin to that of an ambient light.

Technically a thing like this would be pretty cheap on a deferred shading implementation, but gets more expensive because we can't cull the lights as aggressively.

It's definitely an interesting idea, nbohr1more.

 

But generally, I tend to not get to excited over "these" types of rendering concepts. Like dynamic radiosity and real time indirect lighting and other concepts that belong to the "not quite there"'s of modern real time rendering.

What I mean is: Yes, It's interesting, but I imagine it usually constrains the system more than it helps somehow.

Usually faked things make just as big an impression on the user if they are tuned right, so there's really little point to spending a significant chunk of one's leeway in CPU and GPU requirements to "waste" on something the user usually doesn't notice.

Even heavy hitters like Battlefield 3 use faked and approximated solutions for some things, they are making a game after all.

Another good example of this is reflections. Crysis 2 had a few select points where there are real time reflections. Did people actually notice them? Hardly.

(I mean aside from water reflections. I mean cars that reflect the surroundings and such.)

 

Do note I'm not in any way rejecting these concepts, they are just not that essential to me at this point in time.

When I can get away with a faked or approximated solution, I go for that.

 

 

I've not idea what you're talking about. But this creepy hand thing is creepy.

 

It is... It is indeed.