ActionVFX issue in Vegas Pro 18 (Build 284)

odarmonix wrote on 8/20/2020, 9:15 AM

Hi everyone! First of all, I'm still fairly new to video editing in general, so, please forgive me if I'm missing anything obvious.

I upgraded to VP18 Suite a few days ago and after opening some of my old VP14 projects, I noticed that some of the ActionVFX footage (which I got via HumbleBundle in december 2019) looks completely different from what it's supposed to, as you can clearly see in the following picture (not directly taken from one of my actual projects, of course):

It likely has something to do with the mxhevcplug.dll file, but I have no idea how to fix this. I've tried disabling said plugin, changing the media's alpha channel settings, checking and unchecking boxes in the preference's deprecated features and file I/O tabs, installing and uninstalling QuickTime... none of these attempts worked so far. The only somewhat viable solution I found has been to convert the problematic footage to mp4 and use Vegas' built-in chroma keyer, which is far from being ideal...

I can always reinstall VP14 in case I need to go back to my old projects, but I'd prefer not to have to juggle between two different Vegas versions. Not sure either if having both VP14 and VP18 installed on the same computer would be wise. Any help will be greatly appreciated!

Comments

Marco. wrote on 8/20/2020, 11:20 AM

Do you composite the fire against the background? If so, which composite mode do you use? And what is the setting of the pixel format in the project properties?

odarmonix wrote on 8/20/2020, 12:21 PM

Do you composite the fire against the background? If so, which composite mode do you use? And what is the setting of the pixel format in the project properties?

 

The background video track is of course placed below the fire track, if I'm understanding your first question correctly. Admittedly, I didn't know at all about the alpha channel thing when I got the ActionVFX bundles (like I said in the original post, I'm still pretty much a newbie in video editing). The first time I tried using the AVFX clips, I assumed I had to use chroma keying (like one would do with regular green screen-type video), as the clips' black background was still there after dropping them on video tracks set to the default Source Alpha compositing mode.

Only later did I learn about the presence and purpose of the alpha channel in the AVFX .mov clips (and felt like an idiot for not having taken a closer look to this before), but since changing the alpha channel settings in the media properties made zero difference in VP14, I just kept using the chroma keying + source alpha combo in my projects, with satisfying results as the kind of video I create doesn't rely on extreme visual quality and realism.

It seems VP18 always apply transparency to some of the AVFX clips when importing in new projects. That's right, not all of them! Fire and blood hits in particular have transparency applied right away, but this is not the case for dust waves for example, which look and behave just like they did in VP14. Also, this doesn't explain why fire and blood hits suddenly have this strange grainy visual aspect in VP18, changing compositing mode doesn't make any difference in this regard.

As for pixel format, I forgot to mention that I tried changing it from 8 bit to 32 bit in the properties and I can get fire to look like what it used to in VP14 (no more grainy aspect). Problem is, changing pixel format messes up the colors on just about everything else in the project (black backgrounds and grey layers changing to clear blue, wrong PNG transparency management and other such things).    

Marco. wrote on 8/20/2020, 2:16 PM

Try changing the pixel format from "8 bit full level" (which is a new option and which is default now) to "legacy 8 bit video level"

odarmonix wrote on 8/20/2020, 5:07 PM

My VP14 projects are automatically set to Legacy 8-bit when I open them in VP18. I can see a tiny difference when changing pixel format to 8-bit (full range), but the grainy aspect I described earlier is still there. The graininess goes away with the two remaining 32-bit modes, but they also introduce lots of other issues everywhere else, as already mentionned in the last paragraph of my previous reply.