Re: Current Post Processing support

Matthieu Kraus <[email protected]> Tue, 23 Apr 2013 17:32:52 +0200
Newsgroups gmane.comp.graphics.crystalspace.devel
Message-ID <[email protected]>
> About the work that would still need to be done:
> - 1: The conversion into a post effect is in early development status
> and may need quite some time to be done (I would say at least two weeks,
> the harder being to understand deeply the behavior of the SSDO stuff).
> - 2: The branch still needs to be updated with the changes that have
> been made last year by Matthieu to the deferred RM. The SSDO
> implementation would need to be updated too.
> - Not sure what would be the best: work on 1 before 2 or vice versa?
> Maybe complete 1 as it has already been started, then go for 2. No real
> idea of the complexity of 2 actually, in the best case there is nothing
> to do.

How complicated 2 is depends on what exactly you need. While deferred  
already exposes all deferred buffers which should help a lot with such  
post-effects it only exposes them for the main render. Most  
importantly it means that all heavy portals, etc. will *not* be  
represented as seen in those buffers - what you'll see there is what  
they're implemented as: an according quad.

>> The post-processing manager:
>> When using
> "postMgr->AddLayersFromFile("/data/posteffects/effect.xml");"
>> always return true even if the shaders have wrong sintax and not
> compile, you get only a black screen without any notification.
>
> That's a priori not the expected behavior and at least wrong syntax
> should be detected and a negative value returned. That might be a bug
> and you can clearly introduce the fixing of such problems in your
> project if you want to.

Note that it depends on what syntax was wrong whether that's expected  
behavior or not. If all the weaving syntax, etc. is correct and the  
shader simply fails to compile/link due to some problem with that it's  
expected behavior that this error is not detected at that point as  
evaluating whether a shader compiles/links is only done upon  
encountering the usage of that shader with a specific technique  
actually using the snippet in question. Accordingly (due to the  
delayed compile/link) you won't be guaranteed on load that the loaded  
shader will actually work as expected.

kind regards,
Matthieu "RlyDontKnow" Kraus


------------------------------------------------------------------------------
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