Mesh vertices to KnMGLtools compliant structure

That's an interesting question.

The GetMeshComponent is outputting a structure of float4 vectors. There isn't a way I'm aware of to ascribe a key to them that I'm aware of; one does operations depending on the lane it's in... which is xyzw in this case (since it's coordinate info), but not in the keyed sense.

So, this gets me thinking of javascript or the iterator, both of which I'm guessing would massively suck for this.

With OpenCL, you could output just the values that are in any given lane, so you have a structure of all of the x/y/z/w separate, but then you would still be joining back together somehow, or mod the plugin to have 3 separate structure inputs. Hmm. That seems very inelegant, but could work, as outputting the single lanes can happen very quickly via the kernel.

I know smokris retrofitted GL Tools to work with the GetMesh output... maybe he has some insight that would work, but I don't know if it would work in a QCPlugin.

what do you mean by knm gl tools compliant ? couldn't find your updated plugin on your blog to check. on my system a get mesh component by vertices seems to be compliant enough to render lets say a gl point structure from a mesh. so it must be an issue with your plugin expecting a key instead of index as gl tools seems to work with key or index.

if that is the issue then you would need to enumerate your dictionary into an ordered array as the dictionary does not keep its order.

here is some code to re order a float4 qc structure (dictionary) into an array that you can then use in your plugin instead of the keys XYZ.

NSEnumerator *enumerator = [self.inputStructure keyEnumerator];
 
id key;
 
NSMutableArray *index = [[NSMutableArray alloc] init];
 
int i = 0;
 
while ((key = [enumerator nextObject])) {
NSNumber *dex = [NSNumber numberWithInt:i]; [index addObject:[self.inputStructure objectForKey:dex]];i++;
}

thats my guess as a float4 to gl point structure works for me. see attached. so like i said not sure how you address the struct inside your plugin but would love to see how you go from cinder to qc plug.

my bad. The plugin is expecting an index, indeed. But a stupid mistake on my side prevented it from working. Now everything is running smoothly, as it should.

Nice. I'm so looking forward to this one!!!!! This is easily one of my fav plugins from a pure visual perspective.

Sometimes, if I do RII loops, I get issues when I restart the patch... I just have to close it, and re-open. I don't know if you've ever seen that, but I'm going to mention it just in case.

Ability to texture the particles or strips would be another very useful addition indeed. It would somewhat mitigate the fact that placing in RII kills MSA, because you could texture with a gaussian.

look forward to xyz from mesh input. I must say that will make your plugin killer. i mean its all ready killer but you will defiantly be ready for ware far when your dropping hairy mesh bombs controlled by motion input on the battle field. I'm imagining what it will look like when blow up building.

It starts occurring to me that it could be pretty interesting if you could wrangle a new processor patch out of this in addition to a renderer, that output a float4 structure.

This would make way for the possibility of calculating normals with OpenCL, rendering as different geometry types, adding large amounts of extra points to the formation, etc.

That was my initial idea, however it turned out to be quite slow, outputting a NSDictionary of more than 10000 members (each composed of XYZRGBA sub-members) is too heavy.

I updated the plugin to support Zcoord btw. Get it on my blog. (currently looking at adding image input)

Well, it would be possible to do something like emit 3000, then use openCL to calculate triangles or boxes for each particle, then force render as points. I guess that's where my head started going with it... using the 1024 as a kind of seed. If it's just ends up too slow, it's understood.

I guess what got me thinking of this, is something I was doing with OpenCL, taking every pixel and making multiple points based on the pixel value, and getting a few hundred thousand points, controlling gravity by pixel value.

Hmm. I was suggesting this because I was doing an OpenCL calc, taking in something 76,800 vertices, and generating 307,200 out, rendering 60fps (the "hair kinect" clip on vimeo).

I would have thought NSDictionary could handle 10,000! I wonder if it's how the 10,000 was being rendered(?).