Re: Current Post Processing support

On Thu, 2013-04-25 at 15:50 -0300, Pedro Arthur wrote:
> I observed that most of the SSDOManager code is to setup layers
> (input/ output) and chain it correctly. So I was thinking to improve
> the PostProcessParser moving all these configurations (common to most
> effects) from hardcoded C++ to the effect xml file, and the manager
> only will be used to change effect related input parameters. Then we
> can get more flexibility for further effects implementation.

This is a good idea and would clearly be an interesting addition to your
project.

>From the API perspective, I would try to add those functionalities in
some public interfaces rather than in the XML parser, this way the tools
would also be usable in another context than XML, eg when defining the
post process from a graphical user interface. Maybe it can be put in the
interface iPostEffect or in some helper class.

Hopefully, after those changes the SSDOManager class would be completely
removed and replaced by the XML description.

About SSAO, there was a misunderstanding from my side. I thought that
you were actually talking of adding it within the forward RM, the
problem if you want to add it to the deferred RM is that the SSDO
already contains an implementation of SSAO. I you want to keep SSAO
within your project then you can either improve the current
implementation or add an alternate one, or you can implement if for the
forward RM instead.



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr