Hi
Most (if not all) projection functions like glOrtho are preceded by
glLoadIdentity(). Therefore, I think to drop multiplication, and just write
to the current matrix.
Also, it easier to have gpuPopMatrix to call gpuMatrixCommmit() to
automatically restore previous state (at least for now).
For
On Fri, Jun 1, 2012 at 2:00 PM, Brecht Van Lommel
wrote:
> I just meant release / free the arrays, or whatever the API needs to
> do depending if it's using VBO's, vertex arrays, immediate/retained,
ok
>> Also, and most importantly, doing it the way you suggest requires that
>> the programmer re
On Fri, Jun 1, 2012 at 8:02 PM, Jason Wilkins wrote:
>> Basically the API will always be, allocate an array for each needed
>> attribute, fill up the arrays, and then give them back.
>
> Give them back? I'm not sure what you mean. We must assume that if
> the client code has a pointer to the buf
Although I have not committed it yet, I did test gpuImmediate by
porting a lot of the "heavy object" drawing code to use it. I could
not really tell any difference in speed subjectively. Interestingly
though, when enabling VBO, it was faster than using VBO in trunk. So
the preliminary results we
On Fri, Jun 1, 2012 at 9:05 AM, Brecht Van Lommel
wrote:
> I may be saying again what you already wrote, but let me give my view
> on the immediate mode emulation stuff. What we need:
>
> I think the current immediate mode emulation is a good start, but we
> can unify it with vertex arrays and VBO
On Fri, Jun 1, 2012 at 7:59 AM, Brecht Van Lommel
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
On Fri, Jun 1, 2012 at 4:05 PM, Brecht Van Lommel
wrote:
> gpuImmediateBegin(GPU_TEX_COORD|GPU_VERTEX_COLOR)
> gpuBegin(..)
> ...
> gpuEnd(..)
> gpuImmediateEnd()
To be more specific, the call may be something like this:
gpuImmediateBegin(GPU_TEX_COORD_3F|GPU_COLOR_4UB);
For the more complex mes
I may be saying again what you already wrote, but let me give my view
on the immediate mode emulation stuff. What we need:
* For OpenGL ES we need to avoid immediate mode.
* VBO and non-VBO mesh drawing in derived meshes needs to be unduplicated.
* Performance improvements by avoiding CPU overhead
On Fri, Jun 1, 2012 at 1:54 PM, Jason Wilkins wrote:
> On Fri, Jun 1, 2012 at 5:28 AM, Brecht Van Lommel
> The reason is because you could just directly address the matrix you
> want to use. It would be a more object oriented interface that does
> not rely on global state to know which matrix to
On Fri, Jun 1, 2012 at 5:28 AM, Brecht Van Lommel
wrote:
> 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 cha
> 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 manuall
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 "vie
Hi Jason, great stuff. Actually, if you think about it, matrix
multiplications are actually not graphics state strictly, but a
CPU-side transform. So I would maybe vote to actually -substitute-
such uses with regular BLI_math functions, or simply use a BLI matrix
state machine to do such tasks, if
I'm starting to realize that this document is going to be huge.
Getting it completely written may take several more days.
I added more details on replacing the OpenGL transformation stack
since Alex is going to start on that for OpenGL ES 2.0 compatibility.
On Thu, May 31, 2012 at 6:17 AM, Jaso
I'm starting to write up a better breakdown of Viewport FX here:
http://wiki.blender.org/index.php/User:Jwilkins/GSoC2012/Viewport_FX_Design
It is still very rough, but it looks like it is going to be pretty
long, so it is probably a good idea to let people see it as soon as
possible. Help me be
15 matches
Mail list logo
