[Bf-committers] Viewport FX Design

Jason Wilkins jason.a.wilkins at gmail.com
Fri Jun 1 19:22:21 CEST 2012

On Fri, Jun 1, 2012 at 7:59 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> I can imagine an API where every matrix function specifies which of
> the 3 standard matrices it works on. If that's better or not I don't
> have a strong opinion, nearly all modifications are to the modelview
> matrix anyway, so there isn't much matrix mode switching.

I agree somewhat.  After thinking about it more I think that a global
mode switch is worthwhile to save the typing and clutter.  If we had
actual OO syntax I'd be more OK with doing it another way.  Then
again, if we can reduce all or most points that change the matrix to a
single function call it'd be better to not have a global mode switch
because that's a second call.

> If we are talking about a situation where the matrix is retained on
> the GPU, then it indeed makes sense to have this separation. Also for
> shaders it probably makes sense, more advanced GLSL code needs
> separate access to these.
> Though if this is about a matrix retained on the GPU, then the API for
> that would be quite different, I don't think it would be a matrix
> mode, but some sort of handle associated with Blender objects.

The view matrix would be a matrix mode, while the model matrices would
be in some kind of state array associated with the Blender objects.

>>> * "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
>>> 'local'.
>> I've written code many times where I needed to glGetFloat, add a
>> transformation to the beginning, then put the matrix back.  Having the
>> option to separate the model and view matrix probably eliminates that
>> pattern though because that is all I ever used that kind of thing for.
> I still can't think of any such situation, but maybe I'm
> misunderstanding what you mean here.

Ultimately I only need to implement what Blender actually uses.  A lot
of the points I tried to make were merely ideas about what could be
done.  I'm not clear yet on what exactly needs to be done.

> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list