[GSoC 2011 - Accepted] Modern Illumination Techniques

Threads related to Google Summer of Code
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

I've fixed shadow casting lights not showing up, and am working on a fix for the edge-of-the screen problem(it seems like objects at the edge of the screen get wrong tex coords due to interpolation; will probably be using the WPOS semantic to get more accurate results). The issue with the specular term is that my lightbuffer's alpha channel is always 255(or 1, depends on who you ask :P). I haven't the slightest clue as to why. It's declared as PF_FLOAT16_RGBA in the compositor. Any ideas?
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Noman »

Perhaps the blending mode of the material writing to the L-buffer is additive or something like that? I dunno really.
The best way to check things like that IMO is with software such as PerfHUD or PIX. I used PerfHUD all the time when working on the deferred shading demo, in order to see the G-buffers get updated batch-by-batch.

[Edit]
Another way to debug without special software is to modify the shaders and 'cripple' them - for example : always write a constant value (like 0.1) to the alpha channel.

[Edit2] Another suggestion - maybe the default clear color for textures is RGBA = 0001 ?
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

Well, I'm using gDebugger, since I was always kind of an openGL person(and I couldn't get perfhud to work on my old laptop), but I'll give it a try as well.
And yes, I've tried 'crippling' the shader, and no result. Will also try playing with the blending parameters(the operation should be add, but it is possible that the factors are wrong).
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by LBDude »

Hi, I ran into an issue with the alpha channel was not being cleared properly with the clear color that I want, the clear color always defaults to a 1.0. What I did was I would add 1.0 to my specular value on write out from light buffer. In the subsequent forward-pass, I would always minus 1.0 from that value. So clear color (at 1.0) always goes to 0.0. I don't know why, perhaps I missed something. BTW I'm not using compositors, I have my own custom pipeline using RenderToTextures.

For light geometries I use 1.8's instancing manager. I setup the instance manager with a simple sphere mesh, then create N instanced entities with it which serve as my light geometry. During the light buffer pass (this is a light pre-pass setup) I render the instance entities with a bitmask so only the instanced light geometries are rendered. Current bottle-neck is with iterating through every instanced entities--CPU side--and updating it's positions. With this, I can render about 200 lights easily--provided that I don't bunch a whole bunch of lights together and walk up to them since I'm not doing stenciling optimization right now. For RSM, I don't think you will have this bottle neck since all the position updates will be done GPU side--ie. a gathering step on the GPU.

Update:
This where I found some info regarding the alpha being cleared with 1.0 issue. Someone else has the same issue. Although I admit I haven't debugged my own code that much since I have it working with the minus 1.0 hack and I'm busy with other things right now.

http://www.ogre3d.org/forums/viewtopic.php?f=2&t=52010
My blog here.
Game twitter here
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

I managed to fix the bug. The problem was the ambient light, which outputed the ambient color, which has an alpha of 1. I still have a couple of bugs, but not something major. The G-Buffer for inferred lighting also seems to be working properly. Well, kind of; I need to assign an unique id to each smooth group, but I'm not really sure how to do that, so I'm currently assigning id's per object(some lighting bugs might appear when two smooth groups of the same object meet).
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

Time for a well needed status report. Deferred lighting works fine with the following notes
Shadow maps don't get generated(hence lights cast no shadows) - why this happens is beyond me, probably magic. Will have to toy with shadowmaps anyway, for RSM
The lighting model in DL is different than that in DS or forward rendering. This is due to the fact that diffuse light and specular light(both factoring attenuation) are accumulated, then the RV^n term is recomputed in the shader and the material's roughness is applied. This might seem a bit weird, so here are the shaders:

For the light:

Code: Select all

float NL = max(0.0,dot(objToLightDir, normal));
float3 h = normalize(viewDir + objToLightDir);
float specular = max(0,dot(viewDir, h));
specular = pow(specular,30); //30 is the light's specular exponent. This doesn't have a physical meaning, but it prevents high values from accumulating in the LBuffer

ret = float4(NL * attenuation * lightDiffuseColor.rgb,specular*diffuse*attenuation);
For the material

Code: Select all

float4 lightVal = tex2D(LBuffer,pixpos);

float luminance = dot(lightVal.rgb, float3(0.2126, 0.7152, 0.0722));
//lightVal.a/luminance is an approximation for NH^30
float3 specular = diffuseCol*max(0,pow(lightVal.a/luminance,1.0+cSpecularity));
float4 color = float4(lightVal.rgb*(diffuseCol + specular),1);
return color
All the little hacks regarding specularity are to give DL a similar look to DS. Here's the screenshot:
Image

Inferred lighting is 'kind of' working, in that the DSF seems to ameliorate lighting aliasing, but not enough. It's possible that I've screwed up the bilinear upsampling, so I'm attaching the code in case someone spots something off.

Code: Select all

float2 sample1 = float2(1/cWidth,0) *2     ;
float2 sample2 = float2(0,-1/cHeight ) * 2;
float2 sample3 = float2(1/cWidth,-1/cHeight)  * 2;

float4 DSF0 = tex2D(DSFBuffer,pixpos);
float4 DSF1 = tex2D(DSFBuffer,pixpos + sample1);
float4 DSF2 = tex2D(DSFBuffer,pixpos + sample2);
float4 DSF3 = tex2D(DSFBuffer,pixpos + sample3);
		
		
float4 w = float4((1-LBuffpos_frac.x)*(1-LBuffpos_frac.y),LBuffpos_frac.x*(1-LBuffpos_frac.y),
                        (1-LBuffpos_frac.x)*LBuffpos_frac.y,LBuffpos_frac.x*LBuffpos_frac.y);
		
float w0 = saturate(100*(depth_epsilon - abs(depth-DSF0.r))) *
                saturate((1-1000*abs(DSF0.g - cObjectId)));"<<std::endl;
float w1 = saturate(100*(depth_epsilon - abs(depth-DSF1.r))) *
	        saturate((1-1000*abs(DSF1.g - cObjectId)));
float w2 = saturate(100*(depth_epsilon - abs(depth-DSF2.r))) *
                saturate((1-1000*abs(DSF2.g - cObjectId)));
float w3 = saturate(100*(depth_epsilon - abs(depth-DSF3.r))) *
                saturate((1-1000*abs(DSF3.g - cObjectId)));

w *= float4(w0,w1,w2,w3);
float4 lightVal = (w.x * tex2D(LBuffer,pixpos) + w.y * tex2D(LBuffer,pixpos + sample1) + 
                          w.z * tex2D(LBuffer,pixpos + sample2)+w.w * tex2D(LBuffer,pixpos + sample3))/(w.x+w.y+w.z+w.w);
Here's a screenshot of the DSF weights(w0->w3)
Image
And a screenshot of the end result(although the scene doesn't seem very aliased, there is a lot of temporal aliasing):
Image
Will start work on RSM for a couple of days, and come back and work on outstanding issues with DL and IL(I really need a change in scenery).
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Noman »

I really advise AGAINST knowingly changing scope and coming back to the original problems, even if its tempting. We need solid deliverables, not a bunch of half-working features.
If you want to take a short break from the visual debugging, rethink your schedule. Obviously you are not going to get everything done. Try to reorganize it and perhaps remove less important items from the list, and finish with a schedule that you believe you will be able to carry out. When looking at your past work, compare how much time you thought it would take vs how much time it took and try to adapt your future schedule to it.
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

I've done some tweaking with IL, and changed the sampling pattern. The scene, however is a good way to show the flaws of this technique, rather than it's strong points. The toruses are a pathological case for IL, since you have fragments from the same object, in the same normal group(same continuous surface), at close depth with different normals. This produced strong aliasing in that area, so I have added normal comparison. There is still an aliasing issue with objects that occupy less than a textel in the lightbuffer, since they are simply missed some of the time, producing temporal aliasing. However, the technique works very well for geometrically simple surfaces. All in all, it seems like a reasonable performance-quality trade off in most cases.

I've also revised my schedule, as I have a better understanding of problems that could appear, and of specific implementation details

July 10th Implement the rendering of 'fat' shadow maps
July 17th Implement the RSM sampling and generating of VPLs - VPLs will work as a special kind of deferred lights(they provide light over an hemisphere); after each shadow casting light is processed and it's shadow map generated, vpl's for that light are generated and rendered. The number of VPLs will depend on scene settings and the light's intensity.
July 24th Tweak VPL generation to obtain good visuals & solve issues - I expect issues due to the relative small number of VPLs that will be generated for real time performance to be achievable. Each VPL's contribution needs to be clamped to avoid unnatural highlights.
July 31st Implement Spherical Harmonic Lighting (this is a step of implementing LPV) - will generate a set of coeficients for the cathedral scene and use them for (directional only) lighting
August 7th Build a spacial grid containing the scene and render the geometry into it - this involves rendering each shadow map into a 'flat' 3D texture
August 14th Implement propagation & occlusion between grid cells, and generate the SH coefficients for each

PS: I still haven't solved the shadowing issue yet. Well, I've managed to get it to work, but still don't understand the problem: If I add any render_scene passes when I generate the light buffer, the shadow maps get generated. Here's my compositor:

Code: Select all

{
	technique
	{
		// temporary textures
		texture mrt_output target_width target_height PF_FLOAT16_RGBA chain_scope
		
		target mrt_output
		{
			input none
			pass clear
			{
			}
			
			shadows off
			material_scheme DLGBuffer

			pass render_scene
			{
				//These values are synchronized with the code
				first_render_queue 10
				last_render_queue  79	
			}
		}
	}
}

//Postfilter lighting the scene using the GBuffer
compositor DeferredLighting/ShowLit
{
	
	technique
	{
		//Reference the main Gbuffer texture
		texture_ref mrt_output DeferredLighting/GBuffer mrt_output
		texture LBuffer target_width target_height PF_FLOAT16_RGBA chain_scope
        target LBuffer
        {
			input none
			shadows off
			
			pass clear
			{
				
			}

			//Render the lights and their meshes
			pass render_custom DeferredLightingLight
			{
				input 0 mrt_output 0
				//input 1 mrt_output 1
			}
			

			pass render_scene //<-----This is what I need to add for it to work I can render anything here(any render queue), and this can be before the previous pass
			{
			}
		}
target_output
        {
			input none
			//We will dispatch the shadow texture rendering ourselves
			shadows off		
			pass clear
			{
				
			}
			pass render_scene
			{
				material_scheme DLMerge
				//These values are synchronized with the code
				first_render_queue 10
				last_render_queue  79	
			}
		
		}	
	}
}
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Noman »

The problem is with the way Ogre manages render queues and lists of objects that need to be rendered.
It tries to not scan the scene more times than it needs, and in this case it causes it to get to the points of rendering shadows with no objects waiting to be rendered, with the 'find visible objects flag' (essentially telling it to rescan the scene) off.

The following code in DeferredLightCP.h fixes this :

Code: Select all

//Update shadow texture
			if (dLight->getCastChadows())
			{
				SceneManager::RenderContext* context = sm->_pauseRendering();
				bool findVisible = sm->getFindVisibleObjects();
				sm->setFindVisibleObjects(true);
				sm->prepareShadowTextures(cam, mViewport, &ll);
				sm->setFindVisibleObjects(findVisible);
				sm->_resumeRendering(context);
...
This will cause the demos to do more CPU work than required (more scene traversals), but since optimizing the rendering pipeline for advanced rendering is NOT the purpose of your GSoC, you can continue with this fix for now.
Make sure to comment it (maybe even a link to this post), and when Ogre will be ready, we will take it out.

You should try to optimize it a bit more (perhaps only do this once per frame, and not once per light per frame), but this is probably the best direction for now.
When I applied this change, I got shadows in both deferred lighting and inferred lighting.

As a side note, I plan to attack this problem (rendering pipelines, code wise) soon...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Noman »

As for the schedule :
1) In the new schedule, you don't have any time for cleanups/documentation/unexpected bug fixes. Are you that confident?
2) I don't understand where the deliverables are for the 2nd half. Does each stage give something that you can showcase? How will you test/show the new features?
3) Comparing the new schedule to the old one - have you actually added new tasks or just split the old ones into finer pieces?

When you consider these points and perhaps revise your schedule a bit more, please update the official places (Wiki page for project + first post in this thread) with a mid-term progress report and the updated schedule, with deliverables. This will have a large impact on the midterm which is coming up in 2-3 days.
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

Will apply the shadow fix now(thanks a lot for that) and optimize the shaders a bit and this part of the project can be considered closed.
1) In the new schedule, you don't have any time for cleanups/documentation/unexpected bug fixes. Are you that confident?
I'll document the first part right now, and each other stage as I go along. I've set aside more time in the schedule for parts I expect to encounter bugs on.
2) I don't understand where the deliverables are for the 2nd half. Does each stage give something that you can showcase? How will you test/show the new features?
RSM is a nice deliverable in itself and I'll definitely showcase that. Same goes for spherical harmonics lighting. LPV is the end result, though I'm not 100% confident that It will work in real time at the end of the summer. It's a rather complex technique, and a lot of things can go wrong. In consequence, I intend to allocate more time to RSM and SH lighting(which are needed for LPV, but I didn't initially intend to expose them individually in the demo). I guess that answers point 3 as well.
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

I mainly finished rendering into a fat shadowmap. The packing method is different on openGL and directX(and different yet again between SM3 and SM4). On OpenGL I use the packing intrinsics, so that's all nice. On SM4 I use bitwise operations, so less nice but still manageable. The problem is SM3, where I had to restrict to storing just depth, normal and color, and using some modulo arithmetics( something like out = trunc(x*1000) + y). Will need to finish the implementation to test how these precision issues affect the end result(I'm expecting the normal and color to be somewhat error tolerant), and tweak things some more then. I'm currently working on generating the VPLs.
Due to some hardware issues, I'll get a delayed by a couple of days.
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

Sorry for the late update, but I've had some issues with packing the data into the RSM(most packing methods I've tried were dependent on either api or hardware, so I've had to resort to recomputing the world-space position when rendering the VPLs).
First, the eye candy:
Image
The VPL geometry. If you look carefully, you'll notice they aren't really spheres but hemispheres oriented along each light's normal. This avoids a VPL lighting the surface that generated it.
Image
A final image. This is sort of a first draft, as I've cut some corners(the surface that generated the VPL's albedo isn't taken into account, for example).

The major bottleneck at the moment is the number of draw calls needed for the lights(at least for my comp). I'd like to find some way of minimizing that(at the moment, one draw call is generated per VPL; that's 400 draw calls per light).
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Noman »

I don't really see the contribution of the VPL to the final image. Can you point out where the difference is most noticable?

As for your performance problems, have you thought about instancing techniques? There has been much work into adding them to Ogre.
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

The effect is most noticeable where the blue light hits the torus normally light by the white light only, and where the white light hits the torus hit by the yellow light only.
There still some tweaking to be done(there's a balance between clamping each VPLs contribution to avoid noise, the number of VPLs and attenuation), and that's what I'm currently working on(plus fixing some bugs), so the final image will definitely look better.
I've considered instancing, but I've seen a lot of talk about it on the forums, and I'm not really sure what's considered stable. Some small pointers would be greatly appreciated.
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Noman »

This is the main instancing thread on the forums. It looks like the instancing demo of the trunk contains all of the currently available techniques.

Your problem isn't 'classic' instancing as the instances are re-generated each frame. However, I think you can look at your VPL rendering problem as instancing like this :
1 - The basic 'mesh' you are rendering is a hemisphere.
2 - The parameters that change per instance are position, orientation, color, (anything else?).

You can create an 'instance buffer' containing all of the VPL instances as 2, and use the instancing subsystem to render them all in one batch. This seems classic for your usecase.
Note that you can use the 'basic' hardware instancing techniques, as your meshes don't have animations or skinning. So I believe it shouldn't be that hard. Even if the "instance buffer" needs to be recreated each frame (maybe also for each light, I don't know the algorithm well enough) it should be a major performance gain.

You can check out the instancing demo and/or the thread to figure out how to do this.

On a more general note, the end isn't far away. What is your plan until the end of the SoC?
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

The instancing problem is simpler than it sounds. Each VPL is rendered as a sphere with position (0,0,0). The actual position, and the deformation to a hemisphere are computed in the vertex shader(this avoids needing the RSM on the CPU). The only per instance parameter is the VPLs index, so texcoords can be computed. Hence the instance buffer can probably be created only once(or when quality settings are changed, but that's a different issue).
I definitely intend to finish RSM asap, and I don't think it should take more than 2-3 days. Spherical harmonic lighting is next on the list, and that should be pretty straight forward. The status of LPV is a bit uncertain, as I don't know if the remaining time will be enough to produce something usable. If I end up late with the first two parts, or if I encounter some major issue, I'll spend that time to polish the demo.
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

Apparently the instancing problem isn't as simple as it sounds. Here's my problem: I need the VPLs to be rendered immediately after the light's RSM is computed, because it becomes invalid afterwards, and copying it to another texture is both silly and crashes the framerate. I've tried using instanced entities, but they get rendered when the whole scene gets rendered, so no go. I'm currently trying to inject the instance batches directly, which solves the above problem. The issue with this is that each batch checks if it's instances are attached to a scene node, and if not, it considers them out of the scene.
The good news is that this does improve framerate _a lot_(I've tested with using instanced entities). It jumps from less than one fps to about 20(in the debug build).
And while I'm here, I also have a question I haven't been able to answer myself: I noticed each instance has it's own id, written in the first available texcoord. What's the range of that id? (0,1) or (0..num_instances)?
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
LBDude
Gnome
Posts: 389
Joined: Mon Jul 26, 2010 10:53 pm
x 22

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by LBDude »

Can't say I can help you in anyway but in the instancing thread they do talk about updating the instance batches by not iterating them with the scene manager:

http://www.ogre3d.org/forums/viewtopic. ... &start=150

It's the last 3 post which talks about this.

In my own game I have a render target which is the light buffer in my deferred shading pipeline, the instanced lights which I have have a specific visibility mask so when I manually update the light buffer's render target, only these light geometry gets rendered because of the light geometry's visibility masks on the view port of the light buffer render target.
My blog here.
Game twitter here
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Noman »

I would recommend taking instancing-related questions to the instancing thread. The people who know it best are there. You aren't limited to posting on this thread, you know :)
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

In my own game I have a render target which is the light buffer in my deferred shading pipeline, the instanced lights which I have have a specific visibility mask so when I manually update the light buffer's render target, only these light geometry gets rendered because of the light geometry's visibility masks on the view port of the light buffer render target.
My problem was a bit more involved. I need to render each deferred light, and immediately after that, render all the VPLs it generates.

I've managed to sort out the instancing issue, but I've ended up implementing another type of instanced batch. This seems like a reasonable thing, since I use instancing in a slightly different way(I get my world matrices from a texture that's not generated by the instancing batch itself). I'll post what I did on the instancing thread, and see if anyone has any objections/suggestions. While I did get a massive FPS improvement for instancing(I'm at ~15-16 FPS in debug, will run a release build and test that), I'm still pretty much CPU bound(my GPU is a 460M, and my CPU is a i7 740), with my GPU generally at 25-30% load. I'll try to find a more GPU limited machine and see what I get. To be honest I expected the algorithm to be more demanding on the GPU(at the moment I generate 400 VPLs for each shadow casting light; this means 2000 lights in the scene, which is quite a lot).

I still have one issue I neglected earlier. When using a shadow casting material, the parameters to it's shaders get fudged to force black light color and such. I need the spotlight parameters and the diffuse color of each shadow caster. From what I saw in the code, using a dedicated shadow material in a technique overrides this behavior, but I haven't managed to get things working yet.

Oh, and here's a shiny picture: (as you can see the algorithm doesn't account for occlusion)
Image
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Noman »

Cool! Really nice to see the eye candy coming in. This is seriously awesome.
The time for programming is nearly over. It would be a good time to declare a 'feature freeze' (not start anything really new). It is now the time to finish the performance improvements (try to get the instancing support properly done), clean up the code and make sure that your latest improvements didn't break your earlier work (the demo should be able to dynamically switch between all the techniques).
User avatar
Mind Calamity
Ogre Magi
Posts: 1255
Joined: Sat Dec 25, 2010 2:55 pm
Location: Macedonia
x 81

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by Mind Calamity »

andrei_radu wrote:
In my own game I have a render target which is the light buffer in my deferred shading pipeline, the instanced lights which I have have a specific visibility mask so when I manually update the light buffer's render target, only these light geometry gets rendered because of the light geometry's visibility masks on the view port of the light buffer render target.
My problem was a bit more involved. I need to render each deferred light, and immediately after that, render all the VPLs it generates.

I've managed to sort out the instancing issue, but I've ended up implementing another type of instanced batch. This seems like a reasonable thing, since I use instancing in a slightly different way(I get my world matrices from a texture that's not generated by the instancing batch itself). I'll post what I did on the instancing thread, and see if anyone has any objections/suggestions. While I did get a massive FPS improvement for instancing(I'm at ~15-16 FPS in debug, will run a release build and test that), I'm still pretty much CPU bound(my GPU is a 460M, and my CPU is a i7 740), with my GPU generally at 25-30% load. I'll try to find a more GPU limited machine and see what I get. To be honest I expected the algorithm to be more demanding on the GPU(at the moment I generate 400 VPLs for each shadow casting light; this means 2000 lights in the scene, which is quite a lot).

I still have one issue I neglected earlier. When using a shadow casting material, the parameters to it's shaders get fudged to force black light color and such. I need the spotlight parameters and the diffuse color of each shadow caster. From what I saw in the code, using a dedicated shadow material in a technique overrides this behavior, but I haven't managed to get things working yet.

Oh, and here's a shiny picture: (as you can see the algorithm doesn't account for occlusion)
Image

This is really awesome, but I think you should update the repository when you have time, since the sample uploaded there is good, but those screenshots are much better :)
BitBucket username changed to iboshkov (from MindCalamity)
Do you need help? What have you tried?
- xavier
---------------------
HkOgre - a Havok Integration for OGRE | Simple SSAO | My Blog | My YouTube | My DeviantArt
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

I've pushed the changes to Hg. At the moment RSMs work with all three techniques both under directX and OpenGL. The results aren't exactly consistent(because deferred lighting accumulates lights differently), so different parameters for attenuation should be used.
Performance wise, the results are interesting. I'm running unoptimized shaders for the moment so this isn't entirely relevant, but while looking directly at the lights(so that most VPLs are in the scene), deferred shading runs at 40-50 fps, while deferred and inferred lighting run at 80-90 fps. While looking away from the lights, at the rest of the scene, the results are reversed. I'll dig more into this after I finish optimizing the shaders, but I assume deferred shading is bandwith limited, while DL is CPU bound.
My todo-s for the rest of the week are optimizing the shaders(I can squeeze more by modifying each VPLs radius based on it's reflected flux), adding a slider that allows changing the number of VPLs, and general clean-up and documentation.
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
andrei_radu
Google Summer of Code Student
Google Summer of Code Student
Posts: 55
Joined: Fri Mar 18, 2011 8:37 pm
x 8

Re: [GSoC 2011 - Accepted] Modern Illumination Techniques

Post by andrei_radu »

The demo is basically ready. I still need to cleanup the code, improve the shaders and document everything, but from a user's point of view, it's pretty much done.
I still have some issues:
The VPLs aren't always updated when the technique or number of VPLs changes, until the camera moves. Probably from the way I handle the whole instancing thing.
I have some banding artifacts when using deferred lighting.

The whole state change part of the demo is somewhat of a mess. For example, when changing the number of VPLs, the whole instance manager is deleted and a new one created. The reason for this is that I can't just remove entities from the instance manager, since I manually render each batch. Still thinking of ways of cleaning it up.

There are a couple of things I'd like to see improved in Ogre:
More flexibility in the shadow map system; using MRT shadowmaps and being able to set parameters to shadow materials would be awesome
Being able to render into a 3D texture - this would be important for techniques like Light Propagation Volumes

I'd like to add a couple of things to the demo(after GSoC): importance sampling would be really nice to have, would probably decrease the number of VPLs needed by a rather large amount. Would need to be able to set parameters to shadow materials(need spotlight parameters so falloff can be encoded in the RSM, rather than at VPL generation). Specular indirect illumination would also be awesome, but definitely requires importance sampling. I'd also like to modify the scene a bit, since it doesn't really showcase technique very well.

Sorry for the sketchy post,but I wanted to have this things written down somewhere, and this seemed like the logical place.
My Google summer of code 2011 topic: Modern Illumination Techniques
My Google summer of code thread
My Google summer of code wiki page
Post Reply