Forum

Contour needs visible renderer or noop/memfail

vvvv beta bug
#1

I found an old thread about this that seemed to indicate this was fixed, but I’m getting two problems in 25.1 with contour.

If somewhere down the line from contour there is not a visible render of its “seen” output, it stops working.

Also, if another renderer goes full-screen “over” that visible renderer, all sorts of errors occur, and contour stops working, even after the full-screen is removed. Also, the full-screen never happens, I just get a grey box taking up part of the screen.

I was able to use contour before because I was just using the numerical output, and kept a patch window open with a render of it on my patch monitor. But now I’m trying to use the “seen” output, and that means the patch has to go on my full-screen monitor to stay in the render pipeline. Ooops.

Workarounds appreciated - thanks a bunch!

#2

Here’s a test file. Enjoy!

ContourBug.zip (3.2 kB)

#3

Update: The memory errors in full screen only happen for me in Win7 x64, not XP x32.

#4

Hi mediadog. Keep its window in a little renderer down you fullscreen renderer. You can like this delegate behind the main output some work to the gfx card on snd pipeline.
If you still experience this, wich remembers troubles i had on last project, or dimix bug in unc thread, try to ventilate to your 2 outputs the different renderers. Be aware that using freeframes are augmenting the troubles.
You may try to upgrade gfx card to upper model, or rebuild your patch on 23, less ressources consumming, or get down resolution of the project.
For travelling it is what i did.

Hope it may help you

#5

hi guys
https://discourse.vvvv.org/t/4743

  1. _I solved it by positioning the other renderer ‘behind’ the fullscreen one on monitor B, hence the videostream was on the same device._this trick works for me only on main screen …
  2. cant get “shared memory” working for me
  3. “flash”?..never tried yet
    @ karistouf
    sorry I still dont get your “ventilating” trick…
    btw i managed secure and complex FX chain with beta23 by putting all (hidden and preview) renderers on the same 2nd screen, but beta25…olala
#6

Im using s and r node. This enables somehow to bypass troubles of a chain being on two different screens.
Then i manage on fullscreen renderer contour and additional freeframes. I m putting part of subpatchs of filters behind the main output. When i m saying ventilating its because there is a need to dispatch to two outputs of the gfx card the shaders: gfx card is not reacting exactly the same in its capabimities if you put everyone on main output, or ventilate intermediate renderers to the two outpit. Dont have clear logical explanation about it but its what is happening for me.
Travelling was using a 4850 on beginning of creation. then i passed to 5770 wich changes a lot of things.
Xp32 on creation, touring seven64 on 4600m nvidia now.
Those are little ati cards but troubles you encounter show me: bugs happens when we raise limits of a gfx card, they deseappear on upgrading it. Shared memory doesnt work in this case ( sorry devvvs). Never seen its utility in fact.
Maybe a kind of meory leak somewhere resulting in this bug?
Yours devvvvintively

#7

helo mediadog,

in the wrapper-subpatch instead of the videotexture…renderer combo try connecting a Dump (DShow9) to contours output directly. that should keep it running and should not interfere with going fullscreen.

#8

Thanks joreg, I’ll give Dump a try!

@karistouf - I tried S and R, but had the same problems. Are you displaying renderers in the same path on the two different screens? In my experience patches can live happily on two different monitors only as long as they aren’t displaying anything on more than one.

BUT! Experimenting around, I have found that video, unlike layers and textures, crosses between devices OK. There is a performance hit, but it looks like another thread is used for it so it’s not awful, and if I remember the shared mem results correctly it seems about 2x faster than that.

It is too much for 1080p as the fps drops from 60 to 20, and even at 640p it’s still 30. There is also some visible tearing, but for bringing small monitor renders back on the patch screen it works well. Note I have tried this with only one stream at a time.

Thanks all! I’ll keep slugging at it and report back. Hopefully I’ll get back to creating instead of debugging again soon - seems my life has been spent fighting my tools as much as being productive… (%^P)

#9

Hi mediadog

You can if shaders take different time to process same signal. In travelling i m using one video in thats is outputted 6 times or 8 times with s node. Result being sended indide shaders and chains of shaders.

About creation, well its good time now to debug from live patching and create the projectStructure adapted to your artistical needs and constrains of hardware. Sincerely think to get down to 23 or increase gfx card power.
Sometimes yes its painfull, but vvvvhat a result !

© vvvv group