R: Rejected

K3D - "rotation origin" and/or translate/rotate/rotation origin struct input for structure renderer.


One of the cool things about K3D's setup (imo), is that you can move around objects - before - they hit the renderer.

This means that if you have a multi-obj, and want a specific index or range of indices, you can use a conditional or math to make only those indices "do something". So, if you are iterating to render a multi-obj 3D-object, you can connect a K3D object rotate or translate, and make just those indices rotate or translate.

In using this more, I've realized that without a rotation origin, it makes the rotation ability a bit hamstrung, because the sub-object will rotate from wherever it does by default - not necessarily where you want it to.

So, then I lopped out the K3D transform/rotate stuff, and used a 3D transform instead (because there IS a rotation origin".

However, when doing that, if you want to have multiple "pieces" of the 3D object do different things at different index vals, it still makes more sense to use something like a K3D Transform or Rotate, because you could hook up multiple units before it hits the renderer. That way, I could make multiple pieces rotate in "X" with a given rotation origin, in a really obvious and straightforward way. When using a 3D transform's rotation origin in this scenario, this breaks down in complex setups.

An alternate thing would be to be able to send a structure of x/y/z translate, x/y/z rotation, and x/y/z rotation origin to the Kineme 3D Structure Renderer (and scale I guess).

The rotation origin thing would be highly desirable for the Kineme Structure Render environment as well.

Here is a zip that hopefully illustrates my reasoning, and the kind of activities that could be done.

The "movement" qtz shows a couple of pieces of a mult-obj file being "moved" with rotation origin accounted for.

The "rotation origin feature request" shows the same model with it's hand flying around, unconnected to the wrist.

stereoscopic renderer without FOV

This one is pretty simple. It's a request for a stereoscopic render environment that doesn't have the FOV patch in it, or that has a bypass.

Quartz Builder Midi Out/in limit

Quartz Builder seems to have problem running Midi Receiver/Sender patch with more than 21 inputs or outputs. A composition that works in Quartz Composer without any problem (Receiving and Sending Midi with more than 21 I/O) does not work after building with Quartz Builder. Only the first 21 Midi in and outs are working. But there is no crash or something similiar. Only this limit.

KinemeCore Drop patch into Macro feature.

You have a sprite already noodled up and functional. Then you want to drop it into a Macro without having to publish all the input ports and re-noodle.

Something like Cmd-Opt keys while dragging a patch over a Macro and it gets dropped in an renoodled to correct ports automatically.


The patch should have a port where we input the Key name of a patch (eg. Clear_1), and an input port Key (eg. inputColor). The output of the patch would deliver the current state of the patch and input being called upon.

There wouldn't have to be any "send" attached.

I'm marking at as active because of similarity to Spooky.