On Jan 8, 2011, at 2:06 PM, Ben Supnik wrote:
> I think bled interior-color _does_ work in the non-premultiplied case, that is, if linear interpolation is the problem, bleeding out the interior color should fix the artifacts. This works for us in X-Plane. It also lets you adjust color without alpha.
>
> The only thing it doesn't address is the quality of DXT compression, but frankly, there's not much you can do about the quality of DXT compression...it was nice several years ago.
Oh ya, I forgot to touch on that. What my routine does right now is only set edge pixels with 0 alpha that have nonzero neighbors. It sets any isolated 0 alphas to 0 (black). So very few of the pixels are going to be affected, probably something on the order of 4*sqrt(N)/N for the edge pixels, say 1024/65536 pixels for a 256x256 texture, so I guess it's a O(1/sqrt(N)) thing and the overhead will fall rapidly for bigger textures. It's kind of a hack right now I suppose, but will probably be how the batch script works if I ever write it.
>> For me, this means that both modes are suspect, and subjective. I
>> actually consider this a big flaw in OpenGL, and the engineer in me
>> is screaming that maybe it's time to revise how the blend mode in
>> OpenGL works so that interpolation into a 0 alpha considers the color
>> channel undefined for that pixel and uses the color of the neighbor.
>> This case has almost certainly come up in DSP and I bet there are
>> analogs in other disciplines but again I digress.
>
> Uh, what exactly would you put in the rendering pipeline that would solve this problem? Would it be fast? Would it add cost to hardware?
>
> I probably shouldn't jump on you for this, but this isn't the first time that you've hit a complexity in OpenGL, posted to the list, and then declared that there is a design flaw in OpenGL.
>
> The issue isn't the blender ... the issue is whether texture sampling and interpolation is done fully before blending. If it is, then the texture interpolater is going to make a smeared mess and no blending mode will fix it. But I'm having trouble imagining a design where texture interp is deferred without seriously impacting fill rate.
Ya hmmm I think you are right. This is Adobe's problem (but what isn't these days hahah). Just for a thought experiment, if there is a red pixel next to a black pixel, both at full alpha, and you begin to reduce the alpha of the black pixel, then it will near a limit of the scaled interpolated center pixel being [0.5 0 0 0.5], which is correct but unexpected for novices. I think that maybe I was imagining a mode more like the "transparent" mode 36 of CopyBits() from the Quickdraw days, a mode that would special case fully clear alpha to interpolate to "clear" from each of the 8 neighbors (basically repeating their color values). I just wonder if there are maybe cases like this that if they existed, we may not even need the GL_ONE mode at all. But, it's not a mathematically "pure" function and I guess even I probably wouldn't get behind it hahah.
As far as things like fill rate...I'm not even sure anything the GPU does anymore even matters. They could probably do 10 times what they do now with very little hit to performance if it's all pipelined. Part of my complaint I guess is that fragment shaders aren't powerful enough to express what I want to do. Before I knew how they worked, I thought I would be able to load and store the source and destination pixels like registers. Sadly, not being able to get the value of the destination pixel, severely limits most of the fx I would like to do that I used to do with blitters. The simplest example being things like stencils where you only draw on certain colors of the destination. I guess I just want full control, basically a 256 core DPU (DSP-CPU hah) where I can do whatever I want on each core. Such humble dreams...
>> If Adobe could make its developers aware of this issue and fix their
>> save functions to preserve the 0 alpha pixel color, it would prevent
>> a lot of grief and lower the steepness of a big learning curve in
>> OpenGL.
>
> This I agree with...the PhotoShop save mode is wrong for most texture uses, and PhotoShop is heavily used in the game space. I recommend GraphicsConverter as a nice way to inspect what's going on in alpha.
> ...
> Right - this is a tool chain issue, like PhotoShop..that's how game dev is...tool chains often need to be modded, hacked, and worked around for a particular complete pipeline into a particular engine. We were frustrated with PNG premultiply on iphone (I think there is some flag you can set to turn it off but we never got it to work) but we ended up storing uncompressed images in PVR containers anywhere for a faster unified loader.
>
> One last note: in X-Plane we actually do the 'color splat' (filling nearby 100% clear pixels with the color of a non-clear pixel to fix PhotoShop weirdness) in-game in our png loader. Since all png loads run on a second core on the desktop, we thought we could afford it. But for pre-converting PNGs to DDS or some other format we do have to address the problem in tool chain (because we can't "fix" an incorrect-color DDS later).
I'm glad to hear that I'm not the only one doing this stuff, especially from a project as high profile as X-Plane :-P
--Zack
"Go to the edge of the cliff and jump off. Build your wings on the way down."
- Ray Bradbury
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

Apple Footer

This site contains user submitted content, comments and opinions and is for informational purposes only. Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.
Apple