[Fluxus] Postprocessing in fluxus

[Kassen]

Hey Johann, welcome on board.

I am currently trying to do postprocessing in a shader with fluxus (for
> blur, glow, distortion, kaleidoscope, ...). Below is how i do it currently,
> which works fine, except i have a few issues with it:
>
> Let's have a look.


> 0) fluxus limits texture size to power-of-two which is no longer needed,
> every graphics card should be able to use arbitrary sizes AFAIK. This is
> only a minor performance and image quality issue.
>
>
Actually, all sizes for textures should be fine, we recently had a lot of
talk and some confusion about that. Did your images have a alpha channel? If
not add one, that will help.



> 1) It seems that the primitive must be drawn (with the mysterious #t flag)
> and hiding it won't work. I have to move it out of the way, which is a
> really crude workaround.
>
>
The "#t" enables the picture renderer for that pixel primitive, that
probably needs documentation. Also; you can use (scale 0) to make it
invisible. Still a bit crude, but more convenient.


> 2) When i use the mouse to change the camera transform, of course i rotate
> the pixels primitive (or the plane, if i draw onto one) instead of the
> objects rendered into its texture. I tried storing the cam transform,
> setting the transform to its initial state and applying it by hand to the
> objects drawn (see the code below). Somehow, the current cam transform seems
> to be ignored - i suspect the cam transform is set before every-frame calls
> its payload and not when i call set-camera-transform. So i tried storing the
> cam transform and then multiplying its inverse onto the current matrix to
> get a pristine state for drawing the plane, only to discover that minverse
> doesn't actually invert matrices. Im out of ideas now.
>

Sorry, that one is beyond me right now.


>
> 3) It's an awful lot of code with lots of stuff to get wrong when coding it
> live.
>
>
> Yes, indeed. I think that both from the perspective of engaging the
audience and from a convenient programming one it would make sense to work
with code that can be incrementally written (and run!). That should keep the
audience engaged and bugs small. The challenge in cases like this is of
course how to do that without compromising too much. I admit that that's no
solution, but that's how I tend to look at and approach the problem. It
might still be of a bit of help? It is indeed hard.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20110515/ab3c2520/attachment.html>