Hi @Pierluigi Grassi (pgi)

Fairly sure this code doesn't have an active maintainer to review, can you summerize the advantages this patch gives?

If you're able to maintain it we might be best to add you as a committer and you can commit it directly.

The proposal gives no advantages for the user, just the risk to break up working stuff.
The final goal is to add support for filtering optimization (and possibly new techinques) that are not possible with the current system, that could be introduced without the refactoring but would make the current system even more convoluted (the current filtering state is a gigantic function stored in a class instance just to have pseudo-global variables, stored in arrays: it even works well but it's simply not designed to be extended).

Because my C++ is worse than my knowledge of OpenGL, I'd like someone to double check the code. There's no need to know the current bge codebase, that entire stage will be replaced and I am already 100% sure that what is doing now can be also made with the new design.

@Pierluigi Grassi (pgi), Im not sure anyone is available to double check this.
But perhaps it would be best if we give you a branch, then you can apply this patch, and develop further filter improvements there.
Once done, both can be reviewed and applied to master.

How does this sound?

Some feedback to get patch ready for branch. Would be nice to get those figured out.

Also in some files you don't give any copyright note, would be nice to have those clarified as well.

Thanks for checking this.

@Campbell Barton (campbellbarton) on the branch thing I really can't tell - mostly because I ignore the wonders of versioning systems. If creating a new branch can help you revising the code it's fine by me. If from this branch I can get a blender version that can be tested by users on their system (without asking them to build it from scratch), that would be great. There are tons of places where I can get infos on how to write the correct opengl code for what I want to do, it's the testing part that troubles me.

@Sergey Sharybin (sergey)
license issues are due to lack of care from my part (copy paste, let the IDE do it and things like that). It's meant to be the standard blender license, i'll fix that, along with tab and spaces.

7: that stringify is a part of the old system I didn't really decided how to get rid of. Currently the text of shader programs that are used for predefined effects - that the user can choose via buttons in the ui - are written in header files, in the form:

...header xyz
static const char* xyz = STRINGIFY(the plain glsl code)

I can see the reason why it does that, it avoids reading the content of a text file whose existence is a precondition of the engine. I think it's a clever crime, because those are dynamic resources and not real compilation units.

It can be replaced by one of the STRINGIFY macros in BLI_utildefines (I didn't know it existed there too ).

I'll rewrite the code against the latest sources of blender and I'll post an updated and revised patch.

@Pierluigi Grassi (pgi) - regarding a branch, we can give you a branch more or less on a trial basis.

That is, you have the branch to develop in (and become experienced using version control too),
If things don't work out, for whatever reason we can delete the branch (you will still have a local copy).
But if you get the feature completed successfully, it means we can do test-builds and review your working history.

I'd recommend this, but it means you have to take some time to learn GIT.

Let's put it on hold until the next dev meeting on irc. At the end of it I'll plea for a 5 minute talk about bge. I have to look the benevolent dictator in the eyes and ask if the blender foundation has any interest left in a game engine. Not an interactive mode, a spectator seat or the dynamic duo, a game engine. Git, C++, apis, design, long term commitment, these are not going to be a real issue.

Based on what I understood chatting in the quite chaotic irc, I withdraw this proposal. There might or might not be a branching for a more coordinated refactoring - considering the future plans for bge it might be premature starting now, there's the hint of a discussion on the mailing list about that. I'm sorry for the wasted time.