Domanda

C'è qualcosa di insolito come il componente alfa viene gestito in un pixel shader? Ho un'applicazione WPF per la quale il mio artista mi sta dando le immagini in scala di grigi da utilizzare come sfondi, e l'applicazione colora le immagini in base allo stato attuale. Così ho scritto un pixel shader (utilizzando l'infrastruttura Biblioteca WPF Pixel Shader Effects) da utilizzare come un effetto su un elemento immagine. Lo shader ha un colore come un parametro, che si converte in HSL modo che possa manipolare luminosità. Poi per ogni pixel grigio, calcola un colore cui luminosità viene interpolato tra il parametro di colore bianco e in proporzione alla luminosità del pixel sorgente.

float4 main(float2 uv : TEXCOORD) : COLOR
{
    float4 src = tex2D(implicitInputSampler, uv);

    // ...Do messy computation involving src brightness and color parameter...

    float4 dst;
    dst.r = ...
    dst.g = ...
    dst.b = ...
    dst.a = src.a;
    return dst;
}

Questo funziona bene sui pixel in cui alpha = 1. Ma dove alpha = 0, i pixel risultanti escono bianco, piuttosto che avere spettacolo lo sfondo della finestra attraverso. Così ho fatto una piccola modifica:

float4 main(float2 uv : TEXCOORD) : COLOR
{
    float4 src = tex2D(implicitInputSampler, uv);
    if (src.a == 0) 
        return src;
    ...

e ora le parti trasparenti in realtà sono trasparenti. Perché? Perché l'affermazione dst.a = src.a nella prima versione non ha realizzare questo? Purtroppo, anche questa è solo una parziale correzione, perché sembra a me come i pixel con 0

Qualcuno sa che non ci sto capendo su Alpha?

È stato utile?

Soluzione

Dopo un po 'di più la ricerca web, ho scoperto il pezzo che mi mancava.

un articolo su MSDN : "WPF utilizza alpha pre-moltiplicato in tutto il mondo internamente per una serie di motivi di prestazioni, in modo che anche il nostro modo di interpretare i valori di colore del pixel shader personalizzato."

Quindi, la correzione risulta essere di gettare in una moltiplicazione per alpha:

float4 main(float2 uv : TEXCOORD) : COLOR
{
    ...
    dst.rgb *= src.a;
    return dst;
}

E ora la mia uscita appare come mi aspetto che.

Altri suggerimenti

  

0

Quello che spazia si aspetta qui?

Tutti i valori saranno compresi tra 0.0 e 1.0 ... pixel shaders non funzionano in discrete 256 gamme di colore, sono punto galleggianti dove 1.0 è l'intensità massima.

Se i calcoli finiscono per impostare i valori di R / G / B a> 1.0 che si sta per ottenere il bianco ...

http://www.facewound.com/tutorials/shader1/

Amico Sto lavorando su un gioco XNA, e ho dovuto usare uno shader in scala di grigi pixel e ho avuto lo stesso problema si sta affrontando. I Donno se si ha familiarità con l'ambiente XNA o no, ma ho risolto il problema modificando il SpriteBatch di disegno SpriteBlendMode dal SpriteBlendMode.None a SpriteBlendMode.AlphaBlend , spero che questo può aiutare a sapere il motivo.

saluti,

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top