Am 26.05.2005 um 20:41 schrieb Pierre-Olivier Latour:
That makes sense: Sprite has some overhead is setting up the OpenGL
states each time and communicating with other patches. It's not
efficient at all for serious bulk drawing with thousands of instances.
Is there something, you'd recommend ?
It appeared to me, that I might go even faster with a "Core
Image Kernel", but that has left me puzzled. When the kernel is
running with mostly "static" inputs, it is indeed faster than the
"Texturing Matrix", but when I hook up two more inputs it slows
down to the level of the Crop filter. Is there something that I
can do, to make the Core Image Kernel faster ? I suspect it
samples its input for every pixel, but it really only needs to do
this once per iteration. Interestingly it does notice that one of
its inputs is derived solely from iterator variables, and does not
slow down on that input.
Same comment as for Crop: you'll end up doing extra computations
and use extra VRAM.
I don't understand that. If I use as kernel input values derived from
the "Iterator Variables", I don't see a slow down. Why does the use
of variables from outside of the patch as input, force the use of
VRAM ? I know that these values won't change during the "life" of the
iteration step, how can I tell this the "kernel" ?
Ciao
Nat!
------------------------------------------------------
But didn't I always tell you, honey, if I just stayed
in place and I never spoke up, good things are bound
to happen ? -- Jonathan Gems
