[GSoC 2012] Off-Screen Particles project - continuation

[Karol Badowski 1989]

UPDATE: Finally found corect solution. (according to my calculations, there was a mistake in article and third paramer should be "one" instead of "zero").

As I thought, It is probably impossible to combine additive and blended particles in one off-screen target using only one pixel buffer, cose thay use different method of background modification (it cannot be accumulated only in buffer - cose strenght of additive effects impact on off-screen target depends also on the background).
However they cannot be rendered separately, because they have to be sorted.

Using both blended and additive particles is common in games. We have not tried this, but we believe that it would not be possible to combine both in a single off-screen buffer. Supporting both might require a separate off-screen pass for each.

For example fire would make particles brigter (maybe this impact would be hidden in dense mist of particles, but impact on surroundings would be lost). However it is a nice quiz, I think it can be solved with some masque of "influence on background" and "infuence on background brightness modifier" (based on transparency) that will be modified in real-time.

After putting depth test shader to particles material, I'll put it in material scheme listener, and start tidying up code.

[Karol Badowski 1989]

Just a suggestion, make smaller commits, otherwise it will be extremely hard to review and merge them. The rough rule of thumb is that if you can't describe what the commit does in just 72 characters, split it into more commits. Each commit should build preferrably.

I am talking about this specifically:
https://bitbucket.org/KarolBadowski/ogr ... 0ad662ad02

Uploading ZIPs with dates into a version control system also makes little sense.

I'll remember that. (older files are stored there anyway, you are right).
Sorry for such big update, it shoulduld have been divided in time.

After tidying-up code (moving definitions to headers, clearing no longer needed code for displaying viewports) of application part, I'll still need to move sources to analogic structure like in case of samples viewed in sample browser. I haven't transfered it before, but i believe I saw tutorial somewhere...

I had some decrease of framerate. After pencil-down I'll move some passes to one (already partially done and commented), so vertex shaders for the same source could be execulted once instead of several times.

[Assaf Raman]

I will be happy if the following will be done this week:
0. Fill this form and send it to the e-mail at the bottom.
1. Clean all the code you wrote, turn it into a new OGRE sample (like the rest of the samples in the sample browser).
2 . finish the sample to include the following controls - an on\off button to the effect, a "off screen texture size" combo, connect and test that it works.
3. Make sure the sample works on both DirectX and OpenGL render systems.
4. Make sure it works correctly with cmake - meaning adding the sample name and such to the right place.
5. Create a new fork of the trunk (as your current one is one big mess), and commit only that sample and relevant resource. Make sure to use the hgext.win32text ext with hg - so you will have the right EOL when committing.

This is the minimal result I expect.

@kulik - See 5.

[Karol Badowski 1989]

I am cleaning code at the moment and moving used resources to one place (materials that were changed from their original version - renamed and used with new names and made sure that they work fine).
I've modified all used particle materials (as it was mentioned in article, additive effects and blended ones will argue with eachother about transparency).


At this very moment i am removing all parts that are not used anymore - next I'll move the thinner code to sample execuded in SampleBrowser (and use buttons for trigerring compositor) / create new sample when this one works and sompiles in VS (I should finish that part a bit after midnight) and proceed to swapping downsample size from constant to variable;

Then I'll try to check if it works also with CMake. Till official pencil-down tomorrow ( 12:00 Pacific time) I think should manage to complete other tasks from the list and go back to adding the last material scheme logic to listener for swapping shader used by particles.

[Karol Badowski 1989]

I took half an hour brear in cleaning code for a bit of testing.

My particle systems produce about up to 800 particles (part of them is invisible, behind some objects).

As the amount of particles stabilizes, I get below 40 FPS.
In off-screen particles before depth testing, time of rendering is lower (mainly because of multiple renderings to various textures). Current compositor is rather flexible thing so it is easy to just change source textures and to comment/uncomment some renderings.

With all passes enabled, It gets even twice lower FPS, with part of them commented (and just concatenating for example depth texture and particles texture with alpha blend between them - it is aroun 30 FPS on my computer.

It seems that much bigger amount of particles is needed to recompensate multiple passes - I'll rather use this version where depth is rendered to aplha channel.

I can also merge last two passes (rigt now pass that prings output to screen chooses one of off-screen textures for sake of easy testing) - I will make some optimalisations and then tests with much higher amount of particles.


Right now I am back to making code prettier (at the momen describing methods in header). Swap between off-screen compositor and default rendering is done for now from keybord - in about an hour i'll start transfering code to SamleBrowser version.

[Karol Badowski 1989]

Swiching of the compositor is ready, now I am doing the switching of downsample (for now with keyboard key).

Due to long execution od maximumOfDepth when too many pixels are searched - always 4 on 4 field of pixels will be checked, however their arrangement will be different.

[Karol Badowski 1989]

At the moment i am finishing methods, getters, setters etc for flagues used to control compositor. I am accessing compositor from compositor manager, getting it by name - to modify properties of textures.
(their properties are used in shaders cose their inverse_texture_size is used. Probably after change of
textureDefinition WidthFactor and HeightFactor. I hope it will work just fine.

I will make update to old repository this one more time when I finish this step cose it is not transformed to preferred file hierarchy yet - but next update will be in new fork, probably tonight (if I fall asleep, than at morning).

[Karol Badowski 1989]

I have function that access compositor with specified name and changes size of textures, however it turned out that changes were not appplied to compositor instance.

I have to reference CompositorInstance instead of CompositorPtr and do this through listener.

EDIT:
right now i have defined

Code: Select all

Ogre::CompositorInstance *mCompositorInstance;

When compositor is attached to viewport, this instance gets value:

Code: Select all

void SetUpCompositors()
{

	MaterialSchemeListener *schemeListener = new MaterialSchemeListener();
	Ogre::MaterialManager::getSingleton().addListener(schemeListener);
	mCompositorInstance = Ogre::CompositorManager::getSingleton().addCompositor(mViewport, "OSP_AllInOne");
    Ogre::CompositorManager::getSingleton().setCompositorEnabled(mViewport, "OSP_AllInOne", true);

}

I use this method and try to somehow reload compositor, but it seems to have uncomplete effect:

Code: Select all

void OffScreenParticles::setDownsampleLevel(int level){
	Ogre::CompositionTechnique::TextureDefinitionIterator defIter = mCompositorInstance->getTechnique()->getTextureDefinitionIterator();
    while ( defIter.hasMoreElements() )
    {
        Ogre::CompositionTechnique::TextureDefinition * def = defIter.getNext();

        if ( def->name == "particlesDownsampledTexture")
        {
            def->widthFactor = (float)(1.0f / level);
			def->heightFactor = (float)(1.0f / level);
        }
    }
	Ogre::CompositorManager::getSingleton().getCompositorChain(mWindow->getViewport(0))->_compile();//_markDirty();//_markDirty();
	this->downsampleLevel = level;
}

After execution of this method, a I debug it - values in mCompositorInstance are changed (Texture definitions in technique of this compositor, have different widthFactor and heightFactor), however i do not see changes on viewport. It seems that compositor is not recompiled.
I'd like to ask for advice on some working example of compositor listener that submits changes of compositor redefinition.

Right now i am moving my code to samplebrowser version.

EDIT2:
I have found solution for recompiling compositor after redefinition - it works finally . (I just remove it from viewport and add it again - it is compiled with new parameters)

[Karol Badowski 1989]

Temporarily I've uploaded change to old repoitory.
reduced to 3 header and cpp files:

BaseApplication.h /.cpp
MaterialSchemeListener.h /.cpp
OffscreenParticles.h /.cpp

Materials folder "OffScreenParticlesMedia" can be added to resources
(destination folder has to be added in file resources.cfg for example with line: "FileSystem=../../media/OffScreenParticlesMedia") It contains:
-4 textures
-4 Files OSP.* with definitions of: compositrs / materials / programs / shaders
-2 files (particle systems and their materials) - alpha blended materials are adjusted for correct saving to offscreen target

[Karol Badowski 1989]

At the moment I am during the conversion (Transferring logic of the application to a stucture based on "Sample_BezierPatch" project) -I can see changes that are being applied.

EDIT:
Update: now sample browser application does not replace another sample - but is executed and compiled as new one.
(I'm still transfering my code to this sample).

EDIT2:
I've added new project to all files that are made for CMAKE also put everything in the analogic files structure. I do not know which file generates paths to media files (during creation of resources.cfg and resources_d.cfg).
I'll update revision with this stucture and go back to putting everything in created project.

[Karol Badowski 1989]

All objects and materials have been transported to scene (I found some textures that might have been missing - I'm applying them now).

There is one difference between original application (when I was transforming example "Sample_BezierPatch" I had problem with applying the light to the scene - I am searching for the difference).

EDIT: application conversion is complete, so now I'll try to solve this detail

[Karol Badowski 1989]

Current fork is in:
https://bitbucket.org/KarolBadowski/ogr ... tidyupcode
It already supports the compositor and MaterialSchemeListener.

Now I am transferring the code of animation.

It turns out that I need to free resources so application exit would work properly.


EDIT:
All application has been completely transferred to new version, I'm just uploading it to the new fork of repository.

[Karol Badowski 1989]

Conversion is complete, this is how it looks like at the moment:




Right now I'll take few minutes break for dinner and start preparing documents.

Since last printscreens update there was 20 of them (I wouldn't like to spam with too big amount of them).
They all fit to pattern ending with a number from 26 up to 45 (last one was number 25):
example: http://www.bmm.yoyo.pl/everyday_screens ... reen42.JPG


EDIT: currently activated combination of filters shows mentioned aberrations when additive and blended textures are rendered to one off-screen target, background texture concatenated with off-screen texture shows sobel filter (adjusted to downsample level) over the downsampled (max of depth) depth map.

In few hours it is pencil-down. I'll start filling documents and writing description page with presentation. Then I'll get to putting last missing link to the compositor (second scheme-listener that adjust particle system material to the style of 2 prepared example templates (I mean different blending tyle for colour and alpha channel) - that will be analogic to previous scheme listener - however will include not only shader, but also this modification to the material).

[PhilipLB]

I'm not familiar with the Off-Screen particles paper. So this question might sound dumb.
What's missing to a complete implementation?

[Karol Badowski 1989]

I'm not familiar with the Off-Screen particles paper. So this question might sound dumb.
What's missing to a complete implementation?

To complete implementation of compositor logic i need 2 things:

1) - One very simple pass in compositor (it will be modification of shader), that uses already prepared downsampled depth texture and checks whether to render particles here. It is very simple, but I have recently finished fixing bugs in previous passes (they are fixed and do work in DirectX too now) so I haven't added it yet. It is just a depth test, but uses already prepared downsampled texture of depth (instead of depth buffer). I should finish that part within few hours.

2) -One pass that is not necessary, but is extension nearly completed - uses prepared sobel filter to decide whether to render everything again in this pixel without the downsample. That is improvement because sometimes maxofdpth downsample is not enough at high-contrast scenes in motion.
That is called "stenciling" - point is to use this method (so if once rendering is discarded over a pixel - it does not continue). Shader for creating map used in stenciling is ready and works in both OpenGL and DX9 (this is Sobel filter - I will use only alpha channel of that mask).
I should manage to finish this also quickly now, cose everything that was needed to apply this is working (shader is described in article).

For current presentation I used input texture of downsampled depth to show that itdetects edges appropriately to level of downsample (it is concatenation of X, Y, mirroredX, mirroredY Sobel filters that takes more distant pixels for matrix operation if downsample is higher).

[Assaf Raman]

According to Google - Mon, August 20, 12pm – 1pm - is a "Firm 'pencils down' date."
I can't give you more time - even if I wanted - the program doesn't allow it, we all have to respect the program and it's roles.
I am sorry.

[Karol Badowski 1989]

I've done for now that transformation of application to CMake files structure.
For last days I've also tidied - up the code.
Everything is in new revision fork in samples folder (like every other sample) and with updated c-make files.
I've finished transformation to version with button controls that works in sample-browser.
From 5 parts that were mentioned i still have a form to send. I'll print it, sign, scan and send now.

I have a question what do i put in "Company name" in this form?

---------------------------------------------------------------------------------------------------
I'm sorry to hear that there is no more time for adjusting version sent to evaluation.
However, I will continue putting this last missing shader anyway (it is just one puzzle piece) - like I said, I will finish it even if it is not taken into consideration in evaluation.

I just want to finish that task even if i fail evaluation . It would be just shame to leave work unfinished when there is last piece left.
There will be no need to assign this topic for next year - do not worry .

[Assaf Raman]

That is the spirit, we will all be happy if you finish this.
Put nothing in the "company name" - it is not relevant to you.

[Karol Badowski 1989]

Question:

I've prepared yesterday and today version with class definition, definition of methods and properties etcetera, moved to headers (so it would be pretty, clean) in the application version.

When I transferred it to SampleBrowser i saw that there is convention in all these examples to put nearly everything in a header file and leave only one, nearly constant stucture in Cpp file.

(I've moved declarations back to header in this new fork). Compared with last version from older repository - I think that it was better (more clear to read only definitions in header). Which version should I leave?

[Assaf Raman]

Doesn't matter - what looks more clear to read.

[CABAListic]

I'd prefer if you keep with the convention that is already there for the other samples, i.e. everything in the header(s). It isn't the prettiest, but it makes some things simpler and will allow me to compile all samples into a single DLL in the future, to speed up compilation.

[Assaf Raman]

Sounds right to me.

[Karol Badowski 1989]

I've printed, signed, scanned, and sent Licensing Agreement.

Now I am adjusting material of particles.
It is just few silly easy steps:

-new texture unit (it references texture from comositor

Code: Select all

         texture_unit 1
            {
                content_type compositor AllInOne DepthDownsampledTexture
                tex_address_mode clamp
                filtering none
            }

)
-duplicate vertex shader (the same calculation as in vertex shader already written in depth acquisition material) but uncomment that part that is commented now.
-tex2D() operation on both textures
-compare > or < depth passed through TEXCOORD1 (depth of particle) with one achieved from texture.


Ready, steady... here I go and do that.


EDIT:
I've tried and here it is:

Code: Select all

content_type compositor OSP_AllInOne depthDownsampledTexture

was pasted instead of texture file name for colour (every particle displays entire depth map)

As I see it (I told it some time ago) this operation is a little bit slow - i think it waits until entire compositor is executed - because FPS drop down twice.
However i can optimise it later (pass texture from level of application).
Texture is not defined the same way as render_quad, because it is render_scene pass - later optimalisation will happen in listener.

[Karol Badowski 1989]

This is depth passed this way:

Now just compare, It is close to be ready


EDIT:
This part work also in browser, maybe here it is better seen:

[Karol Badowski 1989]

I've just done fix for depth acquisition (in clear section I set colout_value attribute to 1 1 1 1).