QCMeshTools.plugin/QCMeshValidate

interesting. i was also thinking something like this would be cool for interactions. it would be nice if one could validate the test in order to use that boolean to trigger other things etc..

Why can't you use it to trigger something?

If a valid mesh is at the tip, it outputs a 1, otherwise a 0.

So, if you hook that output to something, it will "do stuff" or you can indicate state of the loader or creator, etc.

My sample comp is only manipulating the string printer, but it is easy to make something else pop on/off, or move, or whatever.

I don't see a ton of stuff going on with the QCMesh feed that would be awesome to expose that isn't already available in some way.

There's a bounding box structure, and info about width, depth, and height. That seems useful.

You can "get other stuff" from the QCMesh, but that's all already basically exposed. I guess there isn't such a thing as a get textures that creates an image structure out. I don't know if that's needed.

This is a really interesting idea for a plugin.

I find that if I set Slices and Stacks to Zero then I still get a QC Mesh albeit with Vertices & Component Count at 0 and all other items undefined I still get a True Boolean result, [which I guess I should be getting, due to the way the plug in is defined].

The entry of 1 Stacks over 1 Slices, gave V = 4 and CC = 4. Entering 0 Slice over 1 Stack gave VC = 2 CC = 4 whilst 1 Slice over 0 Stack gave a VC = 0 and CC = 0.

Also if the stacks are less than 2, no rendering takes place, whatever the number of slices, [obviously enough], but it still validates, though it doesn't render.

None the less if I present a .dae in text format , it validates , but take out the Collada tags and it is invalid. Even though I can get the structure out of file and rebuild it into the valid mesh it once was.

So it can validate and invalidate correctly as well as [arguably] incorrectly.

More than being a super interesting idea, it's sort of just square one. "(Is there something valid at this port type? If so, return yes.") I was doing this with a number of different input port types, and then put this one together.

Interesting point... I guess that one actually can't always count on get verts (or another "get") because there may not be any at a given moment. So, I guess that nudges this up in usefulness.

It should probably validate in text format, because the QC loader probably still turns it into QCMesh even though you changed the extension (I bet you could change the extension to "blah" and it would work, for instance...haven't tested that, but some of the other loaders work that way).

That's great that it still returns a 1 value even though you reduced it so that there isn't anything that could render. That means it's definitely working as I would expect.

As far as the other point, definitely arguable :) Look at it this way, once you take out collada tags, none of the stock stuff that takes a QCMesh input could do anything with it. I'm guessing the loader doesn't import it successfully, correct? You'd have to rebuild it (as you say), because it's not QCMesh.