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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
