Sign in to follow this  
Jonas B

Paint app

Recommended Posts

I'm writing a paint app where the pixel processing is (optionally) done in HW. Brushes can affect the canvas not only by copying pixels to it, but also affect it in ways that require pixel shaders (burn, blur, desaturate etc). As I understand it, pixel shaders can't access the surface they render to. The only way I can think of is the following: * Copy the region that will be affected from the canvas to a new texture * Use this texture and the brush texture as samplers in a shader * RenderToTexture * Copy the texture back to the canvas' region All this copying seems a bit unnecessary. Is there a better way?

Share this post


Link to post
Share on other sites
Have you made sure that you can't use any of the blending operations to achieve part of your effect? It can require some creative thinking, but if you render a small sprite the size of your brush to the canvas the shader will only get invoked for the pixels in the sprite. If you can refactor the final write to match one of the D3DBLEND equations you're sorted [smile]

It won't work in all cases so you may need to use your original idea instead. I wouldn't use the copy method though - i'd use some form of double buffering. It uses more memory, but the performance would probably be much better.

If you render a sprite, the size and location of your brush. Create two sets of texture coordinates - one that maps the whole brush to the sprite, and one that maps the exact subset of the destination to the brush. Then render the sprite to the first buffer using the brush and second buffer as input, on subsequent operations use the first buffer and brush as input and second buffer as output. "Ping-pong" between them...

hth
Jack

Share this post


Link to post
Share on other sites
Some brush modes can use FFP, but not all (e.g. blur) and I prefer having a consistent shader-based pipeline. All brushes' (and filters'/effects') .fx files will be easily accessible for the end users to modify, and use as starting points for writing their own tools.

The app uses my node-based signal processing framework (http://www.openblackbox.net) and should be extremely flexible if I manage to get things right.

Ping-pong sounds faster, but I think speed might be less important than mem usage. 4096*4096 or larger isn't uncommon when photoshopping... I'll have to implement a system for splitting images into several textures for images larger than the card's max tex size.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this