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: [email protected]
To: [email protected],[email protected]


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 <[email protected]> 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
[email protected]
http://lists.blender.org/mailman/listinfo/bf-committers
_______________________________________________
Bf-committers mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-committers

Reply via email to