working on finishing a project that i had originally started in vvvv 8.1 in which i used a trick found on the forums … loading textures into video memory by pushing them onto a quad on an unused renderer in order to avoid glitches / stuttering in the main renderer’s output.
noticed a post from tonfilm (“Compressed texture formats” : 09.01.06) which points out that this trick will no longer work in more recent versions of vvvv which don’t use render passes :
(quoting tonfilm)
“here comes another question in my mind. How do i preload textures with the new rendering system ? means: how do i the trick from the older versions with a quad on a unused render pass to load all textures into memory, even if they are not showed ?”
i wonder if anyone has found a workaround for this in newer versions of vvvv? basically i need to be loading textures in the background without disrupting (ie. introducing glitches to) the main renderer’s output …
of course it is possible to preload images … but i have too many for that.
thanks in advance if there are any answers, and sorry if this was answered somewhere else on the forums … i looked but couldn’t find it.
first, its still possible to preload textures: connect the filetexture to a quad and this quad to a renderer with hidden window (rightclick on the renderer node or alt+3).
but loading textures without delaying the next frame is not possible, because every action is done in a frame, so the frame is as long as the loading. if the loading of one picture is very fast, you can try to load one picture per frame, but i never tried that…
ah, thanks tonfilm. this was really bugging me … i forgot to hide the window. it seems to be working well now that i am hiding it. i had myself convinced that without the ability to allocate a separate render pass i was never going to get this to work the way it used to.
luckily i don’t need to load multiple images per frame … just a new image every second or so.
of course smaller textures with lower bit depth will load faster. to make loading textures even faster, it helps to switch off automatic mipmap generation and make sure that the textures do not need to be scaled for display in DirectX. The Renderer (TTY) will tell you how long the loading took - so you can experiment.
asynchronuous texture loading is still on the wishlist
thanks oschatz … the textures are all compressed as dxt1 with mipmaps loading from the files, and all scaled to 1024x1024 … that’s about the best we can do here, right? tty renderer reports loading each file in around 10 - 30 milliseconds.
in case you would not need the mipmaps you could remove them from the file. this would half the size of the textures. but this depends on the usage of the files. if you want to show your textures as reduced sizes on the screen, mipmapping is the way to go. i fear you are approaching the best possible way of doing things. so tonfilms suggestion of loading one texture after another might be the only possibility left.
of course making an avi from the file, seeking the frames and putting them in a queue could be another dirty workaround. while seeking frames from an avi is slow and cumbersome, it might be actually faster than loading from a texture file, knowing when the frame is loaded might be difficult though.
