[Bf-committers] Viewport FX Design
Brecht Van Lommel
brechtvanlommel at pandora.be
Fri Jun 1 12:28:37 CEST 2012
Regarding matrix transformations:
* "There would be no need to change "modes" and more matrix stackes
could be created than the "standard" 3."
I don't understand this, why would you want more stacks, and how would
you avoid changing modes?
* "An option to separate modelview into "model" and "view" matrices
which remain valid until you change the modelview directly."
Also don't understand this, to me it seems the model and view
separation is nicely handled by matrix stacks.
* "Place lights either using the legacy method of using the current
modelview or using a custom matrix."
This seems to be a rare enough thing to do that we should just follow
whatever GL does, not try to make it nicer by adding an abstraction.
* "Concatenate transformations to the top or bottom."
I can't think of a situation where this would be a good thing to do.
It means you have to know something about what happened below in the
stack, if you follow the GL rules any transformation is nicely
Regarding the Start/Commit/Rollback idea, why not add the functions
gpuTranslateScale and glTranslateRotate, and just immediately apply
the transforms always. From looking through the code, that covers
nearly all cases, with a few places in the code that could construct
the matrix manually, and the remaining ones either not being
performance critical enough to bother avoiding the state change.
On Fri, Jun 1, 2012 at 11:11 AM, Antony Riakiotakis <kalast at gmail.com> wrote:
> In fact, if we ever go for a pure GL3+ core profile
> this is absolutely essential as the gpuMatrixTransformCommit
> (BLI_MatrixTransformCommit ?) call would need to probably calculate
> and bind an inverse matrix to the uniform buffer object as well.
Isn't such an inverse matrix is needed only for either normals or some
more advanced shading operation? I hope this would not be needed in
e.g. UI drawing code.
More information about the Bf-committers