iÃ‚Â´m trying all the time to build up an automatic generator for something like a slideshow of n pictures. For that i really want to create a patch that does the transformation for the slides (instead of cuts).
But i find it very difficult to generate this function in 4v… i made some patching with switching transformation and texture nodes that went the way iÃ‚Â´d like it to, but the performance was a problem since all this gonna be a video.
my question is more like this:
did anyone patch this function already or has a function, that creates one big texture out of all the images from one directory so i could slide in one of the four directions (North, South, West, East) in the dimension of the origin image size.
i already thought of creating one huge picture to slide it like old skool animation were made, but the folder content will change during runtime… so this is no solution…
i´m trying to patch something like “new picture pushes old picture left / right / up / down”, where new picture gets old picture when arriving @ x=0, y=0… (the pushing is done by a damper node, and two quads are also realisable)
this is not impossible, but i can´t deal with lags so good. is there something like some a media tracking mechanism (like i load some picture in cache and just route it into the quad texture pipe?)
as mentioned above, just using a pre-edited big texture with all the small images containing is not cool since this would be a step in another software, not mentioning loss of dynamics.
file attachment: pict-o-slide self extracting zip. put into /modules/bbb/
to get a glimpse of what i´m trying… (but with the feature, that two quads align themselves). maybe the pict-o-slide won´t have any gaps if you´re on a very cool computer system but my home pc dies everytime the linkbuffer pushes the to-be-loaded strings one up.
ahemm just to have said that i´m very suspicous that my way of patching the solution is not the quite best… just gimme some bullets (:
The lag you are experiencing caused by repeatingly loading the textures from disk. Open up a Renderer (TTY) to see that this is the case.
With the queues, getslice setslice stuff you are processing the names of the textures. Note that you can also process the spread of textures itself. Connect one Filetexture node to the Dir node and work with the spread of textures by means of GetSlice (Node) etc. - This should significantly speed up your patch.
Check the Memory (Debug EX9) node. it shows you how much memory your graphics card has left. as long as everything fits into video memory, things will go blazingly fast. if you dont have enough video memory, things get swapped out to main memory and things get slower. if main memory is not enough and things need to be read from disk, performance will degrade significantly.
so: the smaller your images are, the more images you will get into video memory. note that images in the graphic card are basically uncompressed and take widthheightdepth bytes (dont get fooled by the size of jpgs on disk).
so to save memory you can try to reduce the width and height of images - images without much contrast usually can be shrinked a lot. or try
different bit depths (either do that in photoshop, for example by creating grayscale or indexed 8bit PNG files or at runtime. see the Format pin on the FileTexture)
or get a graphics card with a lot of video memory.
i´m on it with around 256megs, i already set the include subdir to 0 i think this was one major performance issue. is there a way to instatiate all images on starting time (a bit load before the video starts is okay)