Something fishy about RGB matrix
Fersus
🖼️ 10 images Surveyor
Hi folks!
I had to put my mountain pass aside for a while, as I've to work on a prototype of a board game about grilling:
The board will consist of a circular shape with various areas that represent different food on the grill. My idea that allows for quick changes in which area is assigned to which food is to just make one sheet per food and make a RGB matrix effect on each layer that just changes the color of the segments that belong to this sheet. that way it's just matter of point and click to reassign certain areas by just moving them to a different sheet.
My setup is like this:
As you can see in the background, this works quite well, except: there should be already three colors: Huhn (=chicken), steak and fish.
For some unfathomable reason, steak just does not show. Here are the list properties of three segments (one for each of the aforementioned meat types):
+--Sheet: Huhn ----------------------
|
|2D Polygon: color 15 (white) layer 269 (Meat)
| line style 0 (Solid) fill style 1 (Solid)
| line width 0.00000 tag # 2244 pen :0.000 mm 2nd color 15
| smoothing method: No Smoothing
| start parameter 0.00000, end parameter 4.00000
| length 117.32510, area 598.07367, with 4 nodes:
| node 1 at 100.74915,-21.41517
| node 2 at 145.25484,-30.87527
| node 3 at 141.23195,-45.88946
| node 4 at 97.95882,-31.82903
|
+-----------------------------------------
+--Sheet: Steak ----------------------
|
|2D Polygon: color 15 (white) layer 269 (Meat)
| line style 0 (Solid) fill style 1 (Solid)
| line width 0.00000 tag # 2246 pen :0.000 mm 2nd color 15
| smoothing method: No Smoothing
| start parameter 0.00000, end parameter 4.00000
| length 117.32510, area 598.07355, with 4 nodes:
| node 1 at 102.43573,-10.76671
| node 2 at 147.68646,-15.52288
| node 3 at 145.25502,-30.87533
| node 4 at 100.74924,-21.41519
|
+-----------------------------------------
+--Sheet: Fisch ----------------------
|
|2D Polygon: color 15 (white) layer 269 (Meat)
| line style 0 (Solid) fill style 1 (Solid)
| line width 0.00000 tag # 2248 pen :0.000 mm 2nd color 15
| smoothing method: No Smoothing
| start parameter 0.00000, end parameter 4.00000
| length 117.32510, area 598.07361, with 4 nodes:
| node 1 at 103.00000,-0.00029
| node 2 at 148.50000,-0.00042
| node 3 at 147.68665,-15.52292
| node 4 at 102.43581,-10.76673
|
+-----------------------------------------
Save for the coordinates of the segments they all have the same properties.
I played around with different colors, copying the settings from Huhn and Fisch but steak never shows.
The only thing that I found that works is by putting a non white background behind the segments:
Does anyone know what's going on here?
Comments
I think you might be putting the numbers in the wrong boxes.
The first 3 columns are the ones to use.
Check out the presets. Unity shows the matrix set up for no change, and has a diagonal of 1's. There are other presets as well, but it's probably easier to get a feel for the matrix just by adjusting the Unity preset and see what it does.
Alternatively, you could use a Colorize effect.
Which areas are affected by an effect are computed by there being a difference between the background color and the currently-drawn color. Making the slices a color different than the background should work. In this case, the problem doesn't look like it's a problem with the effect setup, but with how the drawing under it is structured. I'm not sure why it's working on some sheets and not others, though.
@Sue: the Effect does exactly what I expect it to do (which does not mean that colorize might not be the better choice, I'll look into that). I learned from a blogpost from Monsen, that the first 3x3 changes the color as is, while the last entry in each row is just a flat addition. so by setting the 3x3 to all zeroes and just using the last entries, I reduce each segment to black and then set the actual colors I'd like to have (which sounds an awful lot like something a colorize effect might do ^^)
@Jslayton: I just used the first template in the wizard, ditched all the sheets and made new ones. I'll test if this happens with a different template as well...
Looks to me like the easiest way to have it working is to not use white as the base color of your polygons, but some other color. The color will be ignored anyway with your current RGB Matrix setup, and by not being white, you don't run intot he problem Joe describes of being ignored because it is the same color as the background.
I did just that, setting them all to a light grey and the problems disappeared. I also testet it with colorize, but this had the same problems.
After I set them all to grey both colorize and RGB matrix worked, however colorize was the inferior effect, as it did not overwrite the original (grey) color completely and a edge fade inner effect in combination with colorize lets the grey shine through while RGB matrix and edge fade get's the white I wanted to have, as shown here:
Both areas are set to the same color, both have the same edge fade inner effect, but the 3 segments are with RGB matrix and the transparency defaults to white while in the 4 segments area I used colorize and it shows the grey of the original segments.
I don't know why that is (and still don't get why some sheets worked in the original approach and some don't), but at least I can work with it now.
Thanks for all your inputs!
The RGB matrix effect reads each pixel color from the image, adjusts it by the specified matrix values, and writes it back. Colorize does the same thing with a matrix that converts the read pixel to grayscale and multiplies it by the color specified in the GUI before writing it back out, meaning that the underlying color will always contribute something to the final result. The RGB matrix that you're using here is a special one that discards all of the original pixel color and substitutes the new color specified in the right-hand column, so nothing from the underlying color will show through.
The problem with them not working on some of the sheets was most likely because the effects system couldn't distinguish the white of newly-drawn entity from the background of the existing image, meaning that the effects were never given a chance to operate on those pixels at all. The distinguisher is usually fairly robust for exactly the same color on new sheets, but this precise drawing may have hit an edge case in the underlying code. I'm not sure if that speculation helps with the problem you're having, though.
I see, thanks for the explanation!
I noticed, that when I placed the not showing segments from the "steak" sheet back on the "not assigned yet" sheet (that has no effects on it) the segments on the fish sheet lost the color. But as I neither have the means nor the inclination to change the code anyways, it does not really matter to me what exactly goes wrong, I just have to know what behavior to expect. So for me the information that I just have to change the color of the original segment or the background to get the result I wanted (and the explanation on why colorize and RGB matrix behave differently) is enough for me.
If anyone wants to delve into this and find the error, I'm happy to provide the file or any other information I can give!
One afterthought: Object with the same color as the background image are not processed, but that means that objects might get processed or not depending on the color of the view window! (I saw Ralf change the color on the last live mapping session, that's how I came up with that thought)
I somewhat understand that concept if there are two objects overlapping that are the same color. Even though different effects might as well make an important contribution to the map: In my mountain pass map I need the lower edge to throw a shadow, while the upper edge shall be covered by the shadows from the road above. A single entity can't do that, but "invisible" lines with the same color but with a drop shadow effect could do the trick. As I understand it, this is not possible with this rule in place?
But ok, I do get that this might be a useful rule for efficiency purposes. But having this rule in place depending on the background color of the empty canvas seems really odd. The canvas isn't even an object. This is just aesthetics. Having the aesthetics of the UI influence the behavior of sheets effects feels just really really wrong.
Granted I'm just a humble user just at the start of his mapping journey. So I might overlook something important why this situation should be as is, but please think about this again. For the time being my solution is to set the canvas to 254, 254, 254, which to the eye looks exactly like color 15, but does not interfere with the sheet effect, allowing me to use edge fade in conjunction with colorize on white objects as this is faster to adjust than the RGB matrix.
It doesn't have anything with it being an object or not. CC3+ needs to be able to tell where the edges of entities on the sheet is when applying effects. When CC3+ computes effects, it makes a render of the complete stack of sheets up to and including the current sheet in the rendering process, and then compares the image it gets with the same pass done with the below sheet. Pixels that are exactly the same between the two renders will be areas where the latest sheet didn't have any entities, so we are seeing the sheet below through these points, while pixels that have changed represent areas that the current sheet covers. Edges are identified as borders between where pixels change and not. Effects are then applied to the image, and CC3+ continues one with the next sheet in the stack
This may seem complicated since CC3+ should just know where the entities are, right? Well, that would be the case if it wasn't for the effects, because once you start applying these it gets quite complicated and CC3+ needs to actually do these renders to calculate where the effects stretches to. And multiple effects on a sheet also interacts with each other, making this quite complicated.
So, this isn't some arbitrary rule that can just be turned off. Changing this would mean completely changing the way CC3+ renders the drawing.
Thanks for the explanation, Monsen!
I tried to come up with some examples to test if I completely understand how CC3+ works in this instance, like covering an object with a directional shadow in the same color as the object to try and get CC3+ to "not see" the object and reproduce the same behavior (i.e. the colorize effect on the object does not get processed) but I couldn't. So obviously I still don't quite understand when this behavior leads to a problem and when not.
But that's not really a problem. The important takeaway for me is: there might be a "same color" issue, if something does not work as I expect it to, and so I'll check for this the next time this comes up before bothering people on the forum here ^^
Thanks for all your patience!