plugin
Credits: elliotwoods
I know a few of you are streaming DDS's off the HDD to playback video. Here's a ring buffer to do that.
(*) I've manually coded the UpdateTexture function to parse the DDS file header and contents, and push the contents to the GPU without recreating the texture
We didn't end up using this plugin, as we found that texture lookups became slower on DXT5 compared to X8R8G8B8 textures (hits the render stage).
I think in general this effect is negligible, but for the amount of texture lookups we're using (7 * HD in PS 3.0 on Radeon 6970's) it became a noticeable hit (dropped to 40fps min framerate vs 60-synced before). This effect continued after the texture was loaded (i.e. the slowdown was purely at render time).
The hypothesis that a texture lookup on DXT5 takes more GPU time than from an X8R8G8B8 makes theoretical sense, but might turn out to be incorrect. However, it is in line with our tests here.
anonymous user login
~1d ago
~12d ago
~21d ago
~21d ago
~26d ago
~30d ago
~1mth ago
~1mth ago
~2mth ago
~2mth ago
Nice, unfortunately it doesn't work on my machine. (Renderer stays black, node gets red when changing the value on the index pin)... any idea why?
@flux
thanks for the feedback
this is tested on b27. works across 3 machines here.
do you get anything in Renderer TTY?
which vvvv you on?
works here under beta28 with the
\vvvv_45beta28\lib\assets\images\meso_cubemap.dds = DXT format
but not with
\vvvv_45beta28\lib\assets\images\color_cubemap.dds which is a X8R8G8B8 texture
00:05:04 ERR : Exception occured in TMPluginWrapperNode.Evaluate: File format not supported by DDSFile
aha yes.
it's hardcoded for DXT5's right now! :)
will add that to the description
@elliot
sorry i forgot, i tested it on beta28. And i think it was the same issue circuitb mentioned. A8R8G8B8 dds textures don't seem to work. i got it running with dxt5 compressed ones on b27 and 28.
a spreadable version sounds possible?
yes.
certainly possible.
it's not going to be very tidy for changing spread-count
accidentally feeding in a large spread is going to either:
a) be capped (i.e. hard cap on number of slices)
b) crash (you'll allocate too much cpu and gpu ram)
is this something immediately useful?
i haven't got the source here anymore
no not really in a hurry just testing best ways to read image sequences
for something like 5 sequences of 200 frames ...
i duplicate the dds ring buffer node
everything is fine with a smooth playback!
but be careful with the buffercount value
vvvv dedicated memory get bigger and bigger each time you change this value (increase or decrease)... when it reaches the memory limit DDS nodes turns red and you need to restart vvvv to clear the allocated memory.
interesting.
i'm using byte arrays for storage which you can't actively flush (the .NET garbage collector is supposed to clean that up when it feels like).
I can provoke the garbage collector to get on with its job whenever you ask as well, so I can do that when the pin's changed
(flushing GC manually results in a temporary pause of the whole app, something like 50ms)
yep could be cool to manually flush the memory without restarting vvvv!
also the plugin doesn't work with the sharedtexture /dx9ex switch