|
|
GLTools and Blending Recently I've been polishing up a new release of GLTools (including some performance tweaks, bug fixes, and several new patches, including arbitrary projection and modelview matrices, color channel disabling, and independent per-axis scaling), and I came across a slight fork in the road when it comes to blending. The built-in Line patch does not have control for blending. The line is always properly alpha blended (similar to what one would expect from the "Over" blend mode). There doesn't appear to be a way to additively blend line segments. Is there enough demand for additive blending of line segments? There don't appear to be any negative side effects, so it's just a matter of taste... The spline patch has also very problematic -- in Over or Add blend modes, slight 1-pixel overlaps happen while drawing, and these cause artifacts. So it's not practically useful to add blend control input to this patch. Should I leave it in anyway? So, what do you all think I should do about these controls? Should I add them in, even if they don't perform as well as expected? Should I remove them? Also -- the Blending input in QC is very limited; of the 110 or so blend modes in OpenGL, it only offers 3. Should we look into extending this port type? (it would then apply to all patches, even built-in ones, that used the Blending input) If so, which additional blend modes should we include? (since listing all 110 is a bit unsightly ;) |
Exciting... :)
Re. line blending: could you post some examples to illustrate the options, maybe? Re. GL Blend Modes: is there a list of the builtin modes? I can't seem to find one with example pictures...
a|x
These show Lines, Points, Triangles, and Quads in each of Replace (no checkerboard background), Over (checkerboard under), and Add (checkerboard + object).
With the line in Over mode, you can see the faint 1-pixel halo (looks like there is a side effect after all :( )
Point is now a circle inside a square of white -- I'm thinking points should be textured if you want circles anyway... though this certainly isn't uniform in GLTools yet (polygon mode probably has real circles still, since I haven't touched that patch yet)
Here's the blending stuff (you'll know it when you see it):
I'd say leave the problematic blend modes in, personally. Sometimes these slight glitches add to the effect ;)
Without a list of the other OGL blend modes, and no easy way to test them, I couldn't really say with ones should be added, to be honest.
Some more options would be cool though.
a|x
PS Idle thought: do the Kineme particle systems use glPoints? Just wondering if they could be textured, displaced in a GLSL shader. Can't test it right now, as I'm at work.
for an exhaustive list of opengl blend modes, you'll want to look up the inputs to
glBlendFuncBasically, blending in opengl is controlled with 2 operators: a source color function and a destination color function.
the source function can be one of the following values:
the destination function can be one of the following:
That makes for 72 possible combinations (there are 5 or 6 more possible values if some extensions are present)
As for what these do ...... I'll have to whip up a sample app/plugin or something I guess....
regarding particle tools in glsl: vertices can be displaced via glsl, but texturing won't work because vee sucks and doesn't generate usable texture coordinates (maybe there's an option for simple texturing, but as far as I've seen, it internally uses cooked textures and weird coordinates to simulate mipmapping and aging and animation or something.... but not a simple unit-square for plastering images on them)
A blend mode example app would be great. I have a suspicion that the most generally useful ones ARE the one Apple made accessible via QC's builtin patches, but I'd like to see the others in action, anyway.
Re. the particle thing: Does that mean that textured Kineme Particles aren't possible then? That's a shame, if so. Just out of interest, does the particle system you ported make use of images stored in a VBO to keep track of particle properties? Was skimming and article on that technique the other day.
a|x http://machinesdontcare.wordpress.com
Most of the useful ones are indeed what apple included -- however, there are subtle variations on what they've included that I believe remove the antialias halo (which is mostly what I'm interested in). Many are degenerate (GL_ONE and GL_ZERO, primarily), but there are some interesting effects that can be had by tweaking them.
Re. particles: not possible until we rewrite the particle engine ourselves (which should also make it considerably faster, as well). It tracks particle properties via an array of floats -- no GPU acceleration (until OpenCL comes out, it's very cumbersome to implement a proper hardware-accelerated particle system using just VBOs, and spilling across the bus for that one force you just can't get working on the GPU would harm performance.)
In the future, we're also planning on fleshing out the particle tools to include "agents" (particles that react to surrounding particles) -- this isn't possible at all with VBOs, so it would have to be CPU-only for the time being.
Oh, agents sound interesting. I made a start on a JS boids implementation the other day. Didn't get very far, but I may come back to it someday.
a|x
....alot of the "look" of GL blend modes can be achieved with what is already inside of QC- but being able to flip from one style to another quickly can make for some fun, dramatic changes. I think it would be a definite plus.
Do you find that artifact appears whether or not you have depth testing off?
It's there when depth-testing is in any value -- it wiggles when the window resizes. When the line's alpha is set to 0, it still renders the line, but the halo is gone (rather, the halo and the line are the same color and opacity).... this is completely bogus and wrong.
Even if the other blend modes can be accomplished, I guess what I'm really after is an over blend mode that does what it says, rather than whatever it's doing (one of the blendfunc functions is incorrectly set to disregard an alpha channel or something)
There is also the variation allowed by the glBlendEquation function, so you can take the 72 combinations you mention and multiply it by 5 to get all the permutations including this function's variation.
(Though if we are considering swizzling the QCColorPort, might we be able to redefine it as three index ports / dropdown menus, one each for source function, destination function, and blend equation, rather than having one huge list?)
Personally, I'm most interested in seeing just one additional blend mode in QC: Subtractive.
glBlendEquation is a separate state from glBlendFunc. Thus, we can extract glBlendEquation's states and make a macro patch out of it. (secretly, I just did this a few minutes ago in GLTools 0.5 ;)
this gets us back to 72 total combinations, and more importantly, gives us subtractive blending without hacking the blend port. Looks like that disaster is averted until 0.6 I guess :)
expect a release in a few days.
This would be a good time to coin a law: "When you're sure you've read about every last OpenGL function, there's one OpenGL function left to read about"
Brilliant. Looking forward to it.
It is funny....since this post, I have been working on a .qtz that I think can make real use of this, as I can't seem to find the "right" blend mode.