WebGL-推和弹出矩阵的替代方法是什么？

Question

I read the following post about the push/pop approach when rendering is not really being required when working with a scene/graph "system" (reference link below).

I am just curious now, if no matrix push/pop is required, how does one render (and transform) a set of objects properly, like the ubiquitous example of a rotating Wheel & Bolts?

See reference: Does webGL contain push/popMatrix?

Answer 1

All that pushing and popping achieves is a matrix stack. All a matrix stack achieves is storage and restoration of a previous active matrix. So it's a convenient way to manage a scene for the same reason that a call stack is a convenient way to run a program but it's far from required.

So eg you might just have the camera matrix, M , and for each object i , the object matrix Oi .

Then to calculate the equivalent of GL's old MODELVIEW for each object in turn that's just the composition of M and Oi . No need to store or restore anything from a stack. You know M and you know Oi and that's all you need to know.

EDIT: eg for argument's sake suppose you were writing Battlezone . Then you'd have a bunch of objects on the play field. Each object would have a position and a rotation. One such object would be the player, to which the camera is mounted. You might draw the scene by (i) computing a view matrix from the player's position and rotation; then (ii) looping through every object on the play field, computing a model matrix from its position and rotation; and, for each, (iii) composing the two, posting the result to OpenGL and making such geometry calls as are necessary to draw the object.

No stack.

The same thing applies for any play field that's just a flat list of objects (aside: I'm ignoring broad phase model culling for simplicity).

Now suppose some objects are child objects, for whom position and orientation is defined only in terms of a parent object. In that case, whether you store it as one or not, you have a tree of objects.

One solution might be essentially identical to the Battlezone solution, whereby you iterate through every object in turn but now you do:

model matrix = identity
while(object is not root)
{
    compose model matrix with matrix for this object
    let object = parent object
}

So you're walking back up from child to root.

Still no stack.

Conversely, you could flip things around and just let the normal call stack be a stack implicitly:

draw object: object, parent matrix: parent matrix

    child matrix = composition of parent matrix and this object's matrix
    draw object

    for(children of object)
    {
         draw object: child, parent matrix: child matrix
    }

So there's a stack in there but it's the call stack.

Of course your tree doesn't have to be a formal tree data structure. In the Battlezone example you had an implicit tree where everything is a first-level child of the root. Similarly any other code structure could effect an implicit tree.