Euler rotation

I don't know if it would make sense to use that in QC because all of the rotations affecting one another results in gimbal lock. So, you would have to map about a bunch of permutations of the nesting pattern. It can be handled in QC inelegantly to some extent (as far as replicating the effect), by nesting 3D transforms, and making each of the permutations, but that does get kind of ludicrous for complex things.

One would have to be able to determine what the likely view is, and the likely rotations, to then choose the correct euler nesting. I guess that may be possible, but it I don't know if it makes sense for QC to automatically handle that the way maya would, or how it would. Again, this would be useful... just thinking aloud.

I definitely appreciate that it would be nice if there was a tool to kind of handle this in some way...

bah, all this talk of "rotations" and "angles" and "eulers". blech. Those are all for sissies.

I've Invented* an even better solution; I like to call it "The 4x4 Matrix". Totally non-intuitive, but you can get any transformation you want without any nesting insanity. With a complement of matrix-generating patches, it could usher in a new era in object placement for Quartz Composer.

*: by "Invent" I mean someone else did it way before I was born, but now it's patentable because it's In QC**!

**: by "In QC" I mean it's not really in QC at all, but there's no reason why a few well-targeted radars couldn't at least strike up some discussion on it...

I could have predicted you would bring up matrices, but there's nothing in the QC app that exposes that, as you mention.

So no kidding, something is patentable just because it's a QC-centric implementation. Hmm.

I was being facetious (I hope?) about something being patentable because it's in QC (I was playing on the whole "totally obvious technology Now On A Computer" and "totally obvious technology Now On The Internet" patent memes).

Are there downsides to this (matrices, not patents ;)? It's received no discussion that I'm aware of, but it seems like it neatly sidesteps the whole "put it in 6 levels of 3d transformation, and operate on them all backwards" solutions to these kinds of problems (dealing with macros makes this particularly time consuming and confusing, imo).

here is a Euler Angles In Degrees From a Quaternion macros math and js expression. i'm not entirely sure what you are referring to when your saying qc doesn't use Euler angles as this macro is simply a copy of a trackball vector function made by apple(guess i can not patent).

ironically the source seems to be located in /developer/examples/coreaudio/publicutility/cocoa/trackball.mm the utility seems to be provided in the audio utilities as it would be useful to be used with a matrix audio mixer type of thing. even though its in audio examples the principles all apply equally to any sort of pitch, roll, yaw application.

people do use Euler angles in qc, you do not need to do a 4d vector to calculate a Euler angle, although it is most commonly used in 4d with quaternion vectors. the quaternions are usually used so you can use 2d xy points to rotate things in 3d like a trackball or in a game environment as a sort of look controller or what ever, but equally they are used in maya when modeling etc..

but also used in maya when sorting out the gimbal lock problem george mentioned, that is common with forward or inverse kinetic skeletal structures. by adding a constraint to an effector and limiting the rotation of kinetic animation you can get around the gimbal lock problem. if you use maya and make animations you have probably seen this problem, its when your 1st and 3d joints of a kinetic chain line up making your 2nd order joint flip 180 degrees to match the orientation of root effector in the chain.

i'm thinking with AE the Eulers are heavily used in the orbit tool. I like opening up the shutter angle of a camera turning on motion blur then keying the camera and point of interest and then using the "c" to toggle through the orbit tools setting to pan zoom and rotate the camera. it produces a really nice motion blur effect when you animate the camera instead of moving your layers around the screen and using some other sort of blur.

there is a java script 3d gui patch out there that pretty much turns your qc document into how you navigate in maya, i haven't looked but i'm sure there is some Euler stuff in that patch. Also you can check out my Quaternion trackball example in the repository for more vector rotation functions etc.. they are all done with match expressions or js but i think most of them would be easier to do in glsl or open cl as they have all those built in functions for matrix calculations.

Quote:
bah, all this talk of "rotations" and "angles" and "eulers". blech. Those are all for sissies

lol.... chris is just on another level...

gtoledo3 wrote:
I could have predicted you would bring up matrices, but there's nothing in the QC app that exposes that, as you mention.

Can matrixes be outputted from GLSL or CIFilter (if they exist inside CI I haven't looked lately)? GLSL definitely has matrix functions doesn't it?

cwright wrote:
I was being facetious (I hope?) about something being patentable because it's in QC (I was playing on the whole "totally obvious technology Now On A Computer" and "totally obvious technology Now On The Internet" patent memes).

If you can walk into a hospital for a random complaint, have you cheek swabbed and your entire DNA code patented without your release by bigPharma for commercial exploitation at some later point, then I'm guessing a 'good' patent attorney will write you a patent application for mat4 in QC, Chris.

We might see your name in lights on Patently Apple sooner than we thought ;)

Hmm, never really thought of that... all that a CI Filter is going to output is image, and GLSL doesn't have outputs. I guess there might be some way of reading color intensity to get numeric values? I wouldn't know where to start on that one! ;-)

Yeah I've wondered about hacking images to get processed data out of CIFilter in the past but my CIFilter programming is frustratingly lame so far. Colour would be a very clever way to do it, gt, if colour is a supported output type.

PixelS, as magic as it is, is pretty slow for extracting per-pixel info. I've never tried it with just 4 pixels though, could be another way.

EDIT: Oh you mean sample the image colour, I guess, we're talking about the same thing.

one annoyance with baking colors is that they're clamped to 0-1 when they're on color ports. This means you have to scale/bias them (this is great with normal maps since normals are bounded, but for unbounded data like mat4s I'm guessing it'll only end in pain).

CI and GLSL don't output anything (just images from CI, and nothing from GLSL), but internally they can have functions that return matrices (my normalmap 2 demo had a matrix-returning function in the fragment shader, for example).

In this case the output requirements are for X-Rot, Y-Rot, Z-Rot limited to 0-360 ( but mapped to 0-1). I don't know what the matrix functions are to do Euler rotation but don't they evaluate to a [4,1] matrix that can then be sampled to 4 floats and baked?

This sounds so obvious to someone who has no idea what he's talking about :)

Going OT for sec...

Did you even look into parallax mapping or steep parallax? http://graphics.cs.brown.edu/games/SteepParallax/index.html http://www.cs.caltech.edu/courses/cs101gpu/lab2/index.html

I'm really impressed with the visual result on some of these render examples, though obviously I'm not interacting with it to see the potential flaws. If it's similar to the normal mapping look but better, that would be stunning. I already thought the normal map look was already very impressive.

rotation is, but 4x4 matrices embody much more than that. They include scaling (unbounded), translation (unbounded), and shearing (unbounded?). 4x1 matrices could be baked probably, but that's not the kind of matrix I was talking about I guess (I'm talking a full-blown 4x4 to determine object location, scale, orientation, etc). To concatenate 2 4x4s, you multiply them - that'll swizzle the values such that normalized rotations probably(?) won't be preserved.

I don't really see what the point of outputting a 4x4 matrix is that requires hacks like colors -- what exactly is CI going to do to generate these "matrix images"?

yep, I've looked at 'em :) Unfortunately, my main QC development machine (personal, not work-issued) is still the GMA950 monstrosity, and writing decent shaders on that is getting increasingly difficult (the volumetric shader required me to use another machine, for example). parallax mapping requires a few iterations in the fragment shader, and that's one of the many places where GMS950s come up short -- while real GPUs can do hundreds of iterations per pixel (for deferred lighting, among hundreds of other good uses), my GPU can do about 4 -- parallax might be doable with so few iterations, but I'd rather not keep running into that limit as I'm testing. (I guess I could do software GL to work around it?).

The flaws with parallax mapping are that 1) casting shadows on parallax surfaces is actually really really hard, and 2) on-edge stuff doesn't work out so well (maybe that's been addressed by tweaking the vertex shader though, to give you more on-screen fragments?)

With all due respect, cwright, a reminder: since the language of sarcasm uses the opposite meaning for humorous effect, it can be confusing here. I'm a midwestern boy, so I understand the humor in my bones. Truly, I love your voice, and appreciate seeing the transition from kineme to apple. But it can be especially confusing when struggling to keep a grasp on the details on complex material (and in an electronic medium). Sorry if this seems humorless. If you knew me this would be ironic...

There's something about this I don't get...

It seems like the "problem" is that one needs to be able to take in the x/y/z/w and convert to x/y/z. I haven't tested this, but I see 4 ins and 4 outs, so it doesn't seem like it fits the bill (?). I'm not saying that I'm not misunderstanding something.

I wasn't being too sarcastic there actually :) (more dismissive or something?) -- those really aren't the tools necessary to solve the problem the original poster described; they're all subsets of a larger problem that's being ignored.

a single 4x4 matrix can embody any possible position, scale, shear, location, and orientation of any object, without needing to nest anything. They're definitely less intuitive to work with (hence my description of a suite of helper patches), but they feel like a dramatically better solution. Similar to the layer number discussion taking place in parallel (https://kineme.net/Discussion/GeneralDiscussion/LayerNumberMacro#comment...) -- I like real complete solid solutions to icky hacks (like putting a teapot 6 macro levels deep and doing all the transformations in reverse order)

Helper patches make sense... I think this is why the matrix mult is so rarely used by anyone.

Wow, I'm surprised you couldn't do the volumetric shader on your machine.

I've seen various renderings of a cube's edge that has used parallax mapping and it doesn't look any worse than normal mapping....seemingly. I'm certainly not professing to have any more awareness than what can be gathered from reading available web materials.

When you've seen cubed parallax-mapped demos, you're looking at 1 thing: a cube with "sunken" surfaces. This is a cheat, because the edges all line up (they're "flat") so it's still a convex hull.

If you have the surface not "sink", but "rise", it becomes difficult: you can't pop "out" from the surface to color pixels "outside" the original geometry. When you have a stone wall, for example, on edge you can't make the stones pop "out". You can only make the grout sink "in"), and then when you look at concave edges (opposite of a cube -- the surface bends outward, instead of inward on itself -- like being inside the cube, rather than outside), they get a bit funky at the seams where the polygons line up.

Also, with the stock sunken-face cube demo, you can have faces apparently sink to where they'd logically intersect with other faces, but you won't actually see the intersection because each face's parallax is unaware of any other faces and their parallax.

and yet another interesting, informative response -- thanks. :)

And thanks for the reminder a few comments up -- I do tend to use sarcasm rather heavily, and that can be quite annoying/unhelpful. I'll try to find a way to make it more explicit when I'm not being serious.

this macro takes x/y/z/w and converts it to x/y/z, i was passing the w as an output to the macro, but thanks for bringing that to my attention as it i suppose it could get confusing as to what the w is for where in this case the w is not needed as an output so there really isn't any need to have that published although it is needed to make the calculation so it is a required input. here is an updated macro without the published output of w.