[Bf-committers] NULL-like bgl.Buffer and related

[Quentin Wenger]

Hi, thanks for the answer.


-------- Original Message --------
Subject: Re: [Bf-committers] NULL-like bgl.Buffer and related
Local Time: March 1, 2016 8:59 pm
UTC Time: March 1, 2016 7:59 PM
From: significant.bit at gmail.com
To: matpi at protonmail.ch,bf-committers at blender.org


I'm not sure about the Python interface, but a zero offset for glVertexAttribPointer means "from the beginning", not "no offset". So None does not make sense here. Offset could be made 0 by default since that's a pretty common case.

Well I don't get the difference between "from the beginning" and "no offset" in this case... "no offset" = "no offset between actual beginning of array and beginning of reading" = "beginning of array = beginning of reading" = "read from the beginning", right? At least that's what I meant to say.

From OpenGL doc:
"pointer - Specifies a offset of the first component of the first generic vertex attribute in the array[...]The initial value is 0."

and

"pointer is treated as a byte offset into the buffer object's data store."

You are right, however, when saying that NULL/None doesn't make sense, conceptually. ITRW, though, mostly NULL is 0 pointer, so it does work nonetheless passing NULL or (void*)0 to the function. And on Python's side, ctypes.c_void_p(None) == ctypes.c_void_p(0), so when working with PyOpenGL both work, too.




Since Blender uses VBOs mostly and is moving more toward that direction this should be an unsigned integer offset in the API. The old interpretation of a main-memory pointer will be going away.

In this case "all we need" is to be able to pass an integer offset to that function which currently is nothing but useless in bgl - as bgl.Buffer do not mimic pointers but arrays (and this is general - all arguments of bgl functions which would take a pointer/array in C API are translated to Python as needing bgl.Buffer). Thus, some bgl functions - among which glVertexAttribPointer - cannot be used as of now as their only accepted arguments are meaningless.

Do you think this can be changed? Should we allow integers where currently only bgl.Buffer are accepted (this probably would'nt make much sense either, as most of the functions do use bgl.Buffer, i.e. need arrays and not pointers). Or only for certain functions, i.e. being smart...

Anyways this only affects bgl API - i.e. Python - as it is just a matter of translating data from Python to C. Blender's usage of OpenGL doesn't matter much here IMHO.






Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


On Mon, Feb 29, 2016 at 2:26 AM, Quentin Wenger <matpi at protonmail.ch> wrote:

Hi,

[not sure this best belongs to bf-committers or bf-python...]

I am currently developping an addon making heavy use of OpenGL/bgl (and BTW gpu.offscreen, which seems to do exactly what I was lacking for in terms of Framebuffers... thanks Dalai & reviewers!).

Still there is one only thing that seems not to work for me: bgl.glVertexAttribPointer. Reason for that is, I would use (void*)0 (or NULL maybe) as the last parameter in equivalent OpenGL/C code, that last parameter representing an offset in the buffer, which seems not to be possible currently with bgl.Buffer.

So I thought I'd need to implement a kind of special bgl.Buffer (maybe stored as a variable in bgl or even, static in bgl.Buffer) internally mapping to (void*)0 or NULL. But then I realized it could sometimes be helpful to specify other offsets, say (void*)4, etc.

At this point I decided it would be better to ask more people before diving in the code. ;-)

So, what do you think about that? Do you know about a workaround in bgl? Is the implementation of special bgl.Buffer a possibility?

Note that I do have a temporary workaround - OpenGL.GL.glVertexAttribPointer(..., ctypes.c_void_p(None)) in the middle of bgl code - but that's not very nice, uses external package, etc. Moreover, without such as special bgl.Buffer or any similar alternative the function bgl.glVertexAttribPointer simply is mostly useless.

Thanks,
Quentin
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers