6
$\begingroup$

to make exactly clear what i want:

i want to use a scripted animation that uses live motion capture data for projection mapping.
it shall look like some sort of energy beams or electricity going out or into the body of the actor.
for that i rendered a set of png's that use alpha which i added as an image strip to make an animated texture with animall.

so far so good, everything is working.. with one exception.

wanting to do stuff live, i obviously don't want continuous rendering resulting in a mess of noise, so i thought - let's do it in material viewport shading in cycles

i added a node setup for transparency, which works fine in rendered mode. but to ensure that i can use tranparency in material viewport shading, i switched to internal, adjusted transparency settings and switched back to cycles. my problem: this results in transparent mesh, but the color of my texture is gone. why is this and how can i prevent it?

blend file:

enter image description here

i took a second look at the background plane and i noticed that the loss of color appears when the plane's material color is set to black. when it's white, the texture appears blue, although it's hard to see. my goal is to achieve transparent mesh with a texture fading to alpha in viewport material mode, that keeps the blue color no matter what background plane there is. having to use a white background makes transparency obsolete in my case.

why is this happening?
is there a workaround? (like really fast live rendering without noise that doesn't look too bad?)

$\endgroup$
4
+50
$\begingroup$

Short answer

It won't work. Your technique has a fundamental problem that I'll explain below, but even if your technique was correct, some limitations of Blender's viewport will make impossible to produce the correct result.


Long Answer

Why the method you used wont work:

You say you used pre-rendered PNGs as source, and that's the problem.

PNGs use unassociated (often called "straight" alpha), which is inappropriate for compositing light effects. The explanation is rather simple: A lighting effect, such as fire, electricity arcs, laser beams, etc.) is a purely emissive phenomenom, so itt's basically an addition (the light source adds luminosity but doesn't occlude any of the background).

When you use an unassociated alpha image (like your PNGs) every pixel with alpha > 0 will occlude the light coming from the background. The phenomenom you're trying to reproduce shouldn't occlude any light from the background, so its alpha has to be 0.

But in unassociated alpha images, there is no RGB information where alpha is equal to zero, as that information is discarded by the alpha over operation for unassociated. What you need is an associated image (often called "premultiplied), that lets you have RGB where alpha is equal to zero for this kind of effects, that need pixels that are luminous but don't occlude the background at all.

For that reason, PNG won't cut it.

The proper way to composite luminous effects:

If you use instead EXR images you'll be able to produce lighting effects that can be mixed with the alpha over operation as if they were a pure addition. Just render your lighting effects on black, use a "set alpha" node to assign a 0 value (black) to the alpha channel and save as EXR, and you'll have some nice lighting effects ready to be composited.

Why it won't work anyway:

Blender's viewport, and to some extent cycles have some limitations regarding alpha manipulation. The materials view does some funny things flipping between associated and unassociated alpha, which results in RGB with alpha zero being lost before it gets to your screen So, even if you try to produce the right shader with cycles (which could work in the compositor), the material view will kill it. Your best bet is cycles with a good GPU that can keep up the pace needed for realtime preview.

Since the phenomenom is purely emissive, you need an emit shader which is extremely fast to render, and the good news is that you need a few samples to get it rendered. Noise shouldn't be a problem (just use 8 for start resolution and one sample for preview, it will be fast and noise free).

The bad news is that cycles has some problems producing a proper output from a shader constructed with an alpha-driven mix where pixels have to be luminous, so you can connect the nodes in cycles to produce a luminous premultiplied image, but it won't render correctly.

But wait, there's hope! :-)

Not everything is lost: If your ligthing effects are purely emissive and you don't need any occlusion (which means, all your alpha will be zero), you can create the effect with cycles.

First you have to create an emission shader using the ligthing effects rendered on black background as texture, then you need to ADD that shader to a transparent shader using the add shader node. The output will work in the cycles render view and it will be fast.

It won't work in the materials view, though. It will render white.

$\endgroup$
  • $\begingroup$ I'm going to try this out the next time i'm on my pc, but your answer sounds very promising. thank you, that gives me some hope, as emission is what i wanted to do in the first place, but thought it won't be fast enough in rendered view. that opens the possibility for way better results, as long as it is somewhat smooth and if not, i'm going to get a new gpu someday anyways. great answer, thanks for your efforts! $\endgroup$ – e-proxy Feb 13 '16 at 1:18
  • $\begingroup$ What you are saying is correct, but you have to keep in mind that when viewing in material view, cycles doesn't account for the light put off by emissive materials. This makes achieving that effect through viewport impossible, no matter which kind of image you use. However, she only asked for why her solution worked, and consequently, in her blend file was using a diffuse material, so I assumed she didn't want it to put off light. If you want the light to be put off onto the objects of the film strip (properly) she would have to recreate the person with a mesh for the light to hit. $\endgroup$ – Uncle Snail Feb 13 '16 at 1:33
  • 2
    $\begingroup$ Uncle Snail: - e-proxy's solution didn't really work, it only masked the problem. - Showing the result in the viewer isn't technically impossible. It's impossible in Blender because it's not dealing with alpha channel properly. - Saying that the viewer doesn't account for the light put off by emissive materials is inaccurate. There's no difference between light emitted by a light source or bounced by a surface for the camera. If it's a pixel it represents light emission. $\endgroup$ – Gez Feb 13 '16 at 3:29
3
$\begingroup$

This answer may help just for reference purposes, but all of it's contents may not be accurate. So read on if you want.

That is just an illusion created by light. It looks like there's less light because darker colors appear less saturated than lighter colors. That is why it looks like the color is drained.

The reason your solution works is also quite simple. The Blender viewport does not render accurately. If you change the transparency color to black, then press render, it will not be transparent at all. The transparent parts will be black.

Why does this matter? In the viewport, the transparency shader is counted as transparent, and looks transparent, no matter what color it is. However, when there is part transparency, where the transparency is fading out (like on your glow), the render in the viewport will not appear transparent at all. (but instead appear black, like it should, before cutting off entirely.) Now remember, as the glow fades out we get more transparency, NOT less color!

This means that when there is part transparency in the viewport, Blender calculates whether it should be transparent, and because of the black color, decides it shouldn't. This makes the color appear in full again, because the transparency was fading out, not the color. Therefor, if the color is set to black, in the viewport it will appear the same over black and white, but rendered, it will not.

You will still have transparency in parts of you image, but no matter what surface it's on, it will look the same, because it is surrounded by a black outline (even on a white surface), and does not fade out, leaving full saturation color.

I hope you understood that, but I sounded a little confusing, so below are some illustrations.

On top, we see how a white or black background can change the appearance of colors (which is explained by many reasons), and on the bottom, we see a comparison of a Blender viewport render when transparency is set to black, compared to white. Note that in the first image, it is all eye illusion, and all rendering an colors are correct. In the second image, note how the edges of transparency don't appear transparent, but black.

enter image description here

Hope this makes sense. Thanks.

$\endgroup$
  • $\begingroup$ thanks a million! i didn't knew how to deal with this for the past days and it made me mad. you served a perfect answer that is easy to understand and very visual, so thank you for your time and efforts, sir! $\endgroup$ – e-proxy Feb 12 '16 at 18:25
  • $\begingroup$ This is incorrect. Lightning effects are purely emissive phenomena, and the model of occlussion/emission of alpha compositing can only work properly if there's no occlussion at all. Emission with no occlussion is impossible with associated alpha images (PNGs are), hence it's impossible to produce correct lighting effects from a PNG texture. Read my answer for more information. $\endgroup$ – Gez Feb 13 '16 at 0:30
  • $\begingroup$ Sorry, I meant "it's impossible with unassociated alpha images (PNGs are)". Associated is the way to go. $\endgroup$ – Gez Feb 13 '16 at 1:55
  • $\begingroup$ I'm not an "expert" in any way, but in this case, I think, because when alpha is <0, there is no emission (mix shader is all toward transparent) the color data from the image will not need to be used, which means premultiplication should not be necessary. Is it needed because of something to do with the viewport? $\endgroup$ – Uncle Snail Feb 13 '16 at 2:03
  • 1
    $\begingroup$ No. It depends on the alpha format: Unassociated (Straight) alpha foreground will be pre-multiplied by the alpha-over operation, resulting in no RGB where alpha is zero. On the other hand, Associated (premultiplied) alpha doesn't get pre-multiplied by the operation (it already is), so it's only an addition over the occluded background. If the viewport dealt with associated alpha properly, you'd get a proper compositing of lighting effects with associated-alpha images (the one true emission/occlussion model) $\endgroup$ – Gez Feb 13 '16 at 3:34
1
$\begingroup$

Realtime OpenGL Composition in VSE

Maybe this solution is also interesting for you: As others pointed it's difficult to compose transparency in the 3D OpenGl viewport. So why not split your two elements in two scenes and composit them together with light-add-mode in blenders video sequence editor? VSE even plays back in realtime when in OpenGL-Preview Mode.

Blender Screenshot showing the result

So here is how to do it:

  1. Split your two elements (flash-effect and bg-plane) in two different blender scenes
  2. Link camera between the scenes, so they share the same animation
  3. In both scenes set "Render-> Open GL Render Options -> Alpha Mode" to transparent
  4. Create a third scene for compositing and switch to Video-Editing Workspace (VSE)
  5. Add new Scene strip and select Background-Plane Scene
  6. Add new Scene strip on top and select your flash-effect Scene
  7. Set the Blend-Mode of this strip to Add for additive color mixing
  8. In VSE-Preview-Side-Panel make sure OpenGL Preview is checked and set to "Material"
  9. You now have a realtime opengl preview of the two composed opengl-rendered scenes
  10. instead of clicking the cycles Render "Animation" button click the little clapperboard icon in VSE, which says "OpenGL-Render Active Viewport"
  11. If you want you can add other Strip Modifiers, or Effect Strips to correct color/contrast etc.

So maybe this helps! Cheers, Anton

$\endgroup$
  • $\begingroup$ i wouldn't have ever thought of this $\endgroup$ – e-proxy Feb 28 '16 at 20:21
0
$\begingroup$

If anyone has the same problem:
-> set the color of the transparency shader node from white to black !!

now it works

$\endgroup$
  • $\begingroup$ bounty is for anyone, who can explain me why exactly this is, how it works $\endgroup$ – e-proxy Feb 12 '16 at 17:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.