[GSoC 2012] Off-Screen Particles project - continuation

Threads related to Google Summer of Code
Fritznorm
Kobold
Posts: 26
Joined: Mon Aug 02, 2010 5:36 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Fritznorm » Thu Aug 23, 2012 10:37 pm

Karol Badowski 1989 wrote:In debug.

(emerging from lurking to say...) probably best that you check performance-related matters in a release build so that the compiler has a chance to do useful optimisations. You won't get as much useful performance info from a debug build, imo.
0 x

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Thu Aug 23, 2012 10:47 pm

Ow, good to know. I guess that it is possible that some of that delays between passes come from debugger.
Thanks. I'll try that ;).
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 9:14 am

Well, that is SOMETHING !!!
In Release mode, I finally see the difference.


EDIT:


I've cut some renderings to off-screen targets in places where they could have been done directly to screen. I've also nocfigured everything so that it is still dislpayed properly.

I disabled depth test for now (to test both: simple and offscreen rendering time),
however in next test I'll calculate depth anyway to simmulate time consumed by this pass.

In tested compositor it is expected that 1x1 downsample (lack of downsample) should work slower than standard rendering because of rendering particles first to offscreen and then offscreen to screen.

It is also expected that real downsample shoudl increase performance.


Results for current compositor

[render solids to output, render particles to downsampled off-screen target, alpha-blenf off-screen target to background], observations over few minutes of oscilating FPS (scene is dynamic):
  • -standard rendering: from 24 FPS to 32 FPS
    -offscreen without downsample ([2^0]x[2^0]): from 22 FPS to 30 FPS
    -offscreen with 2x2 downsample ([2^1]x[2^1]): from 42 FPS to 59 FPS
    -offscreen with 4x4 downsample ([2^2]x[2^2]): from 56 FPS to 59 FPS (most time 59 - in next samples too)
    -offscreen with 8x8 downsample ([2^3]x[2^3]): from 58 FPS to 59 FPS
    -offscreen with 16x16 downsample ([2^4]x[2^4]): from 56 FPS to 59 FPS (speed jumps below 59 FPS more often *)
Results are as expected *
(* - except last one - perhaps rendering to output runs slower once every animation full cycle in some specific configuration of particles in space - or just many objects rendered to one pixel in off-screen mode when there is a lot of them in little space distance).

Tests were run on battery (it does matter - cose graphic card in my laptop has some different energy plans).
Next one will be with depth testing, compositor configured only for off-screen.
I'll run one separate test for simple rendering - cose it matters for computer other power plan I'll be using.


EDIT2:


I've ulpoaded current tests configuration to the repository.


EDIT3:


I have my power cord plugged in :].

Results [for the same compositor and for standard rendering]:

In almost every mode I have 59 FPS nearly all the time. I guess that this is just whole application + vertices transformations and rendering runs just fast as blink of an eye :D
I'll wait until my battery is full again for next tests ;)
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

User avatar
saejox
Goblin
Posts: 260
Joined: Tue Oct 25, 2011 1:07 am

Re: [GSoC 2012] Off-Screen Particles project

Post by saejox » Fri Aug 24, 2012 12:04 pm

why are stuck at 59, are you using vsync?
second, you should test at highest resolution possible. i fear that performance increase would be negligible in 720p or 1080p.
0 x
Nimet - Advanced Ogre3D Mesh/dotScene Viewer
asPEEK - Remote Angelscript debugger with html interface
ogreHTML - HTML5 user interfaces in Ogre

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 12:16 pm

saejox wrote:why are stuck at 59, are you using vsync?
second, you should test at highest resolution possible. i fear that performance increase would be negligible in 720p or 1080p.
I've just checked the configuration.
Yes, I had Vsync switched on - I'll turn that off.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 12:30 pm

That was great advice for tests!
Now for previous configuration, (with plugged cable power plan).

Results

[render solids to output, render particles to downsampled off-screen target, alpha-blenf off-screen target to background], observations over few minutes of oscilating FPS (scene is dynamic):
  • -standard rendering: from 59 FPS to 90 FPS
    -offscreen without downsample ([2^0]x[2^0]): from 55 FPS to 80 FPS
    -offscreen with 2x2 downsample ([2^1]x[2^1]): from 111 FPS to 156 FPS
    -offscreen with 4x4 downsample ([2^2]x[2^2]): from 213 FPS to 258 FPS (It will not get higher than 258)
    -offscreen with 8x8 downsample ([2^3]x[2^3]): from 254 FPS to 258 FPS
    -offscreen with 16x16 downsample ([2^4]x[2^4]): from 250 FPS to 257 FPS (speed jumps below 257 FPS more often)
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel

Re: [GSoC 2012] Off-Screen Particles project

Post by Assaf Raman » Fri Aug 24, 2012 12:37 pm

Turn on Anti aliasing to the max and re test.
0 x
Watch out for my OGRE related tweets here.

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 12:57 pm

I'll try that too :D, thanks.
Please tell me the entire best configuration of sample browser, so I'll just adjust it for tests with depth pass turned on ;).

EDIT:

(I do not see Anti-aliasing in configuration of SampleBrowser, so i guess it is about configuration of materials...
I thought I've already switched from trilinear antialiasing to none, but I'll double check that).

Previous tests were with OpenGL
I run tests in DX9 now (highest amount of colours, highest resolution... etc. and no V-sync, RTT mode: FBO).

Results [FPS min - FPS max]:

Standard rendering: 37-69
Offscreen without downsampling: 32-60
Offscreen 2x2 dowsnampling: 73-110
Offscreen 4x4 downsampling: 141-186
Offscreen 8x8 dowsnampling: 209-271
Offscreen 16x16 dowsnampling: 261-292
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 2:22 pm

I had some error notification that texture could not be found...
In attribute

Code: Select all

content_type compositor OSP_AllInOne depthTexture// depthDownsampledTexture
It turns out that script parser does not treat "//" as comment here unles I put one space before it :D.
I'm glad i finally found that.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel

Re: [GSoC 2012] Off-Screen Particles project

Post by Assaf Raman » Fri Aug 24, 2012 2:54 pm

FSAA = Anti aliasing
0 x
Watch out for my OGRE related tweets here.

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 3:39 pm

Now I've tested compositor:

render depth to off-screen target
render offscreen depth to screen output
render particles with depth test using simple (not max of depth) depth test to off screen downsampled target
render offscreen particles dowsnampled target to screen output.

Image

Results (now only off-screen) [min FPS - max FPS]:
1x1: 13-21
2x2: 26-37
4x4: 42-59
8x8: 83-108
16x16: 119-137


EDIT:


I did not mention that it also calculates downsampled depth texture but uses simple one (I forgot to switch depth downsampling off).
Last edited by Karol Badowski 1989 on Fri Aug 24, 2012 3:59 pm, edited 2 times in total.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 3:48 pm

As we are in the optimalisations...

I'll ask you for advice on some matrix transformation (I have decided that I want to eliminate dividing operation) and reduce the vertex shader (while rendering particles we want to calculate coordinates of earlier prepared depth texture)
I think it will go faster If the initial parameters are transformed to situation from render_quad - then instead of dividing we use "sign()" function. I mentioned that on previous page...

For now I have put some additional operations to pixel shader to increase the time of execution (genetrating colour) - do not look at that part ;). I mean only calculating coordinates of depth texture.
If it could not be done without dividing (like it is now) - is it better if I transfer some operations from vetex to pixel shader?

Code: Select all

void OSP_DepthTestForParticles_vp_OpenGL(
        float4 inputPosition      : POSITION,
		float2 texCoord0          : TEXCOORD0,
        out float4 outputPosition : POSITION,
		out float2 outputTexCoord : TEXCOORD0,
        out float outputDepth     : TEXCOORD1,
		out float2 screenPosition : TEXCOORD2,

        uniform float4x4 worldViewProjection,
		uniform float4 depthRange
        )
{
        outputPosition = mul(worldViewProjection, inputPosition);
		outputTexCoord = texCoord0;
		outputDepth = (outputPosition.z - depthRange.x) * depthRange.w;
		
		screenPosition = outputPosition.xy/outputPosition.w;
		screenPosition = (float2(screenPosition.x, screenPosition.y) + 1.0f) * 0.5f;
}


float4 OSP_DepthTestForParticles_fp(
		float2 texCoord          : TEXCOORD0,
        float inputDepth        : TEXCOORD1,
		float2 screenPosition    : TEXCOORD2,
		
		uniform sampler valueTexture           : register(s0),
		uniform sampler backgroundDepthTexture : register(s1)
		) : COLOR
{
		
		float backgroundDepth = tex2D(backgroundDepthTexture, screenPosition.xy).x;

		if(inputDepth.x > backgroundDepth){
			discard;
		}
		else{
		
		  /*
			Example colour calculation.
			Should be replaced with original colour WITH ALL MODIFIERS.
			Here I added own modifiers based on XY position and DEPTH of particle.
		  */
		  
			float4 outputColor = tex2D(valueTexture, texCoord);
			outputColor.rgb = ( outputColor.rgb * float3(screenPosition.x,screenPosition.y,1) ) * (1.90-inputDepth*1) *0.5; 
			outputColor.a *= 0.5 * (1.5+inputDepth*0.5)*0.5;
			return outputColor;
		}
}
I'd like to use trick mentioned on previous page,
that is solving two matters: scaling and universal transforming to screen coordinates.

Code: Select all

inputPosition.xy = sign(inputPosition.xy);
This is how it is done in solution that I like (useful only in render_quad (that has some of matrices unified, unlike render_scene).

Code: Select all

void StdQuad_vp
(
    in float4 inPos : POSITION,

    out float4 pos : POSITION,
    out float2 uv0 : TEXCOORD0,

    uniform float4x4 worldViewProj
)
{
    // Use standardise transform, so work accord with render system specific (RS depth, requires texture flipping, etc)
    pos = mul(worldViewProj, inPos);

    // The input positions adjusted by texel offsets, so clean up inaccuracies
    inPos.xy = sign(inPos.xy);

    // Convert to image-space
    uv0 = (float2(inPos.x, -inPos.y) + 1.0f) * 0.5f;
}
My question is whether shoud I use transposed / inverted matrices to transform it to the described situation (render_quad-like, instead of render_scene-like).
I've tried to use this trick with simple matrices in different places between them (but in wrong place between these transformations or with using simple instead of transposed matrix... well this is the all mater of my question ;) ). It is in the commented part.

Code: Select all

void OSP_DepthTestForParticles_vp_DirectX(
        float4 inputPosition      : POSITION,
		float2 texCoord0          : TEXCOORD0,
        out float4 outputPosition : POSITION,
		out float2 outputTexCoord : TEXCOORD0,
        out float outputDepth     : TEXCOORD1,
		out float2 screenPosition : TEXCOORD2,

	  /*	
        //uniform float4x4 world,
        //uniform float4x4 view,
        //uniform float4x4 projection,
	  */
	  
        uniform float4x4 worldViewProjection,
		uniform float4 depthRange
        )
{
        outputPosition = mul(worldViewProjection, inputPosition);
		outputTexCoord = texCoord0;
		outputDepth = (outputPosition.z - depthRange.x) * depthRange.w;
		
	  /*	
		//inputPosition = mul(view, inputPosition);
		//inputPosition = mul(projection, inputPosition);
		//inputPosition.xy = sign(inputPosition.xy);
		//inputPosition = mul(world, inputPosition); 

                 //When I find right order of usinf sign() and matrix transformations, I'll use that solution without dividing:

		//screenPosition = inputPosition.xy;
		//screenPosition = (float2(inputPosition.x, -inputPosition.y) + 1.0f) * 0.5f;
	  */
		
		screenPosition = outputPosition.xy/outputPosition.w;
		screenPosition = (float2(screenPosition.x, -screenPosition.y) + 1.0f) * 0.5f;
}
I am sure 100% that someone did simmilar optimalisation already like 600 times ;) also when he (or she) wanted to get rid of dividing too, so I decided to ask ;).
Last edited by Karol Badowski 1989 on Sat Aug 25, 2012 12:09 am, edited 1 time in total.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 4:38 pm

Repository update.

I've reduced a little bit the clear passes, and I've commented pass that does maxofdepth (previously i forgot to). It works faster now, but of course not as fast as version without depth writing and reading.
I've swapped thumbnail of application to more up-to date. New version in repository (do not switch to non-off-screen mode).

I moved all alternative passes to one place to clear a repository a bit.

I think it is enough tests for afternoon (I'll continue efficiency tests in the evening), because I have to fill the GSoC survey now...

After that I'll divide original materials to two techniques (every of them will be tagged as different scheme - so swaping of the materials will be automatic). That way I'll be able to test efficiency of my own mixed-technique rendering and restore functionality to "mode-switch" checkbox for the time of tests.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 7:03 pm

I've sent the GSoC Survey so I am back to optimalisations :).

I'll test now how Stencil Buffer changes when I render my sobel filter texture - I'd like to finally see the output of mixed resolution.

I'll render that texture with no colour, but set "discard" operation everywhere the alpha value is lower than 1.
Am I right that (if edges on Sobel texture have value 1), then next rendering will be executed only on edges position?
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel

Re: [GSoC 2012] Off-Screen Particles project

Post by Assaf Raman » Fri Aug 24, 2012 7:07 pm

I am not sure what you mean, discard in the shader - means that the pixel will not be drowned
0 x
Watch out for my OGRE related tweets here.

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 7:12 pm

I thought it also influences stencil buffer.
It is not that obvious (things I read about stencil in ogre tutorial are confusing - I've loaded these pages to my browser tabs many weeks ago and have been checking them from time to time).

I clear entire stencil buffer in clear section (everything becomes pink just like in NVidia article - because they also told about "discard" operation during describing stenciling, thought it modifies stencil buffer and causes that nothing will be rendered on that pixel).

I know from other sources I've red that stencil buffer is connected with depth buffer in some rendering systems (when I want my particles to be rendered on every depth, it is not enough to clear depth buffer - I also clear the stencil buffer to make it work in both Dx9 and OpenGL - otherwise even if i set depth check off, the stencil buffer discards rendering of particles that are on depth higher than last rendered solid object);

That is still confusing to me how exactly do I set stencil value from level of pixel shader (if not discard operation / setting depth).
Stencil is modified when i render solid objects (with full opacity). Some pixels on rendered quads (that contain rendered polygons) are outside of polygons and they do not modify stencil buffer.


Tips I've red several times in las two weeks are ones from here: http://www.ogre3d.org/docs/manual/manua ... or_stencil
I/ve been figuring out out how to use them (they mainly say what to do with pizels where quads are rendered) - but much more I was wondering how apply there a texture of stencil.


From link above it seems also that stencil section controls mask set for viewports and that it is connected with depth test.

Idea of stencil buffer is cool, because: you do not have to substitute pixel shader of every material in last rendering of mixed-resolution.
You could just modify the stencil buffer for each pixel and then execute rendering of all objects with unchanged materials (only setting Stencil parameters in compositor script to discard some pixels with different stencil value).

I thought that when I render this texture as a quad (on depth 0, just in front of the camera viewport), than in every pixel that i do not "discard", the depth value is changed. Based on depth I could next modify stencil operation (what to do when standard depth test fails - attribute "depth_fail_op").
Last edited by Karol Badowski 1989 on Sat Aug 25, 2012 12:08 am, edited 8 times in total.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel

Re: [GSoC 2012] Off-Screen Particles project

Post by Assaf Raman » Fri Aug 24, 2012 7:20 pm

It will also not change the stencil.
0 x
Watch out for my OGRE related tweets here.

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 9:06 pm

The stencil buffer is used to efficiently mask areas of the frame buffer. When the low-resolution, off-screen particles are composed back into the main frame buffer, we simultaneously write to the stencil buffer. The stencil value cannot explicitly be set by the pixel shader. However, stencil write can be enabled for all pixels, and then the pixel shader can invoke the discard keyword to abort further output. This prevents the stencil write for that pixel, and the pixel shader effectively controls the stencil value, creating a mask. See Listing 23-4.
I still understand it the same way as before:
Some specific configuration of stencil has to be set in compositor (especially attribute check = on) (and some operation executed on rendering).
In fragment shader we use "discard" when value of Sobel filter is appropriate to use that command.
In these discarded pixels value of stencil buffer is not changed.
In all rendered pixels value of stencil buffer mask is changed according to rules set in compositor.
In next rendering to the same target, only these pixels are rendered, where stencil value == 0;


Earlier solution for mixed-resolution is weaker (one without stencil filter, where bot resolutions compare value of sobel filter texture).
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Fri Aug 24, 2012 11:32 pm

It is end of evaluaton time.

I'm still going to improve quality of output application and add optimalisations ;).

I'm ashamed of my big communication problem that disappointed you so much...
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Sat Aug 25, 2012 2:55 am

I've just spent some time preparing input and to show mask for stenciling and efficiency tests. I'll start with description and then show tests results. Praparation of needed sources is also downsampled, so entire solution is scalable (highr proportion of all passses is done on downsampled targets).

Here is result of displaying only offscreen output:
Image
And this is Sobel filter pesenting only alpha channel (for visibility, a in graphical output set to 1; Inverted value is kept in channel b of output.)
Image
We can see that we got rid of edges that were caused by colour difference (considering only alpha detects only needed places where alpha changed rapidly.
This is very low percentage of picture to display in full resolution - that is good.

In low or none downsample (like 2x2 only intersections with (and being hidden behind) solid onjects cause sharp change of alpha.
(notice that there are no particles behind the square grass-plane).
[imghttp://www.bmm.yoyo.pl/everyday_screenshots/miniscreen72.JPG][/img]
In picture above we can't see edges between fumes from penguin jet edge and their neighbouring clear space (I've prepared for them extramally smooth fade of alpha).
However, there are a lot of particles of red-blue magic smoke in one place. we see slight edge in place of their biggest density but sobel delta is lower than 1, nearly invisible.
(they start in the same position, so their edges alpha-blend eachother in offscreen target and make more oblique - edges are smooth, but not as much as in fumes from penguin jet).

In higher downsample level, I've provided that pixel size parameter is passed. So to the matrix we always receive neighbouring pixels (not sample from constant proportion). We can understand that in higher downsample, smooth edges becomee less smooth, they generalise higher and more distant areas, the higher is downsample level.
Image
We can see that some particles are this time behind the plane - alsostencil edge pixels are bigger (as distance between pixel middles is higher, the higher is also difference of alpha on edges).

These are links to more, intermediate downsamples.
Image Image

And this one below is 16x16 pixels downsample. let's see in which pixels there is high difference of alpha in range of 3x3 matrix.
Image
Notice, that I use not simple sobel filter, but one adjusted to detect x, y, mirroredX, mirroredY edges at the sime time (will detect more potential edges).


Descritpion of activated passes in my compositor:
[Edges of alpha channel from off-screen particles only, are printed on background]
-print colour solids to creen after sclearing pass
-calculate depth to offscreen target
-alpha-blend particles to offscreen target
-detect edges and save them to offscreen Sobel target.
alpha blend them to output for debug.



That was nice introduction to following efficiency test results

Observations over few minutes of oscilating FPS (scene is dynamic):
  • -offscreen without downsample ([2^0]x[2^0]): from 16 FPS to 29 FPS
    -offscreen with 2x2 downsample ([2^1]x[2^1]): from 31 FPS to 51 FPS
    -offscreen with 4x4 downsample ([2^2]x[2^2]): from 67 FPS to 111 FPS
    -offscreen with 8x8 downsample ([2^3]x[2^3]): from 103 FPS to 135 FPS
    -offscreen with 16x16 downsample ([2^4]x[2^4]): from 136 FPS to 152 FPS
We see that solution is scalable.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Sat Aug 25, 2012 8:15 am

I have a particle texture rendering only on the edges, using Discard operation.
At the moment i'm switching it to use stencil buffer.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Sat Aug 25, 2012 8:47 am

Transformations of the mix-resolution upgrade to the project project through the last hours of night:

Rendering use sobel texture to modify rendering (show only this part of texture where are sharp edges).
Image

Display colour rendering and concatenation of stencil and aprticles (their part out of stencil).
Image

Now stenciling contoled not by alpha influence, but using Discard operation and new shader.
Image

This one restored backgroumd solids rendering, we can see pixels of stencil that will be rendered again on full resolution (we can notice not only sharp edge to eliminate on objects intersection, but also on edge of dense particles group with high enough aplha to spot increase of alpha change among neighbouring pixels od downsampled offscreen).
Image
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Sat Aug 25, 2012 8:57 am

Uploaded current stenciling version - compositor configuration zipped.

Now I'll execute new rendering in previously discarded pixels.
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel

Re: [GSoC 2012] Off-Screen Particles project

Post by Assaf Raman » Sat Aug 25, 2012 9:03 am

Sadly. The student failed.
[edit]
After thinking more about it (and from other undisclosed reasons) I decided to not describe why he failed in detail for now.
If you want to understand why he failed - read the whole thread and see the dynamics of this project.
[\edit]
0 x
Watch out for my OGRE related tweets here.

Karol Badowski 1989
Google Summer of Code Student
Google Summer of Code Student
Posts: 185
Joined: Fri Apr 06, 2012 3:04 pm

Re: [GSoC 2012] Off-Screen Particles project

Post by Karol Badowski 1989 » Sun Aug 26, 2012 4:06 am

I fell asleep for a day, now I'll update slowly the changes to final version.

Materials of particles are swapped now.
This way in mixed-resolution, original material with its original colour modifier is displayed.
Also change of mode is aviable that way again (between offsceen and standard compositor).

I had very little mistake that kept me from achieving that. Gladly I solved it.
While declaring 2 different techniques for the same material, I defined previously "scheme" attribute in material technique with

Code: Select all

material_scheme STANDARD //PARTICLE_ALPHABLEND_SCHEME
command instead of just

Code: Select all

scheme STANDARD //PARTICLE_ALPHABLEND_SCHEME
(mixed commands from compositor script). Little bug :). I'm glad that now it works.

I have a listeners for materials, but dynamic swap is done anyway automaticaly after the scheme are named (OGRE automaticaly chooses technique tagged with scheme name this way).

Thanks to setting original technique [one with scheme "STANDARD"] to default (used in default compositor) and offscreen version [one with scheme "PARTICLE_ALPHABLEND_SCHEME"] as a second one - for pass when rendering is done to the offscreen target, the swap of compositors is enabled back again.

Also for spotting areas of stenciled renering in mixed resolution we will clearly see difference of material between one rendered in downsampled and one from full-resolution mode (they have different colour and opacity).

Image

Perhaps I should switch modifiers of opacity, so it would look coooler in presentation (ill do that and switch the linear filtering on.)
0 x
Google Summer of Code 2012 Student
Topic: "Implementation of Off-Screen Particles"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman

Post Reply