BCC+ Vignette rendering bug w VP 19

@PeterMcAuley Here’s the log output (attached) from running with Nvidia first and Intel second with the BCC+Vig enabled.

My actual request would be more along the lines of “all the BCC(+) fx should act consistently.” If users had to keep in mind that the BCC fx act one way and the BCC+ fx act another but they were self-consistent within the groups that would be workable. Part of the problem now is there’s a bug where even that kind of rule doesn’t hold, otherwise we’d get the same results no matter what gpu we’re using. It seems like this is a bug in VP that’s been there since at least v15.

My ultimate preference would be for all of them to act as the BCC filters do today because more often than not I want the effect to act within the visible bounds of the clip it’s applied to. Having an option to give the user more control would be handy at times though I know it’s a double-edged sword for support.

It looks to me like VP is setting an render state and leaving it dirty. When I went to get the attached log I found that the image was going full alpha again when it should have been opaque. Same as in my video from 2d ago. There’s also this error in the log:

2021-09-14 16:49:03 BCC VGS NOTICE: Licensed render 32BitFltLib: BCC+Vignette
2021-09-14 16:49:03 BCC VGS NOTICE: BCC_DFT: ERROR: ocl render - std::exception: clCreateImage2D - Falling back to CPU

BCC - Copy (2).zip (3.3 KB)

@biggrazie both because with the exception of falloff, they’re both only being applied within the bounds of the event they’ve been applied to.

So placing the FX before Pan/Crop results in what you want. Now, and please note, do YOU get this happening? Do you get what you want by placing the FX before Pan/Crop? If it is YES, then you’ve got the solution. If it is NO then we/BORIS/VegasPro need to go deeper.

NB: Placing FX before Pan/Crop to get the effect has been the way with VegasPro, for certain FXs, has been the way forever.

@biggrazie I would change this to “then you’ve got the workaround”

A workaround is fine when you’re on a deadline but the behavior overall shows this is likely unintended behavior, or a bug. I’d rather help get to the root of the problem than just move on with a workaround. Esp since my deadline is weeks away and I’ve (sort of) got the time to gather data.

I also think it’s a bug. Changing just gpu while leaving all other settings the same shouldn’t give different results.

Unless BORIS is willing to accept this, then I strongly advise you both to ask the question on the VegasForum.


1 Like

@biggrazie yah, time has been at a premium so I haven’t been able to start another thread on the forum and Boris is typically more responsive. Plus they, I believe, have a pretty tight relationship with the Vegas team so if things need to be handed off to Vegas I have no doubt that would happen.

@michaelh @biggrazie You are correct - the filter GPU and CPU paths should produce the same result and the BCC+ filters should follow the BCC filters in regard to the way they respect image bounds. I’ll have to ask QA repro and once they do that we file a ticket and have engineering fix the issue. Thank you for alerting us to this!

1 Like

@michaelh @biggrazie

QA have repro’d the issue per your description and have filed a ticket for engineering to fix. Thanks again for the alert!

1 Like

This is definitely reproducible in QA and I’ve logged this issue in our database, but wanted to chime in with a possible work around for the time being.

If you apply BCC+ Vignette to the track itself instead of the individual clips, the issue shouldn’t present itself because it is reading the dimensions of the track, not the individual clip.

Let me know if this works for you.


@vincentm_e8c60 “If you apply BCC+ Vignette to the track itself instead of the individual clips, the issue shouldn’t present itself because it is reading the dimensions of the track, not the individual clip.”

This won’t work for my case because what I’m after is a vignette around the edges of the images and those images do not match the aspect ratio of the track.

Drag BCC+ to the left of pan/crop.

@SummaryActivityNot see above

I get the same (full track undesireable) vignette results in Vegas Pro 17!! (instead of it applying to just the video event on the timeline to which it was assigned) But that was using Continuum 2020.5