[Bf-gamedev] New 2DFilter system for BGE

[pgi]

Thank you.

Short story why I did that, then the goals.

A user on the bge forum asked for a custom filter to be able to write to 
an offscreen buffer, for performance reasons.

It is possible to do that with the current system but it is also awkward 
because there is no "2DFilter", a filter is really an index that the 
filter manager uses to reconstruct the filtering behavior on the fly.

In principle, it is not too hard to add one "offscreen" flag, then tell 
the filter manager that when the pass index has that flag it has get the 
size of the offscreen buffer from some array, initialize and use that 
instead of doing thing the usual way.

The problem comes when a second type of specialized filer is requested 
and maybe a third and so on.

At that point the filter manager starts to gain arrays over arrays and 
maybe two or three different ways to apply filters in its RenderFilter 
function.

I think the point is the lack of a Filter object because if the system 
had a 2DFilter type and the RAS_2DFilterManager was just that, something 
that collects and manages the life cycle of a Filter, then creating a 
specialized filter would be a matter of creating a subtype of this 
abstract filter.

So what I did was to introduce a RAS_2DFilter type in the system.

Which is quite a disruptive change because once you have a Filter 
object, most of the things that RAS_2DFilterManager does now should be 
done by filters.

In all this we have to keep in mind that I have very little knowledge of 
C++ and even less of OpenGL and that's the thing that worries me the 
most (my area of expertise, if I may call it so, is intranet clients for 
crud applications, entirely in the Java ecosystem).

But I tried and it even seems to work (here, on n. 1 systems).

To sum it up, the new system is made of:

RAS_2DFilterManager -> handles the life cycle of RAS_2DFilter instances
RAS_2DFilterContext -> a medium, provided by the filter manager, for 2D 
filters to share values and operations (like reusing textures, getting 
the viewport size and who knows what else).
RAS_2DFilter -> a totally abstract stateful operator on a context.

That's the core structure. The current system is then reproduced with:

RAS_GLSLContext
RAS_GLSLFilter

Ideally I would also have added a RAS_2DFilterFactory but doing that 
requires changing things up to
KX_Scene otherwise it won't be logically consistent.

RAS_GLSLContext does nothing because the GLSLFilters do not share 
anything but that will change for obvious performance reasons, to mimic 
what the current system does.

And that's the picture.

The final benefit comes from a (hopefully) clean separation of 
responsibilities. A filter is a filter, a filter manager is just a 
manager. New filters can be added as a new type of RAS_2DFilter with no 
risk to break existing code.

There are more than a couple of things I've written in the code that 
looks odd in comparison to how the bge code looks and I strongly suspect 
they look odd because they are plain bad practices in C++ (like using a 
class to avoid having a function call with lots of arguments, that's 
what RAS_2DFilterData is for, or declaring non member functions to break 
up a member that would be otherwise too long).

pgi

On 03/01/2015 18:33, Daniel Stokes wrote:
>
> I will take a look at your diff later (on a phone right now). Could 
> you elaborate a bit on what your goals with the rewrite were?
>
> Regards,
> Daniel Stokes
>
> On Jan 3, 2015 6:24 AM, "pgi" <pierluigi at tukano.it 
> <mailto:pierluigi at tukano.it>> wrote:
>
>     Hello, happy new year and things.
>
>     I rewrote the bge 2D filter system, there are a couple of minor
>     things that I have to change (like naming conventions, formatting
>     and so) and a few test I need to run before to have a real patch
>     but I'd like someone to check how things are shaping because I
>     made some design choices that might not be compatible with how
>     blender is supposed to be.
>     The new system is backward compatible. Well, it will be, I have to
>     guess another two or three things before to be 100% sure about it.
>
>     The attached diff contains the changes to the rasterizer package.
>     There are maybe a couple of other minor changes in other parts of
>     the code but they are not relevant.
>
>     pgi
>
>     _______________________________________________
>     Bf-gamedev mailing list
>     Bf-gamedev at blender.org <mailto:Bf-gamedev at blender.org>
>     http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20150103/ce0b2e19/attachment.htm