Feature Requests
From QuartzCompositions.com the central source for Quartz Composer :: wiki
Have you got any ideas on how Quartz Composer could be improved? Perhaps an additional patch, alternative output formats, or a better way to debug it?
If we come up with good enough ideas, we may be able to persuade Apple to release them in a new version.
If you agree with any of the feature requests below, the best way to incorporate it into Apple's plans is via Apple's Bug Reporter (http://bugreport.apple.com). Despite the name, you can ask for a feature to be included in future versions of the software. These reports are used to set priorities for further Quartz Composer development, and Pierre has often asked that members of the QC-dev list enter their feature request in the system.
| Table of contents |
Ideas
Support for arbitrary 3D objects
Current primitives are cubes, spheres and teapots, which are the primitives built in to OpenGL. It would be great to take a 3d object model from Blender (or Luxo Modo, or Maya, and so on) and be able to use that in a patch. For bonus points, allow mesh deformations as part of the patch!
If you're curious about why OpenGL contains the teapot in its primitive library, see the Wikipedia entry on the Utah teapot (http://en.wikipedia.org/wiki/Utah_teapot)
Numerical output for images
Grab a color from a pixel in th eimage, or gain other numerical informations from an image or part of it.
Debugging Core Image Kernels
You should be able to debug Core Image Kernel code using a tool like OpenGL Shader Builder. It would be nice to do this in place, but having the Shader Builder understand the same language variant as Core Image Kernel would be useful too.
Better Routing for circuits
When you build circuits (paths that loop back) using the Core Image Accumulator Patch, some of the important wires are obscured due to poor routing. Either the routing should be better, or special dummy routing nodes (thumbtacks) could be introduced to allow the user to manually route wires
Multiplexer Macro Patch
How about a macro patch which can contain an arbitrary number of sub patches of the same type?
It would have a count output and an index input, and would replicate the input and output of the currently selected sub-patch onto the macro patch itself.
For instance, if it contained a number of Image Importer patches:
then it would replicate the Image output port:
The count would have the value 2, and the index would allow you to select which sub-patch was exported.
One use of this would be a random number input to produce a random output. The beauty of this approach is that if an image was added or removed, no further action would need to be done - it would operate correctly with the new number of images.
Similarly, you could put a selection of different image processing patches in it. In this case, they would not be of the same type, but of the same signature - each sub patch would need to have the same output and input port and port types (or at least a common subset).
You could use the index to select which image processor was currently in operation:
I know you can achieve a similar multiplexing effect using the Multiplexer patch, but if you want to add or remove patches, you need to adjust all sorts of stuff - a count, the multiplexer count, and the connections to the new members of the set!
One difficulty with this macro patch is the need to join the count output back to the random number generator so that the correct range is created - but since count is constant (during rendering) the non-recursion rules could be broken for this patch without a problem (much like for the Core Image Accumulator patch.
