Hi there! Look what happens when I use more than one video texture: Here I have 5 copies of the same AVI file (I tried with this codec: Xvid Mpeg4, PIC VIDEO MJpeg, Indeo 5.10):
http://img694.imageshack.us/img694/7326/screenshotuv.jpg
Is there some way to avoid this delay? Actually I’m trying to create a big video and share the texture on the quads, but it’s a temporary solution :/
nic
hi
I don`t see any controll of the all these Filestreams, you only change the Filename, or?
So - now it needs a little bit time to load a video and here it loads the video 5times in 5textures and the videos starts immediately when the are loaded - so one after another.
There are some ways for syncing all filestreams. Fastest way (just connect one toggle to all for play and stop and DoSeek to PositionZero) but so they are all in freerun and after a while one could be faster than the other one when fps is not extrem constant.
For controlling an syncronising more filestream use the DoSeek Pin and give the Streams all the same SeekingPosition (zB.: controlled by LFO)(PIC VIDEO MJpeg is a good Codec for Seeking)
(Actually I’m trying to create a big video and share the texture on the quads)
I saw this too late
So you don`t need so many filestreams - you only need one and then you can send this texture to 5 quads. With the pin “texture transform” you can fit the texturepart of the video to the quad. (this sentence is not good) just play around with this pin and you will see what I mean
CeeYaa
No no, I still need to syncronize more videos. The texture stuff works great, but I need to works with different video.
The LFO-seeking works great to, once you force the DoSeek to 1 with a toggle.
thanks!
you can also use S(Node) and R(Node) to send the texture. I have an all project working thruth this technique.
Hi karisouf. Thanks for your suggestion, but I don’t really understand how this may help me to share the texture on the quad… I got that S and R are useful just to avoid lots of link crossing the patch, or I’m wrong? :D
hi luper, s and r ( node) will help you to send the texture ( and so the current image of filestream) in memory, avoiding certan delay effect due to pacthing. well it was to help ;-)
ha now I understand. Let’s see if I got it: instead to link the VideoTexture node directly to the quad, if I make
VideoTexture --> S(node) --> R(node) --> Quad
it’s faster?
Now I’m dealing with the AudioIn, hope to try it tomorrow. But if you can show me some little example I’ll be very grateful :D
nic
not faster, i dont think so ( joreg ?) but it enables you to send it everywhere to anybody in your patch.
So if you want to send the same image to different quads in different patch this is a good technique