Re: Registering a class that takes a float*

On 1/4/2011 8:13 PM, beo wulf wrote:
> I want to bind all of OpenGL. I don't want to have to individually
> wrap any OpenGL function that takes a GLfloat* .
>
> What does default_converter do? Does it solve the problem I'm facing?
If it is truly your intent to bind all of OpenGL, you cannot do it 
automatically. That's simply not possible. With Luabind, SWIG, or any 
other Lua-to-C++ tool you can use.

You are going to have to write at least some wrapper or interface code. 
Purely automatic binding isn't going to work. I'm speaking as someone 
intimately familiar with OpenGL, and reasonably familiar with various 
Lua interface tools.

Take a simple function like glGetFloatv(). This is a function that takes 
an enumerator and returns some number of floats. The number of floats 
returned depends entirely on the enumerator's value. And there are 
literally hundreds of possible enumerators.

How do you want glGetFloatv to look from Lua? For a Lua programmer, it 
would make sense for glGetFloatv to look like this:

local value = gl.GetFloatv(gl.SOME_ENUMERATOR)

The "value" will be a table, if it returns multiple values, or a number 
if it returns a single value. That's the most natural way to do this in Lua.

In Luabind, doing this without writing an explicit wrapper function is 
very difficult if not impossible. In SWIG, it's slightly easier, but you 
will still need to write a specific type wrapper to turn the input 
argument in C into an output argument. You'll also need to deal with the 
Lua C interface to turn the array of pointers into a number or a list, 
depending on how many values are returned.

So in both cases, you need to write some code.

And that's the easy stuff. Consider glVertexAttribPointer, and all of 
its relatives. These are vital for rendering if you're interested in 
anything remotely like performance.

When using client-side memory, glVertexAttribPointer takes, among other 
things, a pointer to actual memory. It will not work with a Lua table. 
So you will need some code that converts the user's data from a Lua 
table to a memory pointer. What's worse is that this memory needs to be 
*persistent*. It must continue to exist well after this call is over. So 
you need to allocate memory. And you need some way to manage that 
memory, since OpenGL won't manage it for you.

Now, if you're using buffer objects rather than client-side memory, you 
now need a way to deal with buffer objects. 
glBufferData/glBufferSubData, the functions for uploading data to a 
buffer, deal in real memory, not Lua tables. That memory needs to be 
formatted in a specific way, so that your later glVertexAttribPointer 
call is properly formatted. This is going to require a new kind of 
object, one that can work with blocks of memory at a low level.

WebGL, which is a JavaScript binding to OpenGL ES 2.0, had to deal with 
a lot of these issues. They couldn't just use SWIG or some other 
automated tool to do the binding. They had to invent new objects, write 
wrapper code, etc.

In short, the sooner you understand that doing what you want will 
require writing code yourself, the sooner you'll have written that code.

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl