[Bf-committers] GPU texture painting design doc

[Campbell Barton]

Before merging into trunk - I did some profiling of projection paint
and found ~95% (IIRC, definitely over 80%) of time spent was sending
the texture to the graphics card and redrawing - even with partial
updates working.

I had grease pencil used to pre-define stroke so it was possible to
predictably time the painting operation and test out different
optimizations, should be easy to add back for testing.

Off hand there could be some ways to speedup painting..
- investigate _any_ way to speedup glTexSubImage2D, perhaps new opengl
defines some better ways?
 .... possibly updating smaller areas or restricting to 32x32
chunks... just a suggestion - perhaps hardware is optimized in a way
we dont take advantage of.
- Update the image at half res while painting (kindof lame but might
be beneficial :S)
- delay updates - rather then trying to update on every draw it could
help to allow the texture update to lag a bit - or update async with
redraws at least.


the way partial updates work right now is the bounds of the edited
area are used to make a rectangle that gets updated, this works fairly
well for 2D painting but when projection painting on UV seams it can
span large areas very easily which is very slow to update of course.

You could imagine some way to better update the areas (eg - tag small
tiles as dirty while painting then update those - rather then the
entire area - each small tile could even boundbox the modified area so
painting over contiguous UV's with a smaller brush doesnt give much
worse results).

On Mon, Jun 18, 2012 at 1:03 PM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> My advice would be to only do this after really trying to optimize
> this on the CPU, and if only if that fails, do it on the GPU. As far
> as I know all other 3d painting applications work fine only on the
> CPU. GPU code is much harder to maintain and tends to give graphics
> card specific issues, which you will end spending a lot of time
> debugging.
>
> If you implement it on the CPU in a way that is similar to how you
> would do it on the GPU that probably already gives you a big
> performance gain.
>
> Brecht.
>
> On Sat, Jun 16, 2012 at 5:45 PM, Antony Riakiotakis <kalast at gmail.com> wrote:
>> Hi all, I've given some thought to implementing texture painting on the GPU
>> and posted a rough design document here:
>>
>> http://wiki.blender.org/index.php/User:Psy-Fi/GPU_Texture_Painting_Design
>>
>> There have been some concerns over maintaining two front-ends for texture
>> painting, but I thought I could at least share my thoughts on it.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell