Resolume Forum

Output masks only combine their results when they're placed together in the slice list. Placing a slice, followed by two masks directly on top of it, will let you combine the areas cropped out by the two masks. The moment you place another slice between the two masks in the list, the top mask will crop the result of everything beneath it. Possibly this includes cropping out whatever the other mask cropped out and essentially losing the second mask.

This is the expected behaviour, and it's exactly the same behaviour as crops have in Res 4. Placing a slice between two crops in Res 4 does exactly the same thing.

There is a bug with the view not updating correctly after placing a slice between masks in Res 5. The view will correct itself if you nudge the position of the mask. The end result is still expected and correct. We'll fix the view update for 5.0.2.

Being able to first mask a slice on the output and then combine this with the result of another mask on another slice is different behaviour altogether. Thus far, it has never been possible in Resolume. We do have a feature request pending to improve the current masking behaviour. This way you could mask out slices that partially overlap. This would be completely new behaviour and as such, it's further down the roadmap.

Joris wrote:The moment you place another slice between the two masks in the list, the top mask will crop the result of everything beneath it. Possibly this includes cropping out whatever the other mask cropped out and essentially losing the second mask.

But a disabled mask between two blocks of crop masks breaks all the crop masks, shouldn't a disabled slice or mask have no effect on the rendering - like the disabled mask would not even exist?

Now as to the workflow, the advanced output follows the following principle: when you don't need to adjust geometry, but want to prevent your output from hitting certain areas, you'll want to use regular slices to position your content and then use an output mask.

All other slice options (such as input masks and polygon slices) assume that you want to warp pre-determined geometry to a pre-determined shape. They are specifically meant to help you select a specific part of your input for further manipulation in the output. As such, they are always created on the Input Selection side.

They're not meant for 'freestyling' a projection map by drawing shapes on the Output Transformation. Again, this is what output masks are for. First place your content where you want it, and then mask out the unneeded parts. All other options would result in warping of content.

We recognize and understand that the current masking options are limiting and can sometimes prevent you from getting the result you need. Giving you the right tools to let you do what you want is an ongoing process and takes time. Most of this time is spent figuring out exactly what options you're missing. Proposing quick solutions that involve bending other options to make them do what they're not meant to do, almost always works counter-productive. The best way to help development is to just give us good use-cases of what you want to do and how the current toolset does not allow you to do it.

But a disabled mask between two blocks of crop masks breaks all the crop masks, shouldn't a disabled slice or mask have no effect on the rendering - like the disabled mask would not even exist?

That is indeed broken behaviour. I'm not sure if I understand how its relevant to the problem of mask order that Oaktown is running into?

So let's take Oaktowns example where 4 slices are palced in position, then a lot of inverted Output Masks (crops) are used to show only certain areas.
These masks are in a continuos block.
So now you decide that a mask somewhere in the middle may not be needed so you switch it off, to see the end result.
What you see is all the crops disappearing because the block is broken in two, with no overlaps between the two blocks, just the disabled mask which you'd expect to have no effect whatsoever on the rendering, because it's disabled.
You have to move the Disabled crop mask out from between the two mask blocks to the top or bottom to be able to view the end result.
I hope you can see my point.

Joris wrote: I'm not sure if I understand how its relevant to the problem of mask order that Oaktown is running into?

As I saw the project he's working on, I think he tried to solve his problem with the input masks.
These are walls with 3 projection surfaces each, where the wall between the surfaces needs to be black, but the 3 surfaces must keep their position so one wall (and the 3 surfaces) is projected from one slice.
And he tried to modify the slice mask on the output stage, where he can see the end result to match the 3 surfaces.

Well, I guess in a way you could argue that it's the same problem.

By bypassing a mask between two other masks, essentially you create the same situation as placing a slice between two masks. There is then a a non-masking object breaking up the combining of masks.

The first mask creates transparency everywhere except in its area, the second disabled mask breaks the combining, so the third mask creates transparency everywhere except in *its* area, including creating transparency in the result of the first mask. Result: complete transparency.

Keep in mind that this behaviour is essentially mathematically correct. When you first create transparency everywhere except the bottom left side of the comp, and then create transparency everywhere except the top right side, your net result is transparency everywhere. We already are jumping through hoops to let you combine masks to get the current behaviour in the first place.

Joris wrote:

But a disabled mask between two blocks of crop masks breaks all the crop masks, shouldn't a disabled slice or mask have no effect on the rendering - like the disabled mask would not even exist?

That is indeed broken behaviour...

Joris wrote:Well, I guess in a way you could argue that it's the same problem.

Yes, it is, I tried to show you with the video what I mean exactly before reading quote#1 above.

edit: wait... Oaktown tried to edit an input slice mask in the output stage I mean (slice mask) that's a different thing