GT Structure Point and Line Structure Renderer Patches - Keyed Color

Wow!

George I can't tell you how happy I am that you got into plug-in making business :))

This is superb and I wish I was religious so I could "pray" for you to make more wonderful consumer-focused plugins.

Possible addition to these patches:

If there was a way to key the Point Size and Line With as well, that would be super cool. Anyway I think it will be splendid for the (line/point/triangle etc.) structure patches to have their inputs key-able through input structures. And we could definitely benefit from more basic shapes such as oval, rectangular (in keyed structure too hopefully).

I'm sorry George, I don't want the above lines sound like placing an order for plugins. I just thought this could be good place to post about these suggestions ;)

Cheers again mate!

BTW plugins are made via Xcode right? If want to start learning about the process, is learning Objective C sufficient or should I involve Cocoa in the process as well?

Should I learn C++ first or is it ok to go for Objective C right away? I know about OOP and how it works. I've also coded in processing as well but as you know they're in no comparison with the Mighty C World !

I've found this book, which says its a for beginners:

http://www.amazon.com/Programming-Objective-C-2-0-Stephen-Kochan/dp/0321...

Any suggestion will be highly appreciated!

Very cool....

How can I convert the indices in this JS to output keys to work with these patches?

var _Points = []
 
function (__structure Points) main (__structure Queue, __number yfactor, __boolean reset)
{
 
 
   var result = new Object()
 
   if (reset) _Points = []
   if (Queue != null) {
      var a = 0
 
         for (var i = 0; i < Queue.length; ++i) {
         var pos = i/Queue.length
         var yf = yfactor * (1 - pos) 
 
         _Points[a++] = [ Queue[i][0], Queue[i][1] + (yf *(1-pos)), Queue[i][2], Queue[i][3], Queue[i][4], Queue[i][5], Queue[i][6] ];
 
      };
 
   }
 
   result.Points = _Points
   return result
}

Actually this is the javascript snippet I am working with where I'm guessing it needs to change RGBA indices to keys. (This creates the queue before it gets passed on to the next -- like the dev mouse ribbon). I'm sure it's basic and although I am chipping away, my js skills have gaping holes in basic concepts. Please advise?

function (__structure points) main (__number inputX, __number inputY, __number inputZ, __boolean draw, __boolean reset, __number xTheta, __number yTheta, __number zTheta, __number lineWidthx, __number lineHeighty, __number R, __number G, __number B, __number A, __index queueSize, __number patchTime)
{
   if(reset || result.points == undefined)
      result.points = new Array;
   if(draw)
   {
      var point = new Array;
 
      point[0] = inputX;
      point[1] = inputY;
      point[2] = inputZ;
 
      point[3] = R;
      point[4] = G;
      point[5] = B;
      point[6] = A;
 
      point[7] = lineWidthx;
      point[8] = lineHeighty;
 
      transformPoint(point, xTheta*Math.PI/180, yTheta*Math.PI/180, zTheta*Math.PI/180);
      result.points.push(point);
      if(result.points.length > queueSize) result.points.shift(point);
 
   }
 
      return result;
}

I thought about line width, but consider this - a line doesn't "taper". Chris wrote a cool kind of attenuation scheme for GL Point, but because lines don't taper from one point to another, it looks pretty weird when the distance between steps is largish. You really see the place where one line meets the other.

I think triangle already accepts color... I guess you're talking about size then.

There are some glu basic objects that don't have texturing built in, but they do work with lighting...that might not be hard to use in this context. I was thinking about that.

Keep in mind that there is also the Kineme Structure Environment, which can render any shape at any position (though you can't do stuff like pass colors, unfortunately... though I was recently wondering if something like color matrix or channels could be controlled per Structure Environment instance. Might be a way to get that done.)

I'll take a look at this when i get a chance... I super duper hate js.

Why is that if / reset/ undefined stuff at the top?

It's cwright's solution from a larger js patch -- it's a reset button to clear the queue. If you are curious about the entire js patch have a look at the (abptly named) "MeshDraw" patch I just posted (see what you mean about generic names, though if someone did a search for mesh draw...) I hate js, too. Another (maybe nicer?) solution would be to mod your plugin to allow indices as well as keys.

I would mod the js in the example qtz I posted to have the values do the sin stuff you have going and then just use the normal queue. I don't know if that's an option depending on what you're doing with the values though... I'm not by a computer.

I admit, I had always wished there was a dedicated structure port for color that took plain indices but then the logic of what happens if someone is using that and also keying stuff with the other port gets weird. The color values of one of the ports would either get ignored, summed, multiplied, or ?

Well, users would have to know what's up with the ports, right? Index 0 = X, Indices 3,4,5,6 = RGBA, right? Having to know what works and what doesn't seems common enough already. Though I appreciate the "ease of use" design aspect.

Anyway, re: the typical QC js queue setup, I know what you are saying. I am getting closer but not quite there on how to manipulate the js arrays to my liking with the few methods floating around this forum and the mailing list.

In this case I have two js patches working together pretty well. Once again, conceptually this is the developer example mouse ribbon patch -- create a queue with one js patch, then manipulate the queue points with a second js patch for expressive visual qualities.

Works well except for this new development -- your very nice color possibilities with the gl point/line patches. In fact I have color structure working with the mesh, once again ala mouse ribbon.

It seems like a basic question, how to assign keys to indices within a QC javascript structure, but I haven't found a solution yet. I guess I could post to the mailing list as a basic js question.

Oh, I see what you said, second port for color. I vote for all one port with indices or keys doing the same thing for RGBA.

I'm not sure this is all you are asking but keys are easy in JS. eg:

point["R"] = R;
point["G"] = G;
point["B"] = B;
point["A"] = A;

Thats it. To use a variable assigned key it would go:

var red = "R";
point[red] = R;

You can have the index for an array element alongside an item key for an object. eg:

my_points = new Array();
my_points [0] = new Object();
my_points [0]["R"] = 0.12345;
var red = "R";
for (i in my_points)
{
   my_points [i] [red] *= 0.5;
}

Hope that helps. And yes JS in QC is a pain in the arse;

Hey nice plug-ins, man. I'm losing the QC vibe these days but great to see you forging ahead with your skills to a new level!

Thanks, usefuldesign. Have a feeling this will get me there. I have come so close to these examples, but the syntax is killing me.

I would try something like this:

var result = new Object();
_outputPoints = []
 
var index = 0;
function (__structure outputPoints) main (__number X, __number Y, __number Z, __number R, __number G, __number B, __number A, __number xTheta, __boolean mouseDown, __boolean mouseReset,  __index size)
{
   if(mouseReset || result.outputPoints == undefined)
   {
      index = 0;
      result.outputPoints = new Array();
   }
 
   if(mouseDown)
   {
      result.outputPoints[index] = new Object();
      result.outputPoints[index].X = X;
      result.outputPoints[index].Y = Y;
      result.outputPoints[index].Z = Z;
      result.outputPoints[index].R = R;
      result.outputPoints[index].G = G;
      result.outputPoints[index].B = B;
      result.outputPoints[index].A = A;
      result.outputPoints[index].xTheta = xTheta*Math.PI/180;
 
      //add more stuff here, declare inputs first
      ++index;
   }
   for(var i = 0; i < index; ++i);    
    return result;
 
} 

....and I would put a smooth with a decreasing duration of 1 between Left Mouse button and the "Mouse Down" input (or something close), while flipping a nan value into the javascript when mouse is up. I've attached an example.

Seriously though... I would take a look at the qtz example with that patch where the javascript isn't doing any of the queue function, just the keys. You can queue if you wish inside of the javascript of course... I've certainly done it, but only because of ease of the moment.

for(var i = 0; i < index; ++i);    
    return result;

wtf? that For line does 100% nothing useful. ftw. ;)

lol... I get a wtf! I deserve it, I shouldn't have picked 2AM to reply on this one.

I know...it's a vestige of something that I was going to go into, and I forgot to lop that out. Thanks for pointing that out, because in a scenario like this, it's confusing to someone who wouldn't know. I should have double checked ( I think you know how long I hesitate on things usually, agonizing over doing something inadvertently dumb.)

I was originally going to show that after the main part, you can do something like:

for(var i = 0; i < index; ++i)
   {
 
      result.outputPoints[i].R += result.outputPoints[i].whatever;
 
   }
    return result;

...but I couldn't come up with any fun math for a color scheme, so I lopped it out at the last minute and didn't trash that line.

Also, I see now that I didn't implement that size input port (for the queue), but left it in the interface for inputs. Sigh.

This is something like what I was originally mocking up. This shows how to do an alpha fade over time. (It seemed kind of extraneous to the main point, but now that it's come up).

var result = new Object();
var index = 0;
var f=-1
function (__structure outputPoints) main (__number X, __number Y, __number Z, __number R, __number G, __number B,__number A, __boolean record, __boolean reset)
{
   if(reset || result.outputPoints == undefined)
   {
      index = 0;
      result.outputPoints = new Array();
   }
   if(record)
   {
      result.outputPoints[index] = new Object();
      result.outputPoints[index].X = X;
      result.outputPoints[index].Y = Y;
      result.outputPoints[index].R = R;
      result.outputPoints[index].G = G;
      result.outputPoints[index].B = B;
      result.outputPoints[index].A = A;
      ++index;
   }
   for(var i = 0; i < index; ++i)
   {
      result.outputPoints[i].A += f*.01;
   }
   return result;
}

I'm attaching a comp with iterator and sprites AND that remix struct renderer...so, if it's not installed, you'd get the idea.

Chris, if you have any suggestions about proper indentation in general, I'd appreciate it. When it comes to laying out my indentations and colons, I'm sometimes unsure what is ideal, and it seems like there's not a consensus.

Do excessive comments ever possible harm something (not in QC, in Xcode?).

Makes perfect sense in concept, George. And I appreciate seeing the alpha fade.

However, nothing I have tried to insert into Chris' code works yet. Here's a few of many sad attempts:

result.point[3].R = R;

point["R"] = R;

point[3]["R"] = R;

point["R"] = point[3] = R;

point[3].R = R;

And Chris' js, which may be creating some other issue, the temp setup, or?

var result = new Object();
 
function matrixMult(matrix, point)
{
   var temp = new Array();
   temp[0] = matrix[0][0] * point[0] + matrix[0][1] * point[1] + matrix[0][2] * point[2];
   temp[1] = matrix[1][0] * point[0] + matrix[1][1] * point[1] + matrix[1][2] * point[2];
   temp[2] = matrix[2][0] * point[0] + matrix[2][1] * point[1] + matrix[2][2] * point[2];
   point[0] = temp[0];
   point[1] = temp[1];
   point[2] = temp[2];
}
 
function transformPoint(point, xTheta, yTheta, zTheta)
{
   sinX = Math.sin(xTheta);
   cosX = Math.cos(xTheta);
   sinY = Math.sin(yTheta);
   cosY = Math.cos(yTheta);
   sinZ = Math.sin(zTheta);
   cosZ = Math.cos(zTheta);
 
   // todo:  do the math, and get this right
   //[[cosY*cosZ, cosX*-sinZ, sinY],
   //[sinX*sinY*cosZ+cosX*sinZ, sinX*sinY*-sinZ+cosX*cosZ, -sinX*cosY],
   //[cosX*-sinY*cosZ+sinX*sinZ, cosX*sinY*sinZ+sinX*cosZ, cosX*cosY]];
   var matrix;
 
   matrix =
      [[cosZ,-sinZ,0],
      [sinZ,cosZ,0],
      [0,0,1]];
   matrixMult(matrix, point);
   matrix =
      [[cosY,0,sinY],
      [0,1,0],
      [-sinY,0,cosY]];
   matrixMult(matrix, point);
   matrix = 
      [[1,0,0],
      [0,cosX,-sinX],
      [0,sinX,cosX]];
   matrixMult(matrix, point);
}
 
function (__structure points) main (__number X, __number Y, __number Z, __boolean draw, __boolean reset, __number xTheta, __number yTheta, __number zTheta, __number lineWidthx, __number lineHeighty, __number R, __number G, __number B, __number A, __index queueSize, __number patchTime)
{
   if(reset || result.points == undefined)
      result.points = new Array;
   if(draw)
   {
      var point = new Array;
 
      //last sad attempt, does not work
      point[0] = X;
      point[1] = Y;
      point[2] = Z;
 
      point["R"] = point[3] = R;
      point["G"] = point[4] = G;
      point["B"] = point[5] = B;
      point["A"] = point[6] = A;
 
      point["W"] = point[7] = lineWidthx;
      point["H"] = point[8] = lineHeighty;
 
      /*original:
      point[0] = X;
      point[1] = Y;
      point[2] = Z;
 
      point[3] = R;
      point[4] = G;
      point[5] = B;
      point[6] = A;
 
      point[7] = lineWidthx;
      point[8] = lineHeighty;
      */
 
      transformPoint(point, xTheta*Math.PI/180, yTheta*Math.PI/180, zTheta*Math.PI/180);
      result.points.push(point);
      if(result.points.length > queueSize) result.points.shift(point);
 
   }
 
      return result;
}

Oh, and regarding the nan / smoother solution, I will take heed. I'm ultimately using the patch in a live tracking scenario, so I'm not using the mouse and there are no nans unless triggered by force. I wish there was another solution to breaking the line. I think the twist mesh filter doesn't like nans, for ex. (Can mesh filters be multiplexed with stability? OT, I guess.)

Which brings up another set of questions, again OT perhaps, about filling the queue -- ways to fill it quickly, or more I would like to empty it quickly to control how fast the tail "snaps back" to 0 members. Is there a way to deal with this in js?

Thanks for the comment George!

You're right about the "taper" effect but if the change in with is happened gradually and in close points it will be acceptable. I've done the same thing with Gl Line Patch in Iterator and it worked beautifully but with a low FPS(See the attached comp. it's a fractal attempt on JS). I guess the whole reason for having structure-accepting patches like yours is to get more FPS.

So I still think adding keyed width and size to your plug-ins will be a big plus.

I'd love to see those basic glu objects in QC as well as. Also the modified structure render with keyed color you talked about will be marvelous. What I like about your way of thinking Gorge is that you'll try find the simplest solutions and yet they are big helps for us QC users.

BTW, I'd love to know your thoughts about my second comment above(Objective C etc.)

Given its location just over a return, I wasn't sure if you were perhaps trying to return multiple things (which isn't possible in this manner, and doesn't make any sense) -- glad it was just vestigial :)

gtoledo3 wrote:
Chris, if you have any suggestions about proper indentation in general, I'd appreciate it. When it comes to laying out my indentations and colons, I'm sometimes unsure what is ideal, and it seems like there's not a consensus.

this is an unsolvable topic. My style has changed a bit since moving to Cupertino (smokris has great style, and there's comparably good style here that I now use simply to keep things consistent). I'd start a new topic on this, to be honest (in a "code review" section, most likely -- smokris, perhaps this can be created?).

gtoledo3 wrote:
Do excessive comments ever possible harm something (not in QC, in Xcode?).

Yes, but not in the way you might think.

comments are stripped out as one of the first things the compiler does before it starts actually compiling (comment stripping and macro expansion happen before the compiler even considers creating a binary from your code).

they way they harm is like this:

/* This comment is really really long, and 
contains a detailed analysis of this clever 
algorithm I invented/read in a book/heard from 
a friend.  It works like this:  first, you do 
stuff.  Then, you do something else.  Finally, 
you do the cleanup step*/
static int aFunction(int a, int b)
{
   // this is a hack
   return 42;
}

This is a trivial example: the heading comment has drifted out of date with reality, and there's a new comment ("this is a hack") that denotes the override. Comments don't affect code flow at all, but they do affect how people understand code. Because of this, comments are almost always wrong (because they don't execute, they're never tested). They also add more stuff you need to read/change/maintain if you want to keep them consistent.

Generally, I'd favor less comments and more plainly obvious code. There are times where this isn't practical (tight loops that need to be optimized, and are doing something weird might get an explanatory comment, for example), but that shouldn't happen until you have something that works (i.e., don't make tight loops from the start, measure measure measure).

I'd say objc is easier (I picked it up in a few days -- C++ took much longer, and there are still details I need to look up from time to time).

C++ also isn't used much in QC.

There's this book, which is touted to be really good: http://www.amazon.com/Cocoa-Programming-Mac-OS-3rd/dp/0321503619

Apple's documentation on objective C (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/O...) is also quite good (that's where I learned it from)

Cheers Cwright for the info!

Will look into the book you suggested!

@idlefon -- that branch javascript patch is a super cool. too bad it's a fps killer.

Anyway, thanks so much for your time, George. These kinds of problems really kill my workflow. Then I try to research solutions for such a seemingly simple thing and after a while I am completely crazy.

Maybe I need to go about this another way, like with a js structure merge approach. Are there any issues combining two structures with indices and keys?

Cheers Jersmi!

I think if the line structure patch accepted width as well, it would have been a little better on FPS.

Maybe I'll try to implement it on OpenCL as well and see how that will work out ;)

"cwright" wrote:
Generally, I'd favor less comments and more plainly obvious code. There are times where this isn't practical (tight loops that need to be optimized, and are doing something weird might get an explanatory comment, for example), but that shouldn't happen until you have something that works (i.e., don't make tight loops from the start, measure measure measure).

I believe this fixes the index to key problem. My lesson: an array is indexed, an object is keyed. (This from the Kineme reference page, "Javascript in Quartz Composer". oy.)

Once again, this is a snippet from cwright's awesome javascript drawing patch (see above) demonstrating how to always draw to the viewer and allow the point structure to rotate away from the x/y plane. (The patch also uses the Kineme Inverse Rotation patch, fwiw.) I have been learning quite a bit modifying this patch.

Thanks so much, George and usefuldesign.au, for your generosity and clear examples.

function (__structure points) main (__number X, __number Y, __number Z, __boolean draw, __boolean reset, __number xTheta, __number yTheta, __number zTheta, __number R, __number G, __number B, __number A, __index queueSize)
{
   if(reset || result.points == undefined)
      result.points = new Array;
   if(draw)
   {
      // was: var point = new Array;
      var point = new Object();
 
      point["X"] = X;
      point["Y"] = Y;
      point["Z"] = Z;
 
      point["R"] = R;
      point["G"] = G;
      point["B"] = B;
      point["A"] = A;
 
 
      transformPoint(point, xTheta*Math.PI/180, yTheta*Math.PI/180, zTheta*Math.PI/180);
      result.points.push(point);
      if(result.points.length > queueSize) result.points.shift(point);
 
   }
 
      return result;
}

Now you learned something you will always take with you :) ! Seriously. It's way better to have to get that last little step on your own sometimes ( I was going to post a solution or ask about it in a day or so if I didn't see any action.)

Regarding the thing about "vote about index vals for RGBA"... the only reason I implemented the keyed colors in this case, and posted it here, is because it is "in the style of" and something that I've talked to cwright, and I think smokris, when I found that they didn't respond to keyed color. Then I went through all of the struct renderers and found out what did/didn't respond to what, and we had a back and forth about it.

I don't think it was through want to not have key color ability... I think it was either time, or that the idea of key colors came along after the point and line had been done.

The problem with just going "XYZ = indices 1,2 and 3, and RGBA is 4567, is that "what happens when there's a W value because it's a vec4, not a vec4? As in XYZW that's produced by an OpenCL kernel in many instances, or "get vertices"? Then, there's also options for Normals and UV stuff with the keyed data in some instances with the structure renderer, not just xyz coordinates. So who's to say that U and V shouldn't be 5 and 6?

Those kind of use issues make me feel like just presenting the keyed options gets the job done, without getting into the wormhole of what should equal what index ( I'm typically a big proponent of not using keys, and using indexed data instead, so I find it weird to be writing that).

Ideally in some kind of future QC, users could somehow configure this stuff on the fly better (dictate aspects about what in the structure should equal what), or get exposure to the aspects of GL that the plugin could tap into, but the native QC environment cannot.

The potential issue, lookswise, with adding line size per index is that it would look really weird when one size meets the next, because a line doesn't taper from point A to point B (I may have mentioned this somewhere else?). There's a cool attenuation code for the GL Points, and I've seen similar code on OpenGL tips stuff for emulating that kind of thing, but with lines it looks kinda funky, because of how sudden the size increase or decrease is where segments meet.

Yes these lessons can be hard won. I was going to post that an important step for me on my self-learning JS path was getting that Arrays have indexed elements and Objects have keyed items. Those are the correct terms by the way, helps if we all use them correctly (we don't always see that).

So if you create an Array element:  my_array [100001] = "Success!"; then all the elements from zero to 100 001 inclusive get created. The rest will be null if not already explicitly assigned.

Whereas if I create an Object item my_object[100001] = "Equally successful…"; , just the one keyed item is created in the object.

Quote:
this is an unsolvable topic. My style has changed a bit since moving to Cupertino (smokris has great style, and there's comparably good style here that I now use simply to keep things consistent). I'd start a new topic on this, to be honest (in a "code review" section, most likely -- smokris, perhaps this can be created?).

Oh, I know there are all different kinds of takes on things. I've tried to pay heed to your criticisms and suggestions. I've seen a decent amount of yours and smokris's code, so I guess what's there speaks for itself.

Side note- I think it's funny that you keep talking about a dedicated code section! Is there something wrong about it mixing in with the visual code stuff? Yin/yang. I don't think it would be bad, but I think the two often overlap, because usually someone is asking about syntax based code in the context of visual coding.

Quote:
Yes, but not in the way you might think. comments are stripped out as one of the first things the compiler does before it starts actually compiling (comment stripping and macro expansion happen before the compiler even considers creating a binary from your code). they way they harm is like this:

{code stuff edited out for brevity by gtoledo3}

This is a trivial example: the heading comment has drifted out of date with reality, and there's a new comment ("this is a hack") that denotes the override. Comments don't affect code flow at all, but they do affect how people understand code. Because of this, comments are almost always wrong (because they don't execute, they're never tested). They also add more stuff you need to read/change/maintain if you want to keep them consistent.

I always thought that was the case (compiler stripping it out), but wondered if there might be some exceptions in the case of when you can have various levels of error flags (my terminology may not be 100% right here).

I see your point about the time involved reading/changing/maintaining comments....it's always a drag to have to sit down for who knows how long depending on the size of the project and make sure all of the comments are still relevant. Especially since in "the heat" of coding, you sometimes just don't want to deal with updating comments at that moment. I think when I read about guys like Bill Atkinson commenting every single line, it's like... woah. I wonder if that's a bit of hyperbolic lore.

gt wrote:
The potential issue, lookswise, with adding line size per index is that it would look really weird when one size meets the next, because a line doesn't taper from point A to point B (I may have mentioned this somewhere else?). There's a cool attenuation code for the GL Points, and I've seen similar code on OpenGL tips stuff for emulating that kind of thing, but with lines it looks kinda funky, because of how sudden the size increase or decrease is where segments meet.

gt wrote:
( I'm typically a big proponent of not using keys, and using indexed data instead, so I find it weird to be writing that).

I noticed you have the same line stipple function as GL Tooles Line Structure patch. Is that some standard OpenGL line option or did you use the Kineme source to do it? I've never actually found the stipples very useable (I'm very used to AI style dashed lines or CAD type line styles where you set the dash and the gap).

jersmi wrote:
Once again, this is a snippet from cwright's awesome javascript drawing patch (see above) demonstrating how to always draw to the viewer and allow the point structure to rotate away from the x/y plane. (The patch also uses the Kineme Inverse Rotation patch, fwiw.) I have been learning quite a bit modifying this patch.

Could you post a link to cwright's composition – his comps are always instructional. I saw the JS functions above but would like to see the context.

As far as the line segments stuff goes...for this matter, one could just roll their own structure renderer using an iterator. No one really needs a plugin save for convenience factor and maybe stability? (?)

Re stipple: It's an OpenGL feature. When I implemented it on Meshdraw and the Heightfield_gt it was totally from scratch, from looking at OpenGL.org stuff, and figuring out how to make it work in QCPlugin.

When I added these color keys to these skanky patches here, I maintained cwright's stippling code (there was no reason to change anything!). The only think I did was to add in color keys ala the way they're done in other GL Tools patches, so as to maintain consistency of style.

As far as the usefulness or not... I find it useful. For something like that "felt tip"qtz I posted awhile back, you can use stippling to get a hair/marker like texture. With a heightfield, you can wrangle in pattern and count to make just the sides that extrude render, which looks cool. It can be used for plenty of dashed line stuff and marching ants type things, and it's an OpenGL freebie. Plenty of plusses in my book.

CAD and AI stuff isn't that far off in look in my mind, but I may be off base. I'm sure that there is some fancier stuff available in some CAD programs and in AI. GL Line Stippling is a really old function.

Hard won, indeed. And such a basic issue. What a mindf*ck.

The original post for Chris' javascript is here, comp is called "draw in space". George also has some good stuff in that thread.

I appreciate all the key/index considerations. Makes good sense. And instead of a line patch, a quad or mesh works pretty well for adjustable line width. Though I can see how fps could become an issue with heavier patches. The mouse ribbon patch is a good place to start for making the mesh do some nice calligraphic stuff. Though I'm still working on getting this method to make smooth transitions from quad to quad (looks stair-steppy if consecutive quads change size too abruptly).

True, line segments can be done elsewhere.

Not that stipple isn't useful, I should have said it's hard to use. I'm used to having a determined idea of the dash and spacing lengths I'm looking for and stipple seams like some kind of weird algorithmic series that determines the dash & space lengths.

So it's very hard to say okay I want to see for this kinda line and then come up with the appropriate integer for that style of line. But it's for free you say so not a valid point in that context…

Hi. I guess the link has timed out, may you post them again, George? I haw posted about a project (Drawing a Spiderweb, wanna make it with white lines a la Tron), ask myself, if this could help me ....

http://www.box.net/shared/i73dk2igkozd19b1m4xc

http://www.box.net/shared/5luch7ccih3ndidf2lt0

Thnxs, it helped me out :)

Hey George, is your GT Point Structure patch still around anywhere? I have comp in which I need to assign individual colours to each point in a point structure, but it seems GLTools doesn't allow that - whereas your RGBA version sounds like it does...or is there another way? I'd use VUO, but my project is too far gone in QC at the moment.... thanks in advance if you can make it available :)

I'll give a look around, it's on an old hard drive I think... not sure if it still works or not. I'll try to post back here tomorrow.

https://www.dropbox.com/s/01t8muk4b5k6ay1/GT%20Point%20Structure%20Patch... https://www.dropbox.com/s/b2fglhgub1i84d1/GTLineStructure.plugin.zip?dl=0

I haven't tested them in El Cap, but I'm guessing they should work. Let me know.

Thanks so much George :) Yes - they work perfectly under El Cap.

I found an alternative approach using the QC mesh renderer, using coloured vertices, but it is getting really slow & crashing as I'm trying to render out ~340,000 points. Which shouldn't be a problem for a Mac Pro with 12GB of VRAM, so presumably something funny is going on inOpenGL & QC. Hopefully your patches will give me a way around this - I'll let you know how it goes. cheers Peter

Yeah, could be many different things.

One thing to keep in mind, is that if you write a program to render a bunch of points/particles, you have the structure that you made, and directly render.

Whereas in QC, what likely happens is that you are creating a structure of some sort, and then pass that to another patch. And then maybe to something else. And every member of the structure is a full blown object. So, you may be burning up more CPU that way.

For counts like that, I tend to try to figure out how to have one patch do all the work, or maybe one that generates structure and goes directly to the next.

OpenCL can be good for this, but GPU driver support as well as the QC implementation in some instances - particularly the mesh objects, can make for an uneven experience.

(I get fairly reliable performance with OpenCL in QC, when I'm just working with texture and nothing that involves QCMesh...just mentioning, not that it helps with this problem.)