Upon selecting the camera or sound layer, all other layers have a slight transparency, but this is not desirable behavior.
When the camera layer or a sound layer is active, all layers get a slight transparency applied to them.
The expected behavior when the camera or sound layer is selected is no transparency or filtering of any kind within the render area. It should display _exactly_ what the camera would render (esp. for the camera layer). This transparency is normally applied to all other layers so you can focus on the strokes in the selected layer, which makes sense for bitmap and vector layers but not for sound or camera layers. When the user selects the camera they are conveying that they want to focus on what the camera would render, which is all of the layers not none of the layers.
| | Current Behavior | Expected Behavior |
| --- | --- | --- |
| Viewport
(Camera/
sound
layer
selected) |
Red value: #FF3936 |
Red value: #FF0000 |
| Render |
Red value: #FF0000 |
Red value: #FF0000 |
@scribblemaniac Ah. I somehow knew this was going to be brought up after re-reading my own comments on the other issue.
This is not a bug. It's the relative transparency system in effect. I talk about it here:
https://www.youtube.com/watch?v=GJFW9hzny_M
To make it render "fully opaque" you just have to press the top timeline circle and make it tint black, instead of grey.
I would totally agree that this is not an obvious feature. At all. But it is a working system and in the near future we would need to mix this with individual layer opacity sliders to get the most out of simulating transparency while drawing for animation.
Edit: The explanation for this feature is that when you are drawing with real animation paper, usually this paper has slight transparency due to it's layering process, enough for you to rough out your animation without needing a light table.
Yeah your absolutely right. Hopefully the timeline rewrite will make some of this a bit more obvious.
Just watched your video and it changed my mind: this is still a valid bug. The very first thing you do is go to a camera layer and it shows 'how it would look if it was rendered'. I don't see why this feature was removed, it seems quite intuitive to me.
@scribblemaniac Now that you mention it, I can see now what you mean. Just testing it though I noticed something. When you click on the first bitmap layer that comes with the file, it exhibits the same behaviour as if you clicked the camera before. Making other layers fully opaque "as if rendered". Sigh, I think when they rewrote the camera layer rendering order they erroneously changed the layer index properties.
I was going to make a request later on about changing this to a relative thing, but after investigating the old PCL files, it seems Pencil has an inner system where each layer gets an absolute numbered index. So no matter what you do it's always the same layer index for each individual layer, and if you delete a layer it will just continue counting. So my really vague guess is that the first bitmap layer has the index that was associated with the "make fully opaque when clicking" function. I have no clue about the code involved tho.
You can try it too: open a new file, draw something on the first bitmap layer, then create a new bitmap layer, and draw anything else. Then click on the new layer, and the first bitmap layer back and forth and also on the camera layer. Can you see what I mean?
If you want to check the index I'm talking about, save the file with PCL extension, which is a glorified XML file, and look at the properties. Anyway I'm out, it's past bedtime for me and I gotta work tomorrow. Talk to all of you soon!
Am I correct when I say that the issue that persists, is that when you select a camera layer, all layers are rendered translucent instead of fully opaque?
If so, then an upcoming PR should fix that ;)

Closing, this issue was fixed with #660.
Most helpful comment
Am I correct when I say that the issue that persists, is that when you select a camera layer, all layers are rendered translucent instead of fully opaque?
If so, then an upcoming PR should fix that ;)
