My first Plug-in problem! Blending modes

Is it patch or a plugin?

Sorry George for not being clear enough:) it's a plug-in (Standard API)

In your .h file:

@property (assign) NSUInteger inputBlendMode;

In your .m file, make sure to declare your input property, and sort your inputs if need be.

In your attributes:

if([key isEqualToString:@"inputBlendMode"])
   return [NSDictionary dictionaryWithObjectsAndKeys:@"Blending", QCPortAttributeNameKey,
                [NSArray arrayWithObjects:@"Replace", @"Over", @"Add", @"Alpha", nil], QCPortAttributeMenuItemsKey,
                [NSNumber numberWithUnsignedInt:3], QCPortAttributeMaximumValueKey,
                [NSNumber numberWithUnsignedInt:3], QCPortAttributeDefaultValueKey,
                [NSNumber numberWithUnsignedInt:0], QCPortAttributeMinimumValueKey, nil];

...or where the default is, whatever you wish.

In execute:

if(self.inputBlendMode == 0)
         glDisable(GL_BLEND);
      else if(self.inputBlendMode == 1)
      {
         glEnable(GL_BLEND);
         glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
      }
      else if(self.inputBlendMode == 2)
      {
         glEnable(GL_BLEND);
         glBlendFunc(GL_ONE, GL_ONE);
      }
      else if(self.inputBlendMode == 3)
      {
         glEnable(GL_BLEND);
         glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
      }

...and then at the end, wherever you're disabling stuff:

   glDisable(GL_BLEND);

Oh yeah, I did want to make a point/distinction, because of the way you phrase what you want :

"As same as the KinemeGL render patches"

...if you look at the last published GL Tools code, you'll see that in the skanky API, there's any rendering patch can take advantage of replace/over/add blend modes in QC by having:

   QCOpenGLPort_Blending *inputBlending;

...in the interface, then in the execute method, you :

      [inputBlending setOnOpenGLContext: context];

...and then later, unset. Nerdy distinction being, that this is just a QC thing that the Sprite, or Billboard, or whatever, use in the programming of the patch, without actually writing out the blend mode stuff that one does in QCPlugin.

This distinction is semi-important, because one should note that a blend port that you implement in QCPlugin doesn't get the freebie Alpha mode that something like AlphaBlend.plugin alters the QC Blend port to have. That only works for QC patches, and skanky patches.

So, whether or not a system has alphablend.plugin, your QCPlugin will do alpha blending once you set it up... this runs totally parallel and apart from that blend setup.

A small thought though... how are you planning on doing the ovals (circle?)? Is it from building multiple triangles, or with a polygon and a shader? I think I'd try it with a shader...not to try to impact your choice or anything, just curiosity. I found myself thinking about this in the back of my mind while eating a little bit earlier ... "hmm, how would I make a circle that had to be at any resolution on the edge and still be quick?" I do remember the one thing that sucks a bit about the stock "circle" virtual patch is that it's pretty slow, so I guess I'd be looking to improve on that.

Once again, Cheers George for sharing your wisdom! ;)

I've always missed a good oval patch in QC from the beginning. I used to use Franz's circle plug-in, placing it in a 3d transformation and then scaling it to have a oval (I know, it's probably the dumbest way :D ). The thing with Franz's plug-in was that it didn't make "Filled" circles (Nothing like what Processing and such programs make).

I've recently started my blog (http://holescapes.wordpress.com/category/visual/). I've started posting about QC and Processing and how these two relate, So the need for a proper ellipse plug-in that generates what Processing does became more obvious.

I looked at OpenFrameworks and Cinder's source code (As you know they both use OpenGL for drawing purposes) and found out that they both use the same method and that was to use a VertexArray and "Triangle Fan" to draw the ellipses. That's the method I'm trying to use in my Plug-in.

A shader is a great idea, you should definitely try that!!

BTW I tried the code you mentioned in your first post and it didn't work for the "GL_Triangle_Fan". it worked for "GL_Line_Loop" but for some reason darkens the color.

I attached the project, it will be splendid if you could have a look George. I'd appreciate it alot :)

The reason I suggested a shader was because as you increase "resolution" on your circle and jack up the amount of triangles, you'll get an effect that's a lot like taking the sphere and decreasing stacks/slices. In order to get it to look decently circular, you'll have to use a handful of triangles. That said, the triangle route could be cool because of that fact, and also because it would reveal in wire frame.

My guess is that QC has the sprite/billboard and a gaussian as well as CICircle with it's edge smooth, because it's likely to result in a smoothed edged circle without bogging down performance with verts. (If you're writing about the dif between Processing and QC can you please point out the horribly small resolution render windows that people are used to looking at in Processing, and how that affects people's perceptions of performance?)

I'll take a look at the attachment a bit later on today...

If you are into processing. I made a java jni project. It is in the repository here on kineme. It let's you load a cocoa view like a qc view into java. Still looking at a better way to do this or be able to share contexts between qc and processing. Im thinking that an iosurface syphon approach may be the ideal solution for this. As it is now you can take the jni lib and use it in a processing app. Or you could use both processing and qc in eclipse by extending processing pa applet and importing the jni lib to your project. This will not help you draw circles any faster but thought it may get you started using both apps together.

@George:

As you said, each has its own pros and cons. Yes, the resolution will definitely be a problem with this method and even with large amount of vertices, it still looks aliased. Alpha blending will help with that a lot though (1024_Circle is a proof). Also the sole fact that Cinder and OFx use this method could be an excuse to try this method :)

I think using shaders is a cool idea as well.

QC's circle is good looking but it's a performance killer, especially when the radius is changing rapidly.

You're right about Processing's small windows, that actually use to bug me a lot when I moved to Processing from QC :D but nowadays there are some OpenGL libraries available for Processing that boost the performance and widens the render windows ;)

Can't wait to know your opinion on the attachment...

Hey dust!!

Yeah, I remember you work on that subject.

Whenever I think of connecting Processing and QC something similar to Vade's OFx plug-in for QC and Memo's QC library for OFx comes to my mind. But I remember from the post you mentioned, that someone said it's nearly impossible to do such thing.

With that out of the way, the next approach as you said is a iosurface syphon-like .

Don't even know how eclipse works but will have a look.

Thanks for your suggestions!!

I think it's just where the blend stuff was happening in the code. After some shuffling, this looks like it works fine to me (check attachment).

cool yeah. i wish i could get memo's qc ofx bridge running. got vades ofx 2 qc to work though. a bit tricky sometimes ofx is to build various projects. i hardly ever look at processing to tell you the truth. like george said the debug window is way to small. seems kind of silly to build things in the processing IDE if you have xcode or eclipse etc..

Thanks George!

How do you think we can smooth the outlines of the filled circle? The non-filled circle looks pretty good (with Alpha Blending) but the filled circle still looks pretty aliased, I think it's related to the Triangle_Fan but can't figure out how to solve the problem.

(I think what I've attached is slightly better form than what I posted this morning, even though it doesn't make a big difference in the end result of the plugin. I just don't like that I did the push matrix, then color, then translate... it didn't feel organized how I think makes most sense.)

As far as the edges go, I don't know. The edges look pretty good on my system! Do you have multisampling enabled in your editor preferences? Maybe you could texture stuff, but I don't know if it's worth it or not.

You may want to experiment with the code that's constructing the fan. Do you see how when you put it in a polygon mode wireframe, all of the lines originate at one point, that's on the circumference of the circle? Maybe I'm wrong, but I would expect it the fan formula to have the triangles originate in the center of the circle. It seems like I've seen some tutorials online that do it with where the fan or triangle strip has a center origin, so that the subdivisions that you see along the edge of the circle are consistent in length. Now, segments get smaller as they get closer to the origin point, on the right side of the circle. Just something to consider...

You may wish to make a ton of circles, or iterate a bunch, and then see if your current width height method is quicker than using GL Scale. It may be that GL Scale for width and height is quicker in extreme scenarios... or it may not make a difference. The way I'm looking at it now, you're width and height stuff is happening in a loop that's going to go hand in hand with the actual resolution of the circle. The gl scale should be quicker, but you never know without testing.

You were right! I hadn't check the multisampling option, it looks much better now :) How heavy is it on the GPU by the way? Should I leave it on for everything?

I will experiment more with the code as you suggested, It definitely makes more sense if the lines are drawn to the center. And regarding GL Scale, I'll report back about the performance results.

Cheers!!