Brush spacing / rotate / scale
mnm at dneg.com
Fri Nov 16 15:29:13 CET 2007
david powell wrote:
> well tipicaly i work with images at about 3600*2900 ish
> the screen aria of 1960*1240
That's not even a high res. Eclipse/Satori could handle brushing on
images of 10k*10k pixels in realtime on machines with 128 MB of RAM and
much less CPU power than today a decade ago.
> when doing a brush stroke the following is needed
> 1 it needs to update the actual image
No it doesn't.
> 2 it needs to update the part of the image that is displayed on the screen
> and scale the brush for that modification
Yes, but instead of scaling the brush, the brush should scale itself --
i.e. if it is a com,plex procedural brush, the system should tell the
brush what detail level it needs/wants and the brush should do "less
> if i was drawing using pencils the average short brush stroke = to about 1"
> per second , would translate to 80 points that would need updating
> ( assuming working at 1 to 1 image on the screen )
> first it needs to recode the stroke (and all the changes made during it so the
> undo works )
> so you got
> 1 calculate the brush path and intermediate points
> 2 calculate the actual info to change and log it
> 3 update the main image to a temp image
> 4 recalculate and scale that image
> 5 display it
That is the wrong approach.
1. Calculate visible portion (sub image) and level of detail aka LOD
(zoom level) of current image
2. Calculate the brush path drawn by the user so far (intermediate
points should be handled by the brush itself, not every brush might be
working based on the old-school idea of cloning a bitmap over and over
again along a path)
3. Calculate the visible portion of the brush stroke at the current
resolution (zoom level) NOT at the image resolution
4. Render the brush into a buffer at the highest possible level of
detail that is <= the needed LOD for the current zoom level that can
still be computed in "realtime" on the user's system
5. Compose buffer over visible sub-image image at current resolution &
6. If the LOD in step 4 was equal to the current LOD (i.e. the user's
syetem was fast enough for the required LOD), add result to the tile
cache; If not, re-render step 4 at the needed LOD and go to step 5.
7. Optionally, kick off a thread in the bg that renders the brush into
the image at the images final LOD.
The actual rendering of the brush into the full res image is *not
needed* until the user either pans over the entire image at >=1:1 zoom
or wants to save/print the image. Either is a very rare occurrence commonly.
The approach you outlined misses too points: rendering at only the
needed resolution and rendering with LOD. A procedural brush containing
a fractal noise 6 octaves only needs those octaves rendered whose
frequencies lies below the Nyquist limit for the current zoom level/LOD.
Same goes for everything else. If you have a particle-based watercolor
sim, the number of particles and their size can be adapted to the zoom
level. You can offline the high quality sim to step 7 or even wait until
the user actually zooms in or wants to save the image.
More information about the kimageshop