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