Scratch-render: Brightness + Color effect doesn't work the same as Scratch 2

Created on 1 Jun 2017  ·  8Comments  ·  Source: LLK/scratch-render

Expected Behavior

_Please describe what should happen_
Scratch 2, if you set brightness effect to 100 and color effect to 50, this is what you get
image

Actual Behavior

_Describe what actually happens_

In Scratch 3, you get all white (I added a background so that you can see it).
image


This bug is a simplification of a problem I had when opening this project in scratch 3 https://scratch.mit.edu/projects/1270935/
It should look like this
image

And instead looked like this
image


cc @cwillisf

bug compatibility needs-triage

Most helpful comment

Projects mostly use the brightness effect to transition to and from white and black, so I think it would make the most sense to match the 2D renderer of Scratch 2. Sprites becoming white was also the original behavior before we had to add the 3D renderer, and the bug LLK/scratch-flash#570 was created because the 3D renderer was "wrong": https://scratch.mit.edu/discuss/topic/73118/

All 8 comments

I'm still seeing some strangeness with Brightness but it's a little different from what's listed above. It looks like project 1270935 is working properly. Also, brightnesses between -100 and 0 are behaving as expected.

For brightnesses between 0 and 100 it looks like it is getting brighter, but not all the way white as it does in 2.0.

Here it is in 2.0:
brightnesstest2 0

And here it is in 3.0:
brightnesstest3 0

I used this project: https://scratch.mit.edu/projects/276912470/ to test this.

/cc @kchadha @ktbee @cwillisf

I found something weird. If you use just the brightness effect on a sprite in scratch 2, it looks like this (0 to 100)
Scratch 2:
screen shot 2019-01-09 at 22 32 37

However, if you also use the color effect on any sprite, all of the sprites change to look like this:
Also Scratch 2:
screen shot 2019-01-09 at 22 32 14

And that's what the brightness effect looks like in Scratch 3.0 right now
Scratch 3:
screen shot 2019-01-09 at 22 29 56

@cwillisf when the color effect broke things last time you said it was something to do with the rendering engine?

Found a relevant thread with useful code links: https://github.com/LLK/scratch-flash/issues/570

Note though that HSV vs HSL isn't the problem here though. Here is 1) the current brightness effect, 2) the brightness effect using HSL, 3) the brightness effect in Scratch 2. Neither 1 nor 2 match 3.
screen shot 2019-01-09 at 22 30 45

Maybe relevant: https://scratch.mit.edu/projects/269088736/#comments-105915881

TL;DR a positive brightness effect doesn't seem to have an impact on a costume whose fill colors are already 100% brightness (i.e. the sliders show brightness = 100). I think the brightness effect in 2.0 is more like "mix with white (or black)" rather than "adjust brightness component"? I haven't done testing though.

I found something weird

Good find, @fsih! Adding a color effect to the project causes Scratch 2.0 to switch to its 3D rendering mode, so that explains why the difference shows up when it does. It looks like the 2D and 3D renderers in Scratch 2.0 work very differently for the brightness effect. This is true for several of the graphical effects: for example, the whirl effect reverses direction.

Unfortunately I don't have a strong sense of which version of the brightness effect most projects want; my guess is that most projects end up using the 2D renderer but I'm not certain.

The brightness effect in Scratch 3.0 seems to match the 3D renderer in Scratch 2.0 but doesn't match the 2D renderer in Scratch 2.0. If we decide to match the 3D renderer then I think we're already done; if we decide to match the 2D renderer then there's some shader work at least.

Projects mostly use the brightness effect to transition to and from white and black, so I think it would make the most sense to match the 2D renderer of Scratch 2. Sprites becoming white was also the original behavior before we had to add the 3D renderer, and the bug LLK/scratch-flash#570 was created because the 3D renderer was "wrong": https://scratch.mit.edu/discuss/topic/73118/

@cwillisf @fsih Matching the behavior of the 2D renderer makes sense to me. Thanks for the investigation!

Was this page helpful?
0 / 5 - 0 ratings