A small plugin that allows mathematical operation between structures,
such as + - * / lerp > < != ==
Works with 1D structures of numbers, and 3D structures containing X Y Z sub-element, a la "GLtools".
Is there a recommended range for the Structure Members?
Do you advise against sandwiching other Math Structures between multiple Lerps ?
Probably a dumb question, but is the .plist file's internal format always going to have to be as per the examples you've provided?
I'm sometimes finding this plugin can hang under conditions as complex as enquired about above. & just got another type of hang / crash - when moving focus out of the QC Viewer window onto another application, 2 times in a row this has beach balled, requiring a force quit.
mmm... dividing something by 0 is not recommended. Maybe that's causing the crash.
Strange about this crash...
The plist format is just for reading/saving structures.
I advice avoiding too much sandwiching.
Oh, in case that sounded like a rip or something, I'm actually conveying that it's good fps considered. Doing the same function with javascript yields about half the performance, and when doing it with an iterator with published outs, a quarter. So, this is good, all things considered.
However, backing off, sometimes I'm like "we can really only get this many polys at a given speed, wtf?"
Incidentally, earlier in the week, I figured out a lightning quick structure morph technique using OpenCL (as in 100+FPS for models with 5000+ vert), but morph time is a function of distance of verts from one another... I haven't been able to figure out how to time the morph :-/
gtoledo3 wrote: but morph time is a function of distance of verts from one another... I haven't been able to figure out how to time the morph :-/
Please expand I'm not understanding you…
gtoledo3 wrote:
Incidentally, earlier in the week, I figured out a lightning quick structure morph technique using OpenCL (as in 100+FPS for models with 5000+ vert)…
Ok that thing I was saying about previously thinking OpenCL sounded like the Holy Grail for most things QC, if you are getting that kind of speed and able to use the result data in the QC graph, … well I'm starting to think like that again. That's approaching dedicated C application speedmark inside an uber-flexible QC patch. If that's what you are claiming, pretty awesome! I think I need to get myself an intel Mac — the writing's on the wall.
I just fixed a memory leak problem.
Grab v1.1 from the blog.
And yes, the internal format always has to be like in the plist:
One big structure containing substructures, each containing X Y and Z numbers.
(only numbers)(sorry for not getting what you meant in the first place)
Brilliant, chaining these like in your 3D Perlin example is great fun.
Got to see what this does with Meshes inside a Polygon Mode patch.
Is there a recommended range for the Structure Members?
Do you advise against sandwiching other Math Structures between multiple Lerps ?
Probably a dumb question, but is the .plist file's internal format always going to have to be as per the examples you've provided?
I'm sometimes finding this plugin can hang under conditions as complex as enquired about above. & just got another type of hang / crash - when moving focus out of the QC Viewer window onto another application, 2 times in a row this has beach balled, requiring a force quit.
<key>qcStructure_94</key> <dict> <key>X</key> <real>-0.23828125</real> <key>Y</key> <real>0.19140625</real> <key>Z</key> <real>0.0</real> </dict>Sweet, you did Lerp. Eager to look at this more.
I can get morphing on a dae of around 5000 members up to about 7fps.
mmm... dividing something by 0 is not recommended. Maybe that's causing the crash. Strange about this crash... The plist format is just for reading/saving structures. I advice avoiding too much sandwiching.
Due to the internal use of an ordered dictionary, i doubt the plugin can perform at good framerates beyond 1000 iterations.
Very useful plugin Franz! These are functions I normally hack together but this is a tidy way of dealing with a very common problem!
Oh, in case that sounded like a rip or something, I'm actually conveying that it's good fps considered. Doing the same function with javascript yields about half the performance, and when doing it with an iterator with published outs, a quarter. So, this is good, all things considered.
However, backing off, sometimes I'm like "we can really only get this many polys at a given speed, wtf?"
Incidentally, earlier in the week, I figured out a lightning quick structure morph technique using OpenCL (as in 100+FPS for models with 5000+ vert), but morph time is a function of distance of verts from one another... I haven't been able to figure out how to time the morph :-/
I just fixed a memory leak problem. Grab v1.1 from the blog.
And yes, the internal format always has to be like in the plist: One big structure containing substructures, each containing X Y and Z numbers. (only numbers)(sorry for not getting what you meant in the first place)