So I was reading about scene graphs on Wikipedia, and the concept intrigued me.  It's kind of like what Galileo is supposed to be, but at a more general level.  You create various entities as nodes, and then the nodes can be "attached" to one another in any arbitrary arrangement (hence "graph" and not, say "tree").

The example in the Wikipedia article is that you might have a knight and a horse; the knight is attached to the horse so that when the horse moves, the knight does too.  But the awesome part is that this relationship is not rigid: you can detach nodes and reattach them elsewhere any time you wish (say, when the knight dismounts, he's detached from the horse).  This has the potential to be very powerful, and I'm really considering implementing something like this in minisphere.

Is anything like this in the current Pegasus specification?  If not, it's definitely something worth considering as a standard feature.

An intended feature of Galileo was allowing Groups to be nested. This would allow this kind of thing. It already allows the example you provided, but only because it has only a single level of organization.

I didn't find it really that necessary, and I never got around to figuring out multiple vertex shader passes in GL 4. So I never added that to the spec.

By the way, did I interpret the spec correctly vis-a-vis the x/y and rotX/rotY properties for Groups?  In minisphere rotX and rotY are done before rotation, x/y after.

rotX and rotY are relative to the vertices' positions, to rotate all points about. It doesn't matter what the x and y are, translation is applied after. So...

Code: [Select]

vertices = [{x:2, y:0}, {x:4, y:2}, {x:2, y:4}, {x:0, y:2}]

rotX = 0, rotY = 0, angle = 0, x = 0, y = 0
=======
R . 0 . .
. . . . . 
3 . . . 1 
. . . . .
. . 2 . .

rotX = 2, rotY = 2, angle = Math.PI, x = 0, y = 0
=======
. . 2 . .
. . . . . 
0 . R . 3 
. . . . .
. . 1 . .

rotX = 2, rotY = 2, angle = Math.PI, x = 2, y = 2
=======
. . . . . . .
. . . . . . .
. . . . 2 . .
. . . . . . . 
. . 0 . R . 3 
. . . . . . .
. . . . 1 . .

If you are using ancient GL-style translatef- and rotatef-style calls, you would need to do something like this:

Code: (c) [Select]

glTranslatef(group->x, group->y);
glRotatef(group->angle, group->x + group->rotX, group->y + group->rotX, -1.0f);

So roughly speaking, the theory, ignoring all technical concerns of what happens in what order (full disclosure: matrix math isn't really my forte), is that x/y is "where the group is drawn" and rotX/Y is "the point to rotate it around".  If so (and it looks like it judging by your diagrams) that's exactly what minisphere does, so I'm in the clear.

It's really a question of where the coordinates are relative to. rotX and rotY are applied to each Shape relative to the Shapes' Vertex coordinates (the same system that the coordinates' X and Y are in). a Group's X and Y are relative to the screen.

In a nested-group system, the only difference would be that the Group's X and Y would be relative to the parent group.

Would you want to use a nested Group model? I haven't really found much use for it, but it wouldn't be crazy difficult to do.

I would like to do it, yeah.  The only potential difficulty with nested Groups that I foresee is coordinating all the transformations, since transforms aren't commutitive...

Hm, it strikes me that, even more useful than nested Groups, would be matrix support.  This would generalize transformations in the same way Shapes and Groups already generalize rendering and allow translations, rotations, etc. to be applied in any order and any configuration.  See, because now that I think about it, the X, Y and angle properties actually seem kind of old-fashioned in this sense.

See, because now that I think about it, the X, Y and angle properties actually seem kind of old-fashioned in this sense.

But much more Sphere-like, in my opinion.

It's also of note that full shader support would also add full matrix support.

It just occurred to me that nested Groups might not work.  As far as I'm aware shaders can't be stacked, can they?  Only one can be in effect at any time.  So if transformations, etc. are done in the vertex shader, there's literally no benefit to nesting.